Lesson Contents
This packet capture shows what an EIGRP router does when it loses a route and has no feasible successor: it goes active and sends a Query to its neighbors. The Query is multicast, the Reply comes back as unicast, and both are acknowledged. In about 22 milliseconds you see EIGRP’s Reliable Transport Protocol (RTP) at work: sequence numbers, ACKs, and an infinite delay that means “unreachable”.
The EIGRP packets lesson explains all five packet types, and EIGRP queries and stuck in active covers what happens when a reply never arrives. New to EIGRP? Start with the introduction to EIGRP, or browse more captures in the Packet Capture Library.
Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.
Create a free account to download the pcap
Already have an account? Log in and the download button appears here.
Capture overview
| File | eigrp-query-reply.pcapng |
| Packets | 11 (Hellos, 1 Query, 1 Reply, 2 ACKs) |
| Protocol | EIGRP (RFC 7868), IP protocol 88 |
| Devices | Two Cisco IOS routers, R1 (192.168.12.1) and R2 (192.168.12.2), EIGRP named mode, AS 1 |
| Wireshark filter | eigrp or eigrp.opcode == 3 || eigrp.opcode == 4 for queries and replies only |
Packets in this capture
No. Time Source Destination Info
1 0.000000 192.168.12.1 224.0.0.10 Hello
2 0.262264 192.168.12.2 224.0.0.10 Hello
3 4.104106 192.168.12.1 224.0.0.10 Query
4 4.109716 192.168.12.2 192.168.12.1 Hello (Ack)
5 4.120072 192.168.12.2 192.168.12.1 Reply
6 4.126270 192.168.12.1 192.168.12.2 Hello (Ack)
7 4.640980 192.168.12.2 224.0.0.10 Hello
...R1 asks, R2 acknowledges, R2 answers and R1 acknowledges the answer.
Packet walkthrough
Query (packet 3)
R1 lost its route to 1.1.1.1/32 and has no feasible successor. It sends a Query to all neighbors:
Internet Protocol Version 4, Src: 192.168.12.1, Dst: 224.0.0.10
Cisco EIGRP
Version: 2
Opcode: Query (3)
Checksum: 0xf2a5 [correct]
Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
Sequence: 10
Acknowledge: 0
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
Internal Route = 1.1.1.1/32
Type: Internal Route (0x0602)
Length: 45
Topology: 0
AFI: IPv4 (1)
RouterID: 11.11.11.11
Wide Metric
Offset: 0
Priority: 0
Reliability: 204
Load: 0
MTU: 0
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
NextHop: 0.0.0.0
Prefix Length: 32
Destination: 1.1.1.1- Opcode 3: Query. Other opcodes include 1 (Update), 4 (Reply), 5 (Hello) and 10/11 (SIA-Query/SIA-Reply). An ACK is a Hello with a non-zero Acknowledge field.
- Destination 224.0.0.10: queries go to the EIGRP multicast address, so every neighbor on the link receives one copy.
- Sequence 10: queries are reliable, so they carry a sequence number that every neighbor must acknowledge. If a neighbor doesn’t ACK, R1 retransmits the query to that neighbor as unicast.
- Delay: Infinity, Hop Count 255: this is how EIGRP says “I can’t reach this prefix anymore”. The query carries the prefix with an infinite metric.
- Type 0x0602: an IPv4 internal route TLV in the multi-protocol format with wide metrics. You get this TLV with EIGRP named mode. Classic mode uses the older 0x0102 TLV with 32-bit metrics.
- RouterID 11.11.11.11: the EIGRP router ID of the router that originated the prefix. EIGRP uses it to detect loops for external routes, and it helps you find where a prefix came from.
ACK (packet 4)
Internet Protocol Version 4, Src: 192.168.12.2, Dst: 192.168.12.1
Cisco EIGRP
Version: 2
Opcode: Hello (5)
Checksum: 0xfdef [correct]
Flags: 0x00000000
Sequence: 0
Acknowledge: 10
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1An EIGRP ACK is a Hello packet without TLVs, sent as unicast, with the Acknowledge field set. Acknowledge 10 confirms the query with sequence number 10. The ACK itself has sequence 0 because ACKs are unreliable: nobody acknowledges an ACK.
Reply (packet 5)
R2 checks its topology table, has no other path to 1.1.1.1/32 and replies:
Internet Protocol Version 4, Src: 192.168.12.2, Dst: 192.168.12.1
Cisco EIGRP
Version: 2
Opcode: Reply (4)
Checksum: 0xa243 [correct]
Flags: 0x00000000
Sequence: 13
Acknowledge: 10
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
Internal Route = 1.1.1.1/32
Type: Internal Route (0x0602)
Length: 45
Topology: 0
AFI: IPv4 (1)
RouterID: 11.11.11.11
Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: Infinity
Bandwidth: 1000000
Reserved: 0x0000
NextHop: 0.0.0.0
Prefix Length: 32
Destination: 1.1.1.1- Unicast to 192.168.12.1: a reply is only for the router that asked, so it’s unicast. Queries are multicast, replies are unicast.
- Sequence 13: replies are reliable too, so R2 uses its own sequence number. R1 acknowledges it in packet 6 (Acknowledge: 13).
- Acknowledge 10: R2 piggybacks the acknowledgment for the query in the reply. It already sent a separate ACK in packet 4, so this is a duplicate. That’s harmless.
- Delay: Infinity: R2 has no alternative path either, so it answers “unreachable”. R1 receives a reply from every neighbor, the route goes passive again, and R1 removes 1.1.1.1/32 from its routing table. If R2 had a path, the reply would contain a finite metric, and R1 could use R2 as its new successor.
If a neighbor never sends its reply, R1 stays active for that prefix. After half the active timer (90 seconds), R1 sends an SIA-Query. If the neighbor answers with neither a Reply nor an SIA-Reply, the route is Stuck in Active (SIA) and Cisco IOS resets the adjacency with that neighbor.