Below is only an example. We are migrating from an Arista Network to Cisco Nexus Network, but it could also be HP or any other Vendor. We are running BGP on both networks. There are dual MPLS WAN Routers running BGP and a Pair of Firewalls in an Active/Passive configuration running BGP.
1. Inventory and Documentation
Gather details about the devices (serial numbers, versions), configuration files, and other network data like IP addresses, VLAN IDs, BGP AS numbers, route-maps, prefix-lists, etc. Also, document your network topology for reference.
2. Configuration Translation
Each vendor has its way of implementing protocols and features. In Arista EOS, the command line is similar to Cisco, but there are still differences, especially in advanced features.
For BGP, key items to translate include:
• Neighbor configurations
• Route-maps, prefix lists, and filter lists
• Redistribution policies
• BGP attributes such as weight, local preference, MED, etc.
For SVIs, remember to translate associated settings such as IP addresses, HSRP/VRRP settings, and any ACLs or QoS settings applied to the SVIs.
3. Prioritize VLAN Migration
Prioritize VLANs based on their criticality and potential impact. This would require understanding which services rely on which VLANs, their load, and their downtime tolerance.
4. Scheduling
It would be best to plan the migration during a maintenance window when the network load is at its lowest. This might mean night hours or weekends.
5. Configuration Preparation
Prepare the Nexus switches with the translated configuration.
For instance, a simple BGP configuration on Nexus would be:
router bgp 65001
neighbor 192.0.2.1 remote-as 65002
address-family ipv4 unicast
neighbor 192.0.2.1 activate
network 203.0.113.0/24
exit-address-family
6. Perform the Migration – Layer 2 Scenario
6.1 Start by replacing the Core/Distro switches with Nexus switches. Configure the Layer 2 Port Channel between the cores, allowing all VLANs across it:
interface port-channel1 switchport switchport mode trunk switchport trunk allowed vlan all interface EthernetX/Y switchport mode trunk channel-group 1 mode active
(Note: Replace `EthernetX/Y` with the appropriate interface)
6.2 Next, drain traffic from each ToR switch, migrate the switch, and shift the traffic back. Adjust BGP attributes to make routes less preferred and drain the traffic.
6. Perform the Migration – Layer 3 Scenario
6.1 Start by replacing the Core/Distro switches with Nexus switches. Configure the Layer 3 Port Channel between the cores, creating a point-to-point subnet and enabling BGP on the link:
interface port-channel1
no switchport
ip address 192.0.2.1/30
interface EthernetX/Y
no switchport
channel-group 1 mode active
router bgp 65001
neighbor 192.0.2.2 remote-as 65001
address-family ipv4 unicast
neighbor 192.0.2.2 activate
exit-address-family
(Note: Replace `EthernetX/Y` with the appropriate interface and `192.0.2.1/30` with the appropriate IP and subnet)
6.2 Next, drain traffic from each ToR switch, migrate the switch, and shift the traffic back. Adjust BGP attributes to make routes less preferred and drain the traffic.
7. Validation, Testing, and ARP Flush
After each switch migration, run validation checks:
• `show ip bgp summary` for BGP status
• `show interfaces status` for interface status
• `show ip route` to check routing
• `show hsrp` to validate HSRP operation
Next, flush the ARP cache on connected devices. On most Cisco devices, the command is `clear arp-cache`.
Then, perform the tests:
• Network connectivity tests (ping, traceroute)
• Redundancy tests (shutdown of interfaces and checking traffic flow)
• Service-level tests (checking application functionality)
8. Contingency Planning
Backup Arista configurations using `copy running-config startup-config` on each switch. These can be reapplied if you need to rollback.
Keep redundant connections to the old switches active during migration as a quick fallback path.
The Layer 3 approach is generally a better practice for a collapsed Core/Distro layer design, as it allows better resiliency and reduces the risk of loops and large broadcast domains. However, the Layer 2 approach may be more straightforward and quicker, so the choice depends on your network’s specific requirements and constraints.
NOTE:
Deciding whether to configure your inter-core link as Layer 2 or Layer 3 depends on the specific requirements and design principles of your network.
Layer 2 Port Channel: If you decide to go with a Layer 2 Port Channel, you would effectively be extending all VLANs between the two cores. This approach allows for ease of VLAN extension across the network and it’s typically simpler to set up. However, this can create a larger broadcast domain and may lead to potential issues with loops if STP is not correctly configured.
Layer 3 Port Channel: On the other hand, a Layer 3 Port Channel would involve routing between the cores. This approach isolates broadcast domains, helps with load balancing, and provides improved resiliency. It is typically a better practice for Core/Distribution layers to be Layer 3 to take advantage of these benefits. However, this design would require more advanced configuration and a more careful approach to IP address management.
Given we are using BGP throughout the network, and considering the Cisco best practices for collapsed Core/Distribution layer designs, it’s recommended to use a Layer 3 Port Channel between your core switches. This would provide better isolation and resiliency for your core network, taking full advantage of the routing capabilities of the Cisco Nexus switches.
You would set up a point-to-point subnet between the core switches and enable routing protocols on these interfaces. This will allow BGP to effectively distribute routes between the core switches and rest of the network.