SUMMARY: changing IP addresses (Class C => Class B)

From: Andy Kumeda (
Date: Tue Sep 20 1994 - 00:31:38 CDT

I have included all the responses below my original question. Thanks a
lot to everyone. (Sanjiv Khurana)
        Robert Sargent <>
        Mike Raffety <> (Raymond Trzaska) (Leslie_B_Dreyer Kalra) (John Justin Hough)



Original question:

# I don't recall if this has been discussed before, but if it has, I
# apologize, and would appreciate it if someone can send me the summary.
# We are planning on changing all our bogus Class C addresses to legal
# Class B's. There are appx 15-20 subnets that will need to be modified,
# both on local and wide-area networks, and they are all segregated via
# both Alantec and Cisco routers, with a handful of host-gateways. There
# are several servers with multiple interfaces that connect to each of
# these subnets also. Finally, there are appx 200 clients -- mostly
# diskless Suns and Solbournes, along with HP9000, IBM RS6k, Auspex, NAC,
# Sun, and Solbourne servers.
# I am not asking for a solution (although, that would be nice :), but
# just for some of the 'gotchas', and any helpful hints on going about
# doing this.
# For example:
# o How much downtime is required (if any)?
# o Can/should this be done incrementally?
# o How should routing information be handled before/during/after?
# o Any 'tricks' that can be done with routers to help make it
# less painful?
# o Any helpful scripts/utilities?
# o Others...
# Thanks. (Will summarize of course.)
# Andy Kumeda


I have never had the opportunity to do this but I have a few suggestions:

I assume you will be subneting your class b to a class c. First I would
map out what class b subnet goes with each class c. If possible I would
eliminate static default routes on the hosts and run rip. This way
routes are picked up automatically on the hosts as the router ip #s are changed.
Once the project is done you can turn off rip on the hosts and put static
default routes back (if you prefer static routes over rip). I would do it
incrementally, and if you do start from the inside of your network and work
towards the outside or vice verse. This is because you can't have your
class b address separated by other addresses.

Hope this helps,

I am looking for to seeing the summary. I am sure you will get many response
with a lot of different tips.

Mike Scott

From: (Sanjiv Khurana)


Cisco routers have the capability to use secondary addresses. This allows
them to have multiple ip addresses associated with a single interface..

This could be used as a transition mechanism until machines with local host tables get updated.

If at all posssible, set up each client with a standard hosts file, and set
it up for it's own ip address as the default. This will eliminate dependancy
on which router is on that segment.

Good luck,

Sanjiv Khurana
Internetworking Group
Stentor Resource Centre Inc.

From: Robert Sargent <>

if you configure the Sun's to allow tftp access from the routers
you can pre-write all your new Cisco configuration files on the Sun
and then at the moment you want to make all the changes just
type config net on each Cisco. Dunno about the other boxes.
This method takes about 45 seconds to completely reconfigure each Cisco.



From: Mike Raffety <>

> o How much downtime is required (if any)?

Depends on your staffing.

> o Can/should this be done incrementally?


> o How should routing information be handled before/during/after?

Run in.routed; keep it dynamic!

> o Any 'tricks' that can be done with routers to help make it
> less painful?

Like running multiple IP networks on one physical wire? I'd recommend
against it; if you have two routers with multiple IP interfaces defined
on one wire, you'll get broadcast storms.

> o Any helpful scripts/utilities?

Awk, perl, ... not quite what you were thinking of, I suspect. It's not
going to be painless ...


From: (Raymond Trzaska)


As you are already using class C networks, your easiest transition will be to use a netmask
for your class B of - mapping each subnet directly to a class C net.

some routers, and some CISCOs can support a secondary network on each port - this can help
if some machines are forgotten.

Can this be done incrementally? depends on how incremental you mean. each C-network needs to
become a B-subnet in one sweep, but each subnet can be dealt with individually. ( you can do it
more gradually with a router on a single segment between the two networks, but the error messages
on the consoles about wrong addresses, and the network load increase through repeated broadcast packets
is horrible ).

Downtime will be small - manily in the reconfiguring of the routers, addressing changes on the suns
can be done on the fly - but watch out for NFS mounts when changing, you will have to stop NFS during
the address changes.

--------------------------------------------+###### ## ######
ray k trzaska phone +44 81 544 4422 # # # # # #
brown & root ltd fax +44 81 544 4301 # # ## # #
highlands house email ##### ### ######
Wimbledon, (bbrq990@sunipc6) # # # # # # #
SW19 1AQ , England # # # # # #
---------------------------------------------###### ### # # #


From: (Leslie_B_Dreyer Kalra)

We are in the process of doing exactly the same thing. We're
about half old-half new right now, so yes, it can be done

I don't handle the networking for these machines, but I know
that the networking folks dual-ported the routers so they
could talk to both sets of numbers. That was a big plus.

Next step was to establish an NIS slave for each set of numbers
on each LAN. We've been installing new servers, so we just set
them up with new numbers and made them slaves. Now we have
at least one slave for the old class C addresses and at least
one slave for the new class B addresses on each LAN. One
gotcha with readdressing servers, though, the mounts go south
when you change the address *and they don't ever go stale*.
Any machine that has the server mounted when the server is
readdressed with hang and have to be rebooted, period. (As
much as I warned my users of that, they still stayed logged
in and then whined the next morning when the machines were
locked up tight.)

If your class B network is subnetted, make sure you have the
correct netmasks file in place. If you don't, you won't get
any connectivity to the new machines, and it won't be immediately
obvious why. For instance, yesterday I was cloning a machine
with our old, tried-and-true clone script. It failed trying
to mount a machine on another LAN. It turned out I had to
modify the script to set the right netmask on the ifconfig
before attempting to mount anything. It can pop up in odd

Finally, I was ready to readdress desktop machines. I did
as many as I could when I did their NIS slaves, if I could
catch them with no one on them. I use the following method:

1. Coordinate with our networking people to get DNS changed
   at about the time the machine is rebooted. One of the
   networking people gets up before dawn anyway, so that
   wasn't so bad.

2. The night before, modify /etc/hosts and /etc/defaultrouter.
   Also install good netmasks file, if it's not already done.
   Change the address in the NIS hosts table, but don't push it

3. Set up at job to push NIS hosts table at 6:00 in the morning.

4. Set up at job to reboot the machine at 6:00 in the morning.

5. Send list of machines to be readdressed to networking folks
   for the early-morning DNS change
The downtime for each machine is only long enough to reboot it.
The hard part is killing all of the NFS mounts of an NFS server
when it gets readdressed...

I think that's about it. I've been procrastinating finishing
up our machines, just because the users whine so much if we
ever want to reboot their machines...

Good luck with it, and let's both hope we never have to do
it again...

Leslie Dreyer Kalra
Allentown, PA

From: (John Justin Hough)

Howdy Andy,

o How much downtime is required (if any)?
      None, you can can network interface parameters live with ifconfig,
      that is on suns (sunos 4 & 5) and bsd derived systems - though
      I won't commit to others.

o Can/should this be done incrementally?
      DNS should be correct, then Hosts/Clients if needed then Routers
      should probably have bridging enabled since you are trying to
      merge your network.

o How should routing information be handled before/during/after?
      Default routers and stuff stays the same - mostly you are worried
      about the masks, and having the routers to route properly.

o Any 'tricks' that can be done with routers to help make it less painful?
      Not that I can think of.

o Any helpful scripts/utilities?
      Too dependent on routers to be certain.

o Others...
      Watch out for hosts acting a routers with broadcast masks and
      netmask set Class B wide, it may not work.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:10 CDT