I have the task of migrating a Network using public IP space of 199.248.x.x to private IP space 10.248.x.x. The public IP space is not currently allowed to the public internet but it is not best practice and there are security concerns. I have been here for 2 months and my MIS has used to 10.248.x.x for 2 new remote sites that we have deployed.I am looking for best practice...documentation...folks that have done it already etc...thanks in advance
Use a different class B for each site. Use different class C within each site for specific uses.
Site A 10.10.0.0/16
Site A Servers 10.10.0.0/24 - 10.10.15.0/24
Site A Workstations 10.10.16.0/24 - 10.10.31.0/24
Site A 10.11.0.0/16
Site A Servers 10.11.0.0/24 - 10.11.15.0/24
Site A Workstations 10.11.16.0/24 - 10.11.31.0/24
Even if you don't have many sites or if the company grows and add sites, it will make identification and summarization very simple.
We have learned this the hard way and it is working very well for us now.
A good idea is to set aside networks for management, routed links (/30), DRAC, Security, ETC.
You have an entire class B for each site so you clearly have lots of options.
Try to keep you site specifics on network boundaries for more granular summarization within the campus or site.
I completely agree with letsgomets... the only thing I would emphasize... is his last statement... it is not that important on small networks, but as you network grows... summarization is much more critical.
Thanks and I have for the most part have a new IP schema ready but I found out that all the IPs are static even at the client PC level due to the HP UNIX system we use for banking. It can only comminute with nodes that have static IPs assigned. So can not use DHCP for clients and now I am looking at maybe using loop backs and secondary IPs on the servers and the clients but not sure what we can do with the HP UNIX HOST...has only 1 NIC and I have to find out if we can use 2 NICs and dual home...???
If I understand correctly your post you need to move from IP address block 199.248.x.x
The current block is not connected to the internet but these are public ip addresses.
You also say that you have already configured two new remote sites in net 10.248.x.x
The first note is that the two address blocks have the same size so I don't see any issue on creating the new address plan.
I think you are more interested in how to make the transition as smooth as possible.
You can easily map each 199.248.z.k subnet to a corrispondent 10.248.z.k.
The question become how to modify the routing protocol in use to support a smooth introduction of new IP address ranges.
DHCP on client vlans and DNS for servers complete the picture.
About the routing protocol you have to take in account the following:
OSPF and IS-IS cannot use secondary ip addresses to build neighborship can only advertise secondary ip addresses in client vlans (leaf networks)
EIGRP and RIPV2 allow to build neighborships on secondary ip addresses.
You haven't specified the routing protocol(s) you use but the above notes lead to the following suggestion:
you can distinguish between backbone links and client (or server links).
The first are the links that interconnect networking devices no DHCP or DNS issues here.
I would change each IP subnet associated to a backbone to its new corrispondent 10.248.z.k
you can do this on a per link basis and require some change in network commands for the routing protocol.
For client and server vlans the approach can involve the usage of secondary ip addresses:
the new 10.248..z.k is added as secondary command
ip address 10.248.z.1 255.255.255.0 secondary
routing protocol is modified as needed (see above)
for client vlans you start to create the new DHCP scopes associated to the new address plan.
for server vlans where each server has a fixed or manually configured ip address you can:
configure a new ip address in 10.248.x.x range that uses the secondary ip address as default gateway
You need to update the DNS entries for the server to reflect the change
In this way the transition can be as smooth as you like
Hope to help
just an important note :
to use the approach I suggest if the routing protocol is EIGRP or RIPv2 you need to disable auto-summary with
router eigrp xx | rip
this because if the backbone links are moved before to avoid possible routing issues caused by auto-summary.
For migration on client vlans you can force DHCP based clients to move to new scopes by reducing the range in the old subnet.
Hope to help
Thanks for the help...but I have 1 more very important issue with this migration...all the IPs on all nodes to include client PCs are static. This is due to the HP UNIX system we use for banking and all IPs must be set static....oh joy.
Thanks so much for the help and yes you are correct in all your assumptions. We use EIGRP...I can not use DHCP for clients due to the HP UNIX banking system will not allow DHCP...only static IPs...so all the clients are static ips...400 plus and that does not count the servers or other nodes. However I was looking very hard at ythe use of secondary IPs and using loopbacks...since we currently do not have any loopbacks configured and I would like to fix that as well for many reasons. We also have BGP running so I want to better use this for more than just ISP internet failover.
the approach with secondary ip addresses is still viable.
The headache is that every single host has to be manually migrated.
A possible suggestion is to enable ip directed broadcast: in this way by pinging the directed broadcast you can check when all PCs have been moved to the new subnet.
Using a loopback address in each router is a good practice reserve one or more /24 for the loopback addresses and assign /32 ip addresses to loopback.
Hope to help