First off, happy 2024 … may this coming year be one of happiness and health.
In this blog we talk about L3VPN in NetBox and specifically whether (via a plugin) we could improve the visibility aspects.
What is L3VPN
Fundamentally L3VPN is a way of virtualising a layer3 network. A separate routing table per instance meaning a (usually) service provider can have multiple customers across their core without cross contamination with other customers. Think of this as layer2 (or vlans) for routing, configured as VRF (virtual routing and forwarding) instances.
Components of a L3VPN
Traditionally an SP core will transport L3VPN’s across its core transparently, with ingress of egress at specifically configured points – ie: a hub, connecting to maybe a colo customer, with spokes at various NNI points for circuits or other sites.
If we consider full blown VRF as opposed to VRF-lite (per device, not linked to an MPLS core) then the individual components within a VRF roughly consist of the following components
- Route Distinguisher (RD) – the effective ID for the VPN
- Route Targets (import and exports) – what routes we import and export
- Instances – effectively configuration on the above on a device level, the ingress/egress
- IP info (interfaces, routes, routing protocols, etc) to enable the connection
How NetBox models this
Its worth a reminder at this point that NetBox origins were a DCIM rather than network automation SoT. With this mind, NetBox attempted to document this rather than delve into how this would be directly configured so we shouldn’t expect this out of the box to be able to cater for every aspect.
Starting with the IPAM > VRF object:
So we have a main definition, RD, Tenant, IP Space (alongside prefixes), and Import and Export targets (which are multiple objects). Defining certainly the RD in a ‘global’ context is exactly where it should and likewise this gives us a fantastic starting point further expanded via route targets:
Hence we have immediate visibility of which targets are imported/exported and some metadata to describe the targets purpose via description and comments.
Whats Missing ?
Now, there are many ways to further document the VRF – config context/local context is a way to do this – but it’s not really object modelled in the way we are other things – so lets consider this as an object model.
I’m going to specifically exclude the BGP components here – because this would expand the scope of this and realistically we’d expand on one or more of the existing (and excellent) plugins rather than redefine the wheel here. Indeed certain plugins already are ‘VRF’ aware, the static route
To bullet point this:
- Instances – typing a VRF to specific device
- Interfaces – whilst netbox includes VRF within prefix and IP addresses, there isn’t a way to specifically tie an interface
We should note, you could look this up via the IP, it IS possible, it’s a very long way of doing this – ideally we’d want to see which devices the VRF is configured on directly and which interface reside within it. Theoretically, this would also be possible via Custom Fields, eg: device -> custom field -> multi-model -> VRF … but, personally, I prefer real modelling rather than hacking on custom fields which are effective workarounds… where we need to specifically extend core models.
I’ve already mentioned VRF instances. This should seem to be a logical starting point, ideally we also need to say which interface or interfaces are tied into this.
One of the things net-ops folks sometimes forget is we have to consider the business elements of this. So the question also becomes – what is the product, what would you sell and can we be inclusive of that at this point.
If we consider customers, a customer will buy a ‘virtual network’ with ‘connections’ to that network. From a business perspective, it may or may not be a circuit, but for net-ops engineers, it certainly would be interfaces / IP’s etc (the latter we can die to a vrf, but NOT a connection, or instance)
This model ties a specified VRF to a specified Device. We also have override fields from the global VRF model – why ? in case we specifically want to import/export into other VRF’s on a per device level (ie: to VRF-lite).
The VRF connection ties in vrf and instance alongside interface – yes there’s lots MORE we could include here but this gives the basics
In simple terms, a VRF has many VRF instances, and likewise a VRF Instance has many VRF connections, in this way we can see exactly what VRF’s are configure per device (by displaying this on a device page) and go from there.
What Next ….
In part 2, we’ll write a plugin to create these very objects….