VXLAN EVPN Fabric Forwards Unicast but Drops BUM Traffic
A four-leaf, two-spine VXLAN EVPN fabric runs Nexus 9332PQ spines and 93180YC-EX leafs on NX-OS 9.3(8). The underlay is OSPF area 0 with PIM sparse mode; the rendezvous point is a loopback on spine-1. Each leaf uses loopback0 (/32) as its VTEP, and NVE is configured with source-interface loopback0. VLAN 110 on leaf-3 and leaf-4 maps to VNI 50110 and uses multicast group 239.1.1.1; the anycast gateway has the same MAC and IP on both leafs. Hosts in VLAN 110 on leaf-3 and leaf-4 can ping each other if an ARP entry is manually installed, but DHCP and initial ARP resolution fail, and broadcast pings do not cross the fabric. show nve peers lists both remote VTEPs as Up with the correct VNI, and show nve vni shows VNI 50110 Up with multicast group 239.1.1.1. show ip mroute on leaf-3 has no (*,G) or (S,G) entry for 239.1.1.1. The leaf uplinks to the spines are routed ports configured with no switchport and an IP address, but PIM was never enabled on them. Unicast pings between the leaf loopbacks succeed.
1. Diagnose why unicast works while BUM traffic fails. What does the empty multicast route table prove, and which commands would you run next?
Read the worked answer
VXLAN unicast uses the remote VTEP IP as the outer destination, so it follows the ordinary OSPF route to loopback0 and needs no multicast. BUM traffic (broadcast, unknown unicast, multicast) uses the configured replication mechanism; here that is multicast group 239.1.1.1 over a PIM sparse-mode underlay.
An empty show ip mroute on leaf-3 means the leaf never built a (*,G) tree for that group, so encapsulated BUM frames have no outgoing interface and are dropped. The likely cause is missing PIM on the leaf uplinks: IGMP joins from the NVE have no PIM neighbor to propagate toward the RP.
Confirm with show ip pim neighbor, show ip pim interface, show ip pim rp mapping, show ip igmp groups, show run | include pim, and show nve vni 50110 detail. Also confirm the RP loopback is reachable by unicast from every leaf. The manually installed ARP entries mask the failure because they bypass the need for BUM flooding.
2. Describe two remediation options for the BUM forwarding failure and the trade-offs between them.
Read the worked answer
Option one is to complete the multicast underlay: enable ip pim sparse-mode on every routed link between leafs and spines, confirm the RP address is reachable and consistently configured on all devices, and verify show ip pim neighbor and show ip mroute on the leafs. This preserves the existing design and scales, but it requires consistent PIM/RP configuration and creates multicast state on every VTEP.
Option two is ingress replication: either static (ingress-replication protocol static under the VNI, plus ingress-replication protocol static under nve with ingress-replication peers <VTEP-IP> for every remote VTEP) or BGP EVPN-based IMET (type-3) routes. Static replication is simple but must be updated whenever a VTEP is added; EVPN ingress replication is the better choice if the fabric already uses EVPN for MAC/IP learning.
After either change, show nve vni should show the new replication mode, and broadcast pings and DHCP should work without manual ARP entries.
3. A junior engineer adds `ingress-replication protocol static` under VNI 50110 only, but BUM traffic still fails. Why?
Read the worked answer
Adding ingress-replication protocol static under the VNI only changes the replication mode. Static ingress replication still needs the list of remote VTEPs, configured under the NVE interface (ingress-replication protocol static followed by ingress-replication peers 10.0.0.4 ...). Without that peer list the leaf has no destination to replicate BUM frames to, so behavior is unchanged.
Also check that the VNI no longer has a multicast group configured; show nve vni 50110 detail should show ingress replication and no multicast group, otherwise the configuration is mixed. Finally, verify the remote VTEPs appear in show nve peers and that the peer IPs you list are the loopback0 addresses, not the physical uplinks.