Request for VLAN-Aware EVPN implementation

[IgorAlov]

The main problem of interop Juniper and FRR (Version > 7.4) is different EVPN implementation, Juniper uses VLAN-Aware (rfc7432 sec 6.3), but FRR uses VLAN-Based.

When FRR started to use Ethernet Segment (version 7.5.1 and greater) interop Juniper and FRR fail, because Route Type-1 has different RT.

According to this Juniper's document Route targets are used to identify the different routes that are imported and exported into the VRF tables. When you enable the auto-derived route targets option , Junos derives the route targets based on the EVPN encapsulation for EVPN route type 2 (MAC/IP Advertisement Route) and EVPN route type 3 (Inclusive Multicast Ethernet Tag route). The route targets for remaining EVPN route types are not auto-derived.

Juniper's output: Type-1: show route advertising-protocol bgp 100.100.101.2 match-prefix 1:100.100.100.11:0::050000fde8000186ad00::FFFF:FFFF/192 detail

bgp.evpn.0: 6070 destinations, 36113 routes (6070 active, 0 holddown, 0 hidden)
* 1:100.100.100.11:0::050000fde8000186ad00::FFFF:FFFF/192 AD/ESI (7 entries, 1 announced)
 BGP group evpn type Internal
     Route Distinguisher: 100.100.100.11:0
     Route Label: 1
     Nexthop: 100.100.100.11
     Localpref: 100
     AS path: [65000] I 
     Communities: target:65000:1 encapsulation:vxlan(0x8) esi-label:0x0:all-active (label 0)
     Cluster ID: 21.21.21.21
     Originator ID: 100.100.100.11

Type-2: show route advertising-protocol bgp 100.100.101.2 match-prefix 2:100.100.100.11:1::100013::00:00:01:00:00:13::10.0.5.1/304 detail

bgp.evpn.0: 6070 destinations, 36095 routes (6070 active, 0 holddown, 0 hidden)
* 2:100.100.100.11:1::100013::00:00:01:00:00:13::10.0.5.1/304 MAC/IP (7 entries, 1 announced)
 BGP group evpn type Internal
     Route Distinguisher: 100.100.100.11:1
     Route Label: 100013
     ESI: 05:00:00:fd:e8:00:01:86:ad:00
     Nexthop: 100.100.100.11
     Localpref: 100
     AS path: [65000] I 
     Communities: target:65000:268535469 encapsulation:vxlan(0x8)
     Cluster ID: 21.21.21.21
     Originator ID: 100.100.100.11

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot[bot]]

This issue will be automatically closed in the specified period unless there is further activity.

[IgorAlov]

Can you realize feature? Do you have any update on it?

[volga629-1]

+1

[flashover]

@IgorAlov in JUNOS is the MAC-VRF a potential solution for you? Then you can use the VLAN-based approach. Or alternatively, use the set protocols evpn vni-options vni 100013 export target:65000:1?

[robertlynch3]

@IgorAlov in JUNOS is the MAC-VRF a potential solution for you? Then you can use the VLAN-based approach. Or alternatively, use the set protocols evpn vni-options vni 100013 export target:65000:1?

You'd need to do that on every leaf that is participating in that VNI. Juniper's implementation of VLAN-Aware allows for the almost zero configuration on the leaf side other than defining the VNI to vlan mapping.

[IgorAlov]

@IgorAlov in JUNOS is the MAC-VRF a potential solution for you? Then you can use the VLAN-based approach. Or alternatively, use the set protocols evpn vni-options vni 100013 export target:65000:1?

VLAN-Based implementation is supported by a limited amount of Juniper's switches and has even more limitations to JunOS versions

agreed with @rml596

[flashover]

What is the design reason for the Auto Derived Route Targets? Are you combining this with family RTC or inter-AS EVPN with policies for filtering?

[robertlynch3]

What is the design reason for the Auto Derived Route Targets? Are you combining this with family RTC or inter-AS EVPN with policies for filtering?

Juniper’s EVPN/VXLAN implementation guides use auto derived targets. I’ve hit this issue when I was testing a Linux VTEP (using FRR) connected to a Juniper fabric. Juniper uses iBGP overlays for EVPN. I don’t know if that answers your question.

[flashover]

If you don't combine the auto derived targets with BGP family route-target then what is the benefit of the auto derived targets? Can you not run the fabric without it? The point is, all VTEP devices would receive all EVPN routes in both scenarios.

[robertlynch3]

If you don't combine the auto derived targets with BGP family route-target then what is the benefit of the auto derived targets? Can you not run the fabric without it? The point is, all VTEP devices would receive all EVPN routes in both scenarios.

That is a little outside of my knowledge base. What I do know is if without the correct route target, the Linux VTEP running FRR does not work correctly with the Juniper fabric. Its been a couple months since I did this so I don't recall the exact details. I believe the fabric won't install the EVPN routes because they do not match the correct target for the VLAN.

[flashover]

If you remove the "auto" then the Type 2 route will be re-advertised and the Communities: target:65000:268535469 changes into Communities: target:65000:1 similar as the Type 1 route has. The "268535469" can be recalculated into binary and the final part of that value would be the same as the binary value of the 100013 VNI number.

If you have a super large fabric there might be good reasons for the "auto" that I'm not anticipating here (such as VLAN number reusing with virtual-switch VPNs or inter-AS routing) so please double check my suggestions before implementing them on such scale.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot[bot]]

This issue will be automatically closed in the specified period unless there is further activity.