Assign Multiple L2VPN / VPLS to a Single Endpoint

[kvedder-amplex]

NetBox version

v3.3.3

Feature type

Change to existing functionality

Proposed functionality

On our current routers, we can assign multiple VPLS circuits to a single interface. We cannot do this to VPWS interfaces. I would like to modify the restriction that limits a VPLS endpoint to a single instance/circuit.

Use case

It allows the modeling to align with the possibilities offered by vendors.

Database changes

I don't forsee any DB changes, I suspect modifying some python on model save is what restricts it to one circuit per endpoint currently. Changing the python to allow for more than one circuit if the type is VPLS shouldn't be awful. I am willing to put in the PR.

External dependencies

None.

[kvedder-amplex]

I see this in the model.

      # Only check if L2VPN is set and is of type P2P
        if hasattr(self, 'l2vpn') and self.l2vpn.type in L2VPNTypeChoices.P2P:
            terminations_count = L2VPNTermination.objects.filter(l2vpn=self.l2vpn).exclude(pk=self.pk).count()
            if terminations_count >= 2:
                l2vpn_type = self.l2vpn.get_type_display()
                raise ValidationError(
                    f'{l2vpn_type} L2VPNs cannot have more than two terminations; found {terminations_count} already '
                    f'defined.'
                )

This makes sense, as L2VPNTypeChoices.P2P includes:

     TYPE_VPWS,
        TYPE_EPL,
        TYPE_EPLAN,
        TYPE_EPTREE

The error I get is from:

     if self.assigned_object:
            obj_id = self.assigned_object.pk
            obj_type = ContentType.objects.get_for_model(self.assigned_object)
            if L2VPNTermination.objects.filter(assigned_object_id=obj_id, assigned_object_type=obj_type).\
                    exclude(pk=self.pk).count() > 0:
                raise ValidationError(f'L2VPN Termination already assigned ({self.assigned_object})')

[shatt79]

Here's the thing... by definition, a VPWS circuit is point-to-point. There is no MAC learning on a true VPWS circuit, so it can only be point-to-point. The ONLY types of virtual circuits that could qualify as VPWS are EPL and EVPL. EPLAN, EVPLAN, EPTREE and EVPTREE are point-to-multipoint circuits and would never be considered VPWS.

ALL VPWS circuits are either EPLAN or EVPLAN, but not all EPLAN or EVPLANs are VPWS. What determines that is the configuration on the device. On IOS-XR, a VPWS is built as a xconnect group. P2MPs are built as bridge-domains. You can absolutely build a P2P in a bridge-domain, but MAC learning will occur and by definition NOT be a VPWS.

So... the definitions in the model are wrong. It should say:

TYPE_VPWS,
TYPE_EPL,
TYPE_EVPL

TYPE VPLS,
TYPE_EPL,
TYPE_EVPL,
TYPE_EPTREE,
TYPE_EVPTREE,
TYPE_EPLAN,
TYPE_EVPLAN

[shatt79]

Also, if you want to use a single physical endpoint to terminate multiple virtual circuits, you must use a type of L2 circuit that begins with "EV", and you must use sub-interfaces. EPL, EP-TREE, and EP-LAN can only use physical ports as terminations.

EVPL, EVP-TREE, and EVPLs all use virtual/sub-interfaces with carrier ethernet tagging methods. Its what the MEF calls a multiplexed port. With this, you're not actually connecting the physical port to the L2VPN instance, but the logical/sub-interface. You can NOT attach a single physical or logical interface to multiple L2VPNs. Ever. Neither in Netbox or in the real world. Not without some intermediary device bridging the two LANs together.

[kvedder-amplex]

Well, let me define that a bit more. I was specifically referring to a physical interface, not a logical one.

[shatt79]

So yeah... that's by design then. A single physical port cannot be a member of more than 1 L2VPN or VFI. That would be the equivalent of an access port being a member of two VLANs.

[kvedder-amplex]

Then why am I currently using VPLS with multiple circuits configured on a single physical interface? I must be missing something.

Sanitized Config:

interface ge2
 description TO-SWITCH
 switchport
 mtu 9216
 mpls-vpls VPLS-LOCATION-1000 service-template VPLS-LOCATION-1000
  exit-if-vpls
 mpls-vpls VPLS-BNG1 service-template VPLS-BNG1
  exit-if-vpls
!

Ive seen the limitation you describe with VPWS, but not VPLS.

I am obviously not as familiar as you with all of the protocols and how they are designed. Go easy on me. I am more than willing to learn.

[baldgeek]

We also output multiple VPLS vlans on a single physical ports. You aren't doing anything unusual.

…

On 9/19/22 4:13 PM, kvedder-amplex wrote: Then why am I currently using VPLS with multiple circuits configured on a single physical interface? I must be missing something. Sanitized Config: |interface ge2 description TO-SWITCH switchport mtu 9216 mpls-vpls VPLS-LOCATION-1000 service-template VPLS-LOCATION-1000 exit-if-vpls mpls-vpls VPLS-BNG1 service-template VPLS-BNG1 exit-if-vpls ! | Ive seen the limitation you describe with VPWS, but not VPLS. I am obviously not as familiar as you with all of the protocols and how they are designed. Go easy on me. I am more than willing to learn. — Reply to this email directly, view it on GitHub <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnetbox-community%2Fnetbox%2Fissues%2F10404%23issuecomment-1251501514&data=05%7C01%7Cjos100%40psu.edu%7Ca499ae9ea43644d94a5908da9a7b6570%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637992152013879042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zby%2FVf86ErC4DORE2RUDk7MXRrIEsE%2F9s%2BZMDlLfh5o%3D&reserved=0>, or unsubscribe <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANYW3MLAKNGDXSLMOYZRMYDV7DCN7ANCNFSM6AAAAAAQQFC2T4&data=05%7C01%7Cjos100%40psu.edu%7Ca499ae9ea43644d94a5908da9a7b6570%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637992152013879042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OsdCqVN%2FOZJCjpsBVHUvMmACP10JtiEvzBL8idl5joI%3D&reserved=0>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[DanSheps]

What does your service template say?

It is likely defining a subint within that service template.

It would be weird for you to be terminating multiple VPLS' directly to the physical port, likely you are terminating to a service instance or subint.

[shatt79]

There has to be SOMETHING on the interface that identifies the unique traffic that belongs to specific L2VPNs/bridge-domains. Think about from an ingress perspective: How does the interface know what frames to place on each L2VPN/EVC/bridge-domain? In most cases, that is done through the matching of 1 or more VLAN tags.

This is the interesting part of your config:
mpls-vpls VPLS-LOCATION-1000 service-template VPLS-LOCATION-1000
exit-if-vpls
mpls-vpls VPLS-BNG1 service-template VPLS-BNG1
exit-if-vpls

The interface is referencing two different service templates. What is defined by those templates? I'll bet that if you dig into the config you'll find them and there will be unique VLAN/tagging information for each. It'll probably have something like a "match" command. Eg, "match outer tag 123" or something along those lines.

Even though the config is a little bit different than the traditional Cisco/sub-interface model, its still essentially multiple virtual interfaces under the single physical interface.

Here are three examples of how different vendors do this. There are two from Cisco, and one from another vendor that appears to be what you're using:

Cisco IOS-XR model (sub-interfaces):

interface gi0/0/0/0
mtu 9216
no shut
!
interface gi0/0/0/0.10 l2transport
encapsulation dot1q 10
rewrite ingress tag pop 1 symmetric
!
interface gi0/0/0/0.20 l2transport
encapsulation dot1q 20 second-dot1q 5
rewrite ingress tag pop 2 symmetric
!
l2vpn
bridge-group L2VPNs
bridge-domain CUSTOMER_ABC
interface gi0/0/0/0.10
neighbor 10.20.30.40 pw-id 12345 encapsulation mpls
!
bridge-domain CUSTOMER_XYZ
interface gi0/0/0/0.20
neighbor 10.20.30.40 pw-id 67890 encapsulation mpls

Cisco IOS-XE model (service instances):

interface gi0/0/0
mtu 9216
no shut
service-instance 10 ethernet
encapsulation dot1q 10
rewrite ingress tag pop 1 symmetric
bridge-domain 20
service instance 20 ethernet
encapsulation dot1q 20 second-dot1q 5
rewrite ingress tag pop 2 symmetric
bridge-domain 20
!
l2 vfi CUSTOMER_ABC manual
vpn id 12345
bridge-domain 10
neighbor 10.20.30.40 12345
!
l2 vfi CUSTOMER_XYZ manual

Your model (service templates):

interface ge2
mtu 9216
switchport
mpls-vpls VPLS-LOCATION-1000 service-template VPLS-LOCATION-1000
exit-if-vpls
mpls-vpls VPLS-BNG1 service-template VPLS-BNG1
exit-if-vpls
!
service-template VPLS-LOCATION-1000
match outer-vlan 10
rewrite ingress pop outgoing-tpid dot1q
!
service-template VPLS-BNG1
match double-tag outer-vlan 20 inner-vlan 5
rewrite ingress pop outgoing-tpid dot1q

Same config, different vendors. But its exactly what I stated before: multiple logical interfaces under a common physical interface. The vendors just handle them a bit differently. You simply can NOT have multiple L2VPNs/broadcast domains terminate to a single physical port. You just can't. It violates all the rules of ethernet and L2 switching. Think about it: If you had multiple L2VPN/bridge-domains terminating to a single physical port, then every one of your customers attached to that physical port would be receiving copies of every frame on every L2VPN/EVC terminating to that port. I won't even talk about the loops you'd have...

[vincentschuele]

I believe the request is to map VPLS/VPWS instances to subinterfaces on one physical port. This is supported on most vendors.

[DanSheps]

I believe the request is to map VPLS/VPWS instances to subinterfaces on one physical port. This is supported on most vendors.

Sub-interfaces are already available for assignment for specifically the reasons stated above by @shatt79

[DanSheps]

So, I did a little research on the config.

It appears this is for microtik.

Here would be a full config:

mpls vpls TEST 10
 signaling bgp
  ve-id 10
  exit-signaling
 exit-vpls
!
service-template TEST
 match outer-vlan 10
!
interface xe2
 switchport
 mpls-vpls TEST service-template TEST
  exit-if-vpls

How this should be modelled in NetBox:

(1) Physical Interface (xe2 as a tagged port)
(1+) Virtual Interfaces (x2.10, tagged port with vid 10 as the allowed tag -- tagged/untagged could all be viable here)
(1) VPLS L2VPN: TEST, Identifier: 10
(1+) L2VPN Termination (Interface xe2.10)

All this being said, I do not believe this is a valid FR as it does not meet real-world implementation details. I am going to convert this to a discussion. You are free to re-open an issue once this is more fully fleshed out, if there is anything to flesh out.

[MarianRychtecky]

Hi everyone,
Is there any conclusion on this request/discussion/issue? In our use case (EVPN/VxLAN), we need to terminate multiple VNIs on the same interface as dot1q-tagged VLANs. Could that be done?

[DanSheps]

Can you give a config snippet? What platform are you trying to model?

[DanSheps]

Just re-read your commennt

Terminating VLAN to a single device cannot give you any attributes.

Custom fields are available I believe on the termination endpoint itself (the link between the port/vlan and the L2VPN

I need to create a specific relation (with specific attributes, such as MAC address and ID) between Interface (such as Eth1/1) and multiple VLANs (100,200,300) OR between Interface (Eth1/1) and L2VPNs (EVPN VNIs, 10100,10200,10300), where VNI needs to be PtMP.

The interface can serve multiple L2VPNs (VNIs) as a "switchport mode trunk" (no sub-interfaces). Each relation between the physical port and the L2VPN (VNI) needs to have specific parameters - like MAC or ID (this can be done using Custom Fields). MAC is important in order to configure MAC ACL per VLAN and Interface.

This is a prime use-case of termerinating to a VLAN. You aren't doing anything special with the specific interface, except for the MAC ACL, which is goingn to be outside of the scope of NetBox. It sounds like the L2VPN (sounds like VxLAN EVPN) is global on the switch and the switch is the endpoint for the VxLAN itself.

If there is an option to add multiple L2VPNs to the interface, we can manage to save attributes like in this example: This solves our demand, unfortunately for one L2VPN per port only.

This won't likely be happening any time soon. The complexities are too difficult to manage and you lose the "dot1q" tag mapping without doing subinterfaces.

Again, if you could send me a config snippet (sanitized) I can definitely help you figure this out, but what is in place should hopefully catch 90% of the use-cases out there (SP use-cases with service interfaces/templates aside). It is also possible we are missing a whole use case and that is where seeing an actual config will help

[MarianRychtecky]

Hi Dan, would you mind if I will send you a private email with details? I appreciate your help.

[DanSheps]

That is fine, if you are on Slack I can send you the email over slack, just message me.

Otherwise, let me know

[MarianRychtecky]

Hi Dan,
Is there anything new about this feature request? We are in high demand for terminating multiple L2VPNs on the Interface/port channel. Could we propose a merge request or share a detailed proposal with you?

Thank you, Marian