Table of Contents


Summary:

Traceroute from UTM to SLAC
  • traceroute -m 30 -q 3                  134.79.196.165 140 took 135 secs. (Stop at 11th hop)
  • traceroute -m 30 -q 3 -f6            134.79.196.165 140 took 110 secs. (reached at its destination)
  • traceroute -m 30 -q 3 -n -f6        134.79.196.165 140 took 15 secs.  (reached at its destination) 

From Command Line:

  • traceroute from UTM Pinger command line to SLAC (Stop at 11th hop)
  • traceroute from UTM Pinger command line to SLAC Option -f6 (reached at its destination)
  • traceroute from UTM Pinger command line to SLAC Option -f6 -n (reached at its destination)
  • sudo traceroute -I  www6.slac.stanford.edu (reached at its destination successfully without using -f6) 
Traceroute from UM to SLAC
  • traceroute -m 30 -q 3                      134.79.196.165 140 took 19 secs.
  • traceroute -m 30 -q 3 -f6                134.79.196.165 140 took 21 secs.
  • traceroute -m 30 -q 3 -n -f6           134.79.196.165 140 took 20 secs. 

Details with screenshots:

Traceroute from UTM to SLAC

traceroute -m 30 -q 3        134.79.196.165 140 took 135 secs. (Stop at 11th hop)

  

Traceroute from UM to SLAC

traceroute -m 30 -q 3         134.79.196.165 140 took 19 secs.

 

Traceroute from UTM Pinger command line to SLAC (Stop at 11th hop)

Traceroute from UTM to SLAC Option -f6 (reached at its destination)

traceroute -m 30 -q 3 -f6 134.79.196.165 140 took 110 secs.

Traceroute from UM to SLAC Option -f6

traceroute -m 30 -q 3 -f6 134.79.196.165 140 took 21 secs.

Traceroute from UTM Pinger command line to SLAC Option -f6 (reached at its destination)

Traceroute from UTM to SLAC Option -f6 -n  (reached at its destination)

traceroute -m 30 -q 3 -n -f6 134.79.196.165 140 took 15 secs.

 

Traceroute from UM to SLAC Option -f6 -n  (reached at its destination)

traceroute -m 30 -q 3 -n -f6 134.79.196.165 140 took 20 secs.

Traceroute from UTM Pinger command line to SLAC Option -f6 -n (reached at its destination)

 

sudo traceroute -I  www6.slac.stanford.edu (reached at its destination)

Traceroute from UTM Cisco border router to CERN

Since this router can see cern in 10 hops there are no blocks for the first 10 UDP ports starting at 33434.  There may be blocks in higher number UDP ports that is unknown from this result.

Typically when one blocks a set of ports in an ACL one blocks them both for TCP and UDP.  If this is the case you may be able to use the telnet <cern-host> <tcp port command and see if you get a response as you increase the <tcp-port> starting at 33433  where <cern-host> = e513-e-rbx1-2-te20.cern.ch

You might also play around with the -p option in the traceroute command

Traceroute from UTM to CERN on a Mac

This gives the same result as on Linux. This is not unexpected since the Mac OS is Unix based and so uses UDP probes unlike Windows that uses ICMP probes and hence does not see the effect.

Possible Explanation

Traceroute uses UDP to send the requests (see http://en.wikipedia.org/wiki/Traceroute). The first request is sent to a particular port (33434), with a ttl  to tell it how many hops to go to.  The ttl starts at 1 is incremented as it tries the next hop, also the port is incremented (up to 33465).  It looks like the first few UDP ports are enabled and then they are blocked.  The blocking could be at the border or in the ISP.  Can you try a traceroute from just outside the border (e.g. in the border router itself), or if you can get access to the routers try traceroute from them to the destination. Note Windows tracert uses ICMP and not UDP to send the probes and so should not suffer this problem.

 

  • No labels