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 '13 at 9:01
  • Ctrl-Shift-6 is the break sequence in IOS. May 27 '13 at 15:27
  • 1
    Please elaborate on how long "show adj" takes
    – This
    May 27 '13 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 '13 at 1:43
  • 1
    @rnxrx, I expected at least one comment on that code version's age. Upvote for you. May 28 '13 at 5:08

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 '13 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 '13 at 5:18
  • That's super awesome! Love learning new things. May 28 '13 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 '13 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 '13 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?
    – This
    May 27 '13 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 '13 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.
    – This
    May 27 '13 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 '13 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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