Moving to a new Address Class

[gavin.mckee]

Hi,

I am planning to move about 150-200 servers to a new network environment. At present the IP address range is 172.22.x.x we are moving to 10.64.x.x. I need a way to decouple clients from the existing range. We provide many ways for clients to connect to our services. The internet, extranet via TNS and BT Radianz. Some of our properitary applications have IP address information hardcoded into them. I am thinking that I can use NAT to say if you are targeting say 172.22.150.1 you should be redirected to 10.64.1.1? Is this the best way to do this?

Should I employ a specfic device to do this.

Any help well rated.

Gav

[ankbhasi]

Hi Gavin,

NAT will going to be a good solution but provided all your servers to which clients will access are behind some router which supports NAT. I mean clients are seperated from servers subnet and there is some router between them.

If your network design has some routers between servers and clients configuring NAT will going to be a good solution I believe so.

Ankur

[gavin.mckee]

Thanks Ankur,

I think that I will be able to place a NAT device between the clients and our network.

We have a 6509 in the core/distrubtion of our network that supports NAT on the MSFC. I think we can build NAT tables here pointing outwards towards our new network.

:)

[scottmac]

NATing in the core is usually (at least by Cisco design standards) considered a bad design.

Given that you are migrating, consider using secondary addresses onthe server segment(s).

(original)

int fa0/1

ip addr 172.22.1.1 255.255.255.0

(with secondary addressing)

int fa0/1

ip addr 172.22.1.1 255.255.255.0

ip addr 10.1.1.1 255.255.255.0 SECONDARY

That way either address will work until you completely migrate the servers to the new block.

Servers that must remain hard-coded with the old address can remain on a separate subnet (172.22.x.x) or, worse case, NATed ... but you reduce the overall NAT processor / memory / table loads.

You can also (temporarily) put alias addresses in your DNS that tie back to the original address if needed. The DNS can also be set for address substitution, I believe.

SECONDARY addresses were created with the idea of easing migration problems. IMHO, it's the only real reason for using them.

Give it a try on a pilot system, I think you'll find it easier and less error-prone (think encrypted traffic) than NATing (especially in the core).

Good Luck

Scott

[eugene.beckett]

you might also consider putting secondary addresses on the hosts that cannot have the ip address replaced -

[gavin.mckee]

Does secondary addressing not cause huge problems with routing?

We will need to maintain a fully functional production network while the migration is happening.

The new site will run OSPF. The current production sites are running RIPv2

[amit-singh]

Hi Gavin,

With OSPF enabled you might get into a lots of problem with secondry addresses as OPSF doesnot form adjacency over the secondry addresses. You have to really give it a big thought to get to the final plan.

-amit singh