When you work with a remote rack by using an access-server (e.g. 25xx) with the async lines connected to the console ports of the pod’s routers, you effectively have only one terminal window opened. Using ctrl-Shift-6-x you can quickly switch between terminal lines; however, if you need to monitor “debug” command output on one terminal line, while performing some activity on the other you may face some difficulties.

For example, when you enable debug crypto isakmp on one router, and then switch to the other router, to generate packets with ping command, you may lose some of the debugging output, while switching back to the original router. Two obvious ways to resolve this issue exist: first one – open multiple terminal windows; next one – use logging buffered command to collect the debug logs into logging buffer. The third, not so well-known way to cope with the issue, is to use service telnet-zeroidle command on the access server.

What this command does, is announces TCP receive window with the value of zero for “idle” (currently non-active) connections. How does this work? When a TCP “server” is told that the other side’s TCP receive window is zero, the server starts buffering data to be send, until the other side “un-shrinks” the window again. Now, since all sessions from an access-server are effectively reverse-telnet connections to the access-server itself, by advertising TCP window value of zero, we make access-server buffer router’s console output (e.g. from debug commands), until the respective session becomes active again. In effect, with service telnet-zeroidle enabled, you may start, say, debug crypto isakmp on one router, switch to other, type ping x.x.x.x, then get back to the original router just to grab all the debug output at once – without any loss! Just make sure, your large debugging output runs fit into TCP xmit buffer, and don’t be scared by flood of output when you get back to an idle connection!

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

4 Responses to “Debug output collection”

  1. dknov says:


    Why you need a third option if console output is logged to internal buffer (logging buffer and logging console configured) even if you had switched to another session?


  2. to: dknov

    Just for some added (maybe ;) convenience. It’s not always comfortable to navigate through the logging buffer output, many people prefer to see “live” debugging stream on their screen.

  3. Daniel Ma says:

    I am going to take the LAB in RTP. I heard that they use SecureCRT, not just HyperTerminal. Is it true?

  4. wael says:

    nice router trick; any other practical usage of this command?


Leave a Reply


CCIE Bloggers