mzbroch
commented
5 months ago I can build a BGP peering to a peer endpoint that is not a device object. This would make the provider / provider network models have more value, and would make the BGP plugin make a lot more sense.
This is supported as of today - You can model a peering between two IPs if external devices are not modelled in Nautobot. In case an IP is assigned to a modelled device, Routing Instance has to be modelled too for consistency.
aetherrealm
As ...
Austin - Network Automation Engineer
I want ...
To be able to cleanly define BGP peerings to 'services' which do not fit well into devices that would be added to Nautobot such as providers or affiliates whose networks are outside of our management scope.
So that ...
I don't have to create dummy device objects with bogus information so that I can use the BGP plugin to automate routing configs via GraphQL.
For example, say I want to include 3rd party BGP peerings in the data I get from my GQL query... To do this I create a placeholder device. So when you go to create a new device, what is the manufacturer, serial #, device type, platform, software version, etc of the carrier side? Could you know all that information? This is not a good solution and makes Nautobot messy.
I know this is done when...
I can build a BGP peering to a peer endpoint that is not a device object. This would make the provider / provider network models have more value, and would make the BGP plugin make a lot more sense.
Optional - Feature groups this request pertains to.
Database Changes
The provider model needs to have ASN removed because providers often have multiple ASNs, so a single one is insufficient. Also, rename this to Provider/Partner (or some other wording) since you can use this same model for 3rd party connections that aren't necessarily providers (affiliates, subsidiaries, etc).
ASN should be moved to Provider Network instead so that AT&T, for example, can have multiple provider networks, each with it's own ASN. The ASN should also be a relationship to an ASN object defined in the routing plugin (which currently is one way ASN -> Provider, but the ASN you define on a provider is just a text field...). Furthermore, in the circuit termination view, even though the table shows IP addressing for Z side if a provider network is used, we're unable to assign IP addresses to a Provider Network. Provider networks should have Peer Points (one to many relationship) such that a provider network has IP addresses directly assigned to it representing the various BGP peer IPs you may peer with them on.
This means the IP addresses model needs to be assignable/related to this model as well.
Now, in the BGP peering view we should be able to set a Provider Network Peering Point as the Z side, which would derive the ASN from the Provider Network, and allow you to select the source IP. This would avoid creating Routing Instances for devices that you have no visibility into and wouldn't be privvy to their peer groups or other settings.
The IPs and ASN should not be mandatory as not all circuits are L3, such as an EVPLS circuit where you have many different circuits all terminating to the same Provider Network, however your BGP peerings might be between only your own devices.
External Dependencies
N/A