Need advice on best way to cut over to new network

I have an existing network, and a new network that I installed in parallel using spare fiber. The core is being completely replaced, and each of our 13 closets has had a single 48 port gigabit switch added to it. These Gig switches are connected and online with the new core on seperate fiber. My goal is to do as much as I can before the weekend when we cut over. Ideally, there would be minimal running around and some config changes at the console. I am thinking of connecting the existing 10/100 switches in our mdf's to the new Gig switches using crossover cables. Since I have configured the new core to use the same gateways and IP addresses as the existing core I am a little nervous about causing problems. I was thinking of disabling the ports with the crossover cables and enabling them on the cutover date. I think there might be an easier way, maybe limiting traffic over the trunks to management vlan packets only, until the cutover date, then turning off the old core switch and activating all the vlans on the new core. I would appreciate your recommendations since this is my first time doing this and I am just learning about Cisco switches. Thanks! NH

Reply to
Ned
Loading thread data ...

I agree with your suggestion. If you want to eliminate physical work on cutover, run the cables and plug them in, but disable them on your core only. On night of cutover, shutdown the old core's interface, and bring up the new core's interface. That way if you need to back out, you can just reverse without worrying about losing connectivity to the IDF switches (at least in theory). Do not, and I repeat do not, turn up the new core with same vlans and ip addresses prior to cutover or you will have problems. Well unless of course your new core is connected to your old core and has all of your LAN/WAN routing connections. (IE, your old core is .2 and .3, and your new core is .4 and .5 with all the same HSRP group, etc). I'd just avoid that to be safe if you can avoid it.......

Reply to
Trendkill

Thanks for responding. I have 13 IDFs with 3 crossover cables in each, that's 39 ports to disable/enable. Is there an easier way to limit the traffic? I used an allowed vlans command at the core, could I just disable those vlans (except for management) and stope the traffic that way? Any ideas? thanks

Reply to
Ned

After re-reading your first post, I think I have a little bit better of an idea of what you are doing. So if i understand correctly, you have a completely new layer2/3 core, and new IDF switches that sit next to your old IDF switches, that currently run back to an old core. I would consider turning up the trunks between your new and old IDF switches, and keep the ports blocked at your new core. On night of cutover, I would disable your old core's trunks to the old switches, and enable the new core's trunks. You would technically be moving from old core -> old idf -> new idf X -> new core to a configuration that is new core -> new idf -> old idf X -> old core. Providing your configs are exactly the same, this should work presuming your trunks are all identical on all these trunks (existing and new).

Personally if you can prune back VLANs that don't need to go to an IDF, you should do so, but it is not a prerequisite and you can always go back and prune later. However, I would strongly encourage you to completely shut down the old core on cutover, and if you are going to use both the old and new idf switches long term, each of those should be homed to the core, not daisy chained off one another. In short, and in my production world we use 4 gig etherchannel, but one fiber gig link from core 1 to idf 1a and idf 1b each, and one gig fiber link from core 2 to idf 1a and idf 1b. I would not only prune back VLANs you dont need, but I would make Core 1 own layer2/3 (vlan/hsrp priority) for odd vlans and Core 2 own layer2/3 for even vlans. As I said above, these can be changes for another day, but I would caution you against keeping a 'square' architecture.

Reply to
Trendkill

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.