cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2567
Views
30
Helpful
20
Replies

Need to Transition to a new core Cisco L3 switch, but need smooth transition. Possible, with no down time?

StillMaKiniT
Level 1
Level 1

I'm replacing our old Cisco L3 core switch with a newer one.  As the outfit I'm involved with can't have ANY down time, I'm looking for a smooth transitional method involving little or none.  I'm not as concerned with the other branch switches it interconnects everything with, as I am with the ASA 5525 its using to connect to the WAN side of things.  Normally I'd just do an after hours swap: confirm environment compatibility and the config's, flush the ARP and then move on.  But keeping the other one connected while activating the new one with similar IP structures and other goodies makes me nervous to say the least.  There are numerous VLAN's, Trunks and potential IP issues that could cause problems. I do have an available spare port on the ASA.  I was considering connecting the new Cisco switch while leaving the one it's replacing still servicing the environment. Is it possible to do this and eventually ween off of the old switch even with the similar configuration between them?  I'm concerned about IP conflicts and other unknowns.         

20 Replies 20

Hello


@meisemann7 wrote:

Makes sense, and probably why my downstream L2 access switches can't reach the 'default gateway' when I transfer routing to the new L3 switch, cause the MAC isn't matching.  How long does the 'learning' process take usually if I didn't 'simulate' it. 

 


Its hard to say why you experienced the incomplete arp, but it does suggest routing wasn’t correct in some way- Did you try manually flushing the arp and mac tables of the switches.

Also can you elaborate on the process you performed when you made the L3 change
Did you migrate all L3 or just certain SVI's, did you use an existing L2/l3 svi for the interconnection between old/new or a new temporary one, and as you are performing static routing did you update it to accommodate any new L3 interfaces.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Paul,

My apologies to you also for my slow response.  I am getting ready for my next outage attempt.  I have reduce the default timeout for the ARP entries on my interfaces, something like "

Device(config)# interface GigabitEthernet0/0/0

Arp timeout 10 "

so that should help.  I guess I will need to do this on my connected L2 switches also.  To answer one of your questions, I am trying to migrate 'all' of the SVIs on a given L3 core.  Also, yes I have an old L3 connected switch that is just doing the routing right now and everything is running fine on the connected (new L3 switch but logically just running as an L2 switch) switch.  It is just when I enable routing on the new L3 switch, remove the trunk between the 2, and change the uplink static routing port that things seem to break. I feel more confident it will work now with the ARP timeouts much lower than 4 hours. 

Thanks

Thanks,
Matt

Hello Matt,

>> How long does the 'learning' process take usually if I didn't 'simulate' it.

 

On Cisco network devices  ( non Nexus) the default ARP timeout is 4 hours

 

if the L2 switch management SVI remains up during the new L3 switch insertion  ( it is enough to have at least one L2 port access or trunk in STP forwarding mode ) the L2 switch will keep the old entry until it expires in the moment it sends out a new ARP request for the default gateway address it will learn the new MAC address.

You can reduce this time on network devices by using

clear arp    <IP-entry>

this will delete the current entry and will force the device to send out an ARP request.

The real challenge is the possibly high number of end user devices (PCs and so on)

 

Hope to help

Giuseppe

Giuseppe,

 

Thanks and sorry for my slow response.  I don't look at the community everyday, my fault.  So for my L2 devices hanging off the L3 core switch, next time I try the outage, I will try to reduce the ARP time with a command like

 

"Clear arp [all | dynamic | permanent | static] {ip addr]" 

 

I sadly guess I need to go to each L2 switch and do this.  

Thanks.

Thanks,
Matt

Giuseppe,

Recently, on my new L3 switch, I have been adding the MAC addresses in using your method above, from the old core to the new core switch.  The commands themselves are fine except on the Cat 3650 it is 'mac-address' and not 'mac' but the real problem seems to be that maybe I have to wait until the outage to do this command.  Even though the SVIs are in a down state, changing the MAC on the down SVIs somehow causes connectivity issues for people in those VLANs.  Maybe I need to wait until the outage to add in these MAC addresses?  

 

Thanks,
Matt

Hello
I would say it isnt needed but it saves on all hosts relearning the L3 gateway arp address when you migrate - however if your currently using a first hop redundancy such as hrsp and you again use it on the new core then as long as it the same hrsp version you wouldn't need to do this as the svi,s hrsp vip mac address would be the same on old and new core.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking for a $25 gift card