From Command Line:
traceroute -m 30 -q 3 134.79.196.165 140 took 135 secs. (Stop at 11th hop)
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 110 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 15 secs.
traceroute -m 30 -q 3 -n -f6 134.79.196.165 140 took 20 secs.
sudo traceroute -I www6.slac.stanford.edu (reached at its destination)
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
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.
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.