I am testing EVPN VXLAN interoperability between RouterOS 7.24 and Huawei.
RouterOS is configured with VXLAN VNI 3003490 and an EVPN instance using the same VNI.
RouterOS generates and advertises an EVPN Type-3 IMET route. The Huawei peer successfully receives and installs the EVPN route, including the correct RT and VXLAN encapsulation.
However, Huawei discovers the remote VTEP with:
Out Vni ID: 0
instead of VNI 3003490.
The result is that the EVPN control plane appears established, but the VXLAN peer is associated with VNI 0 rather than the configured VNI.
Lab schema:
Underlay IP connectivity
10.83.2.26 10.83.2.1
┌────────────────┐ ┌─────────────────┐
│ MikroTik │ eBGP EVPN │ Huawei │
│ CCR1016 │─────────────────────
│ │
│ RouterOS 7.24 │
─────────────────────│ AS 65845 │
│ AS 65245 │ │ │
└────────────────┘ └─────────────────┘
│
│ VXLAN / EVPN
│
VNI 3003490
Expected on Huawei:
VNI ID: 3003490
Remote VTEP: 10.83.2.26
Out VNI ID: 3003490
Actual:
VNI ID: 3003490
Remote VTEP: 10.83.2.26
Out VNI ID: 0
Minimal configuration (The current test configuration is intentionally minimal and the VXLAN interface is not yet attached to a bridge. I am primarily testing the EVPN Type-3 control-plane advertisement and interoperability):
/interface vxlan
add local-address=10.83.2.26
mac-address=E6:2C:B9:80:0D:3C
name=vxlan3003490
vni=3003490
/routing bgp instance
add as=65245
disabled=no
name=evpn-inst
router-id=10.83.2.26
/routing bgp connection
add afi=ip,l2vpn,evpn
as=65245
disabled=no
instance=evpn-inst
local.address=10.83.2.26
.role=ebgp
multihop=yes
name=AGMOTU-PRO
nexthop-choice=force-self
remote.address=10.83.2.1/32
.as=65845
routing-table=main
use-bfd=no
/routing bgp evpn
add disabled=no
export.route-targets=300:3490
import.route-targets=300:3490
instance=evpn-inst
name=evpn
vni=3003490
RouterOS associates the Type-3 IMET route with:
belongs-to="evpn-vni-3003490"
and exports:
RT: 300:3490
Tunnel Encapsulation: VXLAN (encap:8)
PMSI: ingress replication
VTEP: 10.83.2.26
afi=evpn
contribution=candidate
dst-address=[10.83.2.26:22]imet:0|10.83.2.26
gateway=10.83.2.26
distance=200
scope=40
target-scope=10
belongs-to="evpn-vni-3003490"
.ext-communities=rt:300:3490,encap:8
.pmsi="ingr-repl-10.83.2.26"
.origin=igp
From Huawei side:
<ITX-AGMOTU-PRO>display vxlan peer vni 3003490
Number of peers : 1
Vni ID Source Destination Type Out Vni ID
----------------------------------------------------------------
3003490 10.83.2.1 10.83.2.26 dynamic 0
<ITX-AGMOTU-PRO>display bgp evpn all routing-table inclusive-route 0:32:10.83.2.26
Route Distinguisher: 10.83.2.26:22
Ext-Community:
RT <300 : 3490>
Tunnel Type <VxLan>
PMSI:
Flags 0
Ingress Replication
Label 0:0:0(0)
Tunnel Identifier: 10.83.2.26
Route Type: 3 (Inclusive Multicast Route)
Ethernet Tag ID: 0
Originator IP:10.83.2.26/32
The Huawei device receives the Type-3 route with the expected RT, VXLAN tunnel encapsulation and VTEP address. However, the PMSI attribute is displayed with Label 0:0:0(0), and the resulting VXLAN peer is installed with Out Vni ID 0.
Is RouterOS expected to encode the VXLAN VNI 3003490 in the PMSI Tunnel Attribute for this Type-3 IMET route? Any ideas?
PCAP BGP UPDATE:
I would like to confirm whether this is expected RouterOS behaviour or a possible EVPN Type-3 interoperability/encoding issue.
Specifically:
- Is RouterOS 7.24 expected to encode the VXLAN VNI in the PMSI Tunnel Attribute of locally generated EVPN Type-3 IMET routes?
- If yes, should the Type-3 generated for VNI
3003490result in a PMSI label/VNI value corresponding to3003490, rather than zero? - Is there any RouterOS configuration required to make EVPN Type-3 advertisements interoperable with third-party VXLAN implementations such as Huawei?
Thank you in advanced.
