tcl and traceroute

[clausonna]

Hi folks.

A few days ago I had an issue at a remote location where packet loss was observed between the ISP's 2nd and 3rd hop routers.  Pings were fine up to our gateway.  I thought this would make for an interesting TCL script:  specify a particular address, do a traceroute to it, and then individually ping each hop along the way to see where the packet loss was occurring.  I should note that we saw loss when pinging a destination IP that took one path across the ISP, but no loss to a different destination IP that took a different path.

However, it seems that traceroute operates differently under TCL than it does normally from the IOS CLI.

Here's the simple version of the script:

set IP "8.8.8.8"

set TRTEST [exec "traceroute ip $IP numeric"]

puts $TRTEST

I added the 'numeric' option because that seems to speed things up and also prevents some odd responses.  I've also messed around with specifying the source interface (something I don't need to do in normal mode.) which seems to help on my MPLS WAN but not over the Internet.  My focus for now is on my Internet-facing sites.

I've tested this on 1800's, 891's, and a 2800, running various flavors of 12.4T and 15M.  They all seem to work normally.

Would someone be so kind as to try this out on their side and see what I'm missing?  I promise to upload the completed script once I work the bugs out.  Also - sanity check - is this even a good idea in the first place? 

Results:

RTR#tclsh

RTR(tcl)#set IP "8.8.8.8"

8.8.8.8

RTR(tcl)#set TRTEST [exec "traceroute ip $IP numeric"]

Type escape sequence to abort.

Tracing the route to 8.8.8.8

  1  ?  ?  ?

  2  ?  ?  ?

  3  ?  ?  ?

  4  ?  ?  ?

  5  ?  ?  ?

  6  ?  ?  ?

<snip>

RTR#traceroute ip 8.8.8.8 numeric   ! IP addreses are -completely- obsfucated

Type escape sequence to abort.

Tracing the route to 8.8.8.8

  1 9.1.2.3 4 msec 4 msec 0 msec

  2 99.88.77.66 4 msec 4 msec 4 msec

  3 3.1.4.5 4 msec 0 msec 0 msec

  4 6.7.8.9 12 msec 12 msec

    6.7.8.13 8 msec

  5 1.3.5.7 12 msec 12 msec 12 msec

[Joe Clarke]

I tested on a 3560 running 15.0(1)S, but that does not support the numeric option.  It exhibits the same problem.  There have been some bugs with various vty interactions and tclsh.  Might I suggest using EEM Tcl for this instead?  You have a much tighter control over the CLI session.

::cisco::eem::event_register_none maxrun 90
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
if { [catch {cli_open} result] } {
    error $result $errorInfo
}
array set cli $result
if { [catch {cli_exec $cli(fd) "traceroute ip $traceroute_ip numeric"} result] } {
    error $result $errorInfo
}
puts $result
catch {cli_close $cli(fd) $cli(tty_id)}

Call this script no_traceroute.tcl and copy it to flash:/policies (create the directory first).  Then register it with the following commands:

event manager directory user policy flash:/policies
event manager policy no_traceroute.tcl

Finally, set your traceroute_ip environment variable and go:

event manager environment traceroute_ip 8.8.8.8

Run the policy from EXEC mode:

event manager run no_traceroute.tcl

With EEM, you can then automate this as well.  You could change the none event detector at the top to a timer event detector and run the policy periodically:

::cisco::eem::event_register_timer watchdog time 3600 maxrun 90

[jerold_swan]

Joe, I found this post while searching the forums and had some questions:

1) When running this on 12.4(22)T5, I always get numeric output regardless of whether the "numeric" keyword is included (the router is set to do name lookup). Arguments past the IP address seem to be ignored: if I run:

traceroute ip $traceroute_ip probe 1

I still get three probes. Same with the TTL and timeout keywords. I assume this is a bug? Any idea where it's fixed?

2) What I really want to do is fire off two traceroutes every time I lose an EIGRP neighbor, and save the results in a way that I can view later, even if the router's uplink to the rest of the world is down. I'm trying to troubleshoot a situation where a router frequently loses the path to both its DMVPN headends, and I want to figure out where on the path to the headends the problem is happening. Is there a way to do this? From a brief skim of the documentation, it doesn't look like I can write the result to flash?

[Joe Clarke]

I didn't find any existing bugs on this, but I will reiterate that EEM is likely a better candidate for this kind of automation.  The traceroute command is kind of tricky since it's a hybrid interactive/non-interactive command.  You should be able to support all of the traceroute options using EEM.

For your other question, please start a new thread for this.

[jerold_swan]

Sorry for not being clear: I am running it using EEM--I followed your instructions in the post above exactly (embedding the command into the EEM TCL script and running from EXEC with "event manager run"). I will start another thread for the other question.

[Joe Clarke]

I tested on 15.2(2)T and I am not seeing this problem with EEM.  I get the traceroute command to show the desired output with arguments:

numeric probe 1 ttl 0 4

One thing I did notice in my sample above is that I'm missing the "enable" command.  Make sure you add the "enable" command before running the traceroute.

[jerold_swan]

Adding the "enable" command solves the problem.