Open WillIrvine opened 4 years ago
While it's not a focus at the moment to create VCs between interfaces. Adding a Virtual Circuit "mode" drop down and choosing between VLAN/MPLS which would then let you select interfaces vs VLANs seems reasonable. I'm not sure if we'll have time to complete that soon but we'd welcome a contribution to expand that!
+1 on this feature request, assigning subinterfaces (virtual) would suit much better as our circuits are terminated on multiple devices inside the same rack/site so the VLAN option does not scale past one device
Fantastic start however 👍
+1 and I agree with semaja2
Our Juniper network can have a virtual circuit, or "service" like VPLS that spans multiple devices, and terminates on either an interface or sub-interface (logical unit) - so this request would fit really well. The standard Netbox concept of a VLAN doesn't really work that well for routed networks where the VLAN X on one interface might be nothing to do with VLAN X on an other...
That usecase would probably also works to document our backup GRE and IPsec tunnels.
gr-0/0/1 on router1 is "connected" to gr-0/0/1 on router2 through VC1 Or even to 3rd parties (only know one side): only gr-0/0/2 on router1 uses VC2
I'm an engineer for an ISP and we are starting to use Netbox. We do alot of L2VPN and this virtual circuit plugin is a great but it's limited since it is based on vlans. A virtual circuit can span across multiple routers and have multiple interfaces(tagged or untagged) on each router, including virtual connections facing the core such as a MPLS pseudo-wire or an EVPN-EVI.
For the virtual circuit model to work in our environment we would need it to be based on vlan and/or interface. We could get by just adding the ability for interfaces.
If it were to be tailored for ISP environments it would also include:
Here is an bridge-domain example across three routers using MPLS:
Router01:
bridge-domain ACME_CUSTOMER_BD
interface Bundle-Ether20.45 <---vlan 45
interface BVI45 <---L3 routed interface
!
neighbor 2.2.2.2 pw-id 45 <---pseudo-wire ID for MPLS peering with R2
neighbor 3.3.3.3 pw-id 45 <---pseudo-wire ID for MPLS peering with R3
Router02:
bridge-domain ACME_CUSTOMER_BD
interface TenGigE0/1/0/2 <---untagged
interface Bundle-Ether60.45 <---vlan 45
!
neighbor 1.1.1.1 pw-id 45 <---pseudo-wire ID for MPLS peering with R1
Router03:
bridge-domain ACME_CUSTOMER_BD
interface TenGigE0/0/0/13 <---untagged
interface Bundle-Ether60.45 <---vlan 45
!
neighbor 1.1.1.1 pw-id 45 <---pseudo-wire ID for MPLS peering with R1
For EVPN you would simply replace the neighbor statements with a single EVI command under each bridge domain which would contain an EVI ID.
We would need to create a Virtual Circuit named "ACME_CUSTOMER_BD" and add all the interfaces above on all three routers. We could use the comments or custom field for the pseudo-wire ID (or in EVPN, the EVI ID). Then when the customer calls I can search by Tenant, Click on the Virtual Circuit stats, and then quickly find all interfaces which are a part of the L2VPN.
I don't know a good way to document the core facing elements(Pws, EVI, Tunnels) since technologies would vary across users of Netbox so I think it would be sufficient to document these via comments.
Adding interfaces would be a HUGE improvement. Thanks for your hard work in maintaining this plugin.
Hi vapor-ware team,
Great plugin. This is something I've been looking for in netbox for sometime. In an MPLS environment we generally pop the tags and create virtual circuits between interfaces / sub-interfaces. Would you look to expand the feature set to support the creation of VC's between interfaces? Or would you accept a PR that creates this functionality?
I understand if you would prefer to keep this plugin limited to your own use case, but happy to contribute should you be willing to expand it.
Thanks