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."
But classless addressing allows any of these to be properly subnetted. There's nothing special about the private blocks that dosn't allow them to be cut up into lots of smaller private networks.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
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.
Ciscos work fine with quads of zero. You just need 'ip subnet-zero', which is the default on 12.x IOS releases anyway.
;)
*Any* equipment that doesn't support subnet 0, or the classful-broadcast subnet (eg 10.255.255.0/24) is broken - there should be no reason not to use these. Of course, if you *know* you have broken equipment, not using them is wise
Regards,
Tim.
Various older IP stacks choke on an all zero subnets like 10.0.0.x/24, or even 192.168.0.x/24.
Mostly those IP stacks went away in the early 90's, but NT 3 was broken, and the mantra of subnet zero lingers on with MCSEs, who may find themselves still working on 3.51 systems. Old SunOS IP stacks, fixed in 1988, didn't like subnet zero as well. And I've seen other broken implementations from time to time, but not on PC/workstation equipment. Even the BSD stack choked, in my distant memory, but was fixed aeons ago.
Cisco used to have "no ip subnet-zero" by default, until 12.0 changed it, meant more as a warning to the network admin to take care about broken stacks. ip subnet-zero and its evil twin, ip classless are two of the most common commands any CCIE enters into a new config. Now in 12.0, cisco believes that there are now few enough NT 3 machines in existence to change the defaults to something reasonable.
I tend to use 10.1.1.0/24 for most of my small networks, its easy to type, easy to remember, and isn't going to break any kit.
[ObOnTopicSection]
ISPs regularly use the RFC1918 addresses internally to keep costs down. Many interfaces internal to an ISP never need to be addressed individually from or to the internet. Management ports, internal point-to-point links, loopback addresses for routing purposes, DSLAMs and DSL routers, and cable modems can all be safely hidden. The traffic to these devices is for internal routing, and is easily non-routed at the limits of the ISPs traffic. Most every ISP I've looked at uses private addresses internally, it saves money and limits skiddies from gaining access too easily to certain things.
An ISP should never present a "private" IP address to a client, it would tend to break things, as Brad found out. This shows the ISP is either clueless, or has run out of money to rent blocks of publically addressable IP addresses. Possibly a combination of both. It could also be that their upstream providers can't deal with any more split, non-agregable ranges of addresses, and they are stuck until they can migrate to a single larger chunk of space. Go read NANOG for various horror stories.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
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.
No customer facing server should be in the reserved addresses range; if that server has additional interfaces to the internal lan, that information should not be propogated outside of the ISP's internal servers (even if this isn't in the protected LAN ranges, it is still a bad idea to give customers internal structure info they don't need, if only from a security standpoint).
--
-=DaveHowe=-
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
I had a daughter who I caught smoking, so I killed her and had another one. Problem solved.
True, but many routing protocols don't accept cassless subnets, such as (as I dimly recall) OPSF and RIP.
~~~~~ BigLig2? You mean there's another one of me?
RIPv1 has problems with (if I recall correctly) advertising routes not on an even octet boundary. I would have to look at the spec, but as far as I'm concerned you shouldn't use RIP at all in a "real" network. I cringe when I'm forced to use RIP to get link-state information from dialup hardware, but I think I've about got those eliminated from my network at least :)
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.