Hey! I am noticing an odd behaviour when using BGP EVPN on a vQFX: it assumes that all VTEP have all the local VNIs. For example, on the local system, I have VNI 654, 655 and 656. However, on the remote VTEP, I have only 654 and 655. However, the local system still assumes VNI 656 should be present:
juniper@QFX1> show version fpc0: -------------------------------------------------------------------------- Hostname: QFX1 Model: vqfx-10000 Junos: 17.4R1.16 limited JUNOS Base OS boot [17.4R1.16] JUNOS Base OS Software Suite [17.4R1.16] JUNOS Crypto Software Suite [17.4R1.16] JUNOS Online Documentation [17.4R1.16] JUNOS Kernel Software Suite [17.4R1.16] JUNOS Packet Forwarding Engine Support (qfx-10-f) [17.4R1.16] JUNOS Routing Software Suite [17.4R1.16] JUNOS jsd [i386-17.4R1.16-jet-1] JUNOS SDN Software Suite [17.4R1.16] JUNOS Enterprise Software Suite [17.4R1.16] JUNOS Web Management [17.4R1.16] JUNOS py-base-i386 [17.4R1.16] JUNOS py-extensions-i386 [17.4R1.16] {master:0} juniper@QFX1> show ethernet-switching vxlan-tunnel-end-point remote Logical System Name Id SVTEP-IP IFL L3-Idx <default> 0 192.0.2.11 lo0.0 0 RVTEP-IP IFL-Idx NH-Id 192.0.2.13 570 1749 VNID MC-Group-IP 656 0.0.0.0 655 0.0.0.0 654 0.0.0.0 {master:0} juniper@QFX1> show route table default-switch.evpn.0 default-switch.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:192.0.2.11:1::010101010101010101::0/192 AD/EVI *[EVPN/170] 00:03:49 Indirect 2:192.0.2.11:1::654::50:54:33:00:00:0f/304 MAC/IP *[EVPN/170] 00:02:43 Indirect 2:192.0.2.11:1::655::50:54:33:00:00:0f/304 MAC/IP *[EVPN/170] 00:01:20 Indirect 2:192.0.2.11:1::656::50:54:33:00:00:0f/304 MAC/IP *[EVPN/170] 00:03:54 Indirect 2:192.0.2.13:1::654::50:54:33:00:00:11/304 MAC/IP *[BGP/170] 00:02:41, localpref 100, from 192.0.2.100 AS path: I, validation-state: unverified > to 203.0.113.13 via xe-0/0/0.0 2:192.0.2.13:1::655::50:54:33:00:00:11/304 MAC/IP *[BGP/170] 00:02:04, localpref 100, from 192.0.2.100 AS path: I, validation-state: unverified > to 203.0.113.13 via xe-0/0/0.0 3:192.0.2.11:1::654::192.0.2.11/248 IM *[EVPN/170] 00:04:08 Indirect 3:192.0.2.11:1::655::192.0.2.11/248 IM *[EVPN/170] 00:04:07 Indirect 3:192.0.2.11:1::656::192.0.2.11/248 IM *[EVPN/170] 00:04:07 Indirect 3:192.0.2.13:1::654::192.0.2.13/248 IM *[BGP/170] 00:03:55, localpref 100, from 192.0.2.100 AS path: I, validation-state: unverified > to 203.0.113.13 via xe-0/0/0.0 3:192.0.2.13:1::655::192.0.2.13/248 IM *[BGP/170] 00:03:55, localpref 100, from 192.0.2.100 AS path: I, validation-state: unverified > to 203.0.113.13 via xe-0/0/0.0 The remote system, 192.0.2.13 (also a vQFX), never send anything that would hint it can handle VNI 656. I have also verified by sniffing on the wire that the remote system is in fact receiving VXLAN packets for VNI 656: Frame 807: 106 bytes on wire (848 bits), 106 bytes captured (848 bits) Ethernet II, Src: MS-NLB-PhysServer-05_86:71:7e:03 (02:05:86:71:7e:03), Dst: MS-NLB-PhysServer-05_86:71:69:03 (02:05:86:71:69:03) Internet Protocol Version 4, Src: 192.0.2.11, Dst: 192.0.2.13 User Datagram Protocol, Src Port: 3471, Dst Port: 4789 Virtual eXtensible Local Area Network Flags: 0x0800, VXLAN Network ID (VNI) Group Policy ID: 0 VXLAN Network Identifier (VNI): 656 Reserved: 0 Ethernet II, Src: 50:54:33:00:00:0f (50:54:33:00:00:0f), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) My BGP EVPN configuration is pretty simple and I rely on auto RT: protocols { bgp { group evpn { type internal; multipath; multihop; family evpn signaling; } } evpn { encapsulation vxlan; extended-vni-list all; multicast-mode ingress-replication; } } switch-options { vtep-source-interface lo0.0; vrf-import EVPN-VRF-VXLAN; vrf-target { target:65000:1; auto; } } policy-options { policy-statement EVPN-VRF-VXLAN { then accept; } } vlans { vlan-client1-654 { vlan-id 654; vxlan { vni 654; ingress-node-replication; } } vlan-client1-655 { vlan-id 655; vxlan { vni 655; ingress-node-replication; } } vlan-client1-656 { vlan-id 656; vxlan { vni 656; ingress-node-replication; } } } Do you observe the same "issue" on your setup? Is there a known way to fix that? Thanks! -- Soap and education are not as sudden as a massacre, but they are more deadly in the long run. -- Mark Twain _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp