A remote municipal VRF is missing Type-5 prefixes that the local DCI border advertises for L3 interconnect. Where should troubleshooting start conceptually?
Select an answer to reveal the explanation.
Short Explanation
Missing Type-5s are usually a guest-list or policy problem—wrong RT, export policy dropping the prefixes, or the VRF not in the club. Start with RT/policy/VRF membership before redesigning the whole underlay. Type-5 is EVPN IP-prefix signaling, not an OSPF LSA scavenger hunt.
Full Explanation
When a remote municipal VRF is missing Type-5 prefixes that the local DCI border advertises for L3 interconnect, troubleshooting should start with route-target import/export, EVPN export policy, and VRF membership for the L3 DCI routes. Type-5 connectivity fails quietly when the remote VRF does not import the advertised RTs, when export policy suppresses prefixes, or when the prefix is not in the originating VRF’s EVPN export set. Replacing VXLAN with GRE immediately because Type-5 supposedly cannot traverse UDP invents a false encapsulation limitation and skips control-plane diagnosis. Clearing OSPF on every spine because Type-5 is supposedly an OSPF LSA type confuses EVPN route types with OSPF; Type-5 EVPN is BGP-signaled IP prefix routing in the overlay. Disabling the remote VRF until all MACs are static because Type-5 never carries IP prefixes is inverted—Type-5 exists specifically to carry IP prefixes for L3 DCI. Exam caveat: missing remote Type-5 → RT/policy/VRF membership first, not GRE migrations or OSPF myths. Operational check: on both civic borders, show EVPN Type-5 advertisements and the remote VRF’s import RTs; fix RT/policy mismatches, confirm the prefix installs in the remote tenant RIB, and ping across the L3 interconnect; attach CLI evidence to the incident ticket.