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.
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:
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.
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.