Overview
NDFC’s brownfield deployment approach streamlines the migration of existing VXLAN EVPN fabrics, previously set-up via CLI or custom scripts. This transition empowers centralized management through a user-friendly web interface, simplifying configuration tasks, promoting consistency across the fabric, and facilitating troubleshooting efforts. The migration process involves fabric discovery, configuration import from the existing environment, and potential adjustments to leverage NDFC’s advanced features.
This blog post showcases the brownfield VXLAN EVPN fabric import process using NDFC version 12.1.3b. It’s important to note that some features might have slight variations. For the most up-to-date information specific to your NDFC version, refer to the official Cisco documentation. However, the core steps outlined here will provide a solid foundation for understanding NDFC’s brownfield import capabilities.
For prerequisites, guidelines, and limitations, please refer to the document available at the following link:
The key steps to migrate to NDFC can be broken down as follows:
- Verification of existing fabric – Before starting the migration process, it’s essential to conduct a thorough assessment of your current VXLAN EVPN fabric’s health and configuration. Confirm that all switches are operational, with established BGP peering, functional vPCs, properly configured interfaces, operational VXLAN tunnels, and consistent configurations across the switches.
- Fabric creation – The “Data Center VXLAN EVPN Template” in NDFC simplifies the configuration process by setting up basic fabric parameters such as the BGP AS number, the underlay routing protocol (typically OSPF or ISIS), etc.
- Switch discovery, addition, and fabric migration to NDFC – NDFC offers tools to discover existing VXLAN EVPN switches within your fabric. You can initiate discovery by specifying a seed IP address. Once discovered, NDFC enables you to add the switches to the fabric management. This process may require configuration adjustments on the switches themselves to allow the NDFC controller to manage them effectively.
- Verification and Validation – Ensure all switch connections and VXLAN tunnel information are accurately reflected, you can leverage your existing monitoring and logging tools alongside NDFC to validate various aspects of your fabric, including BGP peering, EVPN route exchange, and overall fabric health.
VxLAN EVPN Fabric Topology
The blog linked below serves as a comprehensive configuration guide for the existing VxLAN EVPN Fabric topology, along with the corresponding CLI configuration. This documentation is instrumental in demonstrating the brownfield VxLAN EVPN Fabric import process to NDFC.
deliabtech.com/data-center/vxlan-evpn-fabric/
By utilizing this documentation, users can gain insights into the current fabric configuration and follow the step-by-step process for importing it into NDFC. This facilitates a smooth transition to NDFC management, enabling centralized control and improved operational efficiency of the VXLAN EVPN fabric.
The topology comprises Nexus 9K switches, featuring dedicated border leaves and two pairs of vPC switches for host connectivity.
Verification of Existing Fabric
Before initiating the migration, it’s crucial to verify the health and configuration of your existing VXLAN EVPN fabric thoroughly. Ensure the following:
- Switch Functionality: Verify that all switches in the fabric are functioning correctly and are accessible.
- Routing: Pre-configuration checks are crucial. We need to confirm proper underlay routing configuration and functionality. Additionally, verify established BGP peering sessions between all spine and leaf switches, and any relevant external devices.
- vPC: Verify that virtual PortChannels (vPCs) are operational, consistent, healthy and configured correctly, if used in your fabric design.
- Interface Configuration: Ensure that all required interfaces, including uplinks and access ports, are configured properly and are in the desired state.
- VXLAN Tunnels: Verify the operational status of VXLAN tunnels, which are essential for overlay network connectivity.
- Configuration Consistency: Ensure that configurations are consistent across all switches in the fabric. This includes consistency in VLAN assignments, VRF configurations, VXLAN settings, and any other relevant parameters.
By conducting a thorough verification of these aspects, you can identify any potential issues or discrepancies in your existing fabric configuration before proceeding with the migration to NDFC and ensure a smoother transition.
Using a leaf switch (L-1) as a sample for verification of the existing fabric.
### Check interfaces and underlay routing
L-1# sh ip int brief
IP Interface Status for VRF "default"(1)
Interface IP Address Interface Status
Vlan3600 10.10.10.45 protocol-up/link-up/admin-up
Lo0 10.10.100.13 protocol-up/link-up/admin-up
Lo1 10.10.100.113 protocol-up/link-up/admin-up
Eth1/1 10.10.25.18 protocol-up/link-up/admin-up
Eth1/2 10.10.25.22 protocol-up/link-up/admin-up
L-1# sh vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 2
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Enabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled, timer is off.(timeout = 360s)
Delay-restore status : Timer is off.(timeout = 150s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
Virtual-peerlink mode : Disabled
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ -------------------------------------------------
1 Po10 up 1,20,30,40,50,2000,3600
L-1# sh ip ospf neighbors
OSPF Process ID UNDERLAY VRF default
Total number of neighbors: 3
Neighbor ID Pri State Up Time Address Interface
10.10.100.14 1 FULL/ - 2d00h 10.10.10.46 Vlan3600
10.10.100.1 1 FULL/ - 2d00h 10.10.25.17 Eth1/1
10.10.100.2 1 FULL/ - 2d00h 10.10.25.21 Eth1/2
### Show BGP, NVE and VxLAN Tunnels
L-1# sh bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.100.13, local AS number 65125
BGP table version is 761, L2VPN EVPN config peers 2, capable peers 2
46 network entries and 91 paths using 13024 bytes of memory
BGP attribute entries [61/10492], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [10/40]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.100.1 4 65125 3157 2932 761 0 0 2d00h 26
10.10.100.2 4 65125 3154 2932 761 0 0 2d00h 26
L-1# show int nve 1
nve1 is up
admin state is up, Hardware: NVE
MTU 9216 bytes
Encapsulation VXLAN
Auto-mdix is turned off
RX
ucast: 39888 pkts, 3905980 bytes - mcast: 18185 pkts, 6189306 bytes
TX
ucast: 36464 pkts, 14219344 bytes - mcast: 0 pkts, 0 bytes
L-1# sh nve vni summary
Codes: CP - Control Plane DP - Data Plane
UC - Unconfigured
Total CP VNIs: 5 [Up: 5, Down: 0]
Total DP VNIs: 0 [Up: 0, Down: 0]
L-1# show mac address-table
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
C 20 6efe.94ff.d9f7 dynamic 0 F F nve1(10.10.100.143)
* 30 5254.0005.5fb3 dynamic 0 F F Eth1/10
C 40 5254.000a.9126 dynamic 0 F F nve1(10.10.100.143)
* 2000 0200.0a0a.6479 static - F F Vlan2000
* 2000 0200.0a0a.648f static - F F nve1(10.10.100.143)
* 2000 5204.ee2d.1b08 static - F F nve1(10.10.100.115)
* 2000 5206.d4eb.1b08 static - F F Vlan2000
* 2000 520d.67a5.1b08 static - F F nve1(10.10.100.111)
* 2000 5214.adc0.1b08 static - F F nve1(10.10.100.116)
* 2000 5215.edeb.1b08 static - F F nve1(10.10.100.112)
+ 50 5254.000b.9a01 dynamic 0 F F vPC Peer-Link
### Host verification (ping from one host (10.10.40.10) to internal and external hosts (10.10.30.10, 10.10.50.10 & 172.16.1.1)
cisco@S-3:~$ ping 10.10.30.10
PING 10.10.30.10 (10.10.30.10): 56 data bytes
64 bytes from 10.10.30.10: seq=0 ttl=62 time=31.941 ms
64 bytes from 10.10.30.10: seq=1 ttl=62 time=24.428 ms
64 bytes from 10.10.30.10: seq=2 ttl=62 time=19.818 ms
64 bytes from 10.10.30.10: seq=3 ttl=62 time=36.598 ms
64 bytes from 10.10.30.10: seq=4 ttl=62 time=21.841 ms
^C
--- 10.10.30.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 19.818/26.925/36.598 ms
cisco@S-3:~$ ping 10.10.40.10
PING 10.10.40.10 (10.10.40.10): 56 data bytes
64 bytes from 10.10.40.10: seq=0 ttl=64 time=0.067 ms
64 bytes from 10.10.40.10: seq=1 ttl=64 time=0.547 ms
64 bytes from 10.10.40.10: seq=2 ttl=64 time=0.056 ms
64 bytes from 10.10.40.10: seq=3 ttl=64 time=0.076 ms
64 bytes from 10.10.40.10: seq=4 ttl=64 time=0.067 ms
^C
--- 10.10.40.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.056/0.162/0.547 ms
cisco@S-3:~$ ping 10.10.50.10
PING 10.10.50.10 (10.10.50.10): 56 data bytes
64 bytes from 10.10.50.10: seq=0 ttl=62 time=19.125 ms
64 bytes from 10.10.50.10: seq=1 ttl=62 time=26.103 ms
64 bytes from 10.10.50.10: seq=2 ttl=62 time=14.744 ms
64 bytes from 10.10.50.10: seq=3 ttl=62 time=23.825 ms
64 bytes from 10.10.50.10: seq=4 ttl=62 time=34.475 ms
^C
--- 10.10.50.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.744/23.654/34.475 ms
cisco@S-3:~$ ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: seq=0 ttl=252 time=59.062 ms
64 bytes from 172.16.1.1: seq=1 ttl=252 time=34.497 ms
64 bytes from 172.16.1.1: seq=2 ttl=252 time=53.988 ms
64 bytes from 172.16.1.1: seq=3 ttl=252 time=98.455 ms
64 bytes from 172.16.1.1: seq=4 ttl=252 time=40.400 ms
^C
--- 172.16.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 34.497/57.280/98.455 ms
Upon successful fabric health verification, proceed to step 2 – Fabric creation.
Fabric creation
1. LAN -> Fabrics and Actions -> Create Fabric
LAN -> Fabrics
Actions -> Create Fabric
Enter Fabric Name, then click ‘Choose Fabric’ … available list of fabric templates displayed on a ‘Select Type of Fabric’ window.
Select ‘Data Center VXLAN EVPN’ template and click ‘Select’
Create Fabric by setting up the necessary fabric parameters
Create Fabric by setting up the necessary fabric parameters as indicated on the screenshots below
General Parameters
Ensure that the fabric configurations are in line with what is configured through CLI or scripts on the VxLAN EVPN fabric you are attempting to import into NDFC.
General Parameters of a Fabric (Check Section 4.1.1.2)
Always refer to the official Cisco NDFC documentation for detailed instructions and advanced configuration options.
Replication parameters
VxLAN fabrics utilize multicast replication in the underlay network to manage Broadcast, Unknown Unicast, and Multicast (BUM) traffic efficiently. Although ingress replication is an alternative method for handling BUM traffic within VxLAN fabric, it is generally considered less efficient. VxLAN relies on the underlay network to handle BUM traffic effectively, leveraging multicast routing protocols to replicate a single copy of the BUM traffic and forward it to all interested receivers within the same Layer 2 segment (VXLAN overlay).
Ensure that the fabric configurations are in line with what is configured through CLI or scripts on the VxLAN EVPN fabric you are attempting to import into NDFC.
Underlay Multicast Routing for VxLAN BUM Traffic
Replication configuration of a Fabric (Check Section 4.1.1.2)
vPC parameters
Cisco vPC (Virtual Port Channel) is a technology that allows you to create a single, logical Layer 2 link across two physical Cisco Nexus switches.
Ensure that the fabric configurations are in line with what is configured through CLI or scripts on the VxLAN EVPN fabric you are attempting to import into NDFC.
vPC configuration of a Fabric (Check Section 4.1.1.2)
Protocols
In Cisco NDFC (Nexus Dashboard Fabric Controller), the “Protocol” section when creating a VXLAN EVPN fabric plays a crucial role in defining the underlay routing protocol for the fabric. The specific details you might configure in the “Protocol” section can vary depending on the chosen routing protocol, under general parameters section.
Ensure that the fabric configurations are in line with what is configured through CLI or scripts on the VxLAN EVPN fabric you are attempting to import into NDFC.
Protocols configuration of a Fabric (Check Section 4.1.1.2)
Resources
In the Resources tab, you’ll find a summary of various fields related to the configuration of resources within the Cisco platform. While many of these fields are automatically generated based on Cisco recommended best practices, you have the flexibility to review and modify configurations as needed to align with specific requirements or existing configuration of the network environment.
Ensure that the fabric configurations are in line with what is configured through CLI or scripts on the VxLAN EVPN fabric you are attempting to import into NDFC.
Resources configuration of a Fabric (Check Section 4.1.1.2)
- If there are any other parameters under Advanced, Manageability, Bootstrap, Configuration Backup, and Flow Monitor tabs, please assign them accordingly. For this demonstration, no changes are made to the parameters on these tabs.
Click Save
Switch Discovery, Addition, and Fabric Migration to NDFC
Adding Switches
Once a VXLAN EVPN fabric is created and configured within NDFC, the next step is to add switches to the fabric. Before doing so, ensure that the switches are accessible from NDFC. Verify that you have the necessary credentials (username and password) to access each switches. This will be required when adding the switches to the fabric in NDFC.
Log to NDFC -> LAN -> Fabrics -> Select the Fabric
Under the VxLAN EVPN Fabric Overview go to Switches -> Actions -> Add Switches
On the ‘Switch Addition Mechanism’ page, ensure to provide the necessary information such as the seed IP, authentication protocols, and credentials (username and password) for accessing the switches. Since this is a brownfield deployment, leave the ‘preserve config’ attribute checked. Finally, submit the information by clicking the ‘Discover Switches’ button. This action will initiate the process of discovering the switches to the VXLAN EVPN fabric within NDFC.
Once the switches are discovered, they will be listed in the discover results section. This list will include details such as the switch name, serial number, IP address, model, version, and status. From this list, select the switches you wish to add to the VXLAN EVPN fabric. After selecting the desired switches, proceed by clicking the ‘Add Switches’ button located in the bottom right corner of the page. This action will initiate the process of adding the selected switches to the fabric within NDFC.
Please ensure that all the switches are added to the fabric before proceeding with the Brownfield import process
If errors occur, address the underlying issues on the fabric and repeat steps 2 and 3 until all switches are added successfully.
Verify all the switches are added and confirm the role of each switches are the right role, if not change to the right role ‘under the Fabric overview page, Switches -> Actions -> Set Role’.
Confirm all switches are set with the right role.
The vPC configuration is automatically retrieved from the switches when the vPC peer keep-alive is established through the management option. However, if a different network is used for vPC peer keep-alive, a vPC pairing must be done manually.
Recalculate and Deploy
At this step, all switches are imported, assigned the correct role, and set to migration mode.
Once you have confirmed the switch roles, vPC pairings, and any other configurations, navigate to the Fabric Overview page of the VXLAN EVPN fabric. From there, locate the ‘Actions’ dropdown menu at the top right corner of the page. Select the option to ‘Recalculate and Deploy’. Executing this action triggers the system to generate the configuration intent for the VXLAN EVPN fabric based on the design, switch states, roles, and inputs from the fabric creation process. It then compares this configuration with the existing VxLAN EVPN fabric configuration done through CLI or scripts.
Resolve any errors due to configuration inconsistencies on the fabric. This may involve correcting misconfigured parameters, addressing missing configurations, or ensuring alignment between the intended configuration and the actual state of the fabric.
Any errors or inconsistencies found during the migration process are reported in the fabric errors. The switches will remain in Migration mode until these errors are resolved. Once the errors are fixed, complete the migration process again by clicking on ‘Recalculate and Deploy’. This action triggers the system to generate the updated configurations and deploy them to the fabric.
While errors may seem intimidating initially, they are typically minor inconsistencies that are easily fixable. These errors can often be addressed through simple configuration adjustments or corrections. It’s important to carefully review the error messages and take appropriate actions to resolve them. Once addressed, the migration process can proceed smoothly.
Deploy the configuration intent
During the migration process, NDFC communicates with each switch in the fabric to retrieve the current running configuration. It then compares this configuration with the intended state maintained in NDFC, which was defined during the Fabric Creation step. This comparison may reveal configuration differences between the intended and existing states. To ensure consistency, it’s essential to review the pending configuration generated by NDFC. This involves verifying that the configuration lines are valid and align with the intended configuration. Any discrepancies or inconsistencies should be addressed before proceeding with the deployment to ensure a smooth transition and accurate representation of the fabric’s configuration.
Once you’ve verified that the pending configuration, generated from the fabric creation process, and the existing configuration are in line with the design, requirements, and current setup, you can proceed to deploy the pending configurations to the fabric switches. Simply click on the “Deploy All” button to initiate the deployment process. This action will push the configurations to the switches, ensuring that they align with the intended state defined in NDFC. Be sure to monitor the deployment process to ensure its completion without any issues or errors.
At this stage, NDFC has successfully imported the VXLAN EVPN Fabric, and the configurations have been deployed to the fabric switches.
Now that the VXLAN EVPN Fabric has been successfully imported into NDFC, you can manage it effectively using NDFC’s intuitive interface and powerful features. Enjoy the streamlined management, monitoring, and troubleshooting capabilities offered by NDFC for your VXLAN EVPN Fabric!
Verification and Validation
Following a brownfield import, NDFC’s robust monitoring capabilities are essential for validating your VXLAN EVPN fabric. It ensures accurate network representation by verifying switch connections and VXLAN tunnel information. To gain a comprehensive view, leverage your existing monitoring and logging tools alongside NDFC.
This combined approach empowers you to monitor critical aspects like BGP peering, EVPN route exchange, and overall fabric health. This proactive monitoring promotes optimal performance and reliability by enabling you to identify and address potential issues swiftly. Regular monitoring with NDFC and other tools ensures the fabric’s integrity and stability throughout its lifecycle.
Verifying application and system functionality after importing the fabric is a crucial step in ensuring the overall health and performance of the network. While NDFC focuses on monitoring network health, it’s essential to validate application-specific functionality to ensure everything is working as expected.
This verification step can be performed using existing application monitoring tools or through live tests conducted by application owners. By testing various applications and systems against the newly imported fabric, you can ensure that all services are functioning correctly and meeting the desired performance metrics.
Transition Complete: Seizing the Benefits of NDFC Management
A successful transition to NDFC management signifies a healthy fabric. You can now seamlessly add new switches and provision overlay networks moving forward. This transition unlocks the benefits of streamlined operations and enhanced network management capabilities offered by NDFC.
http://deliabtech.com/data-center/vxlan-evpn-fabric/