IMO, it's never a good idea to use public addresses in a private network. The standard response I get when I tell people this is "Well, it's never going to be put on the Internet or connected to another network, so it doesn't matter."
But, you should look at it this way: For a given network, there are two outcomes: 1) It will never be connected to another network or 2) It will someday be connected to another network. For small test networks, training networks, home networks, etc., the first option may truly be the case. If so, it is just as easy to assign one of the 10.x, 172.x, or 192.x networks as it is to assign some other IP block that another company may own. At the least, it gets you accustomed to working with the RFC spec private ranges. For business networks, experience tells me that you should always assume that the network will be connected to another network at some point in the future...even if you can't imagine it now. To mitigate problems down the road, a RFC spec private range should be used. This doesn't eliminate the possibility of overlapping private addresses if, for example, you merge with another company that uses the same private block. It does, however, assure that if you hook to the Internet, you won't hit a local server when trying to get to a registered IP address on the Internet. Here's a true story to illustrate the point: I was called in to examine a network that had chronic connectivity problems to points both inside and outside the corporate network. When I looked at the routers, I was astonished to find that each WAN remote site and each subnet had a different public block assigned. Further, there was a spattering of routing protocols installed, including RIP, OSPF, and iBGP, with no apparent purpose or reason. The company had a single Internet gateway that was performing NAT. I pointed out all of the flaws with the installation and design to the company owners who insisted on calling a meeting with the company that had been maintaining the network. We sat down at the table and I presented my findings. The network admin's only defense to his workmanship was "Show me where it says that I can't set things up this way". Needless to say, the meeting was over in less than an hour and I walked away with a substantial contract to fix and maintain the network. I readdressed the network and put static routes in place of the routing protocols. Problem was solved and connectivity was never again an issue. The moral of the story is that just because you CAN do something, it doesn't mean that you SHOULD do something. Craig At 12:52 AM 5/25/2002 -0400, you wrote: >Thanks Craig. Yes I know 128.128.0.0 is not technically a standard private >address defined in RFC 1918, but those are just so that ISPs have a standard >address in which to block routing information for. Therefore a private >address within a network can be any class A B or C address. Thanks for your >reply. > >Jarred Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45034&t=44946 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
