Since I have been dealing with traceroute for the last couple days,
I thought it would be worth providing an update to this group.
If you do a traceroute from an off-campus source to an on-campus server
or other computer system with a static IP address, you may see several
lines of asterisks before the traceroute completes. Also, the
traceroute may never complete if the target system is firewalled
(see note #2 below).
Here is an example, targeting one of the campus name servers from
off campus:
traceroute to serv3.acns.msu.edu (35.8.98.43), 64 hops max, 72 byte packets
1 robert-vlan503.aset.psu.edu (128.118.1.177) 0.589 ms 0.240 ms 0.210 ms
2 192.168.1.149 (192.168.1.149) 0.521 ms 0.383 ms 0.364 ms
3 172.30.255.62 (172.30.255.62) 0.524 ms 0.383 ms 0.365 ms
4 147.73.1.32 (147.73.1.32) 4.733 ms 4.282 ms 4.211 ms
5 wash-psc10G.layer3.nlr.net (192.88.115.165) 9.727 ms 9.592 ms 9.569 ms
6 chic-wash-59.layer3.nlr.net (216.24.186.18) 27.512 ms 26.340 ms 26.217 ms
7 ge-0-2-0x2087.aa1.mich.net (192.122.183.181) 28.136 ms 101.786 ms 28.541 ms
8 tenge0-0-0-0x9.aa2.mich.net (198.108.22.185) 28.136 ms 28.082 ms
tenge0-0-0-0x25.aa2.mich.net (198.108.22.148) 28.291 ms
9 198.108.23.54 (198.108.23.54) 29.556 ms 30.067 ms 29.703 ms
10 192.122.183.227 (192.122.183.227) 34.686 ms 39.852 ms 39.834 ms
11 cc-t1-ge1-23.net.msu.edu (35.9.101.209) 40.147 ms 39.075 ms 39.991 ms
12 * * *
13 * * *
14 serv3.cl.msu.edu (35.8.98.43) 30.374 ms 30.341 ms 30.323 ms
This will happen if the target system has a 35.8.x.x IP address. At this
time, this behavior is NOT present if the target system has a 35.9.x.x IP
address.
This is an expected behavior, given our current implementation of campus
border routing and its integration with the border IPS systems. We have
not identified any reasonable way of improving this situation at the
present time, so this should be considered the expected response for a
traceroute.
Note that the IP ranges which show this behavior may change, if we
need to rebalance the Internet traffic load across our IPS systems.
Other notes:
1. Ping and traceroute from off-campus to DHCP (wired or wireless)
addresses will always fail beyond the campus border. This includes
IPs in the 35.10.x.x, 35.11.x.x, 35.13.x.x, and 35.14.x.x ranges.
This is because the border firewall systems enforce the policy
disallowing any inbound connections to DHCP wired or wireless systems.
2. If the target system is firewalled, either via a physical firewall
or a software firewall, traceroute may never complete (lines of
asterisks forever). If you want to allow traceroute to complete
successfully, you should modify your firewalls to do one or both of
the following:
a. For "ping" and ICMP-based traceroute (e.g. Windows "tracert"),
permit incoming ICMP Echo Request packets, and outgoing ICMP Echo
Reply packets.
b. For UDP-based traceroute (UNIX default), permit incoming UDP
packets with destination ports 33434 to 33534, and permit outgoing
ICMP port unreachable packets (ICMP type 3).
Doug
On Wed, Jan 21, 2009 at 04:43:09PM -0500, Kramer, Jack wrote:
> Bingo - we had this problem with some emails a while ago and if you ran a traceroute from the originating mail server to our mailservers, it turned out that they were never making it past the IPS on the campus border.
>
> In fact, I have an open helpdesk ticket now regarding that, though no one seems to be working on it...
> ----
> Jack Kramer
> Computer Systems Specialist
> University Relations, Michigan State University
> 517-884-1231
--
Doug Nelson, Network Manager | [log in to unmask]
Academic Technology Services | Ph: (517) 353-2980
Michigan State University | http://www.msu.edu/~nelson/
|
