EIGRP PE-CE Loop

image

 

Suppose you have the topology above. 2 CEs running EIGRP with 2 PEs plus a backdoor link. One of the PE-CE links has a high delay (Between R1 and R2). 

There is another site running OSPF (on R4), plus another site on R5 that is just redistributing a loopback into the VPN. 

R3 is the VPNv4 RR. All PE routers peer via iBGP VPNv4 with it. 

R2 has a different RD (2:10) while the other PEs that are members of the VPN use RD 10:10

 

There is a mayor loop that occurs in this topology. 

1) Both XR1 and R2 redistribute from BGP into EIGRP (into the VRF process). 

2) R2 ends up with D EX routes, where as XR1 keeps the RIB the way it was (does not get feedback).  R2 gets feedback because of the high delay on the PE-CE link. R1 is prefering to use the backdoor link (because of the delay on the PE-CE link), so it advertises those routes back to R2. 

Keep in mind that these D EX routes did NOT come from another EIGRP domain (they came from XR1's redistribution of BGP into EIGRP), so they do not have the cost-community! These routes will cause an issue when being redistributed into MP-BGP. 

R2#show ip route vr A ei              

D        1.1.1.1 [90/409600] via 10.1.2.1, 00:31:41, Ethernet1/0

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D        10.1.201.0/24 [90/307200] via 10.1.2.1, 00:31:41, Ethernet1/0

D EX     10.4.10.0/24 [170/358400] via 10.1.2.1, 00:06:10, Ethernet1/0

D EX     10.10.10.10/32 [170/358400] via 10.1.2.1, 00:06:10, Ethernet1/0

D        10.19.20.0/24 [90/332800] via 10.1.2.1, 00:31:41, Ethernet1/0

      20.0.0.0/32 is subnetted, 1 subnets

D        20.20.20.20 [90/435200] via 10.1.2.1, 00:31:41, Ethernet1/0

      192.168.1.0/32 is subnetted, 4 subnets

D EX     192.168.1.4 [170/358400] via 10.1.2.1, 00:06:10, Ethernet1/0

D EX     192.168.1.5 [170/358400] via 10.1.2.1, 00:06:10, Ethernet1/0

D        192.168.1.19 [90/460800] via 10.1.2.1, 00:31:30, Ethernet1/0

 

XR1 on the other hand only has the internal EIGRP routes in it's RIB. When these routes get redistributed back into MP-BGP, they will have the cost-community set so it will not cause an issue.

XR1(config)#do show ip route vr A ei

D        1.1.1.1 [90/435200] via 10.19.20.20, 00:30:24, Ethernet1/1

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D        10.1.2.0/24 [90/2866944] via 10.19.20.20, 00:30:24, Ethernet1/1

D        10.1.201.0/24 [90/307200] via 10.19.20.20, 00:30:24, Ethernet1/1

      20.0.0.0/32 is subnetted, 1 subnets

D        20.20.20.20 [90/409600] via 10.19.20.20, 00:30:24, Ethernet1/1

      192.168.1.0/32 is subnetted, 4 subnets

D        192.168.1.2 [90/2994944] via 10.19.20.20, 00:28:57, Ethernet1/1

 

 

Let's first do redistribution from XR1 to observe what happens:

XR1:

  router bgp 100

  address-family ipv4 unicast vrf A

  redistribute eigrp 100 

 

The only notable thing that happens is that R2 now uses the MPLS core to reach 

D        20.20.20.20 [90/435200] via 10.1.2.1, 00:31:41, Ethernet1/0  --->(XR2 loopback)

D        192.168.1.19 [90/460800] via 10.1.2.1, 00:31:30, Ethernet1/0 ---->  (XR1 loopback)

 

This is because of the cost-community (the EIGRP metric is less going through the MPLS core than it is through the backdoor)

They are now installed as BGP routes on R2:

B        20.20.20.20 [200/409600] via 19.19.19.19, 00:01:07

B        192.168.1.19 [200/0] via 19.19.19.19, 00:01:07

 

 

So far, we have no loop. The only suboptimal behavior that we've seen is that R2 installed the routes that XR1 redistributed into EIGRP as D EX (using the backdoor link). 

 

Lets now redistribute on R2 (the only missing redistribution) from EIGRP to MP-BGP. This is where the problems will be observed. In order to see really happens, I am just going to redistribute 1 prefix (192.168.1.5/32). This prefix is R5's loopback that was redistributed into the VPN, got picked up by both XR1 and R2 via VPNv4, then XR1 redistributed into EIGRP, causing R2 to learn it via EIGRP and installl it as a D EX route. Again, this happened because of the lower AD between 200 and 170, plus the fact that there was no cost community attached to this prefix (it didnt come from another EIGRP domain). 

 

Here is the sequence of events that will happen:

1) R2 currently has a VPNv4 route for 192.168.1.5/32 that was advertised by R5 (with RD of 10:10). R2 imported this into vrf A and thus the RD was changed to 2:10. 

2) R2 will redistribute this route into MP-BGP. A locally sourced route will be created with weight of 32768.  This new route will have the cost-community included! (because it came from EIGRP)

3) This VPNv4 route will be sent to R3. 

4) Upon R3 receiving this route, it advertise it on to the other PEs!!! Why? Because this route has a different RD attached to it, and thus is considered to be a separate route. R3 will have the 10:10:192.168.1.5/32 from R5, but it will receive 2:10:192.168.1.5/32 from R2. 

5) XR1 will receive this route and import it into its VRF, and since it  has the cost-community attached, it will win over the existing (original) BGP route that R5 advertised. XR1 will install this route from R2 as BGP, and will redistribute it back into EIGRP! LOOP!!!

The update will circle around the network increasing the hop count, until it reaches 100 hops (counting to infinity). 

In my test network, this loop sometimes happens indefinitly (it starts again, until it gets to 100 hops, and then starts again, etc). Other times, after the route gets to 100 hops, the loop will stop (I dont know why). Even though R2 has the route as DEX and is redistributing it into BGP, for some reason unknown to me, the cost-community stops getting attached. So when XR1 receives the update without the cost community, the original R5 update wins and the loop stops.

 

I am having a hard time understanding why the loop stops. Why does the cost-community all of the sudden stop getting attached? 

 

Thanks for your feedback,

 

Pablo

 

 

 

Sign In or Register to comment.