01-20-2016 05:12 PM - edited 03-08-2019 03:29 AM
Hello,
See attached. We're planning on migrating our client from HP Procurve switches to Cisco switches/routers. Here's the current and new topologies:
Current topology:
- Headquarters:
- hp Procurve Switch(hp-Core): This is the Core switch which links to 13 remote locations via point-to-point L3
- Static routing is in use
- There 10 servers(ESX, Vmware, or others) that are uplinked to this Core switch
New topology:
- Headquarters:
- Cisco C4500-X switch(Cisco-Core): This will be the new Core switch and will replace the role of the hp Procurve, so all 13 remote locations will be linked to this Core switch.
- OSPF routing is configured(this sw is the backbone Area 0)
- Cisco C4500-X switch(Cisco-Dist): This will be the distribution switch uplinked to the Core switch via a Trunk. All 10 servers will be uplinked to this switch. OSPF is enabled on this sw this is in area 1
A consulting engineer recommended the following migration plan and I wanted to see someone has had an en experience migrating from HP to Cisco and if they see any issues with this plan or have any other recommendations.
Recommended migration plan:
- Since the hp-Core doesn't have OSPF enabled, the Cisco-Core will be linked to hp Core via L3, enable OSPF on hp-Core, and add the default information originate always statement,
- Uplink the new Cisco-Dist to the hp-Core via L2(Trunk), and then start to moving the servers to the new Cisoc-Dist switch.
Much appreciated.
Best, ~zK
Solved! Go to Solution.
01-20-2016 06:40 PM
Correct on your options.
If you have a decent outage you could move them all at once and if it doesn't go to plan you could move them back.
Make sure you clear arp entries on HP once you have moved them just in case.
Or you can do it a server at a time, up to you really.
In terms of routing it sounds like you are not running a dynamic routing protocol between the HP and remote sites.
If this is the case then do the remote sites just use a static default route pointing to HP ie. no local internet at sites.
And then presumably the HP has static routes for each remote site ?
If so when you migrate a link you can move the HP IP to the new core switch but then you have to add routes to the new core switch for the remote sites subnets and make sure they are redistributed into OSPF so the HP switch knows about them.
Once you have migrated to the new 4500-X core you the would not need to redistribute into OSPF because your core switch will be sending a default route to the distribution switch I assume.
It's late where I am now but if you have any more questions Masoud, if he is around, can more than cover anything I could so I'm sure he'll help out.
Jon
01-20-2016 07:01 PM
I believe you have covered everything. Just one thing I need to know. Do ESX servers have different ranges of IP? I mean is there any interface VLAN shared between ESX servers?
Masoud
01-20-2016 05:28 PM
If each 4500-X is in a different OSPF area then why are you using a trunk between the two switches ?
I would have thought it would be a L3 link ?
Is the distribution switch going to be doing routing between vlans ?
Can you move all the servers at once or do you need to do a phased migration ?
Jon
01-20-2016 05:56 PM
Hello Jon,
Probably, distributed switch will be the gateway for servers and there will be an interface vlan between distribution switch and core. That interface VLAN will be in area 1. But as you mentioned, a L3 interface would be more efficient. It would cut the L2 traffic on distributed switch
Masoud
01-20-2016 05:58 PM
Hi Masoud
Agreed, just trying to work out why the need for a trunk link between the new switches.
Also trying to work out why a trunk link between the distribution switch and the HP because unless the servers need to be reconnected at different times I would personally just move them altogether and then advertise the server IP subnet to the core.
But it's late and I may be missing something :)
Jon
01-20-2016 05:57 PM
Yes, the 4500-Xs are in different OSPF areas. Correction, the link between the Dist and Core is via L3 not a Trunk.
Yes, the dist sw is going routing between the different VLANs and routing between all VLANs is working properly(in the Lab)
We need to move the servers all once(that's one server at a time after testing connectivity, switching, and routing). We're not sure why we even need to uplink the new Cisco Dist to the hp-core via a trunk?? Can't we just bypass this step and jmove the servers to the new Cisco-Dist sw w/o having to uplinking the new Cisco-Dist to the hp-Core?
Thanks, ~zK
01-20-2016 06:01 PM
Yes you can and I just said the same thing in my last post :)
I would simply move them all and advertise server IP subnet from distribution switch.
I cannot see what the trunk link between the distribution switch and the HP switch gives you.
Did the consultant say what it was for ?
Jon
01-20-2016 06:04 PM
Just reread your post.
If you are moving them one at a time and testing connectivity you need the trunk link because the HP will see the server IP subnet as local and so will not route to the servers you have migrated.
Apologies for the misleading information in my other post.
Jon
01-20-2016 06:21 PM
So, it sounds like there're two options for the L2 migration:
1- Move all servers at the same time to the new Cisco-Dist sw, in this case, we won't have to link the Cisco-Dist to the HP via a trunk
2- Or, move one server at a time and in this case, we will have to link the Cisco-Dist to the HP via a trunk.
And there is only 1 option for the L3/Routing migration;
1- Enable OSPF on HP and add the default information originate always statement
2- Link Cisco-Core to HP using an L3
Last question, do we need to enable OSPF on all remote L3 hp switches?
Much appreciated.
~zK
01-20-2016 06:40 PM
Correct on your options.
If you have a decent outage you could move them all at once and if it doesn't go to plan you could move them back.
Make sure you clear arp entries on HP once you have moved them just in case.
Or you can do it a server at a time, up to you really.
In terms of routing it sounds like you are not running a dynamic routing protocol between the HP and remote sites.
If this is the case then do the remote sites just use a static default route pointing to HP ie. no local internet at sites.
And then presumably the HP has static routes for each remote site ?
If so when you migrate a link you can move the HP IP to the new core switch but then you have to add routes to the new core switch for the remote sites subnets and make sure they are redistributed into OSPF so the HP switch knows about them.
Once you have migrated to the new 4500-X core you the would not need to redistribute into OSPF because your core switch will be sending a default route to the distribution switch I assume.
It's late where I am now but if you have any more questions Masoud, if he is around, can more than cover anything I could so I'm sure he'll help out.
Jon
01-20-2016 07:01 PM
I believe you have covered everything. Just one thing I need to know. Do ESX servers have different ranges of IP? I mean is there any interface VLAN shared between ESX servers?
Masoud
01-20-2016 08:04 PM
I will have to confirm with the customer but I think there are 4 different VLANs used by the ESX servers.
~zK
01-20-2016 08:07 PM
If ESX servers share interface VLAN, you may have problem with moving once at a time so make sure of that.
Masoud
01-20-2016 08:12 PM
I will check with the client. Making an assumption here, if all ESX servers share the same SVI, do you propose to move them ALL at once?
~zK
01-20-2016 08:22 PM
Your consultant has considered a trunk link between the switches. I assumed that you are going to remove interface vlan from HP and create it on the distribution switch one by one. In this way, you can move the server once at a time if servers do not share interface VLAN. But if they share interface VLAN, it may cause problem so I suggest moving at the same time.
However, talk to your consultant to make sure. I might be missing something.
Masoud
01-20-2016 08:27 PM
That makes sense.
Thanks so much for all your help.
Best, ~zK
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