Troubleshooting EIGRP Neighbor Relationships

EIGRP internals and getting hands dirty in debugging routing adjacency and solving EIGRP neighboring issues.

What is sequence TLV and Conditional Receive CR-mode and CR flag

Couple of days ago I got a strange network behavior in my CCIE lab. Something was wrong between a router and L3 switch connection and there was EIGRP neighbor relationship reset every few minutes. It was happening all the time so I decided to debug a little.

It was looking something like this and I was very confused about it:

*Mar 1 01:00:32.135: EIGRP: Received Sequence TLV from 155.1.1.2
*Mar 1 01:00:32.135: 155.1.1.1
*Mar 1 01:00:32.139: address matched
*Mar 1 01:00:32.139: clearing CR-mode
*Mar 1 01:00:32.139: EIGRP: Received CR sequence TLV from 155.1.1.2, sequence 5
*Mar 1 01:00:32.139: EIGRP: Received UPDATE on FastEthernet0/0 nbr 155.1.1.2
*Mar 1 01:00:32.139: AS 1, Flags 0xA, Seq 5/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1, not in CR-mode, packet discarded
………………………….
*Mar 1 01:10:00.123: EIGRP: FastEthernet0/0 multicast flow blocking cleared

The thing that was happening here is basically just some EIGRP internals doing their job. To be precise this was reliable routing information delivery over both multicast and unicast doing his reliable update delivery.

Normal EIGRP synchronization is done using multicast.

If we have two EIGRP routers that are trying to make initial sync and become neighbors they will intentionally see each other as “laggard” in the beginning. The term laggard is important here as it symbolize a neighbor to witch we are sending EIGRP updates in separate unicast communication.

Why?

If one EIGRP router is sending updates to, let’s say, 5 other neighbors. It will send that update to address 224.0.0.10 and it will include the update sequence number inside. Let’s say Seq=25.

When it sends the update Seq=25 to the network segment it will get ready to send next update with Seq=26 and wait for the acknowledgement of sequence 25 update. The problem is that the router will put newly prepared update Seq=26 onto the transmission lists for all 5 neighbors and it will not send it out to anybody until he acknowledges sequence 25 update from all 5 neighbors. That means that if one of 5 routers does not send back the acknowledgement for Seq=25 update our router will not continue sending multicast update Seq=26 to anybody and he will lose the neighbors after hold timer expires.

In the first EIGRP sync process newly discovered neighbors will intentionally be market as laggard. Initial sync can take long time and maybe even fail if some timers are not configured as they should be. This would lead to breaking others EIGRP neighbors because of update acknowledge timeout. In this way the newly discovered router is syncronized with separate unicast communication so that other can be normally syncronized using multicast without the risk of timing out. After a while new neighbor will stop being considered a laggard router and he will also join 224.0.0.10 multicast group to receive multicast EIGRP update.

But what will happen if a router is not laggard and it stops to send back acknowledgements to neighbor. He will then risk to brake everybody’s neighboring with that update issuing router?

There are some new terms here that we can explain here with an example. Those are sequence TLV and CR-mode (CR flag) that means Conditional Receive bit in update. When I at first saw this debugging nothing was clear to me. Now I will help you to follow couple of steps in EIGRP syncronziation process so we can understand what’s going on.

Example

1. One of five routers let’s say router R5 do not receive multicast EIGRP update from R1 Seq=25, or the acknowledgement was lost on the way back to R1. In that case R1 has a time defined when he will start to see the neighbor R5 as laggard.
2. R1 generates a new Hello message with Sequence TLV sequence 26 listing router R5 that did not send acknowledgement back to R1.
3. R5 receives that Hello and seeing itself in that Sequence TLV, he does not go into CR-mode. What about other routers on the segment? They did receive Seq=25 and sent back the acknowledgement. Those routers will also receive that particular Hello but they will not be listed in Sequence TLV so they would enter the CR-mode. R2, R3, R4 are not listed in the message and are entering CR mode. In CR mode they are expecting multicast update with the Seq=26 that was indicated in this last Hello with TLV set to seq=26.  Now updates with Seq=25 and Seq=26 are listed on the transmission list for R5. For other routers, the transmission list contains only the update with Seq=26.
4. R1 now sends update with Seq=26 as a multicast with CR bit set. All routers in CR-mode (R2, R3, R4) will process this packet along with sending an acknowledgment back and exit the CR-mode.
5. R5 was not in CR-mode so he will not accept updates with CR bit set. Those packets flagged with CR bit may be received only by routers in CR-mode.
6. R1 will resend each message from the transmission list for R5 as unicast starting with first update Seq=25. If R5 receives and send back an acknowledgement R1 will remove the update Seq=25 from the transmission list for R5 and send another update with Seq=26 as unicast. After R5 acknowledges this one too, the transmission list for routers R2, R3, R4, R5 will be empty so R1 has now made sure that the both routers are fully synchronized.