North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Exodus / Clue problems
John Fraizer wrote: > > >Define "network border." I used to block all traffic from or to RFC1918 > > [[email protected] /]# traceroute mae-east.fnsi.net > traceroute to mae-east.fnsi.net (192.41.177.11), 30 hops max, 40 byte packets > -----> 1 border-core0-eth1.Columbus.EnterZone.Net (209.41.244.1) 0.538 > ms 0.444 ms 0.411 ms > | 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 0.916 ms > 0.783 ms 0.774 ms > | ---> 3 border1-atm6.Vienna.fnsi.net (206.183.239.90) 23.132 ms 23.797 > ms 23.829 ms > | | > | |-- That is the network border of my provider at mae-east. > | > |---- That is the network border for MY network. The DEMARC where my > network ends and my providers begins. > > I can't tell you precisely where yours is since @home has decided to block > the traceroute. 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. > > [[email protected] /]# traceroute www.senie.com > traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0 > traceroute to fennel.senie.com (204.69.207.2), 30 hops max, 40 byte packets > 1 border-core0-eth1.Columbus.EnterZone.Net (209.41.244.1) 0.542 ms > 0.438 ms 0.411 ms > 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 0.896 ms > 0.768 ms 0.731 ms > 3 core1-atm0.Cleveland.fnsi.net (209.115.127.102) 12.083 ms 9.756 ms > 9.316 ms > 4 border1-atm6.SanJose.fnsi.net (206.183.239.94) 66.729 ms 65.678 ms > 63.696 ms > 5 bb2.mae-w.home.net (198.32.136.70) 67.027 ms 65.376 ms 76.126 ms > 6 172.16.2.250 (172.16.2.250) 90.842 ms 78.524 ms * > 7 172.16.2.58 (172.16.2.58) 146.095 ms 130.080 ms * > 8 10.0.248.34 (10.0.248.34) 118.753 ms 125.679 ms 128.392 ms > 9 10.252.48.218 (10.252.48.218) 156.053 ms !X * * > 10 10.252.48.218 (10.252.48.218) 129.488 ms !X * 146.837 ms !X > > Bad idea in my book. By the way, you might want to ask them about all of > those *'s. Nasty, nasty, nasty. > > In addition, path MTU discovery won't work on your network because of the > RFC1918 addresses. Don't get me wrong. I personally use RFC1918 addresses > within my network. Those are NON-EXPOSED hosts however and there is no > need for path discovery to take place. In your case, your provider wanted > to save 4 IP addresses, a /30. I hadn't thought about the PMTU failure this causes. Not nice at all. > > >addresses, but my present upstream is using 10.0.0.0/8 and > >172.16.0.0/16, at least, for their internal use. So, the IP address of > >the WAN interface on my router connecting to them has a 10.0.0.0/8 > >address. If I block incoming traffic to 10.0.0.0/8, they can't monitor > >my net. > > Find out from them SPECIFICALLY which machine they want to monitor your > router from and open your router up to that IP address individually. Block > the rest of them. 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. > > > > >It appears this is becoming the preferred way for ISPs to limit their > >use of address space for internal-only functions. While this makes sense > > The key phrase here is "internal-only." I would hardly consider your router > or any router between yours and the rest of the world to be considered > "internal-only." > > >at some levels, attached corporate networks may have already used those > >addresses. The result is some level of confusion, though for the most > >part it doesn't break too many things. Mostly, it's just annoying since > >firewalls can't filter out stuff they'd otherwise limit. > > I can find no good reason for joe blow fortune 1000 company to use anything > other than RFC1918 addresses on their INTERNAL network and run NAT or set > up a proxy or something. I can also not find any good reason to use > RFC1918 space between routers. It breaks too many things. I want to see > you poll or for that matter, log into your router from any other network > 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. > > > > >In cases where ISPs use RFC1918 addresses within their networks, they > >really should: > > > >- Tell their downstream customers WHICH of these blocks are in use. > > > >- Provide filters at peering points that ensure RFC1918 addresses from > > outside the ISP's space do not come in from outside. > > > >- Provide Ingress filtering at all downstream customer ports to ensure > > only valid source IP addresses come from their customers. > > > > ...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. Dan -- ----------------------------------------------------------------- Daniel Senie [email protected] Amaranth Networks Inc. http://www.amaranthnetworks.com
|