How to troubleshoot EIGRP issue?

Unanswered Question
Jan 5th, 2009

We have user report one-way audio issue. Trace the destination address from the source switch a couple of times. We recieved total different result. Please see the below:


1 0 msec 4 msec 0 msec

2 0 msec 4 msec !A


1 0 msec 0 msec 0 msec

2 !A * !A

IDFA# trace

1 0 msec 0 msec 4 msec

2 4 msec 0 msec 0 msec

3 8 msec 16 msec !A

We are using EIGRP routing protocol and it seems that is show stopper, right?

Can anyone tell me what we can tell from the result? how to troubleshoot it?

Thanks a lot,


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (4 ratings)
Richard Burts Mon, 01/05/2009 - 10:43


The main thing that you can tell from the result is that is configured with an access list which is denying your traceroute. The response of !A is an indication of "administratively prohibited" which is generated when an access list denies the packet.

The other thing that you can tell is that the next hop device (router) with address has multiple paths toward that destination address.

It is not clear whether either of these things has any bearing on your original problem of one way audio.

[edit] since all of the addresses shown are within the same major network of then I do not see where auto-summary or no auto-summary makes any difference.



burleyman Mon, 01/05/2009 - 10:52


I am still learning EIGRP and did not realize the !A was due to an access list....thanks for the info.


learner2008 Mon, 01/05/2009 - 11:03

Rick -

Thanks so much for the information. I didn't know what !A means either. is one of our Core layer-3 switch. What I should do to start troubleshooting this issue? Or which commands are useful for tracing down the issue?

Thanks a lot.

Richard Burts Mon, 01/05/2009 - 11:41


With the limited information we have it is a bit difficult to know what would be the best troubleshooting. If we knew more about what is the application and what is the topology of the network we could probably give better advice.

But based on what we know so far, here is what I would suggest:

- since each of the traceroutes stop at would we be correct in assuming that this might be one hop before the destination address?

- go hop by hop through the network, looking at each of the devices through which the traffic might pass. Check to see if there might be an access list which might be denying the audio one way. Check to see if the device has a valid route to the source and to the destination (and does that route make sense based on what you know of the network topology). Check to see if there might be any RPF check configured which might be denying the audio in one direction.




This Discussion