MPLS - L3VPN BGP EIGRP redistribution

Under normal circumstances, when we redistribute routes into EIGRP those routes appear as external routes, indicated by the D EX designation in the Routing Table. However, in an MPLS scenario where Layer 3 VPNs are used and where EIGRP is used between CEs and PEs, routes redistributed into EIGRP do not have the external designation of D EX, but the normal designation of D.

The reason for this is multifaceted. First of all, the MPLS network is technically transparent to the customer endpoints. It appears as if the CEs are directly connected and just exchange prefixes. This is how MPLS is intended to function.

The reason behind the fact that the routes appear to be internal rather than external (redistributed)is because of the nature of EIGRP and how it classifies routes. When a route is redistributed into EIGRP, it’s classified as an external route. However, in this case, the BGP VPNv4 routes are not being redistributed directly into EIGRP. Instead, they’re being imported into the VRF and then redistributed into EIGRP.

Take a look at the following MPLS topology: mpls-vpn-pe-ce-eigrp-topology.png

EIGRP is being used between the PE and CE routers. Take a look at the redistribution command on PE2:

PE2(config)#router eigrp 1
PE2(config-router)#address-family ipv4 vrf CUSTOMER
PE2(config-router-af)#redistribute bgp 234 metric 1 1 1 1 1

Notice the redistribute command is being applied under the IPv4 address family VRF Customer configuration mode and not directly under the router eigrp 1 configuration mode. This causes the routes to appear as internal because, as far as EIGRP is concerned, they’re originating from within the VRF.

Thus, in the routing table, they appear as D rather than D EX as shown below:

CE2#show ip route eigrp

      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/158720] via 192.168.45.4, 00:04:08, FastEthernet0/0
D     192.168.12.0/24 [90/30720] via 192.168.45.4, 00:04:08, FastEthernet0/0

This behavior is not specific to MPLS but it is specific to VRFs. It has to do with how EIGRP handles redistributed routes from VRFs. The key factor here is that the routes are being imported into the VRF before they’re redistributed into EIGRP, which is why they’re appearing as internal routes.

A similar issue appears with OSPF in the same scenario.

https://networklessons.com/eigrp/eigrp-external-route-path-selection

Links to this page: