couple of thoughts in line: ""Craig Columbus"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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."
CL: it never snows here in my home town, either. things change. > > 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. CL: NAT can solve a lot of problems. However, IMHO, those problems, NAT notwithstanding, are easier to solveif you use either your own public space or reserved private space. > > 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". CL: don't you just love this kind of attack/response? There's no place I know of where it says you can't bathe in gasoline either. >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 CL: the problem arises when you have reason or need to connect to those in the public world using subnets of that particuar public space. It can get real ugly real fast. Now granted, the chances are that you won't need to connect to the Woods Hole Oceanographic Insitution ( if the ARIN record is current ) But you never can tell. > >reply. > > > >Jarred Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45037&t=44946 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
