Changing cores from HP to Cisco

[Michael King]

I have a site that my company taken over.  It has two HP 5406's being used as cores, with a hodgepodge of HP2510 and other model switches being used as access switches.  All the VLANS are terminated on the 5406, using VRRP, with the access switches trunked up to the cores.

We are in the planning process to convert them to our corporate standard design, using 3750X's and 2960's, with a similar design as the HP, using HSRP. (Vlans terminated on core, access layers trunked up to cores.  We will be using the same VLAN id's as well)

Unfortunately, I can't get a maintenace window to do the migration, and for internal reasons, it has to be completed in the next 30 days.  On the plus side all the servers are clustered, on the downside i'll be doing this on a live production network with users on it. (Yes, I know)

For a migration plan, we're thinking the following:

Build new network (there is enough spare fiber)

Pick a port on a 3750x and a port on the 5406, and block spanning tree on it.  (We want to prevent a spanning tree re-calculation when we connect, or disconnect the network, the HP has a stp cost of 0, so it's going to win)

Connect both cores together with a trunk port carring all the vlans

Move all end user devices and clustered servers.

sever link and power down old network.

Now here's the questions.   I know it's bad to have duplicate addresses on the network.  I know it's even worse when the duplicate is the default gateway.

Here's the thing.  I have lab'ed this up in my test lab, and other than a few duplicate IP error messages on the consoles of the cores, Everything continued to work, I experianced no loss of connectivity (other when the devices were disconnected and being moved) on the end devices, and they were able to communicate across both cores, and route between vlans.

Am I overlooking something here?  I had an elaborate plan to enable VRRP on the Cisco and migrate that way, but it was extermetly labor intensive, completely changing the HP core, and removeing HSRP on the cisco, and later (I still hadn't figured that part out yet) switching back to HSRP.  On a whim I just connected the cores with no config changes (other than the spanning tree block) fully expecting the network to melt down.  Imagine my suprise when I was able to complete my "mock" migration without any hiccups.

I can rationalize why everything works.  We trunked all the VLAN's over, so each router can route to all VLANs, so the routers never "actually" talk to each other, so the duplicate IP doesn't seem to come into play.

Agan, is there anything I'm missing?

[Rolf Fischer · Accepted solution]

Hello Michael,

I'd like to start with STP.

... and block spanning tree on it

I don't think this is necessary. As far as I know, the ProCurve switch doesn't support (R)PVST+, so on the Cisco side only the STP instance of VLAN 1 will interact with the HP's ST. And even in VLAN 1 I don't expect a ST recalculation (with rapid-PVST not even a TC) because when the Cisco 3750 becomes root bridge, the ST topology in the Cisco LAN doesn't change at all.

Our approach for such scenarios is to interconnect old and new cores via access-ports for every VLAN which is needed in both worlds. This avoids problems with the Cisco proprietary per-VLAN BPDUs, gives more control (portfeatures) and you can change VLAN-IDs if you need or want to. Of course, depending on the number of VLANs you need a bunch of ports ...

First hop redundancy:

The duplicate IP address is detected by (Gratuitous) ARP:

HSRP: Vl1 Redirect adv out, Active, active 1 passive 0
HSRP: Vl1 Grp 1 Redundancy "hsrp-Vl1-1" state Standby -> Active
HSRP: Vl1 Grp 1 Hello  out 192.168.1.2 Active  pri 100 vIP 192.168.1.1
IP ARP: sent rep src 192.168.1.1 0000.0c07.ac01,
 dst 192.168.1.1 ffff.ffff.ffff Vlan1
IP ARP: sent rep src 192.168.1.1 0000.0c07.ac01,
 dst 192.168.1.1 0100.0ccd.cdcd Vlan1
IP ARP: rcvd rep src 192.168.1.1 0000.5e00.0101, dst 192.168.1.1 Vlan1
%IP-4-DUPADDR: Duplicate address 192.168.1.1 on Vlan1, sourced by 0000.5e00.0101
IP ARP: Gratuitous ARP throttled.
IP ARP: 192.168.1.1 added to arp_defense_Q
HSRP: Vl1 API arp for proto, 192.168.1.1 is active vIP
IP ARP: rcvd rep src 192.168.1.1 0000.5e00.0101, dst 192.168.1.1 Vlan1
IP ARP: Gratuitous ARP throttled.

However, the cores each will only provide ARP information for their own entry and reply to ARP requests with their particular virtual IP. So connectivity between the two worlds will become a game of luck. I wouldn't rely on that.

Hope that helps

Rolf