04-29-2013 06:43 AM - edited 03-07-2019 01:05 PM
All-
We recently purchased 2 Cisco 6500 series switches (with Sup 2T). These switches will be replacing our old 2 6500 series switches (with Sup 720).
We have 70 vlans and 90+ closet switches (2900) connecting the core switches
We have 2 WLC connected to the core switch. We also have a 1 x 1 connection to a VSS switch which in turn connects to our Server Co-Location data center utilizing IPSec & GRE tunnel to connect to our Server Co-Location data center.
Our routing protocol is EIGRP.
Our VTP domain at Server Co-Location is separate from our location “A” campus. I was wondering what is the best way to migrate our Core switches at location “A” campus.
The requirement is we would like to replace these switches with minimum downtime.
Ds
Solved! Go to Solution.
04-29-2013 06:59 AM
Hi,
When moving from 720 to 2T, the biggest challenge is QOS. The QOS architecture for Sup-2T is different from 720. So if you have QOS deployed, you need to read below document:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-652042.html
If you have HSRP or VRRP on your older 6500, you can simply change one device at the time.
replace the stand-by VRRP or HSRP first. Then fail over you HSRP or VRRP from the old switch to the new one and then replace the second old switch and bring it up as stand-by.
You defiinatly want to do all of these during an outage window.
Also, make sure all you old cards are comparable with the new Sup.
HTH
05-02-2013 01:18 PM
Never been bitten by a SUP swap out but did have an issue with a chassis swap out. Was upgrading from a 6509 chassis to a 6509-VE chassis and was also running GLBP. Shut down the old 6K, racked the VE and put the blades in the same slot numbers and booted up with no issues. What we didn't realize is the base MAC addresses are based off the chassis, and when GLBP saw a different MAC it assumed this was AVF #3. There is a 4 hour GLBP AVF timer that removed AVF #1, leaving #2 and #3. Around 4 hours after the bootup our downstream WISMs stopped passing traffic. Their SVI were anchored on the 6K distribution and GLBP was used to handle first hop redundancy. Turned out the WISM has holding the old MAC address of the dead forwarder in memory and would not give it up, thus we were black holed. Could not clear ARP on the WLC and had to reboot the unit to resolve, and this reboot occurred after our downtime window because of the 4 hour AVF timer, and we had already gone home thinking mission accomplished,
Discovered WLC 6.x code did not handle GLBP properly and is corrected in 7.x. We had 9 more chassis to swap out and to avoid this issue, we would shut down the SVI on the chassis that was getting replaced 4 hours before the downtime, that way GLBP aged out the dead AVF gracefully and when we brought up the new VE chassis, everything worked OK and the WISM did not have any problems. We never saw any issues with PCs or any other devices, just the controllers running 6.x code.
04-29-2013 06:59 AM
Hi,
When moving from 720 to 2T, the biggest challenge is QOS. The QOS architecture for Sup-2T is different from 720. So if you have QOS deployed, you need to read below document:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-652042.html
If you have HSRP or VRRP on your older 6500, you can simply change one device at the time.
replace the stand-by VRRP or HSRP first. Then fail over you HSRP or VRRP from the old switch to the new one and then replace the second old switch and bring it up as stand-by.
You defiinatly want to do all of these during an outage window.
Also, make sure all you old cards are comparable with the new Sup.
HTH
04-29-2013 10:45 AM
Reza-
Thanks for the head-up on QoS and I like your idea of using HSRP & VRRP and migrating 1 layer 3 interface at a time. But we are running GLBP on 6500 right now. I am assuming we should be able to do the same thing what you explained above with GLBP as well?
Ds
04-29-2013 10:53 AM
Hi DS,
GLBP should work the same way, as members of a GLBP group select one router as the active gateway and the other group members are backup devices.
Good Luck
HTH
04-29-2013 10:54 AM
Thanks!!!
05-02-2013 01:18 PM
Never been bitten by a SUP swap out but did have an issue with a chassis swap out. Was upgrading from a 6509 chassis to a 6509-VE chassis and was also running GLBP. Shut down the old 6K, racked the VE and put the blades in the same slot numbers and booted up with no issues. What we didn't realize is the base MAC addresses are based off the chassis, and when GLBP saw a different MAC it assumed this was AVF #3. There is a 4 hour GLBP AVF timer that removed AVF #1, leaving #2 and #3. Around 4 hours after the bootup our downstream WISMs stopped passing traffic. Their SVI were anchored on the 6K distribution and GLBP was used to handle first hop redundancy. Turned out the WISM has holding the old MAC address of the dead forwarder in memory and would not give it up, thus we were black holed. Could not clear ARP on the WLC and had to reboot the unit to resolve, and this reboot occurred after our downtime window because of the 4 hour AVF timer, and we had already gone home thinking mission accomplished,
Discovered WLC 6.x code did not handle GLBP properly and is corrected in 7.x. We had 9 more chassis to swap out and to avoid this issue, we would shut down the SVI on the chassis that was getting replaced 4 hours before the downtime, that way GLBP aged out the dead AVF gracefully and when we brought up the new VE chassis, everything worked OK and the WISM did not have any problems. We never saw any issues with PCs or any other devices, just the controllers running 6.x code.
05-03-2013 07:38 AM
Thanks for the heads up Darren !!! I am sure we would have the same problem but now we know what to do.
Ds
07-18-2013 07:37 AM
We were able to migrate from old 6500 (Sup 720) to the new 6500 (Sup 2T). Everything is working fine. Except some of the applications who uses oracle in the backend are having frequent disconnects.
Is anyone aware of the known problems?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide