Debugging EIGRP-1 The topology used is - The Cisco Learning ...

Debugging EIGRP-1 

The topology used is: 

R1 is adjacent to R2 and R3. 

When the eigrp process is cleared, the neighborship builds-

The first snippet of the debug on R3 shows 

00:10:03.131: EIGRP: Received UPDATE on FastEthernet0/0 nbr 10.1.13.1update has flag 0x1, seq 

13/0 , -- this means the update was initial update, and R3 didn’t know any Router R1 up until now. 

Seq 13/0 is the update packet seq no is 13, and it is not sending any ACK with it- just because R1 

hasn’t received any packet yet from R3. 

00:10:03.135: EIGRP: Received Sequence TLV from 10.1.13.1:- just because R1 hasn’t received the 

acknowledgement of its earlier packet, it sends a hello packet with TLV type SEQ (oxooo3), (snip 

below) 

And R3 sees its own ip address, and next 2 line in (snip above ) shows that. Clear CR mode, - means 

don’t entertain the multicast packet with the seq no mentioned, in Hello packet with TLV SEQ field 

set. 

Packet capture 

When ever a Reliable multicast packet is sent on an interface a multicast flow timer is started 

for it, and if ACk for this reliable packet is not received within the multicast flow-timer, router 

generates a special hello, with fields like shown above, and this hello is a multicast. But this 

includes neighbor IP address, as shown in the packet capture (10.1.13.3). The other routers upon 

receiving this hello packet, see the ip address field, and when they don’t find their own ip in this 

field, they transition to Conditional Receive mode (CR). This packet also indicates the seq, no

that the next multicast update will have. Conditional receive just means that the router in that 

mode should receive and process the multicast packet. 

The router mentioned in this hell TLS SEQ, ignores the multicast packet with the seq no 

mentioned in the hello,(here 14.) because it is not following the the update process sequence. 

And any other router don’t want others to suffer because of one/few less responsive router/s, 

so they keep running/sending the update packets with reliable multicast packets in the sequence 

and tells the less responsive router to hold on ,and try out the special treatment (unicasts). After 

that the router running not that good, catches up with others and start dealing with multicasts. 

(repeat)Here this happens because, the router R1 can’t let the (router R3- 10.1.13.3) to stay 

behind in the update process. There-fore it generates a unicast packet, and sends to 10.1.13.3, 

expecting R3 to catch up nicely. 

Router, in CR mode comes out of it, as soon as they see the multcast packet with seq no 

mentioned in the Hello packet with TLV SEQ set,that always precedes the multicast. 

This is the Reliable Multicast packet for which the special hello was sent. The Seq no of the packet 

is same -14. 

It didn’t get acked by R3. 

R3 finally receives that (out of order for it-self) multicast update. And it discards it. 

Mar 1 00:10:03.139: EIGRP: Received UPDATE on FastEthernet0/0 nbr 10.1.13.1 

Mar 1 00:10:03.139: AS 1, Flags 0xA, Seq 14/0 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/0, not 

in CR-mode, packet discarded 

This is the same packet we are talking about, flag is 0xA, the Seq is 14.

Earlier What happened at R1 : 

R1 sent a Multicast Update with Seq 13, and that was not acknowledged by R3 within the Multicast 

Flow timer. Hence a Unicast was sent, 

00:10:05.811: EIGRP: Requeued unicast on FastEthernet0/1 

00:10:05.819: EIGRP: Sending UPDATE on FastEthernet0/1 nbr 10.1.13.3 

00:10:05.819: AS 1, Flags 0x1, Seq 13/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un 

- 00:10:05.827: EIGRP: Building Sequence TLV, EIGRP, and next three line in the cli snip 

Next is R1 receives ACK for its uncast packet Seq no 13. 

ACKS are UNICAST:

EIGRP: Received UPDATE on FastEthernet0/1 nbr 10.1.13.3 

Mar 1 00:10:05.947: AS 1, Flags 0x1, Seq 5/13 idbQ 1/0 iidbQ un/rely 0/0 

peerQ un/rely 0/2 

The earlier outstanding seq no 13 is acknowledged, and it’s the initial update packet from R3, (flag 

0x1) with seq 5. Now the R1 will acknowledge this packet with ack 5. And thing goes onlike this, 

until the process is complete and -----neighborship comes up. 

------------------------------------------------------------ 

You’ll be seeing in debugs, the router sending multicast updates, with CR (conditional receive) flag 

set-ie. 0x2 (or 0xA, depends) and Still stuck on to a single seq no that is lower than the earlier. 

Like— 

There is seq no 16, with intial flag set i.e 0x1, then, seq no 17, with CR Flag bit set. This is because, 

there can be more than one neighbor on a segment. But, it will not increase if there isn’t any extra 

neighbor, it has to receive ACK for those Reliable multicasts. 

RTO here is Retransmission time out, the time in ms between successive unicast updates. ( usually is 

6 times srtt and a max value is 200 ms –if I remember right.)

Now when I add a network on R3. 

There won’t be any flags set, here. As the neighbor ship is healthy at the moment. 

16:27.275: EIGRP: Received UPDATE on FastEthernet0/1 nbr 10.1.13.3 

16:27.279: AS 1, Flags 0x0, Seq 9/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 

16:27.279: EIGRP: Enqueueing ACK on FastEthernet0/1 nbr 10.1.13.3 

16:27.283: Ack seq 9 iidbQ un/rely 0/0 peerQ un/rely 1/0 

16:27.283: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming UPDATE packet 

6:27.287: IP-EIGRP(Default-IP-Routing-Table:1): Int 3.0.0.0/8 M 409600 - 256000 153600 

SM 128256 - 256 128000 

6:27.287: IP-EIGRP(Default-IP-Routing-Table:1): route installed for 3.0.0.0 () 

6:27.291: EIGRP: Sending ACK on FastEthernet0/1 nbr 10.1.13.3 


6:27.303: EIGRP: Enqueueing UPDATE on FastEthernet0/0 iidbQ un/rely 0/1 serno 3-3 

6:27.303: EIGRP: Enqueueing UPDATE on FastEthernet0/1 iidbQ un/rely 0/1 serno 3-3 

6:27.307: IP-EIGRP(Default-IP-Routing-Table:1): Int 3.0.0.0/8 metric 409600 - 256000 

153600 

6:27.311: EIGRP: Enqueueing UPDATE on FastEthernet0/0 nbr 10.1.12.2 iidbQ un/rely 0/0 

peerQ un/rely 0/0 serno 3-3 

6:27.311: EIGRP: Sending UPDATE on FastEthernet0/0 

6:27.311: AS 1, Flags 0x0, Seq 19/0 idbQ 0/0 iidbQ un/rely 0/0 serno 3-3 

6:27.315: IP-EIGRP(Default-IP-Routing-Table:1): Int 3.0.0.0/8 metric 409600 - 256000 

153600 

6:27.315: EIGRP: Enqueueing UPDATE on FastEthernet0/1 nbr 10.1.13.3 iidbQ un/rely 0/0 

peerQ un/rely 0/0 serno 3-3 

6:27.319: EIGRP: Sending UPDATE on FastEthernet0/1 

6:27.319: AS 1, Flags 0x0, Seq 20/0 idbQ 0/0 iidbQ un/rely 0/0 serno 3-3 

6:27.367: EIGRP: Received ACK on FastEthernet0/1 nbr 10.1.13.3 


16:27.371: EIGRP: Received ACK on FastEthernet0/0 nbr 10.1.12.2 


R1 receives the route in update with SEQ no 9 , flags are not set, none of CR and initial, flags are 

set. R1 then acks back SEQ no 9, to R3. And it sends the update to R2 and R3 with SEq no 19 and 

20 respectively. But with diff metrics. 

R2 receives the update-


16:25.907: IP-EIGRP(Default-IP-Routing-Table:1): Int 3.0.0.0/8 M 435200 - 256000 179200 SM 

409600 - 256000 153600 

M is total metric (FD) here. SM is advertised metric(RD). 

And at R3: 


16:24.547: IP-EIGRP(Default-IP-Routing-Table:1): Int 3.0.0.0/8 M 4294967295 - 256000 

4294967295 SM 4294967295 - 256000 4294967295 

The poison route is discarded by R3.

Debugging EIGRP-1 The topology used is - The Cisco Learning ...

Create successful ePaper yourself

Delete template?

Save as template?