Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

EIGRP ACK Packet

All,

I have this setup with lo21 (10.21.21.21/24) on r2. And it is in the shutdown state.

r1-------------r2

When I open lo21 on r2, r2 sends the the update packet, but i dont get an acknowledgment packet for that update packet.

R1 immediately sends the update packet back to R2 with delay set to infinity (split horizon stuff).

Does this packet from R1 back to R2 ack as the eigrp acknowlegment? or should I see a specific packet with an acknowledment as the book indicates (tcp/ip vol1 chap 8)

Packet from R2 to R1

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

Frame 54 (82 bytes on wire, 82 bytes captured)

Arrival Time: Jun 23, 2003 16:33:44.265532000

Time delta from previous packet: 2.464942000 seconds

Time relative to first packet: 36.655849000 seconds

Frame Number: 54

Packet Length: 82 bytes

Capture Length: 82 bytes

Ethernet II, Src: 00:0a:8a:a8:c8:80, Dst: 01:00:5e:00:00:0a

Destination: 01:00:5e:00:00:0a (01:00:5e:00:00:0a)

Source: 00:0a:8a:a8:c8:80 (Cisco_a8:c8:80)

Type: IP (0x0800)

Internet Protocol, Src Addr: 10.1.1.2 (10.1.1.2), Dst Addr: IGRP-ROUTERS.MCAST.NET (224.0.0.10)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 68

Identification: 0x0000 (0)

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 2

Protocol: EIGRP (0x58)

Header checksum: 0xcc95 (correct)

Source: 10.1.1.2 (10.1.1.2)

Destination: IGRP-ROUTERS.MCAST.NET (224.0.0.10)

Cisco EIGRP

Version = 2

Opcode = 1 (Update)

Checksum = 0xfd41

Flags = 0x00000000

Sequence = 16

Acknowledge = 0

Autonomous System : 100

IP internal route = 10.21.21.0/24

Type = 0x0102 (IP internal route)

Size = 28 bytes

Next Hop = 0.0.0.0

Delay = 256000

Bandwidth = 256

MTU = 1514

Hop Count = 0

Reliability = 255

Load = 1

Reserved

Prefix Length = 24

Destination = 10.21.21.0

Packet from R1 back to R2

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

Frame 55 (82 bytes on wire, 82 bytes captured)

Arrival Time: Jun 23, 2003 16:33:44.280577000

Time delta from previous packet: 0.015045000 seconds

Time relative to first packet: 36.670894000 seconds

Frame Number: 55

Packet Length: 82 bytes

Capture Length: 82 bytes

Ethernet II, Src: 00:0c:ce:5d:8a:a0, Dst: 01:00:5e:00:00:0a

Destination: 01:00:5e:00:00:0a (01:00:5e:00:00:0a)

Source: 00:0c:ce:5d:8a:a0 (Cisco_5d:8a:a0)

Type: IP (0x0800)

Internet Protocol, Src Addr: 10.1.1.1 (10.1.1.1), Dst Addr: IGRP-ROUTERS.MCAST.NET (224.0.0.10)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 68

Identification: 0x0000 (0)

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 2

Protocol: EIGRP (0x58)

Header checksum: 0xcc96 (correct)

Source: 10.1.1.1 (10.1.1.1)

Destination: IGRP-ROUTERS.MCAST.NET (224.0.0.10)

Cisco EIGRP

Version = 2

Opcode = 1 (Update)

Checksum = 0x903f

Flags = 0x00000000

Sequence = 21

Acknowledge = 0

Autonomous System : 100

IP internal route = 10.21.21.0/24 - Destination unreachable

Type = 0x0102 (IP internal route)

Size = 28 bytes

Next Hop = 0.0.0.0

Delay = 4294967295

Bandwidth = 25600

MTU = 1500

Hop Count = 1

Reliability = 255

Load = 1

Reserved

Prefix Length = 24

Destination = 10.21.21.0

3 REPLIES
Gold

Re: EIGRP ACK Packet

Hmmm.... The second packet is a multicast, and EIGRP doesn't send multicast packets with the ack piggybacked on to them. EIGRP should always send an ack unicast. Technically, this is because the actual number sent to identify the packet is a sequence number, and the sequence numbers each peer is using can overlap (does that make sense?), so there's no way to know which neighbor's sequence number is being acked if the ack is carried in a multicast....

Was there a hello in the middle that you could have missed? An ack looks just like a hello, it just includes a seperate tlv that most protocol analyzers don't do a good job at processing (unfortunately).

Russ.W

New Member

Re: EIGRP ACK Packet

Hey Russboy :)

Sure does what it is ment to at home on my lab. Update/ack update/ack :))

will have to check at work what version of code i was running on. (sorry for the long packet decodes but for everyone else who may be interested)

look at the non-zero ack field with the seqeunce no from the update in it :))

Frame 21 (82 on wire, 82 captured)

Arrival Time: Jul 29, 2003 20:26:38.738831000

Time delta from previous packet: 0.196336000 seconds

Time relative to first packet: 11.411090000 seconds

Frame Number: 21

Packet Length: 82 bytes

Capture Length: 82 bytes

Ethernet II

Destination: 01:00:5e:00:00:0a (01:00:5e:00:00:0a)

Source: 00:d0:ba:e2:21:44 (00:d0:ba:e2:21:44)

Type: IP (0x0800)

Internet Protocol, Src Addr: 10.51.1.1 (10.51.1.1), Dst Addr: 224.0.0.10 (224.0.0.10)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 68

Identification: 0x0000

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 2

Protocol: EIGRP (0x58)

Header checksum: 0xcc64 (correct)

Source: 10.51.1.1 (10.51.1.1)

Destination: 224.0.0.10 (224.0.0.10)

Cisco EIGRP

Version = 2

Opcode = 1 (Update)

Checksum = 0xc112

Flags = 0x00000000

Sequence = 17

Acknowledge = 0

Autonomous System : 100

IP internal route = 10.69.69.0/24

Type = 0x0102 (IP internal route)

Size = 28 bytes

Next Hop = 0.0.0.0

Delay = 128000

Bandwidth = 256

MTU = 1514

Hop Count = 0

Reliability = 255

Load = 1

Reserved

Prefix Length = 24

Destination = 10.69.69.0

Frame 22 (60 on wire, 60 captured)

Arrival Time: Jul 29, 2003 20:26:38.742701000

Time delta from previous packet: 0.003870000 seconds

Time relative to first packet: 11.414960000 seconds

Frame Number: 22

Packet Length: 60 bytes

Capture Length: 60 bytes

Ethernet II

Destination: 00:d0:ba:e2:21:44 (00:d0:ba:e2:21:44)

Source: 00:30:94:91:c0:c4 (00:30:94:91:c0:c4)

Type: IP (0x0800)

Trailer: 000000000000

Internet Protocol, Src Addr: 10.51.1.2 (10.51.1.2), Dst Addr: 10.51.1.1 (10.51.1.1)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 40

Identification: 0x0000

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 2

Protocol: EIGRP (0x58)

Header checksum: 0xa156 (correct)

Source: 10.51.1.2 (10.51.1.2)

Destination: 10.51.1.1 (10.51.1.1)

Cisco EIGRP

Version = 2

Opcode = 5 (Acknowledge)

Checksum = 0xfd85

Flags = 0x00000000

Sequence = 0

Acknowledge = 17

Autonomous System : 100

Frame 23 (82 on wire, 82 captured)

Arrival Time: Jul 29, 2003 20:26:38.754968000

Time delta from previous packet: 0.012267000 seconds

Time relative to first packet: 11.427227000 seconds

Frame Number: 23

Packet Length: 82 bytes

Capture Length: 82 bytes

Ethernet II

Destination: 01:00:5e:00:00:0a (01:00:5e:00:00:0a)

Source: 00:30:94:91:c0:c4 (00:30:94:91:c0:c4)

Type: IP (0x0800)

Internet Protocol, Src Addr: 10.51.1.2 (10.51.1.2), Dst Addr: 224.0.0.10 (224.0.0.10)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 68

Identification: 0x0000

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 2

Protocol: EIGRP (0x58)

Header checksum: 0xcc63 (correct)

Source: 10.51.1.2 (10.51.1.2)

Destination: 224.0.0.10 (224.0.0.10)

Cisco EIGRP

Version = 2

Opcode = 1 (Update)

Checksum = 0xdc0e

Flags = 0x00000000

Sequence = 18

Acknowledge = 0

Autonomous System : 100

IP internal route = 10.69.69.0/24 - Destination unreachable

Type = 0x0102 (IP internal route)

Size = 28 bytes

Next Hop = 0.0.0.0

Delay = 4294967295

Bandwidth = 256000

MTU = 1500

Hop Count = 1

Reliability = 255

Load = 1

Reserved

Prefix Length = 24

Destination = 10.69.69.0

Frame 24 (60 on wire, 60 captured)

Arrival Time: Jul 29, 2003 20:26:38.758641000

Time delta from previous packet: 0.003673000 seconds

Time relative to first packet: 11.430900000 seconds

Frame Number: 24

Packet Length: 60 bytes

Capture Length: 60 bytes

Ethernet II

Destination: 00:30:94:91:c0:c4 (00:30:94:91:c0:c4)

Source: 00:d0:ba:e2:21:44 (00:d0:ba:e2:21:44)

Type: IP (0x0800)

Trailer: 000000000000

Internet Protocol, Src Addr: 10.51.1.1 (10.51.1.1), Dst Addr: 10.51.1.2 (10.51.1.2)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 40

Identification: 0x0000

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 2

Protocol: EIGRP (0x58)

Header checksum: 0xa156 (correct)

Source: 10.51.1.1 (10.51.1.1)

Destination: 10.51.1.2 (10.51.1.2)

Cisco EIGRP

Version = 2

Opcode = 5 (Acknowledge)

Checksum = 0xfd84

Flags = 0x00000000

Sequence = 0

Acknowledge = 18

Autonomous System : 100

Gold

Re: EIGRP ACK Packet

It _shouldn't_ matter what code you are running--EIGRP's reliable transport has worked pretty much the same way since about 10.3.... Anyway, looking at it in the lab, I see this on the router receiving the update about the new route:

2651A#

00:16:31: EIGRP: Received UPDATE on Serial0/0 nbr 208.0.7.4

00:16:31: AS 100, Flags 0x0, Seq 12/6 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

00:16:31: EIGRP: Enqueueing ACK on Serial0/0 nbr 208.0.7.4

00:16:31: Ack seq 12 iidbQ un/rely 0/0 peerQ un/rely 1/0

00:16:31: EIGRP: Sending ACK on Serial0/0 nbr 208.0.7.4

00:16:31: AS 100, Flags 0x0, Seq 0/12 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0

So, we can see the update come in, and the ack retruend.... We don't see the poison here, but that's easy enough to explain, by taking a look at the event log on the router receiving the update:

2651A#sho ip eigrp e

Event information for AS 100:

1 00:16:31.240 Xmit size/gap: 0 0

2 00:16:31.240 Seq/AckSeq: 0 12

3 00:16:31.240 Opcode/Flags: ACK 0x0

4 00:16:31.240 Serno range: 0 0

5 00:16:31.240 Unicast sent: Serial0/0 208.0.7.4

6 00:16:31.236 Metric set: 144.1.1.0/24 4294967295

7 00:16:31.236 Poison squashed: 144.1.1.0/24 metric chg

8 00:16:31.236 Find FS: 144.1.1.0/24 4294967295

9 00:16:31.236 Rcv update met/succmet: 2297856 128256

10 00:16:31.236 Rcv update dest/nh: 144.1.1.0/24 208.0.7.4

11 00:16:31.236 Metric set: 144.1.1.0/24 4294967295

12 00:16:31.236 Seq/AckSeq: 12 6

13 00:16:31.236 Opcode/Flags: UPDATE 0x0

14 00:16:31.236 Packet received: Serial0/0 208.0.7.4

(I've turned on some additional event logging.)

From the bottom to the top.... Since the event log is upside down:

-- The packet comes in, and is classed as an update

-- The update is dissected, and DUAL runs to determine what we need to do about it.

-- DUAL determines this is a new route, so we just install it, and set up a poison reverse.

-- The transport code pulls out all the neighbors on the interface we received the update on, and decides that clears the entire list of neighbors this poison needs to go to, so the poison is "squashed."

-- The ack is queued, and then sent.

So, you do seem to be running something older on the other routers, since you are seeing the poison on the wire. But, I don't know of any time we've ever accepted a multicast poison update as an ack for a packet we just sent. We kindof do this at startup, but it's still a unicast, and the ack is piggybacked onto the poison, which is why I ask about the startup case.

Russ.W

658
Views
0
Helpful
3
Replies
CreatePlease login to create content