Debug eigrp

Debug eigrp DEFAULT

Troubleshooting Eigrp Authentication

Last Updated on Thu, 17 Dec 2020 | Routing Table

The last step in the flowchart in Figure 5-8 is to troubleshoot EIGRP authentication problems, if configured. This is accomplished by verifying that EIGRP authentication is successful.

Example: Successful MD5 Authentication

The output of the debug eigrp packets command on Router X, shown in Example 5-17, illustrates that Router X is receiving EIGRP packets with MD5 authentication and a key ID equal to 1 from Router Y.

Example 5-17 Confirming MD5 Authentication on Router X

RouterX# debug eigrp packets

EIGRP Packets debugging is on

(UPDATE, REQUEST,

QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY

SIAREPLY)

*Jan 21 16:38:51.745:

EIGRP: received packet with MD5 authentication, key id =

1

*Jan 21 16:38:51.745:

EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102

*Jan 21 16:38:51.745:

AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

peerQ

un/rely 0/0

Similarly, the output of the debug eigrp packets command on Router Y, shown in Example 5-18, illustrates that Router Y is receiving EIGRP packets with MD5 authentication and a key ID equal to 2 from Router X.

Example 5-18 Confirming MD5 Authentication on Router Y

RouterY# debug eigrp packets

EIGRP Packets debugging is on

(UPDATE, REQUEST,

QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY

SIAREPLY)

RouterY#

*Jan 21 16:38:38.321:

EIGRP: received packet with MD5 authentication, key id =

2

*Jan 21 16:38:38.321:

EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.101

*Jan 21 16:38:38.321:

AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

peerQ

un/rely 0/0

Example: Troubleshooting MD5 Authentication Problems

In the example, the key string for key 2 of Router X, the one that is used when EIGRP packets are sent, is changed to be different from the key string that Router Y is expecting.

The output of the debug eigrp packets command on Router Y, shown in Example 5-19, illustrates that Router Y is receiving EIGRP packets with MD5 authentication and a key ID equal to 2 from Router X, but that an authentication mismatch exists. The EIGRP packets from Router X are ignored, and the neighbor relationship is declared to be down. The output of the show ip eigrp neighbors command should confirm that Router Y has no EIGRP neighbors.

Example 5-19 MD5 Authentication Mismatch

RouterY# debug eigrp packets

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY) RouterY#

*Jan 21 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch

*Jan 21 16:50:18.749: EIGRP: Serial0/0/1: ignored packet from 192.168.1.101, opc ode = 5 (invalid authentication)

*Jan 21 16:50:18.749: EIGRP: Dropping peer, invalid authentication *Jan 21 16:50:18.749: EIGRP: Sending HELLO on Serial0/0/1

*Jan 21 16:50:18.749: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 *Jan 21 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.101 (Serial0/0/1) is down: Auth failure

RouterY# show ip eigrp neighbors

IP-EIGRP neighbors for process 100 RouterY#

The two routers keep trying to reestablish their neighbor relationship. Because of the different keys that are used by each router in this scenario, Router X authenticates the hello messages that are sent by Router Y using key 1. However, when Router X sends a hello message back to Router Y using key 2, an authentication mismatch will occur. From the perspective of Router X, the relationship appears to be up for a while, but then it times out, as illustrated by the messages that were received on Router X, shown in Example 5-20. The output of the show ip eigrp neighbors command on Router X also illustrates that Router X does have Router Y in its neighbor table for a short time.

Example 5-20 Confirming MD5Authentication

RouterX# debug eigrp packets

*Jan 21 16:54:09.821: %DUAL-5-NBRCHANGE 0/1) is down: retry limit exceeded

: IP-EIGRP(0)

100:

Neighbor

192

168.1

2 0

(Serial0/

*Jan 21 16:54:11.745: %DUAL-5-NBRCHANGE 0/1) is up: new adjacency

: IP-EIGRP(0)

100:

Neighbor

192

168.1

2 0

(Serial0/

RouterX# show ip eigrp neighbors

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec)

(ms)

Cnt Num

0 192.168.1.102 Se0/0/1 13 00:

00:38 1

5000

1 0

Continue reading here: Summary of Troubleshooting EIGRP

Was this article helpful?

Sours: https://www.ccexpert.us/routing-table/troubleshooting-eigrp-authentication.html

Troubleshoot EIGRP Common Issues

Introduction

This document describes how to troubleshoot the most common Enhanced Interior Gateway Routing Protocol (EIGRP) issues.

Note: This document uses examples and implementation in Cisco IOS® in order to illustrate the various behaviors that can be encountered.

Background Information

This is the topology that is used for this document:

EIGRP troubleshooting - Topology diagram

The sections that follow describe some of the most common EIGRP issues and some tips about how to troubleshoot the issues.

Neighbor Flapping

The single most common issue that is encountered with the use of EIGRP is that it does not establish a neighborship properly. There are several possible causes for this:

  • Maximum Transmission Unit (MTU) issue

  • One-way communication (unidirectional links)

  • There is a multicast problem on the link

  • Unicast problems

  • Link quality problems

  • Authentication issues

  • Misconfiguration issues

If you do not receive an EIGRP Hello message, you cannot see the neighbor in the neighbor list. Enter the show ip eigrp neighbors command in order to view the EIGRP neighbor information and identify the issue:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             12 00:00:48    1  5000  1  0
2   10.1.1.3                Et0/0             12 02:47:13   22   200  0  339
1   10.2.1.4                Et1/0             12 02:47:13   24   200  0  318
0   10.2.1.3                Et1/0             12 02:47:13   20   200  0  33813   20   200  0  338

If you think that the neighborship has been formed, but you do not have the prefixes that you should learn from that neighbor, check the output of the previous command: If the Q-count is always non-zero, it could be an indication that the same EIGRP packets are retransmitted continuously. Enter the show ip eigrp neighbors detail command in order to verify whether the same packet is always sent. If the sequence number of the first packet is always the same, then the same packet is retransmitted indefinitely:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0
   Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack
    UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced
2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

You can see in the output that the first neighbor has a problem, and the Uptime is reset.

It is important that you verify whether the process router EIGRP has the eigrp log-neighbor-changes command. However, this command is included by default since Cisco bug ID CSCdx67706, so it does not show up in the configuration in that case. Check the entry in the logs for both of the EIGRP neighbors on each side of the link. In at least one of the logs, there should be a meaningful entry.

Here are all of the possible reasons for an EIGRP neighborship change and their log entries:

  • No EIGRP packet was received during the hold time:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    holding time expired
  • An EIGRP reliable packet was not acknowledged within the retry limit:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    retry limit exceeded
  • The EIGRP sees the interface in a down state:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
    interface down
  • The router received an initial update packet and restarted the neighborship:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    peer restarted
  • The router received an initial update packet and formed a new adjacency:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
    new adjacency
  • The clear ip eigrp neighbor command was entered, which resulted in a manual clear:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:
    manually cleared
  • The IP address on the interface was changed:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:
    address changed
  • There was a delay/bandwidth change on the interface:

    Note: This only occurs in older code versions. There is no neighbor flap since Cisco bug ID CSCdp08764.

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
    metric changed
  • The K-values are misconfigured or a graceful shutdown occurs:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
    K-value mismatch
  • A graceful shutdown occurs:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    Interface Goodbye received
  • The ip authentication mode eigrp 1 md5 command was configured on the interface:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
    authentication mode changed
  • A graceful restart/Non-Stop Forwarding (NSF) occurred:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:
    peer graceful-restart
  • The neighbors to which there are queries sent without a reply received are cleared:

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:
    stuck in active

Network Problems

These five issues indicate a network problem:

  • A Stuck-In-Active (SIA) state

  • An expired holding timer

  • An exceeded retry limit

  • A restarted peer

  • An Initial Update is sent before the Hello packet

SIA

Refer to the SIA section of this document.

Expired Holding Timer

An expired holding timer indicates that the router did not receive any EIGRP packet (that is, an EIGRP Hello or any other EIGRP packet) during the hold-time interval. There is more than likely a problem on the link in this case.

Check that the router receives the EIGRP Hello packets on this link and that the other side sends them. In order to verify this, enter the debug eigrp packet hello command.

As an alternative to the use of the debug command, you can ping IP address 224.0.0.10 and verify whether that neighbor replies.

Possible causes for the multicast problem on the link are due to interface problems, such as if an intermediate switch blocks the EIGRP Hello packets.

Another quick test that you can perform is to try another protocol that uses another multicast IP address. For example, you can configure Routing Information Protocol (RIP) Version 2 that uses the multicast IP address 224.0.0.9.

Exceeded Retry Limit

An exceeded retry limit indicates that an EIGRP reliable packet was not acknowledged multiple times. An EIGRP reliable packet is one of these five types of packets:

  • Update

  • Query

  • Reply

  • SIA-Query

  • SIA-Reply

The reliable EIGRP packet was retransmitted at least 16 times. A packet is retransmitted every Retransmit Time Out (RTO). The minimum RTO is 200 ms and the maximum is 5,000 ms. The RTO increases or decreases dynamically via observation of the time difference between the time that the reliable EIGRP packet is sent and the time that the acknowledgement is received. When the reliable packet is not acknowledged, the RTO increases. If this persists, then the RTO increases up to five seconds quickly, so the retry limit can reach 16 x 5 seconds = 80 seconds. However, if the EIGRP hold time is larger than 80 seconds, the neighborship does not go down until the hold time has expired. This can occur on slow WAN links where, for example, the default hold time is 180 seconds.

For links with hold times lower than 80 seconds, this effectively means that if the hold time does not expire, it is kept up by the EIGRP Hello packets. The retry limit can then be exceeded. This indicates that there is either an MTU problem or a unicast problem. The EIGRP Hello packets are small; the (first) EIGRP Update packet can be up to full MTU. It will be full MTU size if there are enough prefixes to fill the update. The neighbor can be learned via the reception of the EIGRP Hello packets, but full adjacency might not succeed if the EIGRP Update packet is not acknowledged.

Typically, this is the output that appears:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency

Note : As of Cisco bug ID CSCsc72090, the EIGRP also uses the IP MTU settings of the interface. Before this fix was applied, the EIGRP packets would become fragmented if the IP MTU was configured with a value that was lower than 1,500. This issue can typically occur in Dynamic Multipoint VPN (DMVPN) networks.

A second possibility is that the EIGRP Hello packets make it because they are multicasted to IP address 224.0.0.10. Some EIGRP Update packets might make it, as they can be multicasted. However, retransmitted EIGRP reliable packets are always unicast. If the unicast data path to the neighbor is broken, the retransmitted reliable packet does not process properly. Ping the EIGRP neighbor unicast IP address (with the size of the ping set to the full MTU size of the link, and with the Do Not Fragment bit (DF-bit) set) in order to verify.

A one-way link can cause this problem as well. The EIGRP router might receive the EIGRP Hello packets, but the packets that are sent from this neighbor do not make it across the link. If the Hello packets do not make it, the router is unaware because the Hello packets are unreliably sent. The EIGRP Update packets that are sent will not be acknowledged.

The EIGRP reliable packets or the acknowledgement can become corrupted. A quick test is to send pings with reply validation enabled:

R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]: yes
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
Reply data will be validated
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/24/152 ms

Enable the debug eigrp packets command in order to verify the transmission and reception of the EIGRP Hello packets and the EIGRP Update packets at a minimum:

R1#debug eigrp packets ?

  SIAquery  EIGRP SIA-Query packets
  SIAreply  EIGRP SIA-Reply packets
  ack       EIGRP ack packets
  hello     EIGRP hello packets
  ipxsap    EIGRP ipxsap packets
  probe     EIGRP probe packets
  query     EIGRP query packets
  reply     EIGRP reply packets
  request   EIGRP request packets
  retry     EIGRP retransmissions
  stub      EIGRP stub packets
  terse     Display all EIGRP packets except Hellos
  update    EIGRP update packets
  verbose   Display all EIGRP packets

Here is a typical example of the retry limit exceeded issue:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             12 00:00:48    1  5000  1  0
2   10.1.1.3                Et0/0             12 02:47:13   22   200  0  339
1   10.2.1.4                Et1/0             12 02:47:13   24   200  0  318
0   10.2.1.3                Et1/0             12 02:47:13   20   200  0  33813   20   200  0  338

Note: There is always one or more packets in the queue (Q Cnt).

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             10 00:00:59    1  5000  1  0
   Version 12.4/1.2, Retrans: 12, Retries: 12, Waiting for Init, Waiting for Init Ack
    UPDATE seq 349 ser 0-0 Sent 59472 Init Sequenced
2   10.1.1.3                Et0/0             11 02:47:23   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             11 02:47:23   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             10 02:47:23   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

As shown in the output, R2 awaits the first Update packet (init bit set) from the neighbor at IP address 10.1.1.1.

In this next output, R2 awaits the acknowledgement of the first Update packet (init bit set) from the neighbor at IP address 10.1.1.1.

Note: The RTO is at its maximum of 5,000 ms, which indicates that the EIGRP reliable packets are not acknowledged within the five seconds.

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             11 00:01:17    1  5000  1  0
   Version 12.4/1.2, Retrans: 16, Retries: 16, Waiting for Init, Waiting for Init Ack
    UPDATE seq 349 ser 0-0 Sent 77844 Init Sequenced
2   10.1.1.3                Et0/0             12 02:47:42   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             10 02:47:42   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             11 02:47:42   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

The number of retransmissions rises steadily. It is always the same packet in the queue (seq 349). After R2 has sent this same packet 16 times, the neighborship goes down:

R2#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency

The process begins once again:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0
   Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack
    UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced
2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

The output of the debug eigrp packets terse command shows that R2 sends the same packet over and over again:

Note: The retry value increases, the Flags value is 0x1, and the Init bit is set.

R2#debug eigrp packets terse

EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#
EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 14, RTO 5000
AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 15, RTO 5000
AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

The hold time does not expire because the Hello packets are sent and received properly:

R2#debug eigrp packets hello
EIGRP Packets debugging is on
    (HELLO)

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

Restarted Peer

If you observe a peer restarted repeatedly on one router, it indicates that the router receives the initial Update packets from its neighbor. Be aware of the Flag 1 in the received Update packets.

R2#deb eigrp packets terse

EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#
EIGRP: Received Sequence TLV from 10.1.1.1
       10.1.1.2
       address matched
      clearing CR-mode
EIGRP: Received CR sequence TLV from 10.1.1.1, sequence 479
EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0xA, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0,
not in CR-mode, packet discarded
EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
peer restarted
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency
EIGRP: Enqueueing UPDATE on Ethernet0/0 nbr 10.1.1.1 iidbQ un/rely 0/1
peerQ un/rely 0/0

Initial Update Before Hello

Here is an example where the initial Update packet is received before the Hello packet:

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
  AS 1, Flags 0x1, Seq 3/0 idbQ 0/0
EIGRP: Neighbor(10.1.1.2) not yet found

If this occurs once after a neighbor flap, then this situation is not a problem. However, if you experience it often, it indicates that the unicast on the link is operational, but the multicast on the link is broken. In other words, the router receives the unicast Update packet, but not the Hello packets.

Other Problems

Some other types of problems include:

  • Configuration changes

  • Authentication issues

  • Mismatches on primary and secondary IP addresses

  • DMVPN issues

These issues are explained in greater detail in the sections that follow.

Configuration Changes

Note: The results of the commands that are used throughout this section are the same if you configure the negation instead (the no command).

When you configure the summary statement (or the auto-summary) on the interface, you observe this message on the router:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
summary configured

Here is an example that shows the configuration of a global distribute-list for the EIGRP process:

R1(config-router)#distribute-list 1 out
R1(config-router)#

This message is observed on the router:

Note: The same occurs when you configure a distribute-list <> in as well.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
route configuration changed

All of the EIGRP neighbors then go down when you configure an interface distribute-list for the EIGRP process:

R1(config-router)#distribute-list 1 out ethernet 0/0

In this case, only the EIGRP neighborships on this interface are reset.

Note: After Cisco bug ID CSCdy20284, the neighborships are not reset for manual changes such as summarization and filters.

Authentication

Authentication can be misconfigured or missing. This can cause the EIGRP neighborship to go down because of the exceeded retry-limit. Enable the debug eigrp packets command in order to confirm that it is the Message Digest 5 (MD5) authentication that causes the issue:

R1#debug eigrp packets

EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)

EIGRP: Ethernet0/0: ignored packet from 10.1.1.3, opcode = 1 (missing
authentication or key-chain missing)

Mismatch on Primary and Secondary IP Addresses

The EIGRP sends out the Hello and all other packets from the primary IP address. The packets are accepted from the other router if the source IP addresses falls into the primary IP address range or one of the secondary IP address ranges on the interface. If not, this error message (when eigrp log-neighbor-warnings is enabled) is observed:

IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet
for Ethernet0/0

DMVPN

Check for IPSec problems in the DMVPN networks. The IPSec can cause the EIGRP to flap if the encryption is not clean:

show crypto ipsec sa

   protected vrf:
   local  ident (addr/mask/prot/port):  (10.10.110.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port):  (10.10.101.1/255.255.255.255/47/0)
   current_peer: 144.23.252.1:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 190840467, #pkts encrypt: 190840467, #pkts digest 190840467
    #pkts decaps: 158102457, #pkts decrypt: 158102457, #pkts verify 158102457
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 5523, #recv errors 42

Flags Explained

There is a 32-bit Flags field in the EIGRP packet header, and it is useful to understand the indications of the various Flag values.

  • Flag 0x1 Init bit

    This Flag is set in the initial Update packet.

    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
    AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
  • Flag 0x2 

    This Flag indicates Conditional Receive mode (CR-mode). This is a part of the reliable EIGRP multicast process and is used in order to allow the neighbors who have not acknowledged a previous reliable packet to catch up on a shared link. The addresses in the Sequence Type Length Value (TLV) are the peers who should ignore the multicast packets until they catch up via unicast packets.

    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
      AS 1, Flags 0x2, Seq 21/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1,
    not in CR-mode, packet discarded
  • Flag 0x4

    This Flag is the Restart bit (RS bit). It is set in the Hello packets and the Update packets when NSF is signaled. An NSF-aware router views this bit in order to detect if the neighbor router restarts. The neighbor that detects then knows to keep up the EIGRP adjacency. The router that restarts views this Flag in order to determine whether the peer helps with the restart.

    EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2
    AS 1, Flags 0x4, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
  • Flag 0x8

    This is the End-of-Table (EOT) bit. This bit indicates that the complete routing table has been sent to the neighbor. An NSF-capable router views this bit in order to determine whether the neighbor router has completed its restart. An NSF-capable router waits for this bit before it removes stale routes from the router that restarts.

    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
      AS 1, Flags 0x8, Seq 4/33 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
    EIGRP: NSF: AS1. Receive EOT from 10.1.1.2

The Flags are printed in one HEX number. Thus, Flag 0x5 means that Flags 4 and 1 are set; Flag 0x9 means that Flags 8 and 1 are set; Flag 0xA means that Flags 8 and 2 are set.

You can use these commands in order to troubleshoot flapping neighbors:

  • show eigrp interface detail

  • show ip eigrp neighbor detail

  • ping unicast

  • ping with size full MTU

  • ping with "verify reply data"

  • ping multicast

  • debug eigrp packet (hello)

  • show ip eigrp traffic

  • show ip traffic | begin EIGRP

SIA

This section provides an overview of the SIA state, some possible symptoms and causes, and how to troubleshoot it.

Definition of SIA

The SIA state means that an EIGRP router has not received a reply to a query from one or more neighbors within the allotted time (approximately three minutes). When this occurs, the EIGRP clears the neighbors that do not send a reply and logs a DUAL-3-SIA error message for the route that went active.

Symptoms

These messages can be seen on one or many routers:

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.  Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:
stuck in active

If this only occurs sporadically, it can be ignored. If it occurs frequently, it indicates a persistent network problem.

Possible Causes

Here are some possible causes for an SIA state:

  • Flapping links

  • Bad links

  • Flapping routes

  • Congested links

  • Large network diameter (large query range)

  • Memory shortage

  • High CPU

  • Misconfiguration (wrong bandwidth value)

Troubleshooting Tips

When an SIA situation occurs, there is a problem somewhere in the network. The exact cause can be difficult to discover. There are two approaches:

  • View the prefixes that are consistently reported as SIA and determine the commonalities.

  • Locate the router that consistently fails to answer queries for these routes.

Determine whether all of the prefixes for which SIA is reported have commonalities. For example, they all might be /32 routes from the edge of the network (such as in dial-up networks). If so, it might indicate the problem location in the network (namely, where these prefixes originated).

Ultimately, you must discover the location where one or more routers sends queries and does not receive replies, while the downstream router is not in this state. For example, the router could send queries and they are acknowledged, but the reply from the downstream router is not received.

You can use the show ip eigrp topology active command in order to help troubleshoot the SIA issue. Look for the small r in the command output. This means that the router awaits a reply to a query for that prefix from that neighbor.

Here is an example. View the topology. The links R1-R6 and R1-R5 are shut down. When the loopback interface of the router R1 is shut down, R1 sends a query for the prefix 10.100.1.1/32 to R2 and R3. The router R1 is now active for this prefix. The routers R2 and R3 go active and query in turn the router R4, which goes active and sends a query to R5. The router R5 finally goes active and sends a query to R6. The router R6 should return a reply to R5. The router R5 goes passive and replies to R4, which in turn goes passive and sends a reply to R2 and R3. Finally, R2 and R3 go passive and send a reply to R1, which goes passive again.

If a problem is encountered, then a router can stay active for an extended time, as it must wait for a reply. In order to prevent the router waiting for a reply that might never be received, the router can declare SIA and kill the neighborship through which it awaits the reply. In order to troubleshoot the problem, view the show ip eigrp topology active command output and follow the trail of the r.

Here is the output for the router R1:

R1#show ip eigrp topology active
IP-EIGRP Topology Table for AS 1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible
    1 replies, active 00:01:11, query-origin: Local origin
        via Connected (Infinity/Infinity), Loopback0
      Remaining replies:
         via 10.1.1.2, r, Ethernet0/0

The router R1 is active and awaits a reply from R2. Here is the output for the router R2:

R2#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible
    1 replies, active 00:01:01, query-origin: Successor Origin
        via 10.1.1.1 (Infinity/Infinity), Ethernet0/0
        via 10.2.1.4 (Infinity/Infinity), r, Ethernet1/0, serno 524
        via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 523

The router R2 is active and awaits a reply from R4. Here is the output for the router R4:

R4#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible
    1 replies, active 00:00:56, query-origin: Successor Origin
        via 10.2.1.2 (Infinity/Infinity), Ethernet1/0
        via 172.16.1.5 (Infinity/Infinity), r, Serial2/0, serno 562
        via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 560

The router R4 is active and awaits a reply from R5. Here is the output for the router R5:

R5#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Q
    1 replies, active 00:00:53, query-origin: Successor Origin
        via 172.16.1.4 (Infinity/Infinity), Serial2/0
      Remaining replies:
         via 192.168.1.6, r, Serial3/0

The router R5 is active and awaits a reply from R6. Here is the output for the router R6:

R6#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)
R6#

As shown, the router R6 is not active for the prefix, so the problem must be between routers R5 and R6. After some time, we see that R5 kills the neighborship to R6 and declares an SIA state:

R5#
%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.
  Cleaning up
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:
stuck in active

When you view the output for router R5, you can see that there are problems on the link towards R6.

This is new SIA code, and as such, the SIA occurred on a router that was next to the problem. In this example, this is the link between the routers R5 and R6. In older code versions, the SIA could be declared on any router along the path (such as on R2), which might be distant from the problem. The SIA timer was three minutes. Any router along the path could be the first to go SIA and kill the neighborship(s). With the newer code, the router awaits a reply, intermediately sends an SIA query to its neighbor, and the neighbor immediately answers with an SIA reply. For example, while in the active state, the router R4 sends an SIA query to R5, and R5 replies with an SIA reply.

R5#
EIGRP: Received SIAQUERY on Serial2/0 nbr 172.16.1.4
  AS 1, Flags 0x0, Seq 456/447 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
EIGRP: Enqueueing SIAREPLY on Serial2/0 nbr 172.16.1.4 iidbQ un/rely 0/1
peerQ un/rely 0/0 serno 374-374
EIGRP: Sending SIAREPLY on Serial2/0 nbr 172.16.1.4
  AS 1, Flags 0x0, Seq 448/456 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
serno 374-374

The router R5 also sends SIA queries to R6, but it does not receive an SIA reply from R6.

R5#
EIGRP: Enqueueing SIAQUERY on Serial3/0 nbr 192.168.1.6 iidbQ un/rely 0/2
peerQ un/rely 5/0 serno 60-60

Once the router sends an SIA query but does not receive an SIA reply, the s appears for that neighbor:

R5#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Qqr
    1 replies, active 00:02:36, query-origin: Successor Origin, retries(1)
        via 1172.16.1.4 (Infinity/Infinity), Serial2/0, serno 61
        via 192.168.1.6 (Infinity/Infinity), rs, q, Serial3/0, serno 60, anchored

With the new SIA code, the SIA should be declared on the router R5 when it does not receive an SIA reply. You should then enable the debugging for these two EIGRP SIA packets:

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on
    (SIAQUERY, SIAREPLY)

R2#show deb
EIGRP:
  EIGRP Packets debugging is on
    (SIAQUERY, SIAREPLY)

In summary, you can use these commands in order to troubleshoot the SIA issue:

  • show ip eigrp topology active

  • show ip eigrp event (possibly increase the event log size)

  • show ip eigrp traffic (search for many SIA queries and SIA replies)

  • show proc mem

  • show mem sum

Here are some possible solutions for the SIA issue:

  • Fix the link problem.

  • Apply summarization (manual or automatic) in networks with many prefixes or a deep query range.

  • Use distribute-lists in order to decrease the query range.

  • Define remote routers as stubs.

Missing Prefixes

There are two types of missing prefixes: those that are missing in the routing table (or Routing Information Base (RIB)), and those that are missing in the topology table.

Missing Prefixes in RIB

There can be several reasons that a prefix is not included in the RIB:

  • The prefix is installed in the routing table by another routing protocol with a lower administrative distance.

  • A distribute-list blocks the prefix.

  • A split-horizon blocks the prefix.

Prefix Installed by Routing Protocol with Lower Administrative Distance

In this example, the prefix is installed in the routing table by a static route or a routing protocol with a lower administrative distance.

Typically when this occurs, the prefix is in the topology table but has no successor. You can view all of these entries with the show ip eigrp topology zero-successors command. The Feasible Distance (FD) should have an infinite value.

Enter the show ip route <prefix> command and verify the routing protocols that own the route in the RIB:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1R1#show ip eigrp topology zero-successors
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 192.168.1.0/24, 0 successors, FD is Inaccessible
        via 10.3.1.6 (2681856/2169856), Serial2/0
P 192.168.100.6/32, 0 successors, FD is Inaccessible
        via 10.3.1.6 (2297856/128256), Serial2/0

Distribute-List Blocks the Prefix

The EIGRP is a distance-vector routing protocol. You can use a distribute-list on any router in order to block prefixes. You can use it on an interface in order to stop the prefixes from being sent out or being received, or you can configure the distribute-list globally under the router EIGRP process in order to apply the routing filter on all of the EIGRP-enabled interfaces.

Here is an example:

R1#show running-config | begin router eigrp

router eigrp 1
network 10.0.0.0
distribute-list 1 in
no auto-summary
!
access-list 1 deny   192.168.100.6
access-list 1 permit any

Missing Prefixes in Topology Table

This section describes some of the reasons that a prefix might be missing from the topology table.

Mask Specification for Proper Command Output

Do not make the typical mistake; when you verify a prefix in the topology table, always specify the mask. This occurs if you do not use the mask:

R1#show ip eigrp topology 192.168.100.6  
% IP-EIGRP (AS 1): Route not in topology table

Here is the show ip eigrp topology command output when the mask is specified:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x
      Composite metric is (2323456/2297856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 26000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

As shown, the prefix is present in the topology table.

Split-Horizon Blocks the Prefix

This section describes another common mistake. EIGRP is not a link-state routing protocol, but rather it is a distance-vector routing protocol. The topology table must be used for the correct operation of Diffuse Update Algorithm (DUAL), not because the EIGRP is a link-state routing protocol; hence, it requires a database. The topology table is required because only the best routes are installed in the routing table, while the DUAL demands that the feasible routes are monitored as well. These are stored in the topology table.

You should always have the successor route and the feasible routes in the topology table. If not, there is a bug. However, there could also be non-feasible routes in the topology table, as long as they are received. If they are not received from a neighbor, there could be a split-horizon that blocks the prefix.

The output of the show ip eigrp topology command shows only the prefix entries that point to successors and feasible successors. If you want to view the prefixes that are received over all of the paths (also non-feasible paths), then enter the show  ip eigrp topology all-links command instead.

Here is an example:

R1#show ip eigrp topology         
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial2/0
P 10.2.1.0/24, 2 successors, FD is 307200
        via 10.1.1.2 (307200/281600), Ethernet0/0
        via 10.1.1.3 (307200/281600), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 281600
        via Connected, Ethernet0/0
P 172.16.1.0/24, 1 successors, FD is 2195456
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
P 192.168.1.0/24, 1 successors, FD is 2195456
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
        via 10.3.1.6 (2681856/2169856), Serial2/0
P 10.4.1.0/24, 1 successors, FD is 281600
        via Connected, Ethernet1/0
P 172.16.100.5/32, 1 successors, FD is 409600
        via 10.4.1.5 (409600/128256), Ethernet1/0
P 10.100.1.4/32, 2 successors, FD is 435200
        via 10.1.1.2 (435200/409600), Ethernet0/0
        via 10.1.1.3 (435200/409600), Ethernet0/0
P 10.100.1.3/32, 1 successors, FD is 409600
        via 10.1.1.3 (409600/128256), Ethernet0/0
P 10.100.1.2/32, 1 successors, FD is 409600
        via 10.1.1.2 (409600/128256), Ethernet0/0
P 10.100.1.1/32, 1 successors, FD is 128256
        via Connected, Loopback0
P 192.168.100.6/32, 1 successors, FD is 2297856
        via 10.3.1.6 (2297856/128256), Serial2/0

In this output you can see that the all-links portion of the command includes more paths:

R1#show ip eigrp topology all-links  
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856, serno 43
        via Connected, Serial2/0
P 10.2.1.0/24, 2 successors, FD is 307200, serno 127
        via 10.1.1.2 (307200/281600), Ethernet0/0
        via 10.1.1.3 (307200/281600), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 281600, serno 80
        via Connected, Ethernet0/0
P 172.16.1.0/24, 1 successors, FD is 2195456, serno 116
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
        via 10.3.1.6 (3193856/2681856), Serial2/0
        via 10.1.1.2 (2221056/2195456), Ethernet0/0
        via 10.1.1.3 (2221056/2195456), Ethernet0/0
P 192.168.1.0/24, 1 successors, FD is 2195456, serno 118
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
        via 10.3.1.6 (2681856/2169856), Serial2/0
P 10.4.1.0/24, 1 successors, FD is 281600, serno 70
        via Connected, Ethernet1/0
P 172.16.100.5/32, 1 successors, FD is 409600, serno 117         
        via 10.4.1.5 (409600/128256), Ethernet1/0
        via 10.3.1.6 (2809856/2297856), Serial2/0
P 10.100.1.4/32, 2 successors, FD is 435200, serno 128
        via 10.1.1.2 (435200/409600), Ethernet0/0
        via 10.1.1.3 (435200/409600), Ethernet0/0
P 10.100.1.3/32, 1 successors, FD is 409600, serno 115
        via 10.1.1.3 (409600/128256), Ethernet0/0
P 10.100.1.2/32, 1 successors, FD is 409600, serno 109
        via 10.1.1.2 (409600/128256), Ethernet0/0
P 10.100.1.1/32, 1 successors, FD is 128256, serno 4
        via Connected, Loopback0
P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135
        via 10.3.1.6 (2297856/128256), Serial2/0
        via 10.4.1.5 (2323456/2297856), Ethernet1/0

Consider the last prefix in the previous output; the path via 10.4.1.5 has (2323456/2297856). The reported distance (advertised metric) is 2297856, which is not smaller than the FD of 2297856, so the path is not feasible.

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135
        via 10.3.1.6 (2297856/128256), Serial2/0
        via 10.4.1.5 (2323456/2297856), Ethernet1/0

Here is an example where a split-horizon causes a path to be excluded from the topology table for one route. When you view the topology, you can see that the router R1 has the prefix 192.168.100.6/32 via R6 and R5 in the topology table, but not via R2 or R3:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (2323456/2297856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 26000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

This is because the router R1 never received the prefix 192.168.100.6/32 via R2 or R3, as they have the prefix 192.168.100.6/32 via R1 in the routing table.

R2#show ip route 192.186.100.6 255.255.255.255
Routing entry for 192.168.100.6/32
  Known via "eigrp 1", distance 90, metric 2323456, type internal
  Redistributing via eigrp 1
  Last update from 10.1.1.1 on Ethernet0/0, 00:02:07 ago
  Routing Descriptor Blocks:
  * 10.1.1.1, from 10.1.1.1, 00:02:07 ago, via Ethernet0/0
      Route metric is 2323456, traffic share count is 1
      Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

R3#show ip route 192.168.100.6 255.255.255.255
Routing entry for 192.168.100.6/32
  Known via "eigrp 1", distance 90, metric 2323456, type internal
  Redistributing via eigrp 1
  Last update from 10.1.1.1 on Ethernet0/0, 00:01:58 ago
  Routing Descriptor Blocks:
  * 10.1.1.1, from 10.1.1.1, 00:01:58 ago, via Ethernet0/0
      Route metric is 2323456, traffic share count is 1
      Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

In order to verify this, use the all-links keyword on R1 when you view the topology table. This shows all of the paths for all of the prefixes, which includes the non-feasible paths. You can then see that the prefix 192.168.100.6/32 has not been learned by the router R1 from R2 or R3.

Metrics

Note: The MTU and hop count are not included in the metric calculation.

These are the formulas that are used in order to calculate the path metric of a route:

  • If K5 is a non-zero value:

    EIGRP Metric = 256*(((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay))*(K5/(Reliability + K4)))

  • If K5 is equal to zero:

    EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay))

The K-values are weights that are used in order to weight the four components of the EIGRP metric: delay, bandwidth, reliability, and load. These are the default K-values:

  • K1 = 1

  • K2 = 0

  • K3 = 1

  • K4 = 0

  • K5 = 0

With the default K-values (only using bandwidth and delay), the formula becomes:

EIGRP Metric = 256 * (Bw +  Delay)

Bw= (10^7/minimum Bw in kilobits per second)

Note: The delay is measured in tens of microseconds; however, on the interface, it is measured in microseconds.

All of the four components can be verified with the show interface command:

 R1#show interface et 0/0
Ethernet0/0 is up, line protocol is up
  Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)
  Internet address is 10.1.1.1/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00  Last input 00:00:02, output 00:00:02,
output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     789 packets input, 76700 bytes, 0 no buffer
     Received 707 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     548 packets output, 49206 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

The delay is cumulative, which means that you add the delay of each link along the path. The bandwidth is not cumulative, so the bandwidth that is used in the formula is the smallest bandwidth of any link along the path.

Duplicate Router ID

In order to view the router ID that the EIGRP uses, enter the show ip eigrp topology command on the router and view the first line of the output:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial2/0

The EIGRP router ID is not used at all for internal routes in older Cisco IOS versions. A duplicate router ID for the EIGRP should not cause any problems if only internal routes are used. In newer Cisco IOS software, the EIGRP internal routes do carry the EIGRP router ID.

The router ID for external routes can be viewed in this output:

R1#show ip eigrp topology 192.168.1.4 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.1.4/32
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200
  Routing Descriptor Blocks:
  10.1.1.2 (Ethernet0/0), from 10.1.1.2, Send flag is 0x0
      Composite metric is (435200/409600), Route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 7000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
      External data&colon;
        Originating router is 10.100.1.4 
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)

If an (external) EIGRP route with the same EIGRP router ID as the router is received, it does not generate a log entry. However, the EIGRP event log does capture this. When you check for the (external) EIGRP route, it does not show up in the topology table.

Check the EIGRP event log for possible duplicate router ID messages:

R1#show ip eigrp events                            
Event information for AS 1:
1    08:36:35.303 Ignored route, metric: 10.33.33.33 3347456
2    08:36:35.303 Ignored route, neighbor info: 10.3.1.6 Serial2/1
3    08:36:35.303 Ignored route, dup router: 10.100.1.1
4    08:36:35.303 Rcv EOT update src/seq: 10.3.1.6 143
5    08:36:35.227 Change queue emptied, entries: 2
6    08:36:35.227 Route OBE net/refcount: 10.100.1.4/32 3
7    08:36:35.227 Route OBE net/refcount: 10.2.1.0/24 3
8    08:36:35.227 Metric set: 10.100.1.4/32 435200
9    08:36:35.227 Update reason, delay: nexthop changed 179200
10   08:36:35.227 Update sent, RD: 10.100.1.4/32 435200
11   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.3
12   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.2
13   08:36:35.227 RDB delete: 10.100.1.4/32 10.3.1.6

K-Values Mismatch/Graceful Shutdown

When the K-values are not the same on neighbor routers, this message is observed:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch

The K-values are configured with this command (with the possible values of K between 0 and 255):

metric weights tos k1 k2 k3 k4 k5

!
router eigrp 1
network 10.0.0.0
metric weights 0 1 2 3 4 5
!

The message indicates that the EIGRP neighborship is not established because of a mismatch in K-values. The K-values must be the same on all of the EIGRP routers in one autonomous system in order to prevent routing problems when different routers use different metric calculations.

Check whether the K-values are the same on the neighbor routers. If the K-values are the same, the issue might be caused by the EIGRP graceful shutdown feature. In that case, a router sends an EIGRP Hello packet with the K-values set to 255 so that the K-values mismatch occurs intentionally. This is to indicate to the neighbor EIGRP router that it is going down. On the neighbor router, you would see this goodbye message received:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received

However, if the neighbor router runs an older code version (prior to Cisco bug ID CSCdr96531), it does not recognize this as a graceful shutdown message, but as a mismatch in K-values:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch

This is the same message as in the case of a true K-values mismatch on the neighbor routers.

These are the triggers for a graceful shutdown:

  • The no router eigrp command is entered.

  • The no network command is entered.

  • The clear ip eigrp neighbor command is entered.

  • The router is reloaded.

A graceful shutdown is used in order to speed up the detection of a neighbor down state. Without a graceful shutdown, a neighbor must wait until the hold time expires before it declares the neighbor to be down.

Unequal Cost Load Balancing (Variance)

Unequal cost load balancing is possible in EIGRP with the variance command, but both the variance and feasibility conditions must be met.

The variance condition means that the metric of the route is not larger than the best metric multiplied by the variance. In order for a route to be considered feasible, the route must have been advertised with a reported distance that is lower than the Feasible Distance (FD). Here is an example:

!
router eigrp 1
variance 2
network 10.0.0.0
no auto-summary
!

The router R1 has a variance 2 configured. This means that if the router has a another path for the route with a metric that is not larger  than twice the best metric for that route, there should be unequal cost load balancing for that route.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
  Routing Descriptor Blocks:
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (409600/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (435200/409600), Route is Internal <<< RD = 409600
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 7000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

If the second topology entry is installed in the routing table, the metric of the second topology entry is 435200. Since twice the best metric is 2 x 409600 = 819200, and 435200 < 819200, the second topology entry is within the variance range. The reported distance of the second topology entry is 409600, which is not smaller than the FD = 409600. The second condition (feasibility) is not met, and the second entry cannot be installed in the RIB.

R1#show ip route 172.16.100.5
Routing entry for 172.16.100.5/32
  Known via "eigrp 1", distance 90, metric 409600, type internal
  Redistributing via eigrp 1
  Last update from 10.4.1.5 on Ethernet1/0, 00:00:16 ago
  Routing Descriptor Blocks:
  * 10.4.1.5, from 10.4.1.5, 00:00:16 ago, via Ethernet1/0
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

If the RD of the second topology entry is smaller then the FD, as in the next example, there would be unequal cost load balancing.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
  Routing Descriptor Blocks:
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (409600/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (434944/409344), Route is Internal <<< RD = 409344
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6990 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Both topology entries are now in the routing table:

R1#show ip route 172.16.100.5                        
Routing entry for 172.16.100.5/32
  Known via "eigrp 1", distance 90, metric 409600, type internal
  Redistributing via eigrp 1
  Last update from 10.3.1.6 on Serial2/0, 00:00:26 ago
  Routing Descriptor Blocks:
  * 10.4.1.5, from 10.4.1.5, 00:00:26 ago, via Ethernet1/0
      Route metric is 409600, traffic share count is 120
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    10.3.1.6, from 10.3.1.6, 00:00:26 ago, via Serial2/0
      Route metric is 434944, traffic share count is 113
      Total delay is 6990 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Static Neighbors

The EIGRP supports configurations with one or more static neighbors on the same interface. As soon as you configure one static EIGRP neighbor on the interface, the router no longer sends the EIGRP packets as multicast on that interface or processes the received multicasted EIGRP packets. This means that the Hello, Update, and Query packets are now unicasted. No additional neighborships can be formed unless the static neighbor command is explicitly configured for those neighbors on that interface.

This is how to configure a static EIGRP neighbor:

router eigrp 1
passive-interface Loopback0
network 10.0.0.0
no auto-summary
neighbor 10.1.1.1 Ethernet0/0
!

When the routers on both sides of the link have the static neighbor command, the neighborship is formed:

R1#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                          (sec)         (ms)       Cnt Num
1   10.1.1.2                Et0/0             14 00:00:23   27   200  0  230
   Static neighbor
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1
0   10.3.1.6                Se2/0             14 1d02h      26   200  0  169
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 12
3   10.4.1.5                Et1/0             10 1d02h      16   200  0  234
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 7

If only one router has the static neighbor command configured, you will observe that the router ignores the multicasted EIGRP packets and the other router ignores the unicasted EIGRP packets:

R1#
EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2
  AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Ignore multicast Hello Ethernet0/0 10.1.1.2R2#
EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Ignore unicast Hello from Ethernet0/0 10.1.1.1

There is a special debug command for EIGRP static neighbors:

R2#debug eigrp neighbors static
EIGRP Static Neighbors debugging is on

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 1              
R2(config-router)#neighbor 10.1.1.1 et 0/0
R2(config-router)#end
R2#

EIGRP: Multicast Hello is disabled on Ethernet0/0!
EIGRP: Add new static nbr 10.1.1.1 to AS 1 Ethernet0/0

Here are some reasons that static EIGRP neighbors might be configured:

  • You want to limit or avoid broadcasts on Non-Broadcast Multi-Access (NBMA) networks.

  • You want to limit or avoid multicasts on broadcast media (Ethernet).

  • For troubleshooting purposes (using unicast instead of multicast).

Caution: Do not configure the passive-interface command together with the static EIGRP neighbor command.

Static Route Redistribution

When you configure a static route that points to an interface, and the route is covered by a network statement under the router EIGRP, then the static route is advertised by the EIGRP as if it were a connected route. The redistribute static command or a default metric is not required in this case.

router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary
!
ip route 172.16.0.0 255.255.0.0 Serial2/0
!R1#show ip eigrp top 172.16.0.0 255.255.0.0     
IP-EIGRP (AS 1): Topology entry for 172.16.0.0/16
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (2169856/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 20000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0

Reliability and Load for Metric Calculation

Caution: Do not use reliability and/or load in order to calculate metrics.

The reliability and load parameters appear in the show interface command output. There are no dynamic updates for these parameters when the load and reliability change. If the load and reliability change, it does not trigger an immediate change in the metric. Only if the EIGRP decides to send updates to its neighbors because of topology changes will the change in load and reliability be propagated. Furthermore, use of load and reliability in order to calculate the metric can introduce instability, as adaptive routing is then performed. If you desire to change the routing in accordance with the traffic load, then you should consider the use of Multiprotocol Label Switching (MPLS) traffic engineering or Performance Routing (PfR).

High CPU

There are three EIGRP processes that run simultaneously:

  • Router – This process holds the shared memory pools.

  • Hello – This process sends and receives the Hello packets and maintains the peer connections.

  • Protocol Dependent Module (PDM) – The EIGRP supports four protocol suites: IP, IPv6, IPX, and AppleTalk. Each suite has its own PDM. Here are the primary functions of the PDM:

    • Maintains the neighbor and topology tables of the EIGRP routers that belong to that protocol suite.

    • Builds and translates protocol-specific packets for DUAL (transmission and reception of EIGRP packets).

    • Interfaces DUAL to the protocol-specific routing table.

    • Computes the metric and pass the information to DUAL (DUAL only picks the successors and feasible successors).

    • Implements filtering and access-lists.

    • Performs redistribution functions to and from the other routing protocols.

Here is an example output that shows these three processes:

R1#show proc cpu | include EIGRP
  89           4        24        166  0.00%  0.00%  0.00%   0 IP-EIGRP Router
  90        1016      4406        230  0.00%  0.03%  0.00%   0 IP-EIGRP: PDM  
  91        2472      6881        359  0.00%  0.07%  0.08%   0 IP-EIGRP: HELLO

High CPU in the EIGRP is not normal. If this occurs, either the EIGRP has too much to do or there is a bug in EIGRP. In the first case, check the number of prefixes in the topology table and the number of peers. Check for instability among the EIGRP routes and neighbors.

EIGRP in Frame Relay Networks (Broadcast Queue)

In frame relay networks where there are multiple neighbor routers on one point-to-multipoint interface, there can be  many broadcast or multicast packets that must be transmitted. For this reason, there is a separate broadcast queue with its own buffers. The broadcast queue has priority when it transmits at a rate below the configured maximum and has a guaranteed minimum bandwidth allocation.

Here is the command that is used in this scenario:

frame-relay broadcast-queue size byte-rate packet-rate

As a general rule, begin with twenty packets per Data Link Connection Identifier (DLCI). The byte rate should be less than both of these:

  • N/4 times the minimum remote access rate (measured in bytes per second), where N is the number of DLCIs to which the broadcast must be replicated.

  • One quarter of the local access rate (measured in bytes per second).

If you observe a large number of EIGRP neighbors flapping, increase the frame-relay broadcast-queue size. This issue is not present if there are frame relay subinterfaces because each neighbor router is on one subinterface with a different IP subnet. Consider this as a workaround when there is a large, fully-meshed frame relay network.

Mismatched AS Numbers

When you enter the debug eigrp packets hello command, it reveals that the router does not receive the Hello packets.

Auto-Summary

The EIGRP used to perform summarization at the major network (networks A, B, and C) boundaries by default. This means that more specific routes than the /8 prefixes for the major network type A, more specific routes than the /16 prefixes for major network type B, and more specific routes than the /24 prefixes for major networks type C, are lost when they cross their boundaries. Here is an example where auto-summary causes a problem:

EIGRP troubleshooting - Traffic drop caused by automatic summary routes

As shown, the routers R1 and R3 have auto-summary under router EIGRP. The router R2 receives 10.0.0.0/8 from both routers R2 and R3 because both R2 and R3 are boundary routers between major class A network 10.0.0.0/8 and 172.16.0.0/16. The router R2 can have the route 10.0.0.0/8 via R1 and R3 if the metric happens to be the same. Otherwise, R2 has the route 10.0.0.0/8 either via R1 or via R3, dependent upon the path that produces the least cost. In either case, if R2 must send traffic to certain subnets of 10.0.0.0/8, it cannot be completely sure that the traffic reaches its destination, as one subnet of 10.0.0.0/8 can be only on either the left or the right network cloud.

In order to alleviate this problem, simply type no auto-summary under the router EIGRP process. The router then propagates subnets of the major networks across the boundary. In newer Cisco IOS versions, the no auto-summary setting is the default behavior.

EIGRP Event Log

The EIGRP event log captures the EIGRP events. It is similar to when debugs are enabled for EIGRP. However, it is less disruptive and runs by default. It can be used in order to capture events that are more difficult to troubleshoot or more intermittent events. This log is by default only 500 lines. In order to increase it, enter the eigrp event-log-size <0 – 209878> command. You can increase the log size as much as desired, but keep in mind the amount of memory that the router has to spare for this log. In order to clear the EIGRP event log, enter the clear ip eigrp events command.

Here is an example:

R1#show ip eigrp events
Event information for AS 1:
1    09:01:36.107 Poison squashed: 10.100.1.3/32 reverse
2    09:01:35.991 Update ACK: 10.100.1.4/32 Serial2/0
3    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet0/0
4    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet1/0
5    09:01:35.943 Update delay/poison: 179200 FALSE
6    09:01:35.943 Update transmitted: 10.100.1.4/32 Serial2/0
7    09:01:35.943 Update delay/poison: 179200 TRUE
8    09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet0/0
9    09:01:35.943 Update delay/poison: 179200 FALSE
10   09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet1/0
11   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet0/0
12   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet1/0
13   09:01:35.923 Update packetized: 10.100.1.4/32 Serial2/0
14   09:01:35.903 Change queue emptied, entries: 1
15   09:01:35.903 Route OBE net/refcount: 10.100.1.4/32 3
16   09:01:35.903 Metric set: 172.16.1.0/24 2195456
17   09:01:35.903 Route install: 172.16.1.0/24 10.4.1.5
18   09:01:35.903 FC sat rdbmet/succmet: 2195456 2169856
19   09:01:35.903 FC sat nh/ndbmet: 10.4.1.5 2195456
20   09:01:35.903 Find FS: 172.16.1.0/24 2195456

The most recent events appear at the top of the log. You can filter certain types of EIGRP events, such as DUAL, Xmit, and transport:

eigrp log-event-type {dual | xmit | transport}

Additionally, you can enable logging for one of these three types, a combination of two types, or for all three. Here is an example where two types of logging are enabled:

router eigrp 1
redistribute connected
network 10.0.0.0
no auto-summary
eigrp log-event-type dual xmit
eigrp event-logging
eigrp event-log-size 100000
!

Caution: When you enable eigrp event-logging, it prints the event logging and stores it in the event table. This can lead to a large amount of printed output on the console, similar to when heavy EIGRP debugging is enabled.

Same Network Learned by Two EIGRP Autonomous Systems

If a route is learned via two EIGRP processes, then only one of the EIGRP processes can install the route in the RIB. The process with the lowest administrative distance installs the route. If the administrative distance is the same, then the process with the lowest metric installs the route. If the metric is the same as well, then the EIGRP process with the lowest EIGRP process ID install the route in the RIB. The topology table of the other EIGRP process will have the route installed with zero successors and an infinite FD value.

Here is an example:

EIGRP troubleshooting - Same network learned by two EIGRP autonomous systems

R1#show ip eigrp topology 192.168.1.0 255.255.255.0
IP-EIGRP (AS 1): Topology entry for 192.16.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2681856
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2681856/2169856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 40000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
IP-EIGRP (AS 2): Topology entry for 192.16.1.0/24
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (2681856/2169856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 40000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1R1#show ip route 192.168.1.0 255.255.255.0

Routing entry for 192.168.1.0/24
  Known via "eigrp 1", distance 90, metric 2681856, type internal
  Redistributing via eigrp 1
  Last update from 10.3.1.6 on Serial2/0, 00:04:16 ago
  Routing Descriptor Blocks:
  * 10.3.1.6, from 10.3.1.6, 00:04:16 ago, via Serial2/0
      Route metric is 2681856, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
Sours: https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/118974-technote-eigrp-00.html
  1. Aincrad online codes
  2. Little bot play mat
  3. Muffler cartoon
  4. 4x4 framing brackets

Cisco IOS Debug Command Reference - Commands E through H

debug eap through debug hw-module subslot periodic

debug eap

To display information about Extensible Authentication Protocol (EAP), use the debugeapcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugeap [ all ] [ authenticator | peer ] { all | errors | events | packets | sm }

nodebugeap [ all ] [ authenticator | peer ] { all | errors | events | packets | sm }

Syntax Description

all| method

(Optional) Specifies the method to which the debug command refers.

  • The all keyword turns on debugging for all EAP methods, including the EAP framework.

  • The method argument turns on debugging for specific methods.

  • This keyword or argument is dynamically linked into the parse chain and is present only if the method itself is present.

  • If this keyword or argument is omitted, the debug command is applied to the EAP framework.

authenticator

(Optional) Limits the scope of the output to only authenticator contexts.

peer

(Optional) Limits the scope of the output to only peer contexts.

all

Debugging is turned on for all debug types.

errors

Displays information about EAP packet errors.

events

Displays information about EAP events.

packets

Turns on packet debugging for the specified method or methods.

sm

Turns on state machine debugging for the specified method or methods.

Command Modes


Privileged EXEC #

Command History

Release

Modification

12.3(8)T

This command was introduced.

12.4(6)T

The method argument and authenticator andpeer keywords were added.

12.2(33)SRA

This command was integrated into Cisco IOS Release 12.2(33)SRA.

12.2(33)SXI

This command was integrated into Cisco IOS Release 12.2(33)SXI.

Examples

The following sample output from the debugeapall command shows all EAP information:

Router# *Nov 7 13:05:58.512: EAP-EVENT: Received get canned status from lower layer (0x00000000) *Nov 7 13:05:59.460: EAP-EVENT: Received context create from lower layer (0x00000009) *Nov 7 13:05:59.460: eap_authen : initial state eap_auth_initialize has enter *Nov 7 13:05:59.460: EAP-EVENT: Started 'Authenticator Start' timer (1s) for EAP sesion handle 0xD6000008 *Nov 7 13:05:59.460: EAP-EVENT: Allocated new EAP context (handle = 0xD6000008) *Nov 7 13:05:59.464: EAP-EVENT: Started EAP tick timer *Nov 7 13:06:00.488: EAP-EVENT: 'Authenticator Start' timer expired for EAP sesion handle 0xD6000008 *Nov 7 13:06:00.488: eap_authen : during state eap_auth_initialize, got event 21(eapStartTmo) *Nov 7 13:06:00.488: @@@ eap_authen : eap_auth_initialize -> eap_auth_select_action *Nov 7 13:06:00.488: eap_authen : during state eap_auth_select_action, got event 17(eapDecisionPropose) *Nov 7 13:06:00.488: @@@ eap_authen : eap_auth_select_action -> eap_auth_propose_method

Related Commands

Command

Description

debugeou

Displays information about EAPoUDP.

debug ecfmpal

To enable debugging of the data path of the Ethernet Connectivity Fault Management (CFM) function, use the debugecfmpal command in the privileged EXEC mode. To disable the debugging function, use the no form of this command.

debugecfmpal { all | api | common | ecfmpal | epl | isr }

nodebugecfmpal { all | api | common | ecfmpal | epl | isr }

Syntax Description

all

Specifies all the platform Ethernet CFM events.

api

Specifies the platform-specific application program interface (API) Ethernet CFM events.

common

Specifies the common Ethernet CFM events.

ecfmpal

Specifies the general Ethernet CFM platform events.

epl

Specifies the end-point list Ethernet CFM events.

isr

Specifies the platform-interrupt service request events.

Command Default

Debugging is disabled.

Command Modes


Privileged EXEC (#)

Command History

Release Modification

15.4(1)T

This command was introduced into Cisco IOS Release 15.4(1)T.

Usage Guidelines

Use this command to troubleshoot Ethernet CFM functions on the following routers:

  • Cisco 3900 Series, Cisco 2900 Series, and Cisco 1900 Series Integrated Services Routers Generation 2

  • Cisco 890 Series Integrated Services Routers

Examples

The following is a sample output of the debugecfmpalall command:

Device# ECFMPAL EPL events debugging is on ECFMPAL Ingress ISR events debugging is on ECFMPAL events debugging is on ECFMPAL API events debugging is on ECFMPAL common events debugging is on Router# *Nov 15 05:10:25.909: ECFMPD-API: Port MEP Gi0/2.1 get 0 02DB7F44

debug eigrp address-family neighbor

To display debugging information about Enhanced Interior Gateway Routing Protocol (EIGRP) address family neighbors, use the debugeigrpaddress-familyneighbor command in privileged EXEC mode. To disable debugging of EIGRP service-family neighbors, use the no form of this command.

debugeigrpaddress-family [ ipv4 | ipv6 ] neighbor

nodebugeigrpaddress-family [ ipv4 | ipv6 ] neighbor

Syntax Description

ipv4

(Optional) Enables debugging for neighbors formed using the IPv4 protocol family.

ipv6

(Optional) Enables debugging for neighbors formed using the IPv6 protocol family.

ip-address

(Optional) IPv4 or IPv6 address of the neighbor. Specifying an address enables debugging for the service family at this address.

Command Default

Debugging of EIGRP service-family neighbors is disabled.

Command Modes


Privileged EXEC (#)

Command History

Release

Modification

15.0(1)M

This command was introduced.

12.2(33)SRE

This command was integrated into Cisco IOS Release 12.2(33)SRE.

12.2(33)XNE

This command was integrated into Cisco IOS Release 12.2(33)XNE.

Cisco IOS XE Release 2.5

This command was integrated into Cisco IOS XE Release 2.5.

Usage Guidelines

Consult Cisco technical support before using this command.


Caution


Use of debug commands can have severe performance penalties and should be used with extreme caution. For this reason, Cisco recommends that you contact Cisco technical support before enabling a debug command.


Examples

The following example shows how to enable debugging of an EIGRP address-family neighbor at 10.0.0.0:

Router# Neighbor target enabled on AS 3 for 10.0.0.0 *Mar 17 15:50:53.244: EIGRP: 10.0.0.0/24 - do advertise out Serial1/2 *Mar 17 15:50:53.244: EIGRP: Int 10.0.0.0/24 metric 20512000 -20000000 512000 *Mar 17 15:50:53.244: EIGRP: 10.0.0.0/24 - do advertise out Serial1/2 *Mar 17 15:50:53.244: EIGRP: Int 10.0.0.0/24 metric 28160 - 256002560 *Mar 17 15:50:53.244: EIGRP: 10.0.0.0/24 - do advertise out Serial1/2 *Mar 17 15:50:53.244: EIGRP: 10.0.0.0/24 - do advertise out Serial1/2 *Mar 17 15:50:53.244: EIGRP: Int 10.0.0.0/24 metric 28160 - 25600256 *Mar 17 15:50:53.668: EIGRP: Processing incoming UPDATE packet *Mar 17 15:50:54.544: EIGRP: 10.0.0.0/24 - do advertise out Serial1/1

Related Commands

Command

Description

debugeigrpaddress-familynotifications

Displays debugging information about EIGRP event notifications.

debug eigrp address-family notifications

To display debugging information about Enhanced Interior Gateway Routing Protocol (EIGRP) address family event notifications, use the debugeigrpaddress-familynotifications command in privileged EXEC mode. To disable EIGRP event notification debugging, use the no form of this command.

debugeigrpaddress-family { ipv4 [ | vrf ] | ipv6 [ ] } notifications

nodebugeigrpaddress-family { ipv4 [ | vrf ] | ipv6 [ ] } notifications

Syntax Description

ipv4

Enables debugging for neighbors formed using the IPv4 protocol family.

ipv6

Enables debugging for neighbors formed using the IPv6 protocol family.

autonomous-system-number

(Optional) Autonomous system number of the EIGRP routing process. If no autonomous system number is specified, debugging information is displayed for all autonomous systems.

vrf

(Optional) Enables debugging for the specified VRF.

vrf-name

(Optional) Name of the VRF address family to which the command is applied.

ip-address

(Optional) IPv4 or IPv6 address of neighbor. Specifying an address enables debugging for all entries with this address.

Command Default

EIGRP event notification debugging is disabled.

Command Modes


Privileged EXEC (#)

Command History

Release

Modification

15.0(1)M

This command was introduced.

12.2(33)SRE

This command was integrated into Cisco IOS Release 12.2(33)SRE.

12.2(33)XNE

This command was integrated into Cisco IOS Release 12.2(33)XNE.

Cisco IOS XE Release 2.5

This command was integrated into Cisco IOS XE Release 2.5.

Usage Guidelines

Consult Cisco technical support before using this command.


Caution


Use of debug commands can have severe performance penalties and should be used with extreme caution. For this reason, Cisco recommends that you contact Cisco technical support before enabling a debug command.


Examples

The following example shows how to enable EIGRP event notification debugging:

Router# *Mar 17 15:58:07.144: IP-EIGRP: Callback: reload_iptable *Mar 17 15:58:08.148: IP-EIGRP: iptable_redistribute into eigrp AS 1 *Mar 17 15:58:12.144: IP-EIGRP: Callback: redist frm static AS 0 10.0.0.0/24 *Mar 17 15:58:12.144: into: eigrp AS 1 event: 1 *Mar 17 15:58:12.144: IP-EIGRP: Callback: redist frm static AS 0 172.16.0.0/24 *Mar 17 15:58:12.144: into: eigrp AS 1 event: 1

Related Commands

Command

Description

debugeigrpaddress-familyneighbor

Displays debugging information about EIGRP service family neighbors.

debug eigrp frr

To display debugging information about Enhanced Interior Gateway Routing Protocol (EIGRP) Fast Reroute (FRR) events, use the debug eigrp frr command in privileged EXEC mode. To disable debugging, use the no form of this command.

debug eigrp frr

no debug eigrp frr

Syntax Description

This command has no arguments or keywords.

Command Modes


        Privileged EXEC (#)

Command History

Release

Modification

15.2(4)S

This command was introduced.

Cisco IOS XE Release 3.7S

This command was integrated into Cisco IOS XE Release 3.7S.

Examples

The following is sample output from the debug eigrp frr command. The fields in the display are self-explanatory.

Device# *May 25 15:34:48.421: EIGRP-FRR: 10.6.6.6 can not be a LFA *May 25 15:34:48.421: EIGRP-FRR: 192.168.1.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.422: EIGRP-FRR: 192.168.3.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.422: EIGRP-FRR: 10.3.3.3 can not be a LFA *May 25 15:34:48.422: EIGRP-FRR: 10.6.6.6 can not be a LFA *May 25 15:34:48.422: EIGRP-FRR: 192.168.1.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.422: EIGRP-FRR: 192.168.2.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.422: EIGRP-FRR: 192.168.3.0/24 is having 2 available paths and 2 successors *May 25 15:34:48.435: EIGRP-FRR: 10.5.5.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.435: EIGRP-FRR: 10.1.1.2 can not be a LFA *May 25 15:34:48.435: EIGRP-FRR: 10.3.3.3 can not be a LFA *May 25 15:34:48.435: EIGRP-FRR: 10.6.6.6 can not be a LFA *May 25 15:34:48.435: EIGRP-FRR: 192.168.1.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.435: EIGRP-FRR: 192.168.2.0/24 is having 2 available paths and 1 successors *May 25 15:34:48.435: EIGRP-FRR: Number of LFA are 1 *May 25 15:34:48.435: EIGRP-FRR: Going to update repair path for 192.168.2.0/24 with 10.2.3.3 *May 25 15:34:48.435: EIGRP-IPv4-FRR: Repair path for 192.168.2.0/24 with nexthop 10.2.3.3 has been updated *May 25 15:34:48.436: EIGRP-FRR: 192.168.3.0/24 is having 3 available paths and 1 successors *May 25 15:34:48.436: EIGRP-FRR: Number of LFA are 2 *May 25 15:34:48.436: EIGRP-FRR: SRLG Disjoint *May 25 15:34:48.436: EIGRP-FRR: Going to update repair path for 192.168.3.0/24 with 10.3.3.1 *May 25 15:34:48.436: EIGRP-IPv4-FRR: Repair path for 192.168.3.0/24 with nexthop 10.3.3.1 has been updated *May 25 15:34:48.446: EIGRP-FRR: 10.10.10.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.446: EIGRP-FRR: 10.4.4.4 can not be a LFA *May 25 15:34:48.446: EIGRP-FRR: 10.1.1.2 can not be a LFA *May 25 15:34:48.446: EIGRP-FRR: 10.3.3.3 can not be a LFA *May 25 15:34:48.446: EIGRP-FRR: 10.6.6.6 can not be a LFA *May 25 15:34:48.446: EIGRP-FRR: 192.168.1.0/24 is having 1 available paths and 1 successors *May 25 15:34:48.447: EIGRP-FRR: 192.168.3.0/24 is having 4 available paths and 1 successors *May 25 15:34:48.447: EIGRP-FRR: Number of LFA are 3 *May 25 15:34:48.447: EIGRP-FRR: SRLG Disjoint *May 25 15:34:48.447: EIGRP-FRR: Going to update repair path for 192.168.3.0/24 with 10.4.3.1 *May 25 15:34:48.447: EIGRP-IPv4-FRR: Repair path for 192.168.3.0/24 with nexthop 10.4.3.4 has been updated RTR-1# *May 25 15:34:48.447: EIGRP-IPv4-FRR: Repair path for 192.168.3.0/24 with nexthop 10.2.3.3 has been deleted

debug eigrp fsm

To display debugging information about Enhanced Interior Gateway Routing Protocol (EIGRP) feasible successor metrics (FSMs), use the debugeigrpfsm command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugeigrpfsm

nodebugeigrpfsm

Syntax Description

This command has no arguments or keywords.

Command Modes


Privileged EXEC

Command History

Release

Modification

12.0(7)T

This command was introduced.

12.4(6)T

Support for IPv6 was added.

12.2(33)SRB

This command was integrated into Cisco IOS Release 12.2(33)SRB.

12.2(33)SXH

This command was integrated into Cisco IOS Release 12.2(33)SXH.

Cisco IOS XE Release 2.1

This command was introduced on Cisco ASR 1000 Series Routers.

Usage Guidelines

This command helps you observe EIGRP feasible successor activity and to determine whether route updates are being installed and deleted by the routing process.

Examples

The following is sample output from the debugeigrpfsm command:

Router# DUAL: dual_rcvupdate(): 172.25.166.0 255.255.255.0 via 0.0.0.0 metric 750080/0 DUAL: Find FS for dest 172.25.166.0 255.255.255.0. FD is 4294967295, RD is 42949 67295 found DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0 DUAL: dual_rcvupdate(): 192.168.4.0 255.255.255.0 via 0.0.0.0 metric 4294967295/ 4294967295 DUAL: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216 DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295 DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state. DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0 DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0

In the first line, DUAL stands for diffusing update algorithm. It is the basic mechanism within EIGRP that makes the routing decisions. The next three fields are the Internet address and mask of the destination network and the address through which the update was received. The metric field shows the metric stored in the routing table and the metric advertised by the neighbor sending the information. If shown, the term "Metric... inaccessible" usually means that the neighbor router no longer has a route to the destination, or the destination is in a hold-down state.

In the following output, EIGRP is attempting to find a feasible successor for the destination. Feasible successors are part of the DUAL loop avoidance methods. The FD field contains more loop avoidance state information. The RD field is the reported distance, which is the metric used in update, query, or reply packets.

The indented line with the "not found" message means a feasible successor (FS) was not found for 192.168.4.0 and EIGRP must start a diffusing computation. This means it begins to actively probe (sends query packets about destination 192.168.4.0) the network looking for alternate paths to 192.164.4.0.

DUAL: Find FS for dest 192.168.4.0 255.255.255.0. FD is 2249216, RD is 2249216 DUAL: 0.0.0.0 metric 4294967295/4294967295not found Dmin is 4294967295

The following output indicates the route DUAL successfully installed into the routing table:

DUAL: RT installed 172.25.166.0 255.255.255.0 via 0.0.0.0

The following output shows that no routes to the destination were discovered and that the route information is being removed from the topology table:

DUAL: Dest 192.168.4.0 255.255.255.0 not entering active state. DUAL: Removing dest 192.168.4.0 255.255.255.0, nexthop 0.0.0.0 DUAL: No routes. Flushing dest 192.168.4.0 255.255.255.0

debug eigrp neighbor

To display neighbors discovered by the Enhanced Interior Gateway Routing Protocol (EIGRP), use the debugeigrpneighbor command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugeigrpneighbor [siatimer] [static]

nodebugeigrpneighbor [siatimer] [static]

Syntax Description

siatimer

(Optional) Stuck-in-active (SIA) timer messages.

static

(Optional) Static routes.

Command Default

Debugging for EIGRP neighbors is not enabled.

Command Modes


Privileged EXEC

Command History

Release

Modification

12.0(7)T

This command was introduced.

12.4(6)T

Support for IPv6 was added.

12.2(33)SRB

This command was integrated into Cisco IOS Release 12.2(33)SRB.

12.2(37)SE

This command was integrated into Cisco IOS Release 12.2(37)SE.

12.2(33)SXH

This command was integrated into Cisco IOS Release 12.2(33)SXH.

Cisco IOS XE Release 2.1

This command was introduced on Cisco ASR 1000 Series Routers.

Examples

The following is sample output from the debugeigrpneighbor command:

Router# EIGRP Static Neighbors debugging is on Router# Router(config)# Router(config-router)# Router(config-router)# 22:40:07:EIGRP:Multicast Hello is disabled on Ethernet3/1! 22:40:07:EIGRP:Add new static nbr 10.1.1.1 to AS 100 Ethernet3/1 Router(config-router)# Router(config-router)# 22:41:23:EIGRP:Static nbr 10.1.1.1 not in AS 100 Ethernet3/1 dynamic list 22:41:23:EIGRP:Delete static nbr 10.1.1.1 from AS 100 Ethernet3/1 22:41:23:EIGRP:Multicast Hello is enabled on Ethernet3/1!

Related Commands

Command

Description

neighbor

Defines a neighboring router with which to exchange routing information.

showipeigrpneighbors

Displays EIGRP neighbors.

showipv6eigrpneighbors

Displays IPv6 EIGRP neighbors.

debug eigrp notifications

To debug notifications sent from the L2L3 API interface, use thedebugeigrpnotificationscommand in privileged EXEC mode. To turn off debugging, use the no form of this command.

debugeigrpnotifications { rib | interface }

Syntax Description

rib

Captures notifications from the routing information base (RIB)

interface

Captures notifications from the interface.

Command Default

Debugging of EIGRP notifications for the L2L3 API interface is not enabled.

Command Modes


Privileged EXEC (#)

Command History

Release

Modification

12.4(15)XF

This command was introduced.

12.4(15)T

This command was integrated into Cisco IOS Release 12.4(15)T.

12.2SX

This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.

12.2(33)SRE

This command was integrated into Cisco IOS Release 12.2(33)SRE.

Usage Guidelines

Consult Cisco technical support before using this command.


Caution


Use of debug commands can have severe performance penalties and should be used with extreme caution. For this reason, Cisco recommends that you contact Cisco technical support before enabling a debug command.


Examples

The following example displays information about the L2L3 API Interface:

Router#

Related Commands

Command

Description

eigrpinterface

Sets a threshold value to minimize hysteresis in a router-to-radio configuration.

interfacevmi

Creates a virtual multipoint interface (VMI) that can be configured and applied dynamically.

debug eigrp nsf

To display nonstop forwarding (NSF) events in the console of an NSF-aware or NSF-capable router, use the debugeigrpnsf command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugeigrpnsf

nodebugeigrpnsf

Syntax Description

This command has no arguments or keywords.

Command Modes


Privileged EXEC (#)

Command History

Release

Modification

12.2(15)T

This command was introduced.

12.2(28)SB

This command was integrated into Cisco IOS Release 12.2(28)SB.

12.2(33)SRA

This command was integrated into Cisco IOS Release 12.2(33)SRA.

12.2(33)SXH

This command was integrated into Cisco IOS Release 12.2(33)SXH.

15.0(1)M

This command was integrated into Cisco IOS Release 15.0(1)M.

Cisco IOS XE Release 3.6S

This command was modified. Support for IPv6 and IPv6 VPN Routing and Forwarding (VRF) was added.

15.2(2)S

This command was modified. Support for IPv6 and IPv6 VRF was added.

15.2(1)E

This command was integrated into Cisco IOS Release 15.2(1)E.

Usage Guidelines

The output from the debugeigrpnsf command displays NSF-specific events. The debugeigrpnsf command can be issued on either an NSF-capable or an NSF-aware router.

Examples

The following example shows how to enable the Enhanced Interior Gateway Routing Protocol (EIGRP) NSF debugging and display information about neighbor devices:

Device# EIGRP NSF debugging is on Device# EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 10.1.2.1 Et1/0 11 00:00:25 10 200 0 5 Version 5.1/3.0, Retrans: 2, Retries: 0, Prefixes: 1 Topology-ids from peer - 0 ! *Sep 23 18:57:19.423: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.2.1 (Ethernet1/0) is resync: peer graceful-restart *Sep 23 18:57:19.423: EIGRP: NSF: AS100, NSF or GR initiated by 10.1.2.1, flags 0x4:(RS) *Sep 23 18:57:36.028: EIGRP: NSF: AS100, Receive EOT from 10.1.2.1, Flags 0x8:(EOT) *Sep 23 18:57:36.028: EIGRP: NSF: route hold timer set to flush stale routes *Sep 23 18:57:36.038: EIGRP: NSF: AS100. route hold timer expiry *Sep 23 18:57:36.038: EIGRP: NSF: EIGRP-IPv4: Search for stale routes from 10.1.2.1 ! Device# EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 10.1.2.1 Et1/0 11 00:02:31 12 200 0 6 Time since Restart 00:01:34 Version 5.1/3.0, Retrans: 2, Retries: 0, Prefixes: 1 Topology-ids from peer - 0

The following sample output is displayed when a router is unable to handle an event with NSF-Awareness:

*Jan 23 18:59:56.040: EIGRP: NSF: AS100: Checking if Graceful Restart is possible with neighbor 1.1.2.1, peer_down reason 'peer restarted' *Jan 23 18:59:56.040: EIGRP: NSF: Not possible: 'peer_down was called with a HARD resync flag' *Jan 23 18:59:56.040: %DUAL-5-NBRCHANGE: EIGRP-IPv6 100: Neighbor 10.1.2.1 (Ethernet1/0) is down: peer restarted *Jan 23 19:00:00.170: %DUAL-5-NBRCHANGE: EIGRP-IPv6 100: Neighbor 10.1.2.1 (Ethernet1/0) is up: new adjacency *Jan 23 19:00:00.170: EIGRP: NSF: Enqueuing NULL update to 10.1.2.1, flags 0x1:(INIT)

debug eigrp packets

To display debugging information about Enhanced Interior Gateway Routing Protocol (EIGRP) packets, use the debugeigrppackets command in privileged EXEC mode. To disable debugging, use the no form of this command.

debug eigrp packets [ SIAquery | SIAreply | ack | hello | ipxsap | probe | query | reply | request | retry | stub | terse | update | verbose ] [ detail ]

no debug eigrp packets

Syntax Description

SIAquery

(Optional) Enables debugging of stuck-in-active (SIA) query messages.

SIAreply

(Optional) Enables debugging of SIA reply messages.

ack

(Optional) Enables debugging of EIGRP acknowledgment packets.

hello

(Optional) Enables debugging of EIGRP hello packets.

ipxsap

(Optional) Enables debugging of EIGRP Internetwork Packet Exchange (IPX) Service Advertisement Protocol (SAP) packets.

probe

(Optional) Enables debugging of EIGRP probe packets.

query

(Optional) Enables debugging of EIGRP query packets.

reply

(Optional) Enables debugging of EIGRP reply packets.

request

(Optional) Enables debugging of EIGRP request packets.

retry

(Optional) Enables debugging of EIGRP retry packets.

stub

(Optional) Enables debugging of EIGRP stub packets.

terse

(Optional) Enables debugging of all EIGRP packets except hello packets.

update

(Optional) Enables debugging of EIGRP update packets.

verbose

(Optional) Enables debugging of all EIGRP packets.

detail

(Optional) Enables detailed debugging of packets, depending on any of the keywords specified in the command.

Command Modes


Privileged EXEC (#)

Command History

Release

Modification

12.0(7)T

This command was introduced.

12.4(6)T

This command was modified. Support for IPv6 was added.

12.2(33)SRB

This command was integrated into Cisco IOS Release 12.2(33)SRB.

12.2(33)SXH

This command was integrated into Cisco IOS Release 12.2(33)SXH.

Cisco IOS XE Release 2.1

This command was implemented on Cisco ASR 1000 Series Aggregation Services Routers.

15.2(4)S

This command was modified. The detail keyword was added.

Cisco IOS XE Release 3.7S

This command was modified. The detail keyword was added.

Usage Guidelines

Use the debugeigrppackets command to analyze messages traveling between local and remote hosts.


Note


Although this command accepts a number of keywords, we do not recommend their use.


Examples

The following sample output from the debugeigrppackets command displays the transmission and receipt of EIGRP packets. These packet types may be hello, update, request, query, or reply packets. The sequence and acknowledgment numbers used by the EIGRP reliable transport algorithm are shown in the output. Wherever applicable, the network-layer address of the neighboring router is also included.

Device# *May 24 15:33:10.255: EIGRP: Sending HELLO on Ethernet0/1 *May 24 15:33:10.255: AS 109, Flags 0x0, Seq 0, Ack 0 *May 24 15:33:10.255: EIGRP: Sending HELLO on Ethernet0/1 *May 24 15:33:10.255: AS 109, Flags 0x0, Seq 0, Ack 0 *May 24 15:33:10.255: EIGRP: Sending HELLO on Ethernet0/1 *May 24 15:33:10.255: AS 109, Flags 0x0, Seq 0, Ack 0 *May 24 15:33:10.255: EIGRP: Received UPDATE on Ethernet0/1 from 192.168.78.24, *May 24 15:33:10.255: AS 109, Flags 0x1, Seq 1, Ack 0 *May 24 15:33:10.255: EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.168.78.24, *May 24 15:33:10.255: AS 109, Flags 0x0, Seq 0, Ack 1 *May 24 15:33:10.255: EIGRP: Sending HELLO/ACK on Ethernet0/1 to 192.168.78.24, *May 24 15:33:10.255: AS 109, Flags 0x0, Seq 0, Ack 1 *May 24 15:33:10.255: EIGRP: Received UPDATE on Ethernet0/1 from 192.168.78.24, *May 24 15:33:10.255 AS 109, Flags 0x0, Seq 2, Ack 0

The following sample output from the debug eigrp packets hello detail command displays debugging details of EIGRP hello packets:

Device# *May 25 15:33:10.255: EIGRP: Sending HELLO on Et1/0 - paklen 20 *May 25 15:33:10.255: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 *May 25 15:33:10.255: {type = 1, length = 12} *May 25 15:33:10.255: {vector = { *May 25 15:33:10.255: {01000100 0000000F} *May 25 15:33:10.255: } *May 25 15:33:10.255: {type = 4, length = 8} *May 25 15:33:10.255: {vector = { *May 25 15:33:10.255: {0B000200} *May 25 15:33:10.255: } *May 25 15:33:10.695: EIGRP: Sending HELLO on Et0/2 - paklen 20 *May 25 15:33:10.695: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 *May 25 15:33:10.695: {type = 1, length = 12} *May 25 15:33:10.695: {vector = { *May 25 15:33:10.695: {01000100 0000000F} *May 25 15:33:10.695: } *May 25 15:33:10.695: {type = 4, length = 8} *May 25 15:33:10.695: {vector = { *May 25 15:33:10.695: {0B000200} *May 25 15:33:10.695: }

The table below describes the significant fields shown in the displays.

Field

Description

EIGRP:

EIGRP packet information.

AS 109

Autonomous system number.

Flags 0x0

A flag of 1 means that the sending device is informing the receiving device that this is the first packet that is being sent to the receiver.

A flag of 2 is a multicast that should be conditionally received by devices that have been previously set with the conditionally receive (CR) bit. This bit gets set when the sender of the multicast has previously sent a sequence packet explicitly telling the packet to set the CR bit.

A flag of 0X0 means no flags are set on the packet.

HELLO

Hello packets are neighbor discovery packets. They are used to determine whether neighbors are still alive. As long as neighbors receive the hello packets that a device is sending, the neighbors validate the device and any routing information sent by the device.

debug eigrp service-family

To troubleshoot an Enhanced Interior Gateway Routing Protocol (EIGRP) service-family external client, client, neighbor, notification, topology, or a VRF instance, use the debugeigrpservice-familycommand in privileged EXEC mode.

{ debugeigrpservice-family [ external-client { client | messages | protocol } ] | { ipv4 | ipv6 } [ [ vrf ] | client | neighbor | notificationstopology ] }

Syntax Description

external-client

(Optional) Displays information for a Cisco SAF External Client.

client

Displays information for managing clients and TCP connections.

messages

(Optional) Reliability metric. The range is 0 to 255, entered in increments of 2.5 where 255 is 100-percent reliable.

protocol

(Optional) Displays information on an external-client protocol.

client-label

(Optional) Displays a client, message, or protocol debug for the specified Cisco SAF External Client.

ipv4

Specifies the IP Version 4 address family for this debug.

ipv6

Specifies the IP Version 6 address family for this debug.

vrf

(Optional) Specifies all virtual routing forwarding (VRF) instance tables or a specific VRF table for an IP address.

vrf-name

(Optional) Specifies a VRF table for an IP address.

autonomous-system-number

The Autonomous system number.

service-instance- number

(Optional) Service-instance number between 1 and 65535. Service instance numbers display as: service:subservice:instance.instance.instance.instance.

client

(Optional) Displays EIGRP client information.

client-label

(Optional) A specific client.

neighbors

(Optional) Displays EIGRP neighbor debugging information.

neighbor-ip- address

(Optional) The IP address of the neighbor.

notifications

(Optional) Displays EIGRP notification debugging information.

topology

(Optional) Specifies a service topology.

service-instance- number

(Optional) Service-instance number between 1 and 65535. Topology service instance numbers display as: service:subservice:instance.instance.instance.instance.

Command Modes

Privileged EXEC (#)

Command History

Release

Modification

15.0(1)M

This command was introduced.

12.2(33)SRE

This command was integrated into Cisco IOS Release 12.2(33)SRE.

12.2(33)XNE

This command was integrated into Cisco IOS Release 12.2(33)XNE.

Cisco IOS XE Release 2.5

This command was integrated into Cisco IOS XE Release 2.5.

12.2SX

This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.

15.2(1)S

This command was deprecated in Cisco IOS Release 15.2(1)S and replaced by the debug service-routing xmcp command.

Cisco IOS XE Release 3.5S

This command was deprecated in Cisco IOS XE Release 3.5S and replaced by the debug service-routing xmcp command.

15.2(2)T

This command was deprecated in Cisco IOS Release 15.2(2)T and replaced by the debug service-routing xmcp command.

Usage Guidelines

Use the debugeigrpservice-familyexternal-clientclientcommand to display information to help manage clients and TCP connections. Use the debugeigrpservice-familyexternal-clientmessagescommand to display message content and decoded messages. Use the debugeigrpservice-familyexternal-clientprotocolcommand to display encode and decode information to help manage the interaction with the Cisco SAF internal API.


Note


Using the debugeigrpservice-familyipv6 commands requires an IPv6-enabled SAF client, which currently does not exist.


Examples

The following is sample output of a Cisco SAF External-Client debugging message: Router# *Jun 11 14:25:10.051: 2 found c1 c1 *Jun 11 14:25:10.051: SAF-EC: 100 byte message from c1 *Jun 11 14:25:10.051: 0001 0050 7F5A 9BC7 D285 A1D8 3C54 552F 37AE 655B 0014 0005 2253 4146 2200 *Jun 11 14:25:10.051: 0000 0006 0005 756E 616D 6500 0000 1005 0002 6331 0000 1003 0004 0001 0000 *Jun 11 14:25:10.051: 1001 0002 6331 0000 1004 0004 0000 0005 0008 0014 45F4 57A9 42CF 0556 4077 *Jun 11 14:25:10.051: 7AA3 B94A 703F 1BA3 ACA7 *Jun 11 14:25:10.051: *Jun 11 14:25:10.051: Class: Success Response Method: Register *Jun 11 14:25:10.051: Packet Length: 52 Not including 20 byte Saf Header *Jun 11 14:25:10.051: Magic Cookie: 7F5A9BC7 Transaction ID: D285A1D83C54552F37AE65 Router#5B *Jun 11 14:25:10.051: Realm: 014: Length: 5: "SAF" *Jun 11 14:25:10.051: Keep Alive: 1006: Length: 4: 360000 *Jun 11 14:25:10.051: Client Handle: 1002: Length: 4: 2 *Jun 11 14:25:10.051: Message Integrity: 008: Length: 20: 86839D4C64E36476D743AAF26112D28C32E3DF99 *Jun 11 14:25:10.051: 0101 0034 7F5A 9BC7 D285 A1D8 3C54 552F 37AE 655B 0014 0005 2253 4146 2200 *Jun 11 14:25:10.051: 0000 1006 0004 0005 7E40 1002 0004 0000 0002 0008 0014 8683 9D4C 64E3 6476 *Jun 11 14:25:10.051: D743 AAF2 6112 D28C 32E3 DF99 *Jun 11 14:25:10.055: *Jun 11 14:25:10.055: SAF-EC: kicked timer 360000 The following is sample output of a Cisco SAF External-Client debugging protocol message: Router# *Jun 11 14:27:11.467: SAF-EC: attribute found, type: 1005 *Jun 11 14:27:11.467: No error *Jun 11 14:27:11.467: Class: Request Method: Register *Jun 11 14:27:11.467: Packet Length: 80 bytes Not including 20 byte Saf Header *Jun 11 14:27:11.467: Magic Cookie: 7F5A9BC7 Transaction ID: 8F1F3F36EE43784D0DFABEA6 *Jun 11 14:27:11.467: Realm: 014: Length: 5: "SAF" *Jun 11 14:27:11.467: Username: 006: Length: 5: uname *Jun 11 14:27:11.467: Client Label: 1005: Length: 2: c1 *Jun 11 14:27:11.467: Protocol Version: 1003: Length: 4: 10000 *Jun 11 14:27:11.467: Client Name: 1001: Length: 2: c1 *Jun 11 14:27:11.467: Page Size: 1004: Length: 4: 5 Router# *Jun 11 14:27:11.467: Message Integrity: 008: Length: 20: AB3D7C39E4E0673B1539750D6E21A79ACFCE51F8 *Jun 11 14:27:11.467: SAF-EC: request start. *Jun 11 14:27:11.467: SAF-EC: client successfully registered. client_handle 3 Router#

Related Commands

Command

Description

exit-service-family

Exits service-family configuration mode.

router eigrp

Configures the EIGRP process.

service-family

Specifies service-family configuration mode.

debug eigrp transmit

To display transmittal messages sent by the Enhanced Interior Gateway Routing Protocol (EIGRP), use the debugeigrptransmit command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugeigrptransmit [ack] [build] [detail] [link] [packetize] [peerdown] [sia] [startup] [strange]

nodebugeigrptransmit [ack] [build] [detail] [link] [packetize] [peerdown] [sia] [startup] [strange]

Syntax Description

ack

(Optional) Information for acknowledgment (ACK) messages sent by the system.

build

(Optional) Build information messages (messages that indicate that a topology table was either successfully built or could not be built).

detail

(Optional) Additional detail for debug output.

link

(Optional) Information regarding topology table linked-list management.

packetize

(Optional) Information regarding topology table linked-list management.

peerdown

(Optional) Information regarding the impact on packet generation when a peer is down.

sia

(Optional) Stuck-in-active (SIA) messages.

startup

(Optional) Information regarding peer startup and initialization packets that have been transmitted.

strange

(Optional) Unusual events relating to packet processing.

Command Default

Debugging for EIGRP transmittal messages is not enabled.

Command Modes


Privileged EXEC

Command History

Release

Modification

12.1

This command was introduced.

12.4(6)T

Support for IPv6 was added.

12.2(33)SRB

This command was integrated into Cisco IOS Release 12.2(33)SRB.

12.2(33)SXH

This command was integrated into Cisco IOS Release 12.2(33)SXH.

Cisco IOS XE Release 2.1

This command was introduced on Cisco ASR 1000 Series Routers.

Examples

The following is sample output from the debugeigrptransmit command:

Router# EIGRP Transmission Events debugging is on (ACK, PACKETIZE, STARTUP, PEERDOWN, LINK, BUILD, STRANGE, SIA, DETAIL) Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router#(config)# router eigrp 100 Router#(config-router)# network 10.4.9.0 0.0.0.255 Router#(config-router)# 5d22h: DNDB UPDATE 10.0.0.0/8, serno 0 to 1, refcount 0 Router#(config-router)#

debug elb-pal-pd

To display debugging information related to the Ethernet Data Plane Loopback feature, use the debugelb-pal-pd command in the privileged EXEC mode. To disable the debugging function, use the no form of this command.

debugelb-pal-pd { all | error | event }

nodebugelb-pal-pd { all | error | event }

Syntax Description

all

Displays all the debugging information pertaining to the Ethernet data plane loopback configuration.

error

Displays debugging information pertaining to the Ethernet data plane loopback configuration errors.

event

Displays debugging information pertaining to the Ethernet data plane loopback configuration changes.

Command Default

Debugging is disabled.

Command Modes


Privileged EXEC (#)

Command History

Release Modification

15.4(1)T

This command was introduced into Cisco IOS Release 15.4(1)T.

Usage Guidelines

Use this command to display the errors that occur when the Ethernet Data Plane Loopback feature is configured on the following routers:

  • Cisco 3900 Series, Cisco 2900 Series, and Cisco 1900 Series Integrated Services Routers Generation 2

  • Cisco 890 Series Integrated Services Routers

Examples

The following is a sample output of the debugelb-pal-pd event command:

Device# elb pal pd event debugging is on

The following is a sample output of the ethernetloopback startlocalinterface command:

Device# This is an intrusive loopback and the packets matched with the service will not be able to pass through. Continue? (yes/[no]): yes Router# *Nov 27 20:34:37.200: elb service info in PAL: session id 1, interface GigabitEthernet0/2.301, si_handle 0x0, dir Facility, session_type 3,src mac 0000.0000.0000, dest mac 0000.0000.0000, dot1q_bl , second_dot1q_bl , cos 8, oui 0 etype 0, filter_option_flags 0 *Nov 27 20:34:37.200: elb_pd_sb_init *Nov 27 20:34:37.200: cn_xfr_ge_elb_pd_loopback: on_off 1, hwidb 0x3CFFC364, elb_pd_intf_lpbk_count 1 *Nov 27 20:34:37.200: elb_pal_pd_loopback_wrapper: elb_pal_pd_loopback action succeeded. *Nov 27 20:34:37.200: elb_pal_pd_start_lb: filter_out_vlan 0x0000, filter_in_vlan 0x0000, intf_out_vlan 0xFFFF, intf_in_vlan 0xFFFF *Nov 27 20:34:37.200: elb_pal_pd_start_lb: option_flag 0x00000000, filter_dir 1, loopback_on_off 1, session_type 3 *Nov 27 20:34:37.200: elb_pal_pd_start_lb: elb_pal_pd_num_intf_lpbk 1 *Nov 27 20:34:37.200: %E_DLB-6-DATAPLANE_LOOPBACK_START: Ethernet Dataplane Loopback Start on interface GigabitEthernet0/2.301 with session id 1 Router#

Related Commands

Command

Description

ethernetloopbackstartlocalinterface

Starts Ethernet external loopback on the subinterface.

debug emm

To debug Embedded Menu Manager (EMM) Menu Definition Files (MDFs), use the debugemmcommand in user EXEC or privileged EXEC mode. To disable debugging, use the no form of this command.

debugemm

nodebugemm

Syntax Description

This command has no arguments or keywords.

Command Default

Disabled.

Command Modes


User EXEC (#)
Privileged EXEC (#)

Command History

Release

Modification

12.4(20)T

This command was introduced.

Usage Guidelines

Do not run this command on the same vty as the EMM menu.

Examples

The following is sample output from thedebugemmcommand. The output is described in the EMM XML Schema Definition (XSD), which is available for download at this website:

http://forums.cisco.com/eforum/servlet/EEM?page=main

Router# debug emm EMM debugging is on *Jun 10 15:45:42.043: Looking for MenuTitle, parent = Menu *Jun 10 15:45:42.063: Looking for GlobalTCL, parent = Menu *Jun 10 15:45:42.083: Looking for MenuTitle, parent = Menu

Related Commands

Command

Description

emm

Loads and launches preconfigured MDFs or launches loaded preconfigured EMM menus.

emmclear

Changes the terminal clear-screen escape sequence.

showmdf

Displays loaded preconfigured MDFs.

debug eou

To display information about Extensible Authentication Protocol over User Datagram Protocol (UDP) (EAPoUDP), use the debugeou command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugeou { all | eap | errors | events | packets | ratelimit | sm }

nodebugeou { all | eap | errors | events | packets | ratelimit | sm }

Syntax Description

all

Displays all EAPoUDP information.

eap

Displays EAPoUDP packets.

errors

Displays information about EAPoUDP packet errors.

events

Displays information about EAPoUDP events.

packets

Displays EAPoUDP packet-related information.

ratelimit

Displays EAPoUDP posture-validation information.

sm

Displays EAPoUDP state machine transitions.

Command Default

If you do not enter any keywords, debugging is turned on for all EAPoUDP messages.

Command Modes


Privileged EXEC #

Command History

Release

Modification

12.3(8)T

This command was introduced.

12.2(33)SRA

This command was integrated into Cisco IOS Release 12.2(33)SRA.

12.2(33)SXI

This command was integrated into Cisco IOS Release 12.2(33)SXI.

Examples

The following sample output from the debugeouall command shows all EAPoUDP information:

Router# *Apr 9 19:30:40.782: eou-ev:EOU Init Validation for idb= FastEthernet0/0.420 src_mac= 0001.027c.f364 src_ip= 10.0.0.1 *Apr 9 19:30:40.786: eou_auth 10.0.0.1: initial state eou_initialize has enter *Apr 9 19:30:40.786: @@@ eou_auth 10.0.0.1: eou_initialize -> eou_hello *Apr 9 19:30:40.786: eou-ev:eou_send_hello_request: Send Hello Request host= 10.0.0.15 eou_port= 5566 (hex) *Apr 9 19:30:40.790: EAPoUDP (tx) Flags:0 Ver=1 opcode=2 Len=8 MsgId=3839857370 Assoc ID=0 *Apr 9 19:30:40.790: Dumping TLV contents *Apr 9 19:30:40.790: TLV M:1 R:0 Type=ASSOCIATION ID Length=4 Association=-1994800267 *Apr 9 19:30:40.999: EAPoUDP (rx) Flags:128 Ver=1 opcode=2 Len=24 MsgId=3839857370 Assoc ID=2300167029 *Apr 9 19:30:40.999: Dumping TLV contents *Apr 9 19:30:40.999: TLV M:1 R:0 Type=COOKIE PAYLOAD Length=12 07167CE0: 8919C375 259B6D41 5FEA5D27 ..Cu%.mA_j]' 07167CF0: *Apr 9 19:30:40.999: TLV M:1 R:0 Type=ASSOCIATION ID Length=4 Association=1016688999 *Apr 9 19:31:50.048: @@@ eou_auth 10.0.0.1: eou_eap -> eou_eap *Apr 9 19:31:50.048: eou-ev:10.0.0.1: msg = 24(eventEouEapSuccess) *Apr 9 19:31:50.048: eou_auth 10.0.0.1: during state eou_eap, got event 14(eouEapSuccess) *Apr 9 19:31:50.048: @@@ eou_auth 10.0.0.1: eou_eap -> eou_result *Apr 9 19:31:50.052: eou-ev:Starting RESULT timer 3(10.0.0.1)

Related Commands

Command

Description

debugeap

Displays information about EAP messages.

debugipadmissioneapoudp

Displays information about EAPoUDP network admission control events.

debug epc

To enable debugging of embedded packet capture (EPC) infrastructure, use the debug epc command in privileged EXEC mode. To disable debugging of packet capture infrastructure, use the no form of this command.

debug epc { capture-point | provision }

no debug epc { capture-point | provision }

Syntax Description

capture-point

Specifies debugging of the capture point configuration.

provisioning

Specifies debugging of capture provisioning.

Command Default

Debug messages are not logged.

Command Modes


        Privileged EXEC (#)

Command History

Release

Modification

Cisco IOS XE Release 3.7S

This command was introduced.

Examples

The following example shows how to enable debugging of the Embedded Packet Capture (EPC) capture point:

Device# EPC capture point operations debugging is on Device# *Jul 4 14:17:15.463: EPC CP: Starting the capture cap1 *Jul 4 14:17:15.463: EPC CP: (brief=3, detailed=4, dump=5) = 0 *Jul 4 14:17:15.463: EPC CP: final check before activation *Jul 4 14:17:15.463: EPC CP: setting up c3pl infra *Jul 4 14:17:15.463: EPC CP: Setup c3pl acl-class-policy *Jul 4 14:17:15.463: EPC CP: Creating a class *Jul 4 14:17:15.464: EPC CP: Creating a class : Successful *Jul 4 14:17:15.464: EPC CP: class-map Created *Jul 4 14:17:15.464: EPC CP: creating policy-name epc_policy_cap1 *Jul 4 14:17:15.464: EPC CP: Creating Policy epc_policy_cap1 of type 49 and client type 21 *Jul 4 14:17:15.464: EPC CP: Storing a Policy *Jul 4 14:17:15.464: EPC CP: calling ppm_store_policy with epc_policy *Jul 4 14:17:15.464: EPC CP: Creating Policy : Successful *Jul 4 14:17:15.464: EPC CP: policy-map created *Jul 4 14:17:15.464: EPC CP: creating filter for ANY *Jul 4 14:17:15.464: EPC CP: Adding acl to class : Successful *Jul 4 14:17:15.464: EPC CP: Setup c3pl class to policy *Jul 4 14:17:15.464: EPC CP: Attaching Class to Policy *Jul 4 14:17:15.464: EPC CP: Attaching epc_class_cap1 to epc_policy_cap1 *Jul 4 14:17:15.464: EPC CP: Attaching Class to Policy : Successful *Jul 4 14:17:15.464: EPC CP: setting up c3pl qos *Jul 4 14:17:15.464: EPC CP: DBG> Set packet rate limit to 1000 *Jul 4 14:17:15.464: EPC CP: creating action for policy_map epc_policy_cap1 class_map epc_class_cap1 *Jul 4 14:17:15.464: EPC CP: DBG> Set packet rate limit to 1000 *Jul 4 14:17:15.464: EPC CP: Activating Interface GigabitEthernet1/0/1 direction both *Jul 4 14:17:15.464: EPC CP: Id attached 0 *Jul 4 14:17:15.464: EPC CP: inserting into active lists *Jul 4 14:17:15.464: EPC CP: Id attached 0 *Jul 4 14:17:15.465: EPC CP: inserting into active lists *Jul 4 14:17:15.465: EPC CP: Activating Vlan *Jul 4 14:17:15.465: EPC CP: Deleting all temp interfaces *Jul 4 14:17:15.465: %BUFCAP-6-ENABLE: Capture Point cap1 enabled. *Jul 4 14:17:15.465: EPC CP: Active Capture 1 Device# *Jul 4 14:17:31.963: EPC CP: Stopping the capture cap1 *Jul 4 14:17:31.963: EPC CP: Warning: unable to unbind capture cap1 *Jul 4 14:17:31.963: EPC CP: Deactivating policy-map *Jul 4 14:17:31.963: EPC CP: Policy epc_policy_cap1 *Jul 4 14:17:31.964: EPC CP: Deactivating policy-map Successful *Jul 4 14:17:31.964: EPC CP: removing povision feature *Jul 4 14:17:31.964: EPC CP: Found action for policy-map epc_policy_cap1 class-map epc_class_cap1 *Jul 4 14:17:31.964: EPC CP: cleanning up c3pl infra *Jul 4 14:17:31.964: EPC CP: Removing Class epc_class_cap1 from Policy *Jul 4 14:17:31.964: EPC CP: Removing Class from epc_policy_cap1 *Jul 4 14:17:31.964: EPC CP: Successfully removed *Jul 4 14:17:31.964: EPC CP: Removing acl mac from class *Jul 4 14:17:31.964: EPC CP: Removing acl from class : Successful *Jul 4 14:17:31.964: EPC CP: Removing all policies *Jul 4 14:17:31.964: EPC CP: Removing Policy epc_policy_cap1 *Jul 4 14:17:31.964: EPC CP: Removing Policy : Successful *Jul 4 14:17:31.964: EPC CP: Removing class epc_class_cap1 *Jul 4 14:17:31.965: EPC CP: Removing class : Successful *Jul 4 14:17:31.965: %BUFCAP-6-DISABLE: Capture Point cap1 disabled. *Jul 4 14:17:31.965: EPC CP: Active Capture 0

The following example shows how to enable debugging of EPC provisioning:

Device# EPC provisioning debugging is on Device# *Jul 4 14:17:54.991: EPC PROV: No action found for policy-map epc_policy_cap1 class-map epc_class_cap1 *Jul 4 14:17:54.991: EPC PROV: *Jul 4 14:17:54.991: Attempting to install service policy epc_policy_cap1 *Jul 4 14:17:54.992: EPC PROV: Attached service policy to epc idb subblock *Jul 4 14:17:54.992: EPC PROV: Successful. Create feature object *Jul 4 14:17:54.992: EPC PROV: *Jul 4 14:17:54.992: Attempting to install service policy epc_policy_cap1 *Jul 4 14:17:54.992: EPC PROV: Successful. Create feature object *Jul 4 14:17:54.992: %BUFCAP-6-ENABLE: Capture Point cap1 enabled. Device# *Jul 4 14:18:02.503: EPC PROV: Successful. Remove feature object *Jul 4 14:18:02.504: EPC PROV: Successful. Remove feature object *Jul 4 14:18:02.504: EPC PROV: Destroyed epc idb subblock *Jul 4 14:18:02.504: EPC PROV: Found action for policy-map epc_policy_cap1 class-map epc_class_cap1 *Jul 4 14:18:02.504: EPC PROV: Deleting EPC action *Jul 4 14:18:02.504: EPC PROV: Successful. CLASS_REMOVE, policy-map epc_policy_cap1, class epc_class_cap1 *Jul 4 14:18:02.504: %BUFCAP-6-DISABLE: Capture Point cap1 disabled.

Related Commands

Command

Description

monitorcapturestart

Starts the capture of packet data at a traffic trace point into a buffer.

monitorcapturestop

Stops the capture of packet data at a traffic trace point.

debug ephone alarm

To set SkinnyStation alarm messages debugging for the Cisco IP phone, use the debugephonealarmcommand in privileged EXEC mode. To disable debugging output, use the no form of this command.

debugephonealarm [ mac-address ]

nodebugephonealarm [ mac-address ]

Syntax Description

mac-address

(Optional) Defines the MAC address of the Cisco IP phone.

mac-address

(Optional) Specifies the MAC address of the Cisco IP phone.

Command Default

No default behavior or values

Command Modes


Privileged EXEC

Command History

Release

Modification

12.2(2)XT

This command was introduced on the following platforms: Cisco 1750, Cisco 1751, Cisco 2600 series and Cisco 3600 series multiservice routers; and Cisco IAD2420 series Integrated Access Devices (IADs).

12.2(8)T

This command was implemented on the Cisco 3725 and Cisco 3745 routers.

12.2(8)T1

This command was implemented on the Cisco 2600-XM and Cisco 2691 routers.

12.2(11)T

This command was implemented on the Cisco 1760 routers.

Usage Guidelines

The debugephonealarm command shows all the SkinnyStation alarm messages sent by the Cisco IP phone. Under normal circumstances, this message is sent by the Cisco IP phone just before it registers, and the message has the severity level for the alarm set to “Informational” and contains the reason for the phone reboot or re-register. This type of message is entirely benign and does not indicate an error condition.

If the mac-address keyword is not used, the debug ephone alarm command debugs all Cisco IP phones that are registered to the router. You can remove debugging for the Cisco IP phones that you do not want to debug by using themac-address keyword with the no form of this command.

You can enable or disable debugging on any number of Cisco IP phones. To see the Cisco IP phones that have debugging enabled, enter the showephone command and look at the debug field in the output. When debugging is enabled for a Cisco IP phone, the debug output is displayed for the directory numbers associated with the Cisco IP phone.

Examples

The following example shows a SkinnyStation alarm message that is sent before the Cisco IP phone registers:

Router# phone keypad reset CM-closed-TCP CM-bad-state

Related Commands

Command

Description

debugephonedetail

Sets detail debugging for the Cisco IP phone.

debugephoneerror

Sets error debugging for the Cisco IP phone.

debugephonekeepalive

Sets keepalive debugging for the Cisco IP phone.

debugephoneloopback

Sets MWI debugging for the Cisco IP phone.

debugephonepak

Provides voice packet level debugging and prints the contents of one voice packet in every 1024 voice packets.

debugephoneraw

Provides raw low-level protocol debugging display for all SCCP messages.

debugephoneregister

Sets registration debugging for the Cisco IP phone.

debugephonestate

Sets state debugging for the Cisco IP phone.

debugephonestatistics

Sets statistics debugging for the Cisco IP phone.

showdebugging

Displays information about the types of debugging that are enabled for your router.

debug ephone blf

To display debugging information for Busy Lamp Field (BLF) presence features, use the debugephoneblf command in privileged EXEC mode. To disable debugging, use the no form of this command.

debugephoneblf [ mac-address ]

nodebugephoneblf [ mac-address ]

Syntax Description

mac-addressmac-address

(Optional) Specifies the MAC address of a specific IP phone.

Command Modes


Privileged EXEC

Command History

Release

Modification

12.4(11)XJ

This command was introduced.

12.4(15)T

This command was integrated into Cisco IOS Release 12.4(15)T.

Usage Guidelines

Use this command for troubleshooting BLF speed-dial and BLF call-list features for phones in a presence service.

Examples

The following is sample output from the debugephoneblf command.

Router# EPHONE BLF debugging is enabled *Sep 4 07:18:26.307: skinny_asnl_callback: subID 16 type 4 *Sep 4 07:18:26.307: ASNL_RESP_NOTIFY_INDICATION *Sep 4 07:18:26.307: ephone-1[1]:ASNL notify indication message, feature index 4, subID [16] *Sep 4 07:18:26.307: ephone-1[1]:line status 6, subID [16] *Sep 4 07:18:26.307: ephone-1[1]:StationFeatureStatV2Message sent, status 2 *Sep 4 07:18:26.307: skinny_asnl_callback: subID 23 type 4 *Sep 4 07:18:26.307: ASNL_RESP_NOTIFY_INDICATION *Sep 4 07:18:26.307: ephone-2[2]:ASNL notify indication message, feature index 2, subID [23] *Sep 4 07:18:26.311: ephone-2[2]:line status 6, subID [23] *Sep 4 07:18:26.311: ephone-2[2]:StationFeatureStatV2Message sent, status 2 *Sep 4 07:18:28.951: skinny_asnl_callback: subID 16 type 4 *Sep 4 07:18:28.951: ASNL_RESP_NOTIFY_INDICATION *Sep 4 07:18:28.951: ephone-1[1]:ASNL notify indication message, feature index 4, subID [16] *Sep 4 07:18:28.951: ephone-1[1]:line status 1, subID [16] *Sep 4 07:18:28.951: ephone-1[1]:StationFeatureStatV2Message sent, status 1 *Sep 4 07:18:28.951: skinny_asnl_callback: subID 23 type 4 *Sep 4 07:18:28.951: ASNL_RESP_NOTIFY_INDICATION *Sep 4 07:18:28.951: ephone-2[2]:ASNL notify indication message, feature index 2, subID [23] *Sep 4 07:18:28.951: ephone-2[2]:line status 1, subID [23] *Sep 4 07:18:28.951: ephone-2[2]:StationFeatureStatV2Message sent, status 1

Related Commands

Command

Description

blf-speed-dial

Enables BLF monitoring for a speed-dial number on a phone registered to Cisco Unified CME.

presencecall-list

Enables BLF monitoring for call lists and directories on phones registered to a Cisco Unified CME router.

showpresenceglobal

Displays configuration information about the presence service.

showpresencesubscription

Sours: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/debug/command/e1/db-e1-cr-book/db-e1.html
Understanding EIGRP Unicast and Multicast Neighbor Relationships

CCNA Routing and Switching Portable Command Guide: Enhanced Interior Gateway Routing Protocol (EIGRP)

Displays the neighbor table.

Displays a detailed neighbor table.


TIP The show ip eigrp neighbors detail command verifies whether a neighbor is configured as a stub router.

Shows information for each interface.

Shows information for a specific interface.

Shows information for interfaces running process 100.

Displays the topology table.


TIP The show ip eigrp topology command shows you where your feasible successors are.

Shows the number and type of packets sent and received.

Shows the complete routing table.

Shows a routing table with only EIGRP entries.

Shows the parameters and current state of the active routing protocol process.

Shows authentication key information.

Sours: https://www.ciscopress.com/articles/article.asp?p=2101519&seqNum=4

Eigrp debug

Verifying Eigrp Operation

Last Updated on Fri, 18 Dec 2020 | CCIE

The show commands can be used to verify EIGRP operation.

Verifying EIGRP Operation (Cont.)

router#

debug eigrp packets

• Displays all types of EIGRP packets, both sent and received

router#

debug eigrp neighbors

• Displays the EIGRP neighbor

router#

interaction

debug ip eigrp

• Displays advertisements and changes EIGRP makes to the routing table

router#

debug ip eigrp summary

• Displays a brief report of the EIGRP routing activity

© 2002, CiscoSystems, Inc. All rights reserved.

Cisco CCIE Prep v1.0—Module 6-64

These debug commands can be used to verify EIGRP operation.

show ip eigrp neighbors Command

This can be one of the most useful commands when verifying the operational status of EIGRP. The show ip eigrp neighbors command will show the status of all EIGRP neighbors. The neighbor should be "up" for as long as EIGRP has been running on the link. EIGRP will form a neighbor with all routers on the same subnet, and in the same AS. EIGRP will not form a neighbor with mismatched k values; but a neighbor can be formed with mismatched hellos and dead timers. A neighbor with a short uptime is a clear indication of a problem. Another important field is the queue count. This field indicates the number of packets waiting to be transmitted to that neighbor. This value should be 0 or a number under 20. Consistent Q values in the range of 60 or greater are considered high. A high Smooth Round Trip Timer (SRTT) number can mean the packet is experiencing some type of delay on the link.

Rl# show ip eigrp neighbors

IP-EIGRP neighbors for process 2001

H Address

Interface Hold Uptime (sec)

SRTT RTO Q Seq

Cnt Num

SeO.l

136 05:48:23 36 1302 0 15

Se0.1

131 05:48:24 40 1302 0 17

■ Handle (H): A Cisco IOS internal number used to identify a neighbor. Do not confuse this with hop count.

■ Neighbor Address: This is the adjacent neighbor's IP address. A neighbor should be formed between every router on that subnet running EIGRP in a common AS.

■ Interface: The interface that is reporting the neighbor.

■ HoldTime: This is the amount of time, which counts down, that EIGRP waits for a 'hello' before tearing down the neighbor.

■ Uptime: States how long the neighbor has been up. This number should be up for as long as the link has been up.

■ SRRT: The number of milliseconds it takes for an EIGRP packet to be sent to this neighbor, and for the local router to receive an acknowledgement, hence, a round trip timer. If this number equals zero, a packet has never made a successful round trip.

■ Retransmission TimeOut (RTO): The amount of time, in milliseconds, that the EIGRP waits before re-transmitting a packet from the retransmission queue to a neighbor.

■ Queue count (Q): The number of packets waiting in the queue to be sent out to this neighbor. This value should be 0 or a very low number. A high queue count indicates that data is having trouble getting through.

■ Sequence Number (Seq-Num): Sequence number of the last update, query, or reply that was received from this neighbor. If this number equals zero, it indicates that no reliable packets have ever been received from the neighbor, another clear indication of a problem.

This command lists the EIGRP topology table discussed earlier. The table lists all routes that EIGRP is aware of and whether EIGRP is actively processing information on that route. Under most normal conditions, the routes should all be in a passive state, no EIGRP processes are running for that route. If the routes are active, this could indicate the Stuck In Active (SIA) state, which will be discussed in more detail in an upcoming section. The show ip eigrp topology command can also be extended to show information about an individual route or subnet. This information will include all relevant information about the route, including all of show ip eigrp topology Command its metrics and successors, as well as how the route was learned. This example illustrates the use of show ip eigrp topology followed by the extended version of the command.

Rl# show ip eigrp topology

IP-EIGRP Topology Table for process 2001

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status

P 172.16.5.0/24, 1 successors, FD is 23394560

via 172.16.1.5 (23394560/2 816 00), SerialO.l P 172.16.6.0/24, 1 successors, FD is 23394560

via 172.16.1.6 (23394560/2 816 00), Serial0.1 P 172.16.1.0/24, 1 successors, FD is 23368960

via Connected, Serial0.1 P 172.16.2.0/24, 1 successors, FD is 281600 via Connected, Ethernet1

R1# show ip eigrp topology 2001 172.16.5.0 255.255.255.0

IP-EIGRP topology entry for 172.16.5.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 23394560 Routing Descriptor Blocks:

172.16.1.5 (Serial0.1), from 172.16.1.5, Send flag is 0x0

Composite metric is (23394560/281600), Route is Internal Vector metric:

Minimum bandwidth is 112 Kbit

Total delay is 21000 microseconds

Reliability is 254/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

The fields to note in this output are as follows:

■ P - Passive, no EIGRP computation is being performed. This is the ideal state.

■ A - Active, EIGRP computations are "actively" being performed for this destination. Routes constantly appearing in an active state, indicates a neighbor or query problem. Both are symptoms of the SIA problem.

■ U - Update, an update packet was sent to this destination.

■ Q - Query, a query packet was sent to this destination.

■ R - Reply, a reply packet was sent to this destination.

■ Route information - IP address of the route or network, its subnet mask, and the successor, or next hop to that network, or the feasible successor.

■ FD - Feasible distance to the destination network.

■ Send Flag - The type of packets that need to be sent for the entry are indicated by the send flag.

0x0 - If there are packets tha need to be sent in relation to this entry, this indicates the type of packet.

0x3 - The router has received a query for this network and needs to send a unicast reply. route is active and a multicast query should be sent. route has changed and a multicast update should be sent.

Continue reading here: Enhanced Interior Gateway Routing Protocol Eigrp Summary

Was this article helpful?

Sours: https://www.ccexpert.us/ccie-2/verifying-eigrp-operation.html
EIGRP Key Chain \u0026 Debug

EIGRP (just like OSPF or BGP) establishes a neighbor adjacency before it exchanges any routing information. If your neighbor adjacency is up and running, this post is for you. If it’s not working, check out my troubleshooting EIGRP neighbor adjacency lesson first.

Having said that, let’s fix some missing route advertisements!

Most of the time you are expecting to see a certain network in the routing table but it’s not there. I’ll show you a number of things that could go wrong with EIGRP and how to fix them, here are the most common errors:

  • Someone configured a distribute-list so routing information is being filtered.
  • Auto-summarization has been configured or someone created a manual summary.
  • Split-horizon is preventing the advertisement of routing information.
  • Redistribution has been configured but information from EIGRP is not being used.
  • Redistribution has been configured but no EIGRP external routes are showing up.

Let’s look at these issues.

EIGRP Distribute-List

R1 R2 two loopbacks

Let’s start with a simple topology. R1 and R2 are running EIGRP and each router has a loopback interface. Here’s the configuration of both routers:

Everything is working fine until a couple of weeks later one of the users is complaining that they are unable to reach the 2.2.2.0 /24 network from behind R1. You take a look at the routing table on R1 and this is what you see:

For some reason you don’t see network 2.2.2.0 /24 in the routing table. Let’s check if R1 is using a filter:

I can see no distribute lists have been configured on R1. What about R2? Let’s check its routing table:

R2 does have network 1.1.1.0 /24 in its routing table and 2.2.2.0 /24 is showing up as directly connected. Let’s do a quick debug to see what is going on.

A debug quickly shows us what is going on. It make tight a while before you see this message or you can reset the EIGRP neighbor adjacency to speed things up. As you can see network 2.2.2.0 /24 is being denied because of a distribute list. You can see it here:

R2 has an outbound distribute-list that refers to access-list 1. You can also see this in the configuration:

Let’s take a closer look at the access-list:

It’s denying 2.2.2.0 /24. Let’s get rid of this distribute-list:

And now we take a look at R1 again:

There it is, problem solved!

Lesson learned: If the network commands are correct, check if you have a distribute-list that is preventing prefixes from being advertised or installed in the routing table.

Keep in mind that distribute-lists can be applied in- or outbound.

EIGRP Discontiguous Network

Onto the next scenario, same two routers but different networks on the loopbacks:

R1 R2 discontigious network

Below you will find the network commands on R1 and R2:

It’s a pretty basic configuration as you can see. Let’s check the routing tables:

Looking at the routing tables, I don’t see network 10.1.1.0 /24 or 10.2.2.0 /24. I do see an entry for the 10.0.0.0/8 network pointing to the null0 interface on both routers. This entry only shows up when summarization is configured and it’s used to prevent routing loops. Let’s enable a debug:

Now I’ll reset the neighbor adjacency so that the routers exchange routes again:

Here’s what you will see on R2:

Here’s our answer. The debug tells us that 10.2.2.0 /24 should not be advertised but 10.0.0.0 /8 has to be advertised (a summary). This can happen because of 2 reasons:

  • Summarization was configured by someone.
  • Auto-summary is enabled for EIGRP.

Let’s see take a closer look at the configuration:

As you can see auto-summary is enabled for EIGRP. Depending on the IOS version this is enabled or disabled by default. Let’s disable it:

Now take a look at the routing tables:

Now we see both networks appearing in the routing table.

Lesson learned: If EIGRP auto-summary is enabled you might end up with discontiguous networks.

EIGRP Summarization

Let me show you another issue that can arise with summarization. In the example above we have 2 routers but different networks:

R1 R2 172.16 networks

R1 has network 172.16.1.0 /24 on a loopback interface and R2 has network 172.16.2.0 /24 and 172.16.22.0 /24 on its loopback interfaces. Let me show you the EIGRP configuration of both routers:

You can see that all networks are advertised. Note that R1 has auto-summary enabled and R2 has auto-summary disabled. R2 has a summary configured:

Someone configured a summary on R2 and is sending it towards R1. The summary that was created is 172.16.0.0 /16. Let’s take a look at the routing table of R1:

However if I look at the routing table of R1 it doesn’t show up. We do see an entry for the 172.16.0.0 /16 network but it’s pointing to the null0 interface…not towards R2. What is going on here? A debug gives us the answer:

I’ll do a clear ip eigrp neighbors too just to speed things up. Here’s what we see:

Looking at the debug we can see that R2 is working properly. It’s advertising the 172.16.0.0 /16 summary route as it should. This means the problem has to be at R1.

Let’s debug R1:

Here’s what we see:

We can see that R1 receives the summary route from R2 but decides not to use it. Why? We can find the answer in the topology table:

Above you can see that it does have the 172.16.0.0 /16 summary from R2 in its EIGRP topology table but R1 decides not to use it because the entry to the null0 interface is a better path. To fix this issue, we should get rid of the null0 route. Disabling auto-summary will do the job:

Now take a look again at the routing table of R1:

There we go. Disabling auto summarization removes the null0 entry and now the summary of R2 can be installed…problem solved!

Lesson learned: EIGRP auto-summary creates an entry to the null0 interface which might prevent the installation of summaries you receive from neighbor routers.

EIGRP Summary not advertised

There is one more summarization issue I want to show you, here’s the topology:

R1 R2 loopback summarization issue

Here’s the configuration:

All networks are advertised and auto summarization is disabled on both routers. R2 has a summary:

This summary will be advertised to R1. However, R1 doesn’t have it:

Unfortunately I’m not seeing anything on R1. Let’s check R2 to see what is wrong:

When it comes to troubleshooting networking not Google but debug and show commands are your friends. Here’s what we see:

Hmm this is the only network that R2 is advertising. Let’s check the routing table of R2:

One of the golden rules of routing: You can’t advertise what you don’t have. Apparently R2 only knows about network 192.168.12.0 /24. Let’s check the interface:

Uhoh…this looks like a Friday afternoon error! Someone left a shutdown command on the loopback interfaces. Let’s enable them:

If you left the debug enabled then you’ll see the route advertisement:

Now we see that the summary is being advertised. Here’s the routing table of R1:

Now we see the summary in the routing table of R1, problem solved!

Lesson learned: You can’t advertise wat you don’t have in your routing table.

The last problem might be simple but there’s an important lesson you should not forget: In order for a summary route to be advertised at least one prefix that falls within the summary range has to be in the routing table of the advertising router!

EIGRP Split Horizon

Here’s something new for you, a different topology:

EIGRP Hub Spoke Split Horizon

In the picture above we have a frame-relay hub and spoke topology. Spoke1 and Spoke2 each have a loopback interface which we will advertise in EIGRP. Here’s the relevant configuration of all routers:

As you can see all networks are advertised. Let’s check the routing tables…we’ll start with the hub router:

Our hub router sees the networks of the 2 spoke routers. What about the spokes?

Unfortunately our spoke routers don’t see anything…what’s going on here? Let’s enable a debug:

We’ll reset the neighbor adjacencies to force the routers to send the route advertisements again:

Here’s what you will see:

In the debug we can see that our Hub router learns about network 2.2.2.0 /24 and 3.3.3.0 /24 but only advertises network 192.168.123.0 /24 to the spoke routers. Split horizon is preventing the advertisements from one spoke router to another. (If you learn something on an interface…don’t advertise it out of the same interface again). Let’s disable split horizon:

Let’s disable split horizon on the serial interface of the Hub router. Take a look at the debug of the hub router now:

Now we can see that the Hub router does advertise all networks. Let’s see if the spoke routers installed the routes:

The spoke routers can now learn about each other’s networks since split horizon has been disabled. This is looking good but we are not done yet. Lesson learned: RIP and EIGRP are distance vector routing protocols and use split horizon. Split horizon prevents the advertisement of a prefix out of the interface where we learned it on.

Even though we solved this problem, there is still another issue we have to deal with. Take a look at these pings:

Sours: https://networklessons.com/eigrp/troubleshooting-eigrp-route-advertisement

Now discussing:

Debug EIGRP

Here are some notes to remember and commands for debugging EIGRP:

Neighbor Requirements

  • same subnet
  • same K values
  • same AS
  • authentication

EIGRP and Frame - Split horizon is ON BY DEFAULT on frame links.

show ip eigrp neighbor
- shows neighbor status. Look for 0 under Q count in good relationship.

debug eigrp packet hello
- sending hellos?

debug ip eigrp
- shows routes blocked by distribute lists

debug ip routing or debug ip routing 1 (for just the target route)
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 deny any
- shows route being constantly added

show ip eigrp interface
- shows peers, round trip time, pending routes

show interface s0/0/0
- shows the delay and bandwidth set on the interface. Remember to add them for a cumulative route value.

show ip protocol
- will show the K values for EIGRP

ping 224.0.0.10
- check eigrp listeners

clear ip eigrp neighbors
- Will reset neighbor relationships and kick off DUAL

show ip route x.x.x.x
- Shows the routing table with details on x.x.x.x

show ip route eigrp

- Shows the EIGRP routes in the routing table

show ip eigrp topology x.x.x.x
- Shows the eigrp database

show ip eigrp event
- troubleshooting flopping route. Look for timer update 0:00:00, find neighbor doing update.

show ip eigrp topology active
- hunt stuck in active on each neighbor

debug eigrp packet
- will show authentication failures

Additional Reading:
Troubleshooting EIGRP
EIGRP Commands
EIGRP
Troubleshooting IP Routing Protocols
Also check out general debugging under Debug RIP.

Sours: https://routeswitchlabtips.com/routing/debug-eigrp/


587 588 589 590 591