Hi Edison,

thanks for your reply. thats what i thought so and its something i dont wish to do so as that IP addresses has been used up

i have came out a phases approach to address it and now im stuck with a problem. let me describe to you guys.

Objectives:

1) A redundant dual-core network

2) IP addressing/VLAn not greater than class C

N.b Currently, the environment is only running on a single core switch 6509

Stage 1:

Configure Core 2 (6506) with multiple class C vlans (.129, .130, .131, .132, .133) shut down all VLANs except 133 to support new office.

Connect Core 2 to Core 1(6509) using layer 3 point-to-point instead of Trunking. this allow co-existent of same IP addresses. Configure static route on Core 1 to route 133 traffics to Core 2, on Core 2 - default route to Core 1

Stage 2

Replace existing Core 1 (6509) to new Core 1 (6506), configure as trunk (layer 2) to Core 2 to form dual-core switching environment. VLANs should leran from Core 2 and now both switches will have same VLAN segments setup

either reboot access switches to re-learn the new VLANs info or wait for it to update itself. configure ports to correct VLAN.

Here are my questions:

in Stage 1:

the new VLAN 133 on Core 2 will not be able to get DHCP from the server connected on Core 1, users on Core 1 will not be able to "talk" to 133 on Core 2, as the network traffic will still be switch among it own subnet /20 ealthough there is a layer 3 static route on the msfc.

What should i do so that users on Core 2 Vlan 133 able to talk to servers on Core 1 VLAN.. cause my impression will be servers on Core 1 will reply traffic "moves" within its VLAN

On stage 2:

will the access switches able to re-learn automatically or need reboot?

On servers and workstations on stage 1 within the Core 1, you can manually add a route within their operating system. On Windows, you can use the 'route add' command - pointing to the Core 1 SVI.

Crazy enough, this may work - though I never seen nothing like it :)

On Stage 2, the access switches should be able to refresh their Vlan DB provided the VTP domain and password matches and they are configured as VTP Clients.

HTH,

__

Edison

any one can help??

Thanks

Have you considered using secondaries for the address migration? You'll want insure the address spaces don't overlap, but secondaries allow multiple (host) address spaces to share the same "wire". Once devices are on the replacement address space, you remove secondaries.

Hi Joseph,

Able to illustrate with an example? sorry that im unable to undersand how it works.

If possible, please illustrate with the scenario i explained above.

Thank

using the secondary ip method, may i know of they are feasible with such implementations

Core switch Vlan 1:

IP address 20.5.129.1 255.255.240.0

ip address 20.5.130.1 255.255.255.0 secondary

ip address 20.5.131.1 255.255.255.0 secondary

ip address 20.5.132.1 255.255.255.0 secondary

ip address 20.5.133.1 255.255.255.0 secondary

may i know if the above config will be ok? these IP overlap with the primary IP subnet.

next, with this config in place.

since all the users/printers are still in the vlan 1 (have not change yet), their DHCP IP address for e.g is

20.5.131.100 Mask: 255.255.240.0 Gateway: 10.4.129.1

Will they still work normally?

for subsequent new workstations/printers, i will configure them to use /24 mask and the respective gateway IP which i suppose it will work as well.

please advise,

Thanks

Charles

When using secondaries, you still want to avoid overlapping addresses.

Secondaries lend themselves to dealing with static address hosts. You can go to each host, change its addressing, and it will continue to work.

Secondaries also can be used to allow DHCP hosts to migrate to new addresses as DHCP leases expire.

An issue you might have with DHCP hosts, is too many on an existing subnet to fit within a smaller subnet address space. You could go to much effort to control DHCP renewal per host, but if you can accept a brief network interruption, having a DHCP host see its link change state, I believe, will cause DHCP to confirm and, if necessary, obtain a new IP address.

I.e. for DHCP hosts, define the new subnet(s) on a different VLAN(s), and either repatch access connection, or shut access port, reassign port's VLAN, no shut port. (In other words, don't use secondaries.)

PS:

If you're tight on address space, you only need new to migrate to. Once subnet is migrated, you can reuse its address space.

Base on what you have said, i will not be able to configure this way. Because the main idea is to break down 20.5.129.1/20 into multiple class C.

Any better suggestions?

Core switch Vlan 1:

IP address 20.5.129.1 255.255.240.0

ip address 20.5.130.1 255.255.255.0 secondary

ip address 20.5.131.1 255.255.255.0 secondary

ip address 20.5.132.1 255.255.255.0 secondary

ip address 20.5.133.1 255.255.255.0 secondary

Perhaps your missing the point that it's unlikely you can break down an existing active /20 into its component /24s. (For one reason, keep in mind that many /24s network addresses and broadcast addresses are /20 "host" addresses.) Think as if you were migrating to a new addressing scheme (which you are - just you'll be able to reuse most of the address space).

If you migrate the host addresses, in the existing active /20, into /24s not in any active address space, then both secondaries and/or new VLANs /24s could help the migration. Once you've "emptied" the /20, its /24s could be used for another active /20 (or you can move back into the original /20's /24s from the "new", and temporary, /24s).

BTW, if you do use secondaries and DHCP, I recall DHCP will only "see" the primary gateway address unless it's placed directly on the same subnet you want it to provide an address for. This often means the new address is configured as the primary and the old address as the secondary.