Migration of SVI causes random connectivity issues

[clive.hodgetts]

Hi! So I have a really weird issue since I migrated an SVI from my current Core switch to a new Catalyst switch. The back story is, we have physically migrated all edge stacks from our current core to the new core. The SVI's for the clients/phones etc remain on the current core. No issues at this point. However, when we move an SVI from the current core to the new core we see seemingly random connectivity from various points in the network to any device on the migrated SVI. 

Testing, we have completed basic testing. From the NEW core switch we can ping any device on the migrated VLAN/SVI. As mentioned, all edge devices and host now connect directly into the new core switch, so we are actually moving the SVI closer to the clients. We can traceroute ok to some of the clients but not all. Where there are several clients on one edge stack, we can traceroute ok to some but not others on the same stack. Now weirdly, although we can ping all devices, the traceroute from the new core is failing even when we source from the same VLAN/SVI. I have never observed a ping success and a trace fail when sourcing from the same SVI which is directly connected to the hosts! There is no routing occurring as we source from the local SVI and no intermediate switch/router/firewall which might be blocking the traceroute as the topology is core to edge stack (with port-channel) and host directly connected to an edge port

[Joseph W. Doherty]

Change in SVI MAC?

[Richard Burts]

My first thought was similar to Joseph that it might be something about the MAC address, and I was thinking more specifically about the possibility that some devices in their arp table still have the MAC of the original switch. Then I think about the part of the post that ping and traceroute sometimes get different results. And that would not be consistent with incorrect MAC address. This leads me to wonder if there is something in the path that is examine traffic and doing some type of filtering (some type of security device?).

[clive.hodgetts]

Hi, I will post a topology later today but really there is nothing in the path. In essence, we have a layer 3 switch which is configured (SVI) and is acting as the gateway for the affected hosts. This core switch has a direct layer 2 connection (2 port port-channel) into the edge switch which in turn has the hosts directly connected. We test traceroute from the core, sourcing from the local SVI which fails for some host but not all. There is no intermediate layer 3 device between the gateway and the host other than a standard layer 2 cisco 3750. As unlikely as it is we are going to disable one of the links on the port-channel today to see if there is anything in that as it is the only physical/logical link between the gateway and the host.

Just as a reminder, when the SVI is configured on another layer 3 switch, which it was until now, it worked as expected. The layer 3 switch was one more hop away than where it is configured now.....makes little sense to me!