In modern networking environments, interoperability between different vendor equipment is crucial for maintaining seamless operations across diverse network architectures. One such challenge arises in the context of Ethernet VPN (EVPN) services between Juniper Networks' Junos OS and switches operating on Cisco's NXOS or Huawei platforms.
Junos OS implements the VLAN-aware EVPN service type by default. This service type involves the addition of a non-zero Ethernet Tag ID to the BGP EVPN NLRI for specific EVPN route types. This is a fundamental aspect of how Junos OS handles VLAN-aware services in EVPN implementations. On the other hand, NXOS and Huawei utilizes the VLAN-based EVPN service type, which expects a zero Ethernet Tag ID in the BGP EVPN NLRI. This divergence in default configurations leads to interoperability issues, where non-zero Ethernet Tag IDs are not recognized or handled correctly by NXOS or Huawei devices.
EVPN route seen as packet capture from Juniper when interoperability issue is present:
Frame 42: 475 bytes on wire (3800 bits), 475 bytes captured (3800 bits)
Ethernet II, Src: xx:xx:xx:xx:xx:xx
Internet Protocol Version 4, Src: xxx.x.x.3, Dst: xxx.x.x.11
Transmission Control Protocol, Src Port: 53337, Dst Port: 179, Seq: 64,
Border Gateway Protocol ~ KEEPALIVE Message
Border Gateway Protocol ~ UPDATE Message
Border Gateway Protocol - UPDATE Message
Marker: fAftTTtetet ere enter et eftttete
Length: 99
Type: UPDATE Message (2)
Withdrawn Routes Length: @
Total Path Attribute Length: 76
Path attributes - ORIGIN IGP
Path Attribute - AS PATH: xxxx
Path Attribute - EXTENDED_COMMUNITIES
Path Attribute - PMSI_TUNNEL_ATTRIBUTES
Path Attribute - MP-REACH_NLRI
Flags: 0x9
Type Cod
Length: 28
Address family identifier (AFI): Layer-2 VEN (25)
Subsequent address family identifier (SAFI): EVPN (70)
Next hop: xxxx.x.x.3
Number of Subnetwork points of attachment (SNPA): @
Network Layer Reachability Information (NLRI)
EVPN NLAI: Inclusive Multicast Route
Route Type: Inclusive Multicast Route (3)
Length: 17
Route Distinguisher: xxx.x.x:3.1
Ethernet Tag ID: 101 >>>> It is non-zero Ethernet Tag ID
TP Address Length: 32
IPv4 address: xxx.x.x.3
EVPN route seen as packet capture from Juniper when the issue is resolved:
Protocol | Length! info
BGP 475 KEEPALIVE Message, UPDATE Message, UPDATE Message, UPDATE Message, UPDATE Message
Frame 43: 475 bytes on wire (3800 bits), 475 bytes captured (3800 bits)
Ethernet II, Src: xx:xx:xxx:xx:xx:xx)
Transmission Control Protocol, Src Port: 61635, Dst Port: 179, Seq: 64, Ack: 96, Le
Marker: ff FfffE FETE T EFT EFF fff TTT
Path attributes
Path Attribute - ORIGIN: IGP
Path Attribute - AS_PATH: 65423
Path Attribute ~ PHSI_TUNNEL_ATTRIBUTE
Path Attribute ~ MP_REACH NURI
Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
Type Code: MP_REACHNLRI (14)
Address family identifier (AFI): Layer-2 VPN (25)
Next hop: xxx.x.x.3
Number of Subnetwork points of attachment (SNPA): 0
EVPN NLRI: Inclusive Multicast Route
Route Distinguisher: xxxx.x.x.3:1
Ethernet Tag ID: 0 >>> It is zero Ethernet Tag ID
IPv4 address: 192.0.2.3
To address this interoperability issue, a configuration change is recommended for Junos OS-based switches. The goal is to align the configuration with the VLAN-based EVPN service type expected by NXOS and Huawei devices.
The recommended solution is as follows:
mac-vrf
routing-instances { v100_mac_vrf { instance-type mac-vrf; protocols { evpn { encapsulation vxlan; extended-vni-list all; } } vtep-source-interface lo0.0; service-type vlan-based; interface ae0.0; route-distinguisher 192.0.2.3:1; vrf-target target:100:100; vlans { v100 { vlan-id 100; vxlan { vni 10100; } } } } }
Refer in page 8 in EVPN VXLAN Interoperability Between NXOS and Junos OS