Cisconinja’s Blog

Archive for the ‘EIGRP’ Category

EIGRP SIA-Query and SIA-Reply

Posted by Andy on September 18, 2009

EIGRP SIA Query and Reply

R1:
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
 ip hold-time eigrp 1 500
 no keepalive
!
router eigrp 1
 network 10.0.0.0
 eigrp log-neighbor-changes

R2:
interface Loopback0
 ip address 10.2.2.2 255.255.255.0
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0
 no keepalive
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
!
router eigrp 1
 timers active-time 1
 network 10.0.0.0
 eigrp log-neighbor-changes

R3:
interface Loopback0
 ip address 10.3.3.3 255.255.255.0
!
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
!
router eigrp 1
 timers active-time 1
 network 10.0.0.0
 eigrp log-neighbor-changes

This first example uses IOS version 12.0(5), which does not have support for SIA-query and SIA-reply messages.  The active timer has been lowered to 1 minute on R2 and R3 in order to see the results faster.  Keepalives have been disabled on the R1-R2 link and the hold timer increased on R1 to prevent R2 from discovering that R1 is down before the active timer expires.  We will shut down R1 S0/0 so that R1 stops receiving traffic from R2, and then shut down R3’s loopback:

R1:
interface Serial0/0
 shutdown

R3:
interface Loopback0
 shutdown

When R3’s loopback gets shutdown, R3 sends a query to R2 for 10.3.3.0/24.  R2 acknowledges the query and sends queries to both R1 and R3 for the route.  R3 acknowledges the query and sends a reply with it’s current metric (infinity).  R2 does not receive an ACK to the query that it sent to R1 so it continues to retransmit it.  R3 continues to wait on a reply from R2, but R2 can’t reply until it receives an ACK and a reply from R1:

1-R3-Topology-Table

1-R2-Topology-Table

R3#debug eigrp packets update ack query reply
Mar 1 00:14:26.075: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 23-23
Mar 1 00:14:26.079: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 23-23
Mar 1 00:14:26.079: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.079: AS 1, Flags 0x0, Seq 21/28 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 23-23
Mar 1 00:14:26.159: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.159: AS 1, Flags 0x0, Seq 0/21 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:14:26.191: EIGRP: Received QUERY on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.191: AS 1, Flags 0x0, Seq 31/21 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:14:26.191: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.195: Ack seq 31 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:14:26.195: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.195: AS 1, Flags 0x0, Seq 0/31 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:14:26.207: EIGRP: Enqueueing REPLY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 24-24
Mar 1 00:14:26.211: EIGRP: Sending REPLY on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.211: AS 1, Flags 0x0, Seq 22/31 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 24-24
Mar 1 00:14:26.255: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:14:26.255: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

 

R2#debug eigrp packets update ack query reply
Mar 1 00:14:26.823: EIGRP: Received QUERY on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.823: AS 1, Flags 0x0, Seq 21/28 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:14:26.823: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.827: Ack seq 21 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:14:26.827: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.827: AS 1, Flags 0x0, Seq 0/21 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:14:26.839: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 18-18
Mar 1 00:14:26.839: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 18-18
Mar 1 00:14:26.843: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.0.12.1 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 18-18
Mar 1 00:14:26.843: EIGRP: Enqueueing QUERY on Serial0/1 nbr 10.0.23.3 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 18-18
Mar 1 00:14:26.843: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1
Mar 1 00:14:26.847: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:26.847: EIGRP: Sending QUERY on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.847: AS 1, Flags 0x0, Seq 31/21 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:26.911: EIGRP: Received ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.911: AS 1, Flags 0x0, Seq 0/31 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:14:26.935: EIGRP: Received REPLY on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.935: AS 1, Flags 0x0, Seq 22/31 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:14:26.935: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.935: Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:14:26.935: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:14:26.935: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:14:31.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 1, RTO 5000
Mar 1 00:14:31.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:36.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 2, RTO 5000
Mar 1 00:14:36.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:41.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 3, RTO 5000
Mar 1 00:14:41.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:46.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 4, RTO 5000
Mar 1 00:14:46.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:51.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 5, RTO 5000
Mar 1 00:14:51.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:14:56.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 6, RTO 5000
Mar 1 00:14:56.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:01.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 7, RTO 5000
Mar 1 00:15:01.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:06.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 8, RTO 5000
Mar 1 00:15:06.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:11.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 9, RTO 5000
Mar 1 00:15:11.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:16.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 10, RTO 5000
Mar 1 00:15:16.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:21.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 11, RTO 5000
Mar 1 00:15:21.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:26.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 12, RTO 5000
Mar 1 00:15:26.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:31.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 13, RTO 5000
Mar 1 00:15:31.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:36.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 14, RTO 5000
Mar 1 00:15:36.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:41.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 15, RTO 5000
Mar 1 00:15:41.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:46.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 16, RTO 5000
Mar 1 00:15:46.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:51.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 17, RTO 5000
Mar 1 00:15:51.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:15:56.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 18, RTO 5000
Mar 1 00:15:56.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:16:01.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 19, RTO 5000
Mar 1 00:16:01.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:16:06.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 20, RTO 5000
Mar 1 00:16:06.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18

The active timer expires first on R3, and R3 assumes R2 is the cause of the problem and clears the adjacency.  A couple seconds later, the adjacency is reestablished and all updates must be resent between R2 and R3.  The active timer expires on R2 a few seconds later and R2 clears the adjacency with R1.  It no longer needs to send a reply to R3 since R3 already reset the adjacency between R2 and R3:

R3#debug eigrp packets update ack query reply
Mar 1 00:16:05.295: %DUAL-3-SIA: Route 10.3.3.0/24 stuck-in-active state in IP-EIGRP 1. Cleaning up
Mar 1 00:16:05.295: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.0.23.2 (Serial0/0) is down: stuck in active
Mar 1 00:16:07.659: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.0.23.2 (Serial0/0) is up: new adjacency
Mar 1 00:16:07.659: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 1-1
Mar 1 00:16:07.663: EIGRP: Sending UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 00:16:07.663: AS 1, Flags 0x1, Seq 23/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-1
Mar 1 00:16:09.051: EIGRP: Received UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 00:16:09.051: AS 1, Flags 0x1, Seq 32/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:16:09.067: EIGRP: Enqueueing UPDATE on Serial0/0 iidbQ un/rely 0/1 serno 25-26
Mar 1 00:16:09.071: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 25-26
Mar 1 00:16:09.663: EIGRP: Sending UPDATE on Serial0/0 nbr 10.0.23.2, retry 1, RTO 3000
Mar 1 00:16:09.663: AS 1, Flags 0x1, Seq 23/32 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2 serno 1-1
Mar 1 00:16:09.707: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:16:09.707: AS 1, Flags 0x0, Seq 0/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
Mar 1 00:16:09.711: EIGRP: Sending UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 00:16:09.711: AS 1, Flags 0x0, Seq 24/32 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 25-26
Mar 1 00:16:09.739: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:16:09.739: AS 1, Flags 0x0, Seq 0/24 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

 

R2#debug eigrp packets update ack query reply
Mar 1 00:16:08.363: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.0.23.3 (Serial0/1) is down: peer restarted
Mar 1 00:16:09.695: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.0.23.3 (Serial0/1) is up: new adjacency
Mar 1 00:16:09.695: EIGRP: Enqueueing UPDATE on Serial0/1 nbr 10.0.23.3 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 1-18
Mar 1 00:16:09.699: EIGRP: Sending UPDATE on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:09.699: AS 1, Flags 0x1, Seq 32/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-18
Mar 1 00:16:10.383: EIGRP: Received UPDATE on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:10.383: AS 1, Flags 0x1, Seq 23/32 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:16:10.383: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:10.387: Ack seq 23 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:16:10.387: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:10.387: AS 1, Flags 0x0, Seq 0/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:16:10.395: EIGRP: Received UPDATE on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:10.395: AS 1, Flags 0x0, Seq 24/32 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:16:10.395: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:10.399: Ack seq 24 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:16:10.399: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:16:10.399: AS 1, Flags 0x0, Seq 0/24 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:16:11.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 21, RTO 5000
Mar 1 00:16:11.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:16:16.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 22, RTO 5000
Mar 1 00:16:16.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:16:21.347: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 23, RTO 5000
Mar 1 00:16:21.347: AS 1, Flags 0x0, Seq 30/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 00:16:21.403: %DUAL-3-SIA: Route 10.3.3.0/24 stuck-in-active state in IP-EIGRP 1. Cleaning up
Mar 1 00:16:21.403: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.0.12.1 (Serial0/0) is down: stuck in active

Note: The active timer is not exact and seems to vary quite a bit from the actual configured time.  In my tests, it took as long as 1 minute over the configured active time for a route to be declared SIA, so the active time may end up expiring on R2 before R3.

The full exchange of non-hello EIGRP packets between R2 and R3 from the time 10.3.3.0/24 went down looks like this:

1-Wireshark

Resetting the adjacency between R2 and R3 obviously does not help the situation and wastes bandwidth and processing on both routers as the adjacency has to be reestablished and updates resent.  Let’s try the same scenario again on IOS version 12.4(15)T5, which supports SIA-query and SIA-reply messages:

R1:
interface Serial0/0
 shutdown

R3:
interface Loopback0
 shutdown

The first part of what happens is the same as before.  R3 sends a query to R2 for 10.3.3.0/24.  R2 acknowledges the query and sends queries to both R1 and R3 for the route.  R3 acknowledges the query and sends a reply with it’s current metric (infinity).  R2 does not receive an ACK to the query that it sent to R1 so it continues to retransmit it.  R3 continues to wait on a reply from R2, but R2 can’t reply until it receives an ACK and a reply from R1:

R3#debug eigrp packets update ack query reply siaquery siareply
Mar 1 00:06:33.299: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 10-10
Mar 1 00:06:33.303: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 10-10
Mar 1 00:06:33.307: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.23.2
Mar 1 00:06:33.307: AS 1, Flags 0x0, Seq 9/7 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 10-10
Mar 1 00:06:33.531: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:06:33.531: AS 1, Flags 0x0, Seq 0/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:06:33.535: EIGRP: Received QUERY on Serial0/0 nbr 10.0.23.2
Mar 1 00:06:33.535: AS 1, Flags 0x0, Seq 13/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:06:33.535: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:06:33.539: Ack seq 13 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:06:33.543: EIGRP: Sending ACK on Serial0/0 nbr
10.0.23.2
Mar 1 00:06:33.543: AS 1, Flags 0x0, Seq 0/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:06:33.551: EIGRP: Enqueueing REPLY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 11-11
Mar 1 00:06:33.559: EIGRP: Sending REPLY on Serial0/0 nbr 10.0.23.2
Mar 1 00:06:33.559: AS 1, Flags 0x0, Seq 10/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11
Mar 1 00:06:33.759: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:06:33.759: AS 1, Flags 0x0, Seq 0/10 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

 

R2#debug eigrp packets update ack query reply siaquery siareply
Mar 1 00:06:33.787: EIGRP: Received QUERY on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.787: AS 1, Flags 0x0, Seq 9/7 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:06:33.791: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.791: Ack seq 9 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:06:33.795: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.799: AS 1, Flags 0x0, Seq 0/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:06:33.803: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 6-6
Mar 1 00:06:33.803: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 6-6
Mar 1 00:06:33.807: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.0.12.1 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 6-6
Mar 1 00:06:33.807: EIGRP: Enqueueing QUERY on Serial0/1 nbr 10.0.23.3 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 6-6
Mar 1 00:06:33.811: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1
Mar 1 00:06:33.815: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:06:33.815: EIGRP: Sending QUERY on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.819: AS 1, Flags 0x0, Seq 13/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:06:33.887: EIGRP: Received ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.887: AS 1, Flags 0x0, Seq 0/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:06:33.979: EIGRP: Received REPLY on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.979: AS 1, Flags 0x0, Seq 10/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:06:33.979: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.979: Ack seq 10 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:06:33.983: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:06:33.983: AS 1, Flags 0x0, Seq 0/10 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:06:38.815: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 1, RTO 5000
Mar 1 00:06:38.819: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:06:43.819: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 2, RTO 5000
Mar 1 00:06:43.823: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:06:48.823: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 3, RTO 5000
Mar 1 00:06:48.827: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:06:53.827: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 4, RTO 5000
Mar 1 00:06:53.831: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:06:58.831: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 5, RTO 5000
Mar 1 00:06:58.835: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6
Mar 1 00:07:03.835: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 6, RTO 5000
Mar 1 00:07:03.839: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6

After approximately half of the configured active timer, R2 and R3 both send an SIA-query to the neighbor that hasn’t replied yet.  (R2’s SIA-query never actually gets sent to R1 since RTP uses a window size of 1 packet and it is still waiting for an ACK to the original query).  R2 ACKs R3’s SIA-query and sends an SIA-reply.  R3 resets the active timer when it receives the SIA-reply.  Since R2 does not receive an SIA-reply from R1, it does not reset the active timer, and once the active timer expires it declares the route stuck in active and resets the adjacency with R1.  R2 is then able to finally reply to R3’s query, and the R2-R3 adjacency does not have to be reestablished:

R3#debug eigrp packets update ack query reply siaquery siareply
Mar 1 00:07:06.087: EIGRP: Enqueueing SIAQUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 12-12
Mar 1 00:07:06.095: EIGRP: Sending SIAQUERY on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:06.095: AS 1, Flags 0x0, Seq 11/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 12-12
Mar 1 00:07:06.131: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:06.131: AS 1, Flags 0x0, Seq 0/11 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:07:06.135: EIGRP: Received SIAREPLY on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:06.135: AS 1, Flags 0x0, Seq 15/11 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:07:06.135: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:06.139: Ack seq 15 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:07:06.139: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:06.143: AS 1, Flags 0x0, Seq 0/15 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:07:33.655: EIGRP: Received REPLY on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:33.659: AS 1, Flags 0x0, Seq 16/11 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:07:33.659: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:33.659: Ack seq 16 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:07:33.663: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 00:07:33.667: AS 1, Flags 0x0, Seq 0/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0

 

R2#debug eigrp packets update ack query reply siaquery siareply
Mar 1 00:07:03.847: EIGRP: Enqueueing SIAQUERY on Serial0/0 nbr 10.0.12.1 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 7-7
Mar 1 00:07:06.367: EIGRP: Received SIAQUERY on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:06.367: AS 1, Flags 0x0, Seq 11/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 00:07:06.371: EIGRP: Enqueueing ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:06.371: Ack seq 11 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:07:06.375: EIGRP: Sending ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:06.375: AS 1, Flags 0x0, Seq 0/11 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 00:07:06.387: EIGRP: Enqueueing SIAREPLY on Serial0/1 nbr 10.0.23.3 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 8-8
Mar 1 00:07:06.395: EIGRP: Sending SIAREPLY on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:06.395: AS 1, Flags 0x0, Seq 15/11 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 8-8
Mar 1 00:07:06.535: EIGRP: Received ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:06.539: AS 1, Flags 0x0, Seq 0/15 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 00:07:08.839: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 7, RTO 5000
Mar 1 00:07:08.843: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2 serno 6-6
Mar 1 00:07:13.843: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 8, RTO 5000
Mar 1 00:07:13.847: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2 serno 6-6
Mar 1 00:07:18.847: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 9, RTO 5000
Mar 1 00:07:18.851: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2 serno 6-6
Mar 1 00:07:23.851: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 10, RTO 5000
Mar 1 00:07:23.855: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2 serno 6-6
Mar 1 00:07:28.855: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.12.1, retry 11, RTO 5000
Mar 1 00:07:28.859: AS 1, Flags 0x0, Seq 12/3 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2 serno 6-6
Mar 1 00:07:33.859: %DUAL-3-SIA: Route 10.3.3.0/24 stuck-in-active state in IP-EIGRP(0) 1. Cleaning up
Mar 1 00:07:33.863: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.12.1 (Serial0/0) is down: stuck in active
Mar 1 00:07:33.875: EIGRP: Enqueueing REPLY on Serial0/1 nbr 10.0.23.3 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 9-9
Mar 1 00:07:33.887: EIGRP: Sending REPLY on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:33.891: AS 1, Flags 0x0, Seq 16/11 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 9-9
Mar 1 00:07:34.039: EIGRP: Received ACK on Serial0/1 nbr 10.0.23.3
Mar 1 00:07:34.043: AS 1, Flags 0x0, Seq 0/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

The full exchange of EIGRP packets between R2 and R3 from the time 10.3.3.0/24 went down excluding hellos looks like this:

2-Wireshark

The two packets that show up as ‘unknown’ in wireshark are the SIA-query (OpCode 10) and the SIA-reply (OpCode 11).  No updates needed to be resent.

EIGRP attempts to send up to 3 SIA-queries to a neighbor about an active route.  Each SIA-query is sent at an interval of 1/2 of the active timer, and each SIA-reply causes the active timer to be reset.  After 3, the router stops sending SIA-queries even if an SIA-reply has been successfully received for each one and allows the active timer to expire if the reply to the original query still hasn’t been received.  To demonstrate this, we will set the active time back to the default of 3 minutes on R2.

R2:
router eigrp 1
 timers active-time 3

R1:
interface Serial0/0
 shutdown

R3:
interface Loopback0
 shutdown

R3#debug eigrp packets update ack query reply siaquery siareply
Mar 1 01:56:43.315: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 14-14
Mar 1 01:56:43.319: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 14-14
Mar 1 01:56:43.323: EIGRP: Sending QUERY on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.323: AS 1, Flags 0x0, Seq 13/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 14-14
Mar 1 01:56:43.547: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.551: AS 1, Flags 0x0, Seq 0/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:56:43.551: EIGRP: Received QUERY on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.555: AS 1, Flags 0x0, Seq 22/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 01:56:43.555: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.555: Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:56:43.559: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.563: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:56:43.579: EIGRP: Enqueueing REPLY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 15-15
Mar 1 01:56:43.583: EIGRP: Sending REPLY on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.583: AS 1, Flags 0x0, Seq 14/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 15-15
Mar 1 01:56:43.735: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:56:43.739: AS 1, Flags 0x0, Seq 0/14 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:57:13.963: EIGRP: Enqueueing SIAQUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 16-16
Mar 1 01:57:13.971: EIGRP: Sending SIAQUERY on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:13.971: AS 1, Flags 0x0, Seq 15/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 16-16
Mar 1 01:57:14.099: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:14.103: AS 1, Flags 0x0, Seq 0/15 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:57:14.107: EIGRP: Received SIAREPLY on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:14.111: AS 1, Flags 0x0, Seq 23/15 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 01:57:14.111: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:14.111: Ack seq 23 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:57:14.115: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:14.119: AS 1, Flags 0x0, Seq 0/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:57:45.863: EIGRP: Enqueueing SIAQUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 17-17
Mar 1 01:57:45.871: EIGRP: Sending SIAQUERY on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:45.871: AS 1, Flags 0x0, Seq 16/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 17-17
Mar 1 01:57:45.979: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:45.979: AS 1, Flags 0x0, Seq 0/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:57:46.003: EIGRP: Received SIAREPLY on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:46.003: AS 1, Flags 0x0, Seq 24/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 01:57:46.003: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:46.007: Ack seq 24 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:57:46.011: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:57:46.011: AS 1, Flags 0x0, Seq 0/24 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:58:18.447: EIGRP: Enqueueing SIAQUERY on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 18-18
Mar 1 01:58:18.455: EIGRP: Sending SIAQUERY on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:18.455: AS 1, Flags 0x0, Seq 17/24 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
Mar 1 01:58:18.575: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:18.579: AS 1, Flags 0x0, Seq 0/17 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:58:18.583: EIGRP: Received SIAREPLY on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:18.587: AS 1, Flags 0x0, Seq 26/17 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 1 01:58:18.587: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:18.587: Ack seq 26 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:58:18.591: EIGRP: Sending ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:18.595: AS 1, Flags 0x0, Seq 0/26 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Mar 1 01:58:51.695: %DUAL-3-SIA: Route 10.3.3.0/24 stuck-in-active state in IP-EIGRP(0) 1. Cleaning up
Mar 1 01:58:51.699: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.23.2 (Serial0/0) is down: stuck in active
Mar 1 01:58:56.391: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.23.2 (Serial0/0) is up: new adjacency
Mar 1 01:58:56.391: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/1 peerQ un/rely 0/0
Mar 1 01:58:56.403: EIGRP: Received UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.403: AS 1, Flags 0x1, Seq 27/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:58:56.407: EIGRP: Sending UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.407: AS 1, Flags 0x1, Seq 18/27 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 1 01:58:56.411: EIGRP: Enqueueing UPDATE on Serial0/0 iidbQ un/rely 0/1 serno 7-7
Mar 1 01:58:56.415: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 7-7
Mar 1 01:58:56.523: EIGRP: Received UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.527: AS 1, Flags 0x8, Seq 28/18 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
Mar 1 01:58:56.527: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.531: Ack seq 28 iidbQ un/rely 0/1 peerQ un/rely 1/1
Mar 1 01:58:56.535: EIGRP: Sending UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.539: AS 1, Flags 0x8, Seq 19/28 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 7-7
Mar 1 01:58:56.695: EIGRP: Received UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.695: AS 1, Flags 0x8, Seq 29/19 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
Mar 1 01:58:56.695: EIGRP: Enqueueing UPDATE on Serial0/0 iidbQ un/rely 0/1 serno 19-20
Mar 1 01:58:56.699: EIGRP: Enqueueing ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.699: Ack seq 29 iidbQ un/rely 0/1 peerQ un/rely 1/1
Mar 1 01:58:56.703: EIGRP: Sending UPDATE on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.707: AS 1, Flags 0x8, Seq 20/29 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 7-7
Mar 1 01:58:56.711: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 10.0.23.2 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 19-20
Mar 1 01:58:56.827: EIGRP: Received ACK on Serial0/0 nbr 10.0.23.2
Mar 1 01:58:56.831: AS 1, Flags 0x0, Seq 0/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2

The route remains active for a little over 2 minutes (twice the active time and four times the SIA retransmit interval).  When the original reply still hasn’t been received from R2 and the active time expires after 3 SIA-queries/replies, R3 resets the adjacency and updates are resent.

Posted in EIGRP | Leave a Comment »

Offset-lists in EIGRP

Posted by Andy on September 7, 2009

EIGRP Offset Lists

R1:
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Serial0/0
 bandwidth 128
 ip address 10.0.12.1 255.255.255.0
!
router eigrp 1
 network 10.0.0.0

R2:
interface Serial0/0
 bandwidth 128
 ip address 10.0.12.2 255.255.255.0
!
router eigrp 1
 network 10.0.0.0

The minimum bandwidth for 10.1.1.0/24 at R2 is 128k and the cumulative delay is 25,000 microseconds (20,000 serial + 5,000 loopback), so R2 calculates the metric as:

Metric = 256 * (10^7 / 128) + 256 * 2500

= 20,000,000 + 640,000

= 20,640,000

1-R2-Show-IP-Route

Now we will add an offset of 10,000 to all routes advertised by R1:

R1:
router eigrp 1
 offset-list 0 out 10000

Let’s see how this effected the update sent by R1.  The first picture shows the update before the offset-list was applied, and the second shows the update after being applied:

1-R1-Update

2-R1-Update

Loopback interfaces have a default delay of 5,000 microseconds and the value carried in the update for delay is after it has been multiplied by 256, so before the offset-list R1 advertises it as 128,000.  After the offset-list was configured, the delay advertised in the update increased to 138,000, so the offset is applied to delay after it has been multiplied by 256.  Since the delay is cumulative along the path and the offset is applied after the delay has been multiplied by 256, the overall metric for routers receiving the update will increase by the same value configured in the offset.  On R2, the composite metric has increased from 20,640,000 to 20,650,000:

2-R2-Show-IP-Route

To determine the actual delay along the path (in tens of microseconds), R2 divides the delay value received in the update by 256, and then adds it’s own delay on the receiving interface:

Delay = (138,000 / 256) + 2,000

= 2539.0625

When converted back to microseconds and rounded down, this matches the total delay of 25,390 shown for the route on R2.  To find the delay that will be added by the configured offset value, you could also multiply by 10/256:

10,000 * (10/256) = 390 microseconds

 

The configured offset will match the offset applied to the composite metric as long as K3 = 1 and K5 = 0.  If either of these are changed it isn’t quite as simple.  Let’s try changing K3 to a value of 20 first.  We will also remove the offset-list and then add it again after we have seen the initial update and metric calculation:

R1:
router eigrp 1
 metric weights 0 1 0 20 0 0
 no offset-list 0 out 10000

R2:
router eigrp 1
 metric weights 0 1 0 20 0 0

3-R1-Update

3-R2-Show-IP-Route

The update still contains a delay of 128,000, so we know that the value carried in the update must be before being multiplied by K3.  R2 multiplies the delay of the receiving interface by 256, adds this to the delay in the received update and multiplies the sum by K3, and also adds the bandwidth component:

Metric = 256 * (10^7 / 128) + 20 * (128,000 + (256 * 2,000))

= 20,000,000 + 12,800,000

= 32,800,000

Let’s put the offset-list back on:

R1:
router eigrp 1
 offset-list 0 out 10000

4-R1-Update

4-R2-Show-IP-Route

The update contains 138,000 for the delay value like before when K3 was 1.  R2 calculates the metric as 

Metric = 256 * (10^7 / 128) + 20 * (138,000 + (256 * 2,000))

= 20,000,000 + 13,000,000

= 33,000,000

Since the offset gets multiplied by K3 just like the rest of the delay, the actual metric increases by K3 * offset, or 200,000 in this case.  The calculation for total delay of the path does not depend on K-values, so R2 calculates the same total delay of 25,390 microseconds.  Let’s try changing K3 to 0:

R1:
router eigrp 1
 metric weights 0 1 0 0 0 0
 no offset-list 0 out 10000

R2:
router eigrp 1
 metric weights 0 1 0 0 0 0

5-R1-Update

5-R2-Show-IP-Route

R1:
router eigrp 1
 offset-list 0 out 10000

 

6-R1-Update

6-R2-Show-IP-Route

If K3=0, the offset has no effect on the overall metric since it only adds to the delay.  R2 is still able to calculate the correct total delay for the route however since the delay value is carried in route TLVs regardless of the K-values.

 

Next, we will look at what happens when K5 ≠ 0.  The K-values will be set to: K1=1, K2=0, K3=20, K4=1, K5=64.  The offset-list is again removed:

R1:
router eigrp 1
 metric weights 0 1 0 20 1 64
 no offset-list 0 out 10000

R2:
router eigrp 1
 metric weights 0 1 0 20 1 64

The received delay is 128,000 like before.  Since K5 is non-zero, R2 performs an additional calculation and calculates the metric as:

Metric = (256 * (10^7 / 128) + 20 * (128,000 + (256 * 2,000))) * (64 / (255 + 1))

= (20,000,000 + 12,800,000) * (64/256)

= 8,200,000

7-R2-Show-IP-Route

Add the offset again:

R1:
router eigrp 1
 offset-list 0 out 10000

Metric = (256 * (10^7 / 128) + 20 * (138,000 + (256 * 2,000))) * (64 / (255 + 1))

= (20,000,000 + 13,000,000) * (64/256)

= 8,250,000

8-R2-Show-IP-Route

The configured offset value is multiplied by K3, and (if K5 ≠ 0) also by (K5 / (reliability + K4)).  Therefore the actual amount that the configured offset will cause the metric to increase can be calculated as:

Metric increase = K3 * offset * (K5 / (reliability + K4))

In the example we just did, the offset of 10,000 caused the metric to increase by 50,000:

Metric increase = 20 * 10,000 * (64 / (255 +1))

= 50,000

 

Most of the time with offset-lists we are trying to add a certain amount to the overall metric of a route, so it would be much more useful to know the amount of offset that we need to add in order to get the desired metric increase.  Solving the equation for offset gives us:

offset = metric increase * (reliability + K4) / (K3 * K5)

Let’s try another example and see if it works.  We will pick some new K-values and remove the offset-list:

R1:
router eigrp 1
 metric weights 0 5 0 10 45 4
 no offset-list 0 out 10000

R2:
router eigrp 1
 metric weights 0 5 0 10 45 4

9-R2-Show-IP-Route

The metric for the route is now 1,418,666.  Let’s see if we can add 81,334 to it to make it an even 1,500,000.  That means we should have to offset the metric by:

offset = 81,334 * (255 + 45) / (10 * 4)

= 610,005

R1:
router eigrp 1
 offset-list 0 out 610005

10-R2-Show-IP-Route

Looks like it worked perfectly.  The delay added was:

610,005 * (10/256) = 23,828 microseconds

which makes the total delay of the route now 48,828 microseconds.

Posted in EIGRP | Leave a Comment »

Testing EIGRP metric with non-default K-values

Posted by Andy on September 6, 2009

In this post we will look at how changing EIGRP K-values from their defaults effects the metric calculation and how it effects when updates are sent.  The topology and configurations for this example are shown below:

EIGRP Topology

R1:
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
!
router eigrp 1
 passive-interface Loopback0
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

R2:
interface FastEthernet0/0
 ip address 10.2.2.2 255.255.255.0
!
interface Serial0/0
 bandwidth 100
 ip address 10.0.12.2 255.255.255.0
 load-interval 30
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
 load-interval 30
!
router eigrp 1
 passive-interface FastEthernet0/0
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

R3:
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
 load-interval 30
!
router eigrp 1
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

Each of the K-values has been set to 1 on all routers.  The bandwidth of the R1-R2 link has also been lowered to 100k on R2.

The EIGRP metric is calculated as:

Metric = ((k1 * BW) + ((k2 * BW)/(256 – load)) + (k3 * delay)) * (k5 / (reliability + k4))

BW = 256 * (10^7 / interface BW in kbps)

load = txload on the interface

delay = 256 * interface delay in tens of microseconds

reliability = reliability rating on the interface

Of the 4 metric components, only the delay is added at each hop.  The other 3 (BW, load, reliability) use the worst value of any single link in the path.  When calculating the composite metric, each individual component is rounded down.   For example, loopback interfaces have a default bandwidth of 8 Gbps:

1-R1-BW

R1 therefore calculates the bandwidth as 10^7 / (8 * 10^6).  The bandwidth value is rounded down (from 1.25 to 1) before being multiplied by 256, and the value carried for BW in the route TLV is 256 (instead of 320, if the rounding had occurred after):

1-R1-BW-Wireshark

When the calculation is reversed, the result is that as far as R1’s topolgy table and any neighbors that R1 is advertising the route to are concerned, the BW is 10 Gbps, as shown in the topology table on R1:

1-R1-Metric

A similar method of rounding occurs for each of the other components.  Loopback interfaces have a default delay of 5000 microseconds and the reliability and load on the interface are 255 and 1 respectively.  The overall calculated metric on R1 is:

Metric = ((1 * 256) + ((1 * 256)/(256 – 1)) + (1 * 128,000)) * (1 / (255 + 1))

= (256 + 1 + 128000) / 256

= 128,257 / 256

=  501

The load component was rounded down (from 256/255 to 1) prior to being multiplied by (k5 / (reliability + k4)) and the final metric was again rounded down (from 501.0039 to 501).  R2’s calculation works the same way:

Metric = ((1 * 25,600,000) + ((1 * 25,600,000)/(256 – 1)) + (1 * 640,000)) * (1 / (255 + 1))

= (25,600,000 + 100,392 + 640,000) / 256

= 26,340,392 / 256

= 102,892

1-R2-Metric

R3 computes the metric as:

Metric = ((1 * 25,600,000) + ((1 * 25,600,000)/(256 – 1)) + (1 * 1,152,000)) * (1 / (255 + 1))

= (25,600,000 + 100,392 + 1,152,000) / 256

= 26,852,392 / 256

= 104,892

1-R3-Metric

As you can see, only the delay increased when R2 advertised the route to R3 (by 20,000 microseconds, the default on a serial interface) since the other 3 values only use the worst value in the path and the BW, load, and reliability on the R2-R3 link from R3’s perspective are either better than or equal to the worst values that were advertised by R2.

 

And now for the main point of this example, to show how including load and reliability in the equation effects updates being sent.  Many sources incorrectly say that including load and reliability in the equation is not recommended because it will cause updates to be sent frequently when the load and/or reliability change.  The actual behavior is that EIGRP advertises the route only at the start of the adjacency or after an event that causes updates to be resent, with whatever the current worst load and reliability rating along the path are.  In many cases this could be even worse than if updates were frequently sent to update the load and reliability ratings, because the load and/or reliability can change dramatically after an update has been sent and neighboring routers continue to assume the original load/reliability values that were advertised before the change.  To demonstrate this, we will add an additional router, R4, with links to R1 and R3:

EIGRP Topology3

 

R1:
interface Serial0/2
 ip address 10.0.14.1 255.255.255.0
 load-interval 30

R3:
interface Serial0/1
 ip address 10.0.34.3 255.255.255.0
 load-interval 30

R4:
interface Serial0/0
 bandwidth 100
 ip address 10.0.14.4 255.255.255.0
 load-interval 30
 delay 2001
!
interface Serial0/1
 ip address 10.0.34.4 255.255.255.0
 load-interval 30
!
router eigrp 1
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

The bandwidth on the R1-R4 link is configured as 100k like the R1-R2 link and the delay as 20,010 microseconds to make the path through R2 preferred by R3.  R3 keeps the path through R4 as an FS but since unequal cost load balancing is not configured, R3 will only use the original link to reach R1:

3-R3-ShowTopology

3-R3-RouteTable

Next, we will use a host on the 10.2.2.0/24 subnet connected to R2 to send approximately 96kbps of traffic to R1 (for more information on the method of generating traffic, see WFQ tests):

flood.pl --port=1000 --size=1496 --delay=125 10.1.1.1

All traffic is sent out S0/0 on R2 and the txload increases to 234:

3-R2-Load

After several minutes, R2 still has not updated the metric in it’s topology and also has not sent an update to R3:

4-R2-ShowTopology

4-R3-ShowTopology

4-R3-RouteTable

Although the R1-R2 link is almost entirely saturated and R3 would have a better path through R4, it is unaware of this because updates are not sent to dynamically update the load and reliability.  Next we will clear the R1-R2 adjacency, causing updates to be resent (clearing the R2 to R3 adjacency would not refresh the load value, because R2 simply sends R3 the same information about 10.1.1.0/24 that already exists in it’s routing table):

R2#clear ip eigrp neighbors 10.0.12.1

R2 receives an update from R1 and records the higher of the received load value (1) and the load of the receiving link (232).  R2 then sends an update to R3 and R3 records the higher of the received load value (232) and the receiving link (1).  R3’s metric for 10.1.1.0/24 through R2 is now higher than through R4, so R3 now uses the path through R4 instead:

5-R3-ShowTopology

5-R3-RouteTable

Note: The FD of the successor on R3 in the topology table as well as the metric in the route table show 104,893, while the FD listed in the topology table for the route on the third line says 104,892 (the original FD of the route through R2).  I think this happens whenever the router is able to switch to an FS for a route without having to go active – the route table and FD through the successor show the new value but the overall FD for the route shows the original FD for the route.

Let’s check the topology table on R2:

5-R2-ShowTopology

That’s strange, R2 and R3 both show the correct load value but the FD at R2 doesn’t match the AD that R3 calculated through R2.  Using the formula, the FD at R2 should be:

Metric = ((1 * 25,600,000) + ((1 * 25,600,000)/(256 – 232)) + (1 * 640,000)) * (1 / (255 + 1))

= (25,600,000 + 1,066,666 + 640,000) / 256

= 27,306,666 / 256

= 106,666

R3 calculated the AD correctly for R2 and also calculated it’s own FD of 108,666 through R2 correctly.  Looking back at the previous topology table on R2 we can see that the metric hasn’t changed at all on R2 – R2 is still calculating the metric as if there is a load of 1.  It appears that although R2 records the higher of the two load values (the one in the received update and the one on the receiving interface) and also advertises the higher one to R3, it only uses the one in the received update for it’s own calculation.  I can’t figure out why this would be desirable since a saturated link between R1 and R2 effects R2 just as much as R3 or any other upstream routers, but there are already enough reasons not to use load or reliability in a production network anyway.

 

As one last test, we will stop the traffic generator.  After a few seconds the interface load is updated on R2 and drops back to 1:

6-R2-Load

Like before, R2 does not dynamically refresh the load value in it’s own topology table or send updates to it’s neighbors.  R3 continues to use the route through R4 to reach 10.1.1.0/24 until something causes updates to be resent between R1 and R2:

6-R3-RouteTable

Posted in EIGRP | Leave a Comment »

CBWFQ, Routing Protocols, and max-reserved-bandwidth

Posted by Andy on February 18, 2009

Numerous sources, including Cisco documentation, often say that the percentage of bandwidth excluded from max-reserved-bandwidth (25% by default) is reserved for either link queues (routing updates, keepalives, etc.), unclassified best-effort traffic (matched by class-default), or both.  The 12.4 Mainline command reference for max-reserved-bandwidth says:

The sum of all bandwidth allocation on an interface should not exceed 75 percent of the available bandwidth on an interface. The remaining 25 percent of bandwidth is used for overhead, including Layer 2 overhead, control traffic, and best-effort traffic.

As can be seen in the previous CBWFQ tests that were performed, this definitely does not hold true for best-effort traffic that is put into dynamic conversations.  What about routing updates and other important traffic that ends up in the link queues?  To test this out, we will use the same simple topology shown below in IOS 12.4(18):

topology

R1:
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 load-interval 30
 speed 100
 full-duplex
 no keepalive
 no mop enabled
!
interface Serial0/0
 ip address 10.1.12.1 255.255.255.0
 load-interval 30
 no keepalive
!
no cdp run

R2:
interface Serial0/0
 ip address 10.1.12.2 255.255.255.0
 load-interval 30
 no keepalive
!
no cdp run

Next we will configure EIGRP on R1 and R2 and decrease the hello and hold timers to give us a little bit more traffic:

R1:
router eigrp 1
 network 10.1.12.1 0.0.0.0
 no auto-summary
!
interface Serial0/0
 ip hello-interval eigrp 1 1
 ip hold-time eigrp 1 3

R2:
router eigrp 1
 network 10.1.12.2 0.0.0.0
 no auto-summary
!
interface Serial0/0
 ip hello-interval eigrp 1 1
 ip hold-time eigrp 1 3

Next we will configure R2 to measure incoming traffic.  A TFTP flow will be used to create congestion, so we will create 3 different classes to measure TFTP, EIGRP hellos, and EIGRP updates (we will see later on why it was a good idea to measure EIGRP hellos and updates separately):

R2:
ip access-list extended EIGRP-Hello
 permit eigrp any host 224.0.0.10
ip access-list extended EIGRP-Update
 permit eigrp any host 10.1.12.2
ip access-list extended TFTP
 permit udp any any eq tftp
!
class-map match-all EIGRP-Hello
 match access-group name EIGRP-Hello
class-map match-all EIGRP-Update
 match access-group name EIGRP-Update
class-map match-all TFTP
 match access-group name TFTP
!
policy-map Traffic-Meter
 class EIGRP-Hello
 class EIGRP-Update
 class TFTP
!
interface Serial0/0
 service-policy input Traffic-Meter

Now let’s shutdown and re-enable R2’s S0/0 interface and examine how the EIGRP adjacency forms in the absence of congestion:

R2:
interface Serial0/0
 shutdown

A few seconds later…

R2:
interface Serial0/0
 no shutdown

wireshark1

cbwfq2-1-r2pmap

We can see that hello packets are being sent every 1 second in each direction.  When the adjacency forms, 3 update packets are exchanged in each direction followed by an acknowledgement from R1 to R2.  Each of the hello packets has size 64 bytes, which is confirmed in both Wireshark and the policy-map on R2.  Each of the update and acknowledgement packets has size 44 bytes.  Therefore we can expect that EIGRP traffic will use about 512 bps from hellos (8 * 64) plus a small amount of additional bandwidth from updates and acknowledgements at the start.  Next we will configure CBWFQ on R1 and shape traffic to 32 kbps:

R1:
ip access-list extended TFTP
 permit udp any any eq tftp
!
class-map match-all TFTP
 match access-group name TFTP
!
policy-map CBWFQ
 class TFTP
  bandwidth percent 75
 class class-default
  fair-queue 4096
policy-map Shaper
 class class-default
  shape average 32000
  service-policy CBWFQ
!
interface Serial0/0
 service-policy output Shaper

TFTP has been given 75% bandwidth, and the max-reserved-bandwidth has not been changed from the default of 75%.  If the remaining 25% (8,000 bps) is actually used for link queues, EIGRP should have way more bandwidth than it needs.  Now we will generate 64 kbps of TFTP traffic, more than enough to saturate the link and cause CBWFQ to begin:

flood.pl --port=69 --size=996 --delay=125 10.1.12.2

Within a few seconds, the following log messages repeatedly show up:

R1:
*Mar 1 04:25:31.998: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 04:25:32.930: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is up: new adjacency
*Mar 1 04:25:40.302: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 04:25:41.242: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is up: new adjacency
*Mar 1 04:25:48.278: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 04:25:49.222: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is up: new adjacency
*Mar 1 04:25:56.538: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 04:25:57.530: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is up: new adjacency
*Mar 1 04:26:04.782: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 04:26:05.730: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.2 (Serial0/0) is up: new adjacency

R2:
*Mar 1 04:26:34.506: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 04:26:37.506: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: holding time expired
*Mar 1 04:26:42.774: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 04:26:45.770: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: holding time expired
*Mar 1 04:26:51.242: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 04:26:54.238: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: holding time expired
*Mar 1 04:26:59.298: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 04:27:02.298: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: holding time expired
*Mar 1 04:27:07.522: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 04:27:10.518: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: holding time expired

On R2, we can see that the hold timer keeps expiring and approximately every 8 to 8.5 seconds the adjacency is reforming.  Next take a look at the queues on R1 and the traffic  received on R2:

cbwfq2-2-r1queue

cbwfq2-2-r2pmap

As we saw in previous CBWFQ tests, CBWFQ uses a constant that is based on the number of WFQ dynamic queues when calculating the weights for user defined conversations as shown in the following table:

Number of flows

Constant

16

64

32

64

64

57

128

30

256

16

512

8

1024

4

2048

2

4096

1

We configured WFQ to use 4096 dynamic conversations, which results in the smallest possible constant.  Using the formula to calculate weights for user defined conversations, TFTP is assigned a weight of:

1  * (100 / 75)   = 1.33

When rounded up this becomes 2 as shown in the show traffic-shape queue output.  We also see 2 other conversations with packets enqueued.  Both are IP protocol 88, so we know they are both EIGRP.  One of them has destination address 224.0.0.10 and size 64 (EIGRP hellos) and the other has destination address 10.1.12.2 and size 44 (EIGRP updates).  Interestingly, they have both been given very different weight values.  The conversation number for EIGRP hellos (4103) falls within the range of the link queues (N through N+7, where N is the number of WFQ queues) and the weight of 1024 is also the same as the weight for link queues.  The conversation number for EIGRP updates (137) however falls within the range of dynamic queues (0 through N-1), and we can see that it’s weight of 4626 is consistent with a dynamic conversation that has IP Precedence of 6 ((32384 / (6 + 1)).  Because the link queue’s weight of 1024 is 512 times larger than TFTP’s weight of 2, TFTP will be able to send 512 times as many bytes.  Looking at the byte count of received traffic on R2, we can see that the results match this (1,149,000 / 2,240 = 512.9).  This also explains why the EIGRP adjacency reformed every 8 to 8.5 seconds.  For every 1 hello that EIGRP is allowed to send on R1 (512 bits), TFTP is allowed to send 262,144 bits (512 * 512).  The total time required for this is ((512 + 262,144) / 32,000) or about 8.2 seconds.  This is somewhat of an extreme example since we configured the max amount of WFQ dynamic queues in order to minimize TFTP’s weight and also shaped to a very low rate, but the main point here is that the 25% unallocated bandwidth is not reserved for anything.  Any non-priority queue can consume as much of the bandwidth as it’s weight relative to the other queues allows it to.

 

For one final test, let’s decrease the number of WFQ dynamic queues to a value such that the link queue can send at least 512 bps for EIGRP hellos:

R1:
policy-map CBWFQ
 class class-default
  fair-queue 256

Using 256 dynamic queues, the weight of TFTP will be:

16 * (100 / 75)   = 21.33

IOS rounds this to 21:

cbwfq2-3-r1queue1

The share that each queue receives is inversely proportional to it’s weight.  One way of finding the share that EIGRP hellos will receive is:

1 / ((1024 / 21) + (1024 / 1024) + (1024 / 4626))   =  2%, or about 640 bps

This should be a little more than enough to allow a hello packet every second, and looking at the output above we can see that only 1 packet is in the queue.  However, now there is a new problem:

R2:
*Mar 1 05:45:01.462: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: retry limit exceeded
*Mar 1 05:45:01.478: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 05:46:20.998: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: retry limit exceeded
*Mar 1 05:46:21.226: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 05:47:40.746: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: retry limit exceeded
*Mar 1 05:47:41.242: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 05:49:00.758: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: retry limit exceeded
*Mar 1 05:49:01.502: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency
*Mar 1 05:50:21.014: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: retry limit exceeded
*Mar 1 05:50:21.226: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency

Approximately every 1 minute and 20 seconds, we see ‘retry limit exceeded’ followed by the adjacency coming back up less than 1 second later.  A debug eigrp packets update shows what is happening:

R2:
*Mar  1 06:08:22.550: EIGRP: Sending UPDATE on Serial0/0 nbr 10.1.12.1, retry 14, RTO 5000
*Mar  1 06:08:22.550:   AS 1, Flags 0x1, Seq 1186/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
*Mar  1 06:08:27.554: EIGRP: Sending UPDATE on Serial0/0 nbr 10.1.12.1, retry 15, RTO 5000
*Mar  1 06:08:27.554:   AS 1, Flags 0x1, Seq 1186/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
*Mar  1 06:08:32.558: EIGRP: Sending UPDATE on Serial0/0 nbr 10.1.12.1, retry 16, RTO 5000
*Mar  1 06:08:32.558:   AS 1, Flags 0x1, Seq 1186/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
*Mar  1 06:08:37.566: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is down: retry limit exceeded
*Mar  1 06:08:37.758: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency

R2 does not receive an acknowledgement from R1 for it’s update so it retries a total of 16 times at 5 second intervals.  Remember that EIGRP updates and acknowledgments were assigned to a dynamic conversation and given a weight of 4,626 based on their IPP of 6 – as a result, they cannot be scheduled in time, and after the last retry R2 takes the adjacency down.  Since we manipulated the TFTP queue weight so that a link queue has just more than enough bandwidth to send an EIGRP hello every second, the adjacency comes back up less than a second later, resulting in a very strange overall behavior.

Posted in EIGRP, QoS | 2 Comments »