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."
You think that's bad? The subsidiary of a Fortune 10 company that I work for owns a class B IP range. All of 5-10 of those IPs are accessible via the Internet, the rest are only accessible via the internal network.
For 10.* this is irrelevant anyway. This are _private_ addresses which can not advertise outside of your network. So the size simply doesn't matter.
For months I had a static ISDN connection that used 192.168/24 addresses for the PPP link between my router and my ISP's. It didn't cause any problems at all.
I consider this to be a good practice. (Networking gurus, feel free to disagree.) The network in question doesn't need to be accessible from the outside world, and it didn't confuse my Cisco router.
Now, since you're dealing with Microsoft software, all bets are off...
Only on slashdot can a posting be rated "Score -1, Insightful".
Windows has this need to have a 8 bit subnet mask with a class A network.
We have a 16 bit subnet mask (255.255.0.0) with 10.x.x.x addresses for our offices. Our VPN server is Linux, hands out ips and all. Our windows clients assume that everything 10.x.x.x is on the other end of the tunnel... this has really caused minor problems Win2k RRAS at one office, but otherwise, its not really a problem, It's kind of a feature.
I personally see no problems with the using of 10.x.x.x addresses with windows, but if your using 10.x.x.x addresses on two sides, id say be prepared for problems. From experence, I would perfer to use anything but windows for routing data. I think Linux 2.4 might be interresting to see on routers, but I have not the time to see. Windows is a very poor choice for routing data.
I personally think it dosen't really matter anymore. It's easy to migrate network addresses, change it on the dhcp server, setup alias ips on servers and routers.
You don't have many problems as long as your subnetted, and your not in the same subnet at two locations.
It becomes stupid when people do 10.0.0.0/8, which not many do anyway. Most people use 192.168.0.0/24 or 192.168.1.0/24 anyway.
1. 10.0.0.0 uses subnet mask of 255.0.0.0
2. deny outbound or inbound 10.x.x.x connections at your firewall machine. this will filter out inside and outside traffic and separate the 10.x.x.x addresses. consult your firewall for deny rules.
Why read the article when I can just make up a snap judgement?
First, you may be experiencing a problem with the network address translation. If these tables become corrupt or are cleared, then you will experience problems since the association between real and virtual IP addresses will be broken. If you are NAT-ing the entire 10.x.x.x subnet, you could potentially be running into memory/caching issues because of the shear number of IP addresses that are being mapped -- it could explain why rebooting temporarily solves the problem.
Second, you may have an overlap with static and dynamic IP addresses. If you are assigned an IP address by your DHCP server that is already taken by another computer then it is only a matter of time before you run into a problem like the one you described. Changing your IP subnet may have temporarily fixed the problem because no one has assigned a static IP address from your DHCP pool. Yet.
It is unlikely that using the 10.x.x.x subnet itself (other than the problems I have described above) has had anything to do with the failures. It is very common to use it for internal networking. I won't get into a debate as to whether it is good practice or not.
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.
Ever hear of Multicast IP, it uses 224.0.0.0 up to 239.255.255.255
J
I am not a Frog. I am a Free Womble!
IN a very rare case would this cause a problem with an ISP that was using these blocks also. Reason being if an ISP is using these types of address' inside for lets say maybe a webserver it would be hitting a firewall hopefully a cisco which would route to the destination of which the correct interface it is connected. If you had NAT setup at your business and or a firewall the ip that people and or routers would see would be the router you were either assinged statically from your ISP or from the dial-up pool that radius assinged you. The only thing the local address would have to do with anything would be routing locally. Hence the 10.x.x.x block that you are coming from should never affect the 10.x.x.x block that the isp is using. If this were the case breaking into the ISP's network would be an ease if they didn't have 10.x.x.x from 0.0.0.0 block out.
Smileyq ---------------------------- UNIX geek and proud of it ----------------------------
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?
um hows about because when someone starts using them, you wont be able to send packets to them?
With the rfc1918 numbers, you are gauranteed that they will not be used.
Other than that, go ahead and have fun. You can do whatever you like on your internal network man.
-Steve
"I opened my eyes, and everything went dark again"
A good class C 192.168.1.x will serve 255 clients... all you need is 6, why use a network that gives you thousands?
10.x.x.x MS does like to use 255.0.0.0 for that... you might consider switching that over too. If its a microsoft network you might as well make it happy, even if there is no compeling reason to do so.
The compeling reason could be your sanity!
AF-Design, web development.
Uh, sorry, read RFC 1812 for requirements for Internet routers (circa 7/95 mabye??).
RIPv2 has more sophisticated support for route aggregation that CIDR allows for, but RIPv1 works fine (given that it's RIP, of course).
M$ OS's have worked properly with the 0 subnet for a LONG time, since at least mid-95, by the way, and this was BEFORE Cisco properly implemented 1812 (everyone seems stuck on 950).
Regards,
Brian in CA
is valid. The use of the so-called "10 net" address range is actually preferred over the class C private addresses for a few reasons, namely ease of classless interdomain routing, supernetting, and whatnot.
what in the nine hells is a "quad"?
i think you're fumbling for the term "octet".
Lots of people seem to have incorrect IP blocks, esp 192.168.* The only correct private IP blocks in RFC1918 are 10.0.0.0/8 (10.0.0.0-10.255.255.255) 192.168.1.0/24 (192.168.1.0-192.168.1.255) 172.16.0.0/12 (172.16.0.0-172.31.255.255)
ICQ# : 30269588
"I used to be an idealist, but I got mugged by reality."
ICQ# : 30269588
"I used to be an idealist, but I got mugged by reality."
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.
I was wondering, hmmm xemu is the master
A small company I do some work for has their entire internal network set up using IPs that -should- be out on the internet, but are NATed off. I think the block properly belongs to the University of Toronto.
Granted, the network's a mess in a lot of other ways, but this one is one that always gets my goat. The response? "Yes, it's not right, but it works fine and hasn't caused any problems yet".
I think too many networking vendors get hungup on previously 'illegal' numbering schemes. IP addressing isn't only for the computers, it should also be designed to be human readable. There should be no reason for IP stacks of various flavours to not understand all zero quads with valid netmasks.
RFC1918 is still valid and should be used where ever possible, and pressure should be put onto those vendors who refuse to accept oddball netmasks just because it wasn't done that way 10 years ago. With modern VPNs, NAT, Squids and the like, many networks have need for only a handful of true addresses. Its not only better for conservation of address space, but also much more secure overall.
Don't let anyone tell you you can't use 10.0.0.0 with a mask of 255.255.0.0 (or a wide variety of other possibilities)
I enjoy the 172.16.0.0-172.31.0.0 range with a 255.255.252.0 mask. This allows 1024 hosts per network. (Ex. 172.16.0.1 - 172.16.3.254) If your vendors cannot get this flexible, then tell them to fuck off...
Scott
Please READ RFCs before becoming an expert. The section you referred to in RFC 1918 is as follows....
3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
This is a great thread. Could someone please post some books that they have found helpful with routers and IP configurations. thank you
ONEPOINT
spambait e-mail
my web site artistcorner.tv hip-hop news
please help me make it better
if you see me, smile and say hello.
Anything in the 10.x.x.x network can be considered private, ie. non-routable. Generally, there should be no problem using a 10 network for your private network, but there are a few exceptions, and one which comes to mind is my T1 provider, @Work. Whether or not it's safe to use a 10 network with your ISP, or any private addressing scheme for that matter, depends on how their routers are configured. IDEALLY, the ISP will configure all interfaces on their routers to use routable IP's. This makes for a nice, clean configuration which in turn makes route summarization a snap. This is much easier on the network in that the routing tables don't get ridiculously huge. @Work, however, for some reason uses IP's out of the 10 network to assign to serial interfaces to their border routers, the ones that connect their customers' T1's. If their customers use their assigned routable IP's then there is not a problem, but if they are set up on a private NAT'ed 10 network that just HAPPENS to be on the same subnet as their border router, it can raise hell. Actually, I had a friend who ran into this issue with Flashcom DSL when he was trying to set up a router to VPN into his work, which was all on a 10 network. It would take the VPN connection but he couldn't get to anything inside of his network, so he telnetted to a known server and ended up getting a Redback in Flashcom's network. Imagine his surprise. Since his DSL was bridged, not routed, he could see a bunch of their numbers out of the 10 network. He ended up having to do something funky with his routing tables to get the packets going to the right places. Anyway, barring all this jabber, in your case you are much better off with the 192.168 network, especially considering you have a pretty small network. Heck, I've set up entire WAN's based on a 192.168 network for all of the offices in it and there are more than enough IP's to go around.
-R
God I hate that, windows boxes seem to do it periodically, for no reason whatsoever. On a 192.168.x.x network, it breaks about one in 255 sites. The fix is easy (renew DHCP leases) but it confuses and angers the hell out of lusers.
If there is a patch for this anywhere, let me know
On a network with multiple internal class 'C's contiguous 192.168 nets can be summarized by EIGRP or OSPF. The 10 nets cannot. This means that your routing advertisments will be bigger.
Of course for tiny/static networks that's irrelevant. The only consideration is whether the network numbers will conflict with some other use.