Why does the "show adjacency" command take so long to run (in the order of minutes) on Cisco IOS Software, 7200 Software (C7200P-SPSERVICESK9-M), Version 12.4(4)XD5, RELEASE SOFTWARE (fc1)? The router is an Internet edge router running BGP? What do the "(5)", "(10003)", or "(75845)" mean after the addresses? It seems to enumerating mostly addresses on a directly connected /23 network. CPU is < 2% and memory don't seem to be cause for this.

r-x-y-edge1#sh adjacency
Protocol Interface                 Address
IP       GigabitEthernet0/2        x.67.155.9(5)
IP       GigabitEthernet0/2        x.67.155.8(5)
IP       GigabitEthernet0/2        x.67.155.11(5)
IP       GigabitEthernet0/2        x.67.155.10(5)
IP       GigabitEthernet0/2        x.67.155.13(5)
IP       GigabitEthernet0/2        x.67.155.12(5)
IP       GigabitEthernet0/2        x.67.155.15(5)
IP       GigabitEthernet0/3
IP       Serial1/0                 point2point(75845)

CPU utilization for five seconds: 2%/1%; one minute: 3%; five minutes: 3%

Processor Pool Total:  864815572 Used:  547631528 Free:  317184044
      I/O Pool Total:   67108864 Used:    4520592 Free:   62588272

Is there a way to interrupt the execution of this command short of closing the session as Ctrl-^x doesn't have any effect?

  • Have you tried different versions of IOS? Has it always taken a long time to display results or has it just started happening? May 27, 2013 at 9:01
  • Ctrl-Shift-6 is the break sequence in IOS. May 27, 2013 at 15:27
  • 1
    Please elaborate on how long "show adj" takes May 27, 2013 at 17:12
  • 1
    That code version is not only old (4+ years) but even within that train is superseded many times over. There have definitely been fixes and changes to CEF handling and would tend to suggest that you'd be better off troubleshooting on a more recent (or final within train) code rev.
    – rnxrx
    May 28, 2013 at 1:43
  • 1
    @rnxrx, I expected at least one comment on that code version's age. Upvote for you. May 28, 2013 at 5:08

3 Answers 3


Have you checked to see if you have domain lookup disabled? (no ip domain lookup)

It could be that your command is taking so long to come back as it is trying to resolve all of the IP's to hostnames.

  • This is an interesting suggestion - I wouldn't think that IOS would attempt to do name resolution for CEF adjacency entries since the majority of them will represent prefixes with a length < 32. May 27, 2013 at 12:06
  • I had "ip domain name" and "ip domain list" configured, but no "ip name-server". Setting a couple of name-servers made the output display almost instantly. May 28, 2013 at 5:18
  • That's super awesome! Love learning new things. May 28, 2013 at 5:43
  • Great catch @David, didn't occur to me either. Not as well-known DNS woe as lack of 'transport preferred none' under line VTY :)
    – ytti
    May 28, 2013 at 7:29
  • Thanks for the comments from the more experienced network engineers in the group; I don't feel as bad that it was a reverse lookup that stumped me. May 28, 2013 at 21:18

What do the "(5)", "(10003)", or "(75845)" mean after the addresses?

The value in parentheses refers to the number of times a FIB entry points to an adjacency entry. Mentioned here.


Is the router taking full tables? If it is, I guess I wouldn't be surprised that it's taking a long time, seeing as how it has to resolve however many networks that represents a full table to an exit interface (RIB->FIB). Also remember that the 7200 is still a software based forwarding platform. You still have 3 more layers of CEF above you in terms of which ones are faster.

If a large number of those adjacencies are punt adjacencies (an entry that would have to be punted to the next-level switching method) or glean adjacencies, this may also explain why it's taking a long time - and I'd imagine that a large number of them would be - again, still assuming it's a full table here.

The number in parentheses is called the refcount, and represents the number of times that adjacency is pointed to by FIB entries.

Edit: regarding canceling the command, try Ctrl+C (repeatedly) - sometimes this works for me for killing long-running commands. OTOH if I know the command will produce a lot of output, I'll set "terminal length" to something like "50", that way I have the option of killing the command by way of output pagination.

  • Hi John, I'm not sure I follow the comment about 3 more layers of CEF... can you elaborate? May 27, 2013 at 17:14
  • Sure - in general I was talking about the "best" (according to Cisco) switching methods, in order: hardware dCEF -> hardware CEF -> PXF switching -> software-based CEF -> fast switching -> process switching May 27, 2013 at 18:06
  • But I am not seeing why it's relevant to mention other switching paths... AFAIK, other switching paths being more efficient at moving packets has nothing to do with the time it takes to dump the adjacency table on a 7200 router. May 27, 2013 at 18:13
  • It was relevant to my point that a 7200 is a software based platform rather than something like a cat65k or a 7600 which does CEF in hardware; it would seem like it would be a safe assumption that a platform that does CEF in hardware would perform a little snappier at dumping adjacencies, would it not? Being totally honest though my experience with 7200's in production is limited - I've always been "lucky" enough to work with the bigger ASIC- based multi-stage boxes. May 27, 2013 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.