search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.83k stars 2.54k forks source link

Assign ASN to prefix and device #8782

Closed PieterL75 closed 1 year ago

PieterL75 commented 2 years ago

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.

The assignment for prefixes should be one2one

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

External dependencies

No response

jeremystretch commented 2 years ago

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 commented 2 years ago

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] commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

nickper commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

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

Possible Solution 1

Possible Solution 2

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] commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

PieterL75 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jeremystretch commented 1 year ago

If you consider use cases beyond your own it will make sense.

PieterL75 commented 1 year ago

If you consider use cases beyond your own it will make sense.

I know :-) just found it one of the funny things in Netbox..

Kind of the same that it makes sense to link ASNs to Devices, Prefixes and Aggregates, I guess.. There are use cases for that (which I use daily)

peterbaumert commented 1 year ago

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.

Yeah but concerning the reasoning given here that should also have been reasoned back then to put it in a plugin.

Best outcome would be to model all in core anyway :)

jeremystretch commented 1 year ago

Any further discussion on this topic is unlikely to be productive and at this point I can only repeat points that I've already made, so I'm closing this. I encourage anyone interested in the functionality discussed above to actually try building a plugin as has been suggested and publish it for review by others. Maybe then the considerations I've enumerated above will become more clear.