You know...I just revamped a class b network (150.150.0.0) that a company
had implemented years ago and they didn't own the space.
Even though everything seemed to be working properly, the entire 150.150
network was not accessible on the internet. Heaven forbid micrsoft move
their hotmail servers to 150.150.x.x.
There should be no reason to not do things the right way... :)
>>> "Craig Columbus" 05/25/02 01:25PM >>>
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
>>>>>>>>>>>>> Confidentiality Disclaimer <<<<<<<<<<<<<<<<
This email and any files transmitted with it may contain confidential and
/or proprietary information in the possession of WellStar Health System,
Inc. ("WellStar") and is intended only for the individual or entity to whom
addressed. This email may contain information that is held to be
privileged, confidential and exempt from disclosure under applicable law. If
the reader of this message is not the intended recipient, you are hereby
notified that any unauthorized access, dissemination, distribution or
copying of any information from this email is strictly prohibited, and may
subject you to criminal and/or civil liability. If you have received this
email in error, please notify the sender by reply email and then delete this
email and its attachments from your computer. Thank you.
================================================================
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=45246&t=44946
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
