Two Tips, One Trick: Follow the Path

For some admins, their primary tools for troubleshooting are ping and traceroute. In later posts, we can help to expand that toolset. For now, we'll just focus on those traceroutes you're already using.

On a Cisco router (in this example, R1), I enter the command traceroute 50.1.1.14 to see the path a packet takes from my router to the destination, 50.1.1.14. If this times out trying to get to the destination, traceroute will show up to 30 rows of asterisks.

TIP:

To break out, hold down the keys Ctrl and Shift and tap 6. Let go of the keys and do it a second time. Now, you're free. If you have been held hostage in the past waiting to get to the thirtieth line, this will make traceroutes much less aggravating.

There are a couple of reasons why you may have to enter that key sequence twice. One is if you are initially consoling into a central device. From there, it is configured to do reverse Telnet to the console port of your intended device. Another occurs when you are Telnet hopping. You Telnet into R2 and from there Telnet into R3. Because you are two devices deep, entering the traceroute command from R3 will require you to issue the key sequence twice to break out.

Those key sequences, Ctrl+Shift+6, sometimes cause frustration. Usually the issue is that you're pressing all three keys at exactly the same time instead of in sequence. However, if breaking out of a traceroute continues to be a hit-or-miss annoyance for you, a simpler alternative can be configured.

TRICK:

If you are on a Cisco router or switch, you can reprogram the key sequence.
line vty 0 15
escape-character 3

Now instead of having to press Ctrl+Shift+6 twice, just press Ctrl+C twice. By the way, the same escape-character 3 command can also be entered under your console line.

When you issue a traceroute, each router you pass through returns a message containing its IP address to the source. The source is always the outgoing (egress) interface of the router. In this example, if I were to trace from R1 to R4, the source address would be 30.1.1.5. But what if I have a public server attached to that router and I want to check to see if the routers along the path have connectivity all the way back to my server's subnet, 20.1.1.0, not just my router's egress interface on subnet 30.1.1.0?

TIP:

I can do this from R1 using an extended traceroute. This allows me to change the source from the router's egress interface to the IP address found on the same subnet as the server, 20.1.1.2.

traceroute 50.1.1.14 source g0/0