EIGRP

BGP and EIGRP mutual redistribution routing loops and prevention…

The dreaded routing loop, I ran into an interesting problem the other day regarding a BGP/EIGRP mutual redistribution configuration.  There was an issue with the secondary router receiving BGP advertisements, but the resulting behavior was unexpected.  It created a loop in the network, every 30 seconds the routes either went into the routing table or were flushed out.  I’ve recreated the scenario in a lab environment and I can recreate the problem but not the exact symptoms.  I still can’t get the 30 seconds in/out, this could be because I’m using newer code or IOU or I don’t have all the pieces exactly recreated.

Here is what the topology looks like in the lab:

diagrams 16(2)

Here is what the routing loop looked like from L3

 L3(config)#do traceroute 10.100.201.1
 Type escape sequence to abort.
 Tracing the route to 10.100.201.1
 VRF info: (vrf in name/id, vrf out name/id)
 1 10.107.163.6 4 msec 5 msec 5 msec
 2 192.168.101.49 5 msec 5 msec 5 msec
 3 * * *
 4 * * *
 5 10.51.157.10 2 msec 5 msec 1 msec
 6 10.107.163.9 1 msec 1 msec 1 msec
 7 10.107.163.6 0 msec 1 msec 1 msec
 8 192.168.101.49 0 msec 0 msec 1 msec
 9 * * *
 10 * * *
 11 10.51.157.10 3 msec 1 msec 1 msec
 12 10.107.163.9 1 msec 1 msec 1 msec
 13 10.107.163.6 1 msec 1 msec 1 msec
 14 192.168.101.49 1 msec 1 msec 0 msec
 15 * * *
 16 * * *
 17 10.51.157.10 8 msec 6 msec 2 msec
 18 10.107.163.9 1 msec 6 msec 1 msec
 19 10.107.163.6 5 msec 1 msec 2 msec
 20 192.168.101.49 1 msec 1 msec 1 msec
 21 * * *
 22 * * *
 23 10.51.157.10 1 msec 1 msec 1 msec
 24 10.107.163.9 1 msec 3 msec 1 msec
 25 10.107.163.6 1 msec 1 msec 1 msec
 26 192.168.101.49 1 msec 1 msec 1 msec
 27 * * *
 28 * * *
 29 10.51.157.10 3 msec 1 msec 2 msec
 30 10.107.163.9 1 msec 5 msec 3 msec

After drawing up what I thought was happening, it was clear that because the BGP prefix was being blocked into CE2 it was learning the prefix from EIGRP and then advertising into BGP.  Normally this wouldn’t matter because CE1 would recognize that the BGP advertisement had it’s own as-path and would reject it.  But due to some legacy configuration, as-override was running on the service provider PE routers.  So when CE1 saw the BGP advertisement from CE2 with a shorter as-path it installed that route.  This meant that the packets went from L3 -> CE1 -> CE2 -> CE1 until the infinity count expired.
diagrams 16
To clear this looping, I first thought of setting a tag outbound on the BGP neighbor route-map and then block inbound. You can block the route, using an inbound route-map but you can’t set a tag on an outbound route-map.

 % "PREPEND" used as BGP outbound route-map, set tag not supported

I then tried to set a tag from EIGRP->BGP then blocking that route using a route-map when redistributing from BGP->EIGRP. I ran into a restriction on setting the tag on redistribution.

 % "BGP-EI" used as redistribute eigrp into bgp route-map, set tag not supported

Finally I settled on setting a tag on the redistribution of BGP->EIGRP, and then blocking that tagged route when redistributing EIGRP back into BGP. The configuration is below.


 route-map BGP-EI permit 10
 set tag 666
 route-map EI-BGP deny 10
 match tag 666
 route-map EI-BGP permit 50
 
 router ei 50
 redistribute bgp 65003 metric 10000 1000 255 1 1500 route-map BGP-EI
 
 router bgp 65003
 redistribute eigrp 50 route-map EI-BGP

A much simpler solution would be to use network statements under the BGP process instead of redistributing EIGRP into BGP, but it is very handy to understand how to stop routing loops when you are restricted either by an existing production setup or by the CCIE.

Strange Behavior w/ EIGRP Distribute List using Standard ACL

I ran into an issue earlier this week while simulating a change in my GNS3 lab.  What I found was interesting on the way that EIGRP deals with inbound distribute-lists that use access-lists with wildcard masks. This diagram shows the small network we are dealing with on this lab.

EIGRP_Distribute-List

As you can see R1 has 4 loopback adapters:

Loopback 1: 10.8.0.1/24

Loopback 2: 10.254.254.1/30

Loopback 3: 10.20.20.1/24

Loopback 4: 20.64.0.1/12

All four loopback adapters are included in the EIGRP process on R1.  There is a successful EIGRP neighbor adjacency between R1 and R2. The following is configured on R2:

router eigrp 100
distribute-list 50 in Ethernet0/0
distribute-list 50 out Ethernet0/1
network 100.100.100.0 0.0.0.255
access-list 50 permit 10.20.20.0 0.0.0.255
access-list 50 permit 10.8.0.0 0.7.255.255
access-list 50 permit 20.64.0.0 0.7.255.255

What I would expect is that only 10.20.20.0/24 would be installed.

But when I check the routing table on R2 I get the following on R2:

10.0.0.0/24 is subnetted, 2 subnets
D        10.8.0.0 [90/435200] via 100.100.22.3, 00:15:28, Ethernet0/0
D        10.20.20.0 [90/435200] via 100.100.22.3, 00:18:42, Ethernet0/0
20.0.0.0/12 is subnetted, 1 subnets
D        20.64.0.0 [90/435200] via 100.100.22.3, 00:18:42, Ethernet0/0

Why is this? It is due to the way that Cisco IOS processes an access-list when used to filter routes.  Basically it doesn’t work as expected. When we turn on debug ip eigrp we see that R2 processes the 20.64.0.0/12 subnet advertised from R1 and then installs it.

*Nov 21 21:20:51.838: EIGRP-IPv4(100): Int 20.64.0.0/12 M 409600 - 10000 6000000000 SM 128256 - 4060086272 76293

*Nov 21 21:20:51.838: EIGRP-IPv4(100): table(default): route installed for 20.64.0.0/12 (90/409600) origin(100.100.100.1)
So it is processing the /12 even though only a /13 is allowed.  So let’s change this to a prefix-list instead of standard access-list and see what happens.
R2 routing table
  10.0.0.0/24 is subnetted, 1 subnets D 10.20.20.0 [90/409600] via 100.100.100.1, 00:00:10, Ethernet0/0
This is the expected behavior.  One thing to note is that when debugging EIGRP updates, the denied by distribute-list is only seen on outbound filtering.  Inbound filtering does not show a message saying that it was denied.

Summary: this is just one more reason why you should use prefix-lists when dealing with routing protocols.