Slashdot Mirror
Will ISP Use of 10.0.0.0 Addresses Cause Problems?
"The setup is a small network, 6 PC's and one server. The server has Microsoft Small Business Server 4.5 (Proxy Server) loaded. Intermittently the PC's would lose connection to the server and start broadcasting for a master browser reelection. These requests were logged in the server event log. We also found that sometimes the subnet masks of the PC's would change from 255.255.255.0 to 255.0.0.0. The server acts as the DHCP server and the PC's were using DHCP. Rebooting the server would fix the problem for a time, maybe 10 minutes, maybe a day. Sometime the problem would go away without rebooting the server. The network was 10.0.0.0 with subnet 255.255.255.0.
I found that the problem was caused by the dial-up networking connection to the ISP. One of the ISP's servers is configured to use the Class A 10.0.0.0 addresses and network address translation the others use real IP addresses. The problem was intermittent because it would just depend on which of the ISP servers we happen to connect through. I resolved the problem by changing the internal network to 192.168.0.0."
I don't know why people insist on ignoring the RFCs on private network numbers.
If you only have a small network, or a group of small networks, use the 192.168. addresses. This is what the RFC recommends. Yes, I know 10.x.x.x is easier to remember, but it will cause you problems down the road, since everyone thinks they should use it.
Why? You might say, "They are both reserved addresses - why would one have any trouble?" Technically, you are correct. However, the problems come when two private networks connect to each other (you and your friend set up a VPN, your ISP does something like you describe, two companies merge).
To avoid these problems MOST of the time, pick a random number between 0 and 255. Use a net address of 192.168.. Chances are this won't conflict with someone else's network when you merge your networks.
Note that the quad boundary only matters if you are using subnets in octet size; the Ciscos don't like any subnet with a subnet address of zero. For example:
Suppose your ISP assigns you a chunk of 256 routable IP addresses, say 123.45.67.0/24. You decide you want to split this among four offices using private T1s between your Cisco routers. You break them up this way:But the Ciscos in their default configuration will choke on this; they don't like the top one because its subnet address is all zeros (or, IIRC, the bottom one because it is all ones). The especially ridiculous case is if you try to split the net in half (e.g., 123.45.67.0/25) in that case my recollection is that it won't allow use of either subnet. In this case, the "ip subnet-zero" instruction is vital.
Caveat: It's been a few years since I had to beat a Cisco into submission. But a quick search on the net suggests that things are still the same.
10.0.0.0/8 -- You got that one right.
172.16.0.0/12 -- That right, too
You messed up on the other one, though. It's 192.168.0.0/16. That's right, the full 192.168.0.0 - 192.168.255.255 range is open.
Ref: RCF1918
--
--
"I personal[ly] think Unix is "superior" because on LSD it tastes like Blue." -- jbarnett
These can be summarized as follows:
If packets from the IP address will never reach the public internet without it being re-written (NAT'd) to a public address, then it is ok.
Some ISP's think that it's ok to use RFC1918 addresses on their internal point-to-point links. It is not. The reason why is that many ISP's filter anything coming from or going to a RFC1918 address because they generally are bogus packets anyways. However, if the RFC1918 addresses are used on internet visible interfaces, this causes things to break.
A good example of this is MTU path discovery. Basically this works by sending a packet from point a to point b with the don't fragment bit set. If the packet reaches a router which can't handle a packet of that size, the router sends back an ICMP packet which basically tells the "Discovering" machine that it couldn't forward the packet because it was too big for it's MTU setting. If the IP address of the offending router's interface happens to be an RFC1918 address, then you might never see the ICMP back and as such you will have weird problems going on.
Note: This is also why you shouldn't just filter ICMP packets.
In the case above, it sounds like the ISP is using the 10.0.0.0 address internally. As they also had the customer using the 10.0.0.0 address range, this could get weird really fast.
This was the words out of the mouth of a MSCE when I had set up an office environment with network 10. Because the office was rather large, I had thought to use 10.0.0.x/24 for the main office network and 10.0.1.x/24 for the lab. When DSL testing was to go in, the DSL and LAN lab would use 10.0.[234].x/24 for primary DSL, primary LAN, and secondary LAN.
I took the advice, and selected 10.1.[1234].0/24, and things worked swell.
This proved to be excellent advice when we started testing with Cisco router-access servers, because those things do NOT like a zero in any quad. With 10.1.1.0/24, though, everything worked great.
I now continue that practice, using 10.1.1.0/24 for any small private network I set up. Because the gateway to the Internet uses NAT, I'm not concerned about what the numbering is on the other side. In any case, every firewall is configured to not forward the private network addresses.
This works with NT, 2K, 98, 95, 3.1, and Linux. Not to mention BDS, Ascend, Cisco, USRobotics Total Control, Portmaster, and other RAS brands.