North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Exodus / Clue problems
At 05:18 PM 11/16/98 -0500, Daniel Senie wrote: >Actually, the blocks are mine, not theirs. If you use a traceroute on a >system which uses ICMP ECHO packets to do the trace, instead of the >older Unix implementations which use random UDP ports, your traceroute >will get to my site without trouble. The traceroute I am running is current as it gets, for the unix world that is. I have found that most sites won't block UDP near as often as they block ICMP and this, I have much more success with this traceroute than say, the tracert program on winblows boxes. > >I hadn't thought about the PMTU failure this causes. Not nice at all. Most people don't think about it. It can cause you problems though. Especially when in most cases, when PMTU can't be determined, it is defaulted to 1500. >The problem with this is I can't do traceroutes out, then, because all >the responses from the 10.x.x.x/8 and 172.16.0.0/16 machines get caught >in the filters. Sure you can. Any decent NAT or MASQ system will take care of that for you. Case in point: root> ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:C9:06:7C:82 inet addr:192.168.101.250 Bcast:192.168.101.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5427402 errors:0 dropped:0 overruns:0 TX packets:4912650 errors:0 dropped:0 overruns:0 Interrupt:9 Base address:0xff40 root> route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 62 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 19 lo 0.0.0.0 192.168.101.48 0.0.0.0 UG 0 0 412 eth0 root> traceroute mae-east.psi.net traceroute to mae-east.psi.net (126.96.36.199), 30 hops max, 40 byte packets 1 barrister (192.168.101.48) 0.467 ms 0.363 ms 0.346 ms 2 188.8.131.52 (184.108.40.206) 154.795 ms 139.175 ms 139.722 ms 3 220.127.116.11 (18.104.22.168) 139.654 ms 139.077 ms 139.712 ms 4 leaf2.nc.us.psi.net (22.214.171.124) 179.613 ms 179.044 ms 159.642 ms 5 rc1.nc.us.psi.net (126.96.36.199) 299.494 ms 188.930 ms 169.680 ms 6 core.net223.psi.net (188.8.131.52) 209.555 ms 178.857 ms * Note: I am quite amazed to only see ONE "*" in that trace considering the network that box is attached to. >> than your own. I Hope nothing happens that would require your PERSONAL >> attention while you're at some convention, on vacation, etc. > >Fortunately I have enough of an operation to have a direct dial-in to my >network so that I can get in even if the ISP link is down, but I agree >with your assessment. I think most of us can do that. The difference is that I use the dialin for security to get devices that I can NOT install SSH on. For everything else, it is a backup link. It would be quite costly for me to dial into the box from the Philippines while I'm over there, even if I could find a decent phone line to do so. The satellite link while slower than I would like, works quite well though. I suppose that you could also telnet/ssh to a "real" IP address behind your router and then telnet to the router though. >> ...and one last point... >> >> - Have someone loan them a clue about why they should NOT use RFC1918 space >> in the way your isp is doing so. > >Agree. Unfortunately, when selecting ISPs, this was not an aspect I >expected I'd have to worry about, and so I didn't ask. It certainly goes >on my list for the next negotiation, though. I never asked FNSI either. I guess that considering how many providers actually do this, I was lucky to find one that actually knows better. ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...