A fire district attaches a township that already standardized on EIGRP at the edge to an MPLS L3VPN PE. Which concern should designers keep in mind at a conceptual level?
Select an answer to reveal the explanation.
Short Explanation
EIGRP on the PE-CE link is fine when the township already speaks it—but watch for routing loops when sites reconnect through the VPN. Site-of-Origin style protections are part of that story. EIGRP at the edge doesn’t delete RD/RT or replace MP-BGP in the core.
Full Explanation
EIGRP can serve as PE-CE for a fire-district township that already standardized on EIGRP at the edge, but designers must keep Site-of-Origin and related loop-prevention behavior in view. When multipath or multihomed VPN topologies could reintroduce routes, SoO-style protections help prevent loops while EIGRP continues as the edge protocol.
Claiming EIGRP cannot be used as PE-CE under any VRF configuration is incorrect. EIGRP PE-CE does not remove the need for RD or RT on the PE—those remain L3VPN control-plane requirements. EIGRP PE-CE also does not replace MP-BGP between PEs for VPN route exchange across the provider backbone.
Exam caveat: PE-CE protocol choice is independent of the PE-PE VPNv4/MP-BGP requirement; loop prevention is the EIGRP-specific design watch-out.
Operational check: enable EIGRP in the township VRF, configure SoO or equivalent loop prevention for multihoming, verify RD/RT and MP-BGP still carry VPN routes, and test failover without route feedback loops. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.