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/