Assign ASN to prefix and device

[PieterL75]

NetBox version

v3.1.7

Feature type

Change to existing functionality

Proposed functionality

We would like to be able to assign an ASN to device(s) and prefix(es).

Use case

Our public IP ranges are announced under different ASN's. In order to keep track of what Prefix belongs to what ASN, we need to be able to assign the prefix to an ASN.

Next we have ASN numbers assigned to a device in our VXLAN networks. For this we need to be able to assign an ASN to device.

The assignment for devices should be many2many.

• a device can have many ASN
• one ASN can belong to many devices

The assignment for prefixes should be one2one

• one prefix can only be assigned to one ASN
• one ASN can contain many prefixes

Aggregates should contain a readonly,dynamic field that summarizes the ASN's of the prefixes that belong to it.

Aside of the request : In my opinion, assigning ASN's to a site is a little unlogical. It seems more logical to only be able to assign the ASN to a device/prefix and the site inherits the ASN assignment from the device/prefix A Site could have a similar readonly dynamic populated field that shows what ASN's are used in the devices/prefixes of that site.

Database changes

• Add ASN relation to devices
• Add ASN relation to prefixes

External dependencies

No response

[jeremystretch]

Sounds like a good use case for custom object fields in v3.2. I don't think it makes sense to bake into the core data model though.

[PieterL75]

I tend to disagree on this.. an AS is related to prefixes and devices, not physical sites Currently I have to jot down the AS number in the description of the RIR (that I use as ASN per LIR) and document the AS usage like that.

Custom fields are an option in v3.2, but I do feel that the datamodel should reflect the real usage of an ASN

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

[peterbaumert]

I agree with @PieterL75 as ASNs, prefixes, devices are already part of netbox it makes sense that one can actually tie them together properly, Currently i can add a Site for an ASN or add it to a RIR. But at least the Sites part is not accurate, so why not change this to actually reflect real world usage?

[DanSheps]

Real world, they aren't tied to prefixes either, they are tied to routing instances on devices, so I can see the use case for a device, but not for a prefix.

As Jeremy mentioned, this can be achieved with custom object fields.

[PieterL75]

I tend to disagree an that Daniel. Public ip addresses are bound to asn numbers (RIR/LIR) Internally we also assign prefixes to asns...

And a asn is used on a device, not assigned to it. One device can have multiple asns ( different vrf, underlays, overlays, ...)

[jeremystretch]

Public ip addresses are bound to asn numbers (RIR/LIR)

There is no direct correlation between the two types of records. A prefix can be advertised via any ASN belonging to the organization to which it has been allocated.

[PieterL75]

Prefix are bound to ASNs and will they only be announced over one AS (in most use cases). Typically you'll create a ROA (RPKI) record to digitally sign the link between an prefix and an AS, so that it cannot be announced by any other AS than the one you own.

I don't see many use cases to announce one prefix with multiple ASN's (except for migration and anycast purposes)

[PieterL75]

I don't understand why this FR is such a problem. It reflects how ASN really work for ISP's and MSP's. How can I keep track in netbox of what prefixes we announce under what ASN ? How can I keep track of what device has what ASN in my ebgp vxlan underlay ?

[jcralbino]

In a modern datacenter the BGP is also used provide connectivity to other routing devices, one use case is this one https://datatracker.ietf.org/doc/html/rfc7938

Even in a Datacenter where ACI is deployed is the recommended option for External Connectivity integration with other routing devices.

I believe we that assigning ASN to a device is something to be part of the Core in order to model real modern data center environments.

[PieterL75]

@jeremystretch can you remove the pending closure tag? This does feel like there is traction from the community to have asns relate to devices and prefixes

[DanSheps]

I don't understand why this FR is such a problem. It reflects how ASN really work for ISP's and MSP's. How can I keep track in netbox of what prefixes we announce under what ASN ? How can I keep track of what device has what ASN in my ebgp vxlan underlay ?

To be very blunt, no it doesn't; at least not to prefixes (devices I can see). What you want is something that models routing.

@jeremystretch can you remove the pending closure tag? This does feel like there is traction from the community to have asns relate to devices and prefixes

There is 1 upvote on the main description, this isn't traction from the community.

[jeremystretch]

There are two components to this FR:

1. Relating prefixes to ASNs
2. Relating devices to ASNs

Regarding the first part, as I noted above, there is no direct relationship between a prefix and an ASN in reality; the ASN(s) associated with a prefix are a function of the devices/sites advertising it. So, we're not going to implement this.

Regarding the second part, while I agree that it makes sense to model a relationship between devices and ASNs, more consideration needs to be invested into how and when this should be implemented. I don't think it makes sense to introduce a direct relationship now without any planning with respect to potential future modeling of routing adjacencies and policies. (For example, a BGP router may be configured to advertise different ASNs to different peers. Your proposed implementation would not support this.) This is part of a much larger discussion we have yet to hold concerning the modeling of routing topologies in general.

Of course, if you want to model direct relationships between ASNs and prefixes or devices right now, you can do so in NetBox v3.2 using custom fields.

[PieterL75]

Prefixes are linked to ASN's... ex: https://bgp.he.net/AS16591#_prefixes This is in the ISP/MSP world of course. I can imagine that most companies take public IPs from ISP and don't care about the ASN their prefix is linked to. In our case that is real world, and I can imagine that there will be a lot of future customers that think the same.

One device should be able to contain multiple AS numbers. Each VRF/RI can have its own AS, and you can also 'pretend' to be another ASN.

I do follow that you see this as a part of a bigger discussion to implement routing/asn/route protocols/... more detailed.

Too bad that you as maintainer downvote this discussion. We can/may/must differ on opinion.

I'll take the customfield approach for now, but that one lacks the searchability and deeper insigths.

Pieter

PS: I'm not native English, so please don't think I'm rude or anything... Just trying to express my thoughts :-S

[jcralbino]

Although I would like to have this implemented in netbox , association of a BGP ASN to device I do understand that providing only they it may lack in providing what will be a

future modeling of routing adjacencies and policies

I have stumbled at some point on this tool Peering Manager, that is sharing the same technology stack , being a django app.

Maybe it could be interesting to see how netbox and Peering manager can integrate better and complement their models

Here is one of the discussion within that project that may be relevant here

https://github.com/peering-manager/peering-manager/discussions/498

[jeremystretch]

I think further discussion is needed to figure out where this overlaps and/or conflicts with #9828.

[nickper]

I'm also throwing my opinion into this. For us an assignment to an device is not good enough. We actually do ASN rewrites in our core router for our clients. For now we use the solution of a custom field on the aggregate where we note the ASN.

Problem is that on our new stredged DC platform that uses a bgp overlay with different asn's per pop, and the private 10.x.x.x space for between pop communication. This custom field setup doesn't suffice anymore.

A coupling to prefixes would be nice to have in that case. (as an optional field ofc)

When I look to RPKI in relation to Aggregate/prefixes, I would say that it is better to relate it to Prefixes instead of aggregates. I see aggregates as ranges provides by the LIR, which in turn can turned into smaller Prefixes/subnets for their respective purposes. These can have different ASN's, most specific announcements etc. So a linkage between RPKI and prefixes would also be more logical.

[ThomasADavis]

I just opened an issue for this, not realizing it's already under discussion..

We need ASN's assigned to devices for VXLAN/EVPN usage. Spines have the same ASN - and there can be multiple spine switches. Leafs need their own ASN assigned, different from the each other and the spines.

I simply would like to see the ASN's assigned to devices show up on the devices page..

Currently using the custom field with the ASN object, but there's no way I know of to have the custom field show both in the device view and the ASN view. Assigning multiple objects to the custom field assigned objects/models doesn't tie the ASN object custom field to the device object custom field - they are two different custom fields.

[cyberndj]

Howdy, I was going through our company and our IPAM info doing some adds arround ASNs, Aggregates and Prefixes and I would like to share my thoughts. For context, here is how I am viewing the following terms:

RIR - An agency that assigns Aggregates/Prefixes and AS-Numbers to companies. ASN - a collection of connected (IP) routing prefixes Wikipedia Aggregates - A collection of different IP Prefixes Prefixes- A collection of specific IP addresses in sequence Providers - A company that owns/controls different ASN's and/or Aggregates/Prefixes

• The NetBox BGP Plugin (https://github.com/k01ek/netbox-bgp) can be a good plugin to help managing the more detailed requests from others regarding what ASNs/Prefixes are being assigned to a device and how they are peered/configured with other ASNs/Devices. The plugin might also be a better place for RPKI's/ROI's than NetBox Core. I believe the plugin was recently updated to use the NetBox Core Prefix/RIR/Aggregates/ASN items vs its plugin specific items.
• When I added Aggregates I noticed that the different prefixes I had configured showed up in a usage view like prefixes with child objects.
• Aggregates and ASN's both require a RIR to be configured.
• While looking at RIRs, only Aggregates show up, but not ASNs.

Some things that make me go hmmm......

• I have seen a Prefix be apart of two different ASN's ie, a /29 is part of ASN for a regional ISP (ie a /22 Aggregate), but also falls into a parent ASN for a more national company like Century Link (ie a /13 Aggregate)
• Similar observation, in @PieterL75's Google Fiber link, there are two Aggregates (136.58.96.0/19 & 136.32.0.0/11) listed for the same prefix (136.58.112.0/20) listed for the same ASN (16591).
• NetBox Aggregates do not support parent/child relationships like prefixes do.
• I don't see any assignment of ASN's to Providers.

Possible Solution 1

• Assign Aggregates to ASNs and/or Providers (/ipam/aggregates/#/edit)
• Have ASN's show up as assigned in RIR's and Providers
• Allow parent/child Aggregates

Possible Solution 2

• Remove Aggregates completely.
• Add option for Prefix status to be Aggregate (/ipam/prefixes/#)
• Allow Prefixes to be assigned to ASNs and/or Providers (/ipam/prefixes/#)
• Show an assigned ASN section under Providers (/circuits/providers/#)
• Show a section of Prefixes for ASNs (/ipam/asns/#)
• Move RIRs and ASNs to Prefixes section in the side menu

I also noticed that the ASN field for Providers has a depreciation note. That is a good touch and possibly can be done if solution 2 is accepted.

I know this might not appease all use cases or be a perfect solution, but hopefully it will get us all closer to real-world usage. Thanks! -Jake

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[nickper]

@cyberndj I think for some of your findings you should create an bug report.

For reference to the rest, I tested the custom object links in v3.3.10 (already released in 3.2) and that seems to be sufficient for me. It is a better solution than a custom field.

[tgreer]

Can I just add that assigning ASN to Prefixes is most sensible. I have multiple devices advertising the same routes under the same ASN, sometimes in different sites.

[jeremystretch]

After reviewing this yet again, I'm convinced it does not make sense to implement any of the proposed relationships directly among ASNs, devices, and prefixes, because doing so ignores the very real implications and caveats of routing policy. A device, for instance, can advertise different prefixes as originating from different ASNs. Conversely, a prefix can "belong" to one ASN or to multiple ASNs: Either condition can be valid or invalid depending on the configured policy. An implementation which purposely ignores these details precludes a great degree of functionality and would be a disservice to our users.

Instead, I propose that these ideas be implemented in a separate plugin expressly designed to model routing policy. We can achieve much greater flexibility by introducing an intermediate object representative of routing policy to correlate ASNs, devices, and prefixes, while simultaneously unlocking additional functionality around routing metrics, filter lists, etc.

[jeremystretch]

#11844 was raised to propose the assignment of ASNs to aggregates as well. Folding that into this discussion.

[PieterL75]

Lets get the discussion going then. I would like to the possibility to link an ASN to

• device
• prefix
• aggregate

Justification Device: In EVPN each device is assigned a dedicated ASN. This ASN is used in config generations for EVPN

Prefix: We have several ASNs that announce their prefixes to the internet. Being able to assing an ASN to a prefix, helps us to document this. These prefixes are also linked to the ASN in the LIR portals (RIPE)

Aggregate: Aggregates are super-prefixes that are handed out by a LIR. In the LIR portal, these aggregates are typically linked to the owners ASN.

I noticed that there is plugin request for ROA records. Implementing this FR, would benefit that plugin to only store the ROA records, and not the ASN logic

[DanSheps]

Honestly, I think that all of these "Routing Policy" settings should be in a plugin. It makes the most sense as not everyone will want/need to model routing policy.

[peterbaumert]

Honestly, I think that all of these "Routing Policy" settings should be in a plugin. It makes the most sense as not everyone will want/need to model routing policy.

But then everything else regarding routing, like RIRs, ASNs, etc should be remove from core as well. So either model all or none in core and the rest to a plugin.

[cyberndj]

Howdy, Some thoughts...

not everyone will want/need to model routing policy.
I think that this is a bad take because essentially, you (aka devs) are making an "forced-out" approach onto everyone. For those that don't want to do this type of modeling, the answer is to just not to make the association.

While the plugin idea is an option, the suggestion to move it comes across as...laziness to make the best product available. Like @peterbaumert put it

either model all or none

...but by adding the models/relationships, you are supporting the plugins to do more of their routing specific stuff by making the core models standardized.

The core premise of NetBox which is "the leading solution for modeling and documenting modern networks" and "the ideal 'source of truth'". Adding the relationship will let different companies model what their networks are and help solidify their own network truth. For those that don't want to utilize the relationships, they don't have to. Therefore, the "opt-in" approach should be implemented.

v/r Jake

[jeremystretch]

But then everything else regarding routing, like RIRs, ASNs, etc should be remove from core as well.

These were added to address unrelated use cases.

[PieterL75]

Still wondering why an ASN can be linked to a Site... Never saw a building with AS12345 on it :-)