LAN Fabrics
The following terms are referred to in this document:
-
Greenfield Deployments: Applicable for provisioning new VXLAN EVPN fabrics and eBGP-based routed fabrics.
-
Brownfield Deployments: Applicable for existing VXLAN EVPN fabrics:
-
Migrate CLI-configured VXLAN EVPN fabrics to Nexus Dashboard Fabric Controller using the Easy_Fabric fabric template.
-
NFM migration to Cisco Nexus Dashboard Fabric Controller using the Easy_Fabric fabric template.
-
Note that in this document the terms switch and device are used interchangeably.
For information about upgrades, refer to the Cisco Nexus Dashboard Fabric Controller Installation and Upgrade Guide for LAN Controller Deployment.
The following table describes the fields that appear on
.
Field |
Description |
---|---|
Fabric Name |
Displays the name of the fabric. |
Fabric Technology |
Displays the fabric technology based on the fabric template. |
Fabric Type |
Displays the type of the fabric—Switch Fabric, LAN Monitor, or External |
ASN |
Displays the ASN for the fabric. |
Fabric Health |
Displays the health of the fabric. |
The following table describes the action items in the Actions menu drop‐down list, that appear on
.
Action Item |
Description |
---|---|
Create Fabric |
From the Actions drop-down list, select Create Fabric. For more instructions, see Create a Fabric. |
Edit Fabric |
Select a fabric to edit. From the Actions drop-down list, select Edit Fabric. Make the necessary changes and click Save. Click Close to discard the changes. |
Delete Fabric |
Select a fabric to delete. From the drop-down list, select Delete Fabric. Click Confirm to delete the fabric. |
Fabric Summary
Click on a fabric to open the side kick panel. The following sections display the summary of the fabric:
-
Health - Shows the health of the Fabric.
-
Alarms - Displays the alarms based on the categories.
-
Fabric Info - Provides basic about the Fabric.
-
Inventory - Provides information about Switch Configuration and Switch Health.
Click the Launch icon to the right top corner to view the Fabric Overview.
Understanding Fabric Templates
Fabric Templates
The following table provides information about the available fabric templates:
Fabric Template | Description | Detailed Procedures |
---|---|---|
Easy_Fabric | Fabric template for a VXLAN BGP EVPN deployment with an IGP (OSPF, IS-IS) and iBGP deployment for Nexus 9000 and Nexus 3000 switches. Both IPv4 and IPv6 underlay are supported. | Creating a VXLAN EVPN Fabric Using the Easy_Fabric Template |
Easy_Fabric_IOS_XE | Fabric template for a VXLAN BGP EVPN deployment with Catalyst 9000 switches. | Create Easy_Fabric for Cisco Catalyst 9000 Series Switches |
Easy_Fabric_eBGP | Fabric template for an eBGP based Routed Fabric deployment with Nexus 9000 and Nexus 3000 switches. This template also supports an eBGP VXLAN BGP EVPN deployment with eBGP used as both the underlay and overlay protocol. | Creating VXLAN EVPN Fabric with eBGP-based Underlay |
External_Fabric |
Fabric template that supports Nexus and non-Nexus devices. Non-Nexus device support includes other Cisco devices (IOS-XE, IOS-XR) and third-party switches. This template can manage BGP configuration on core and edge routers. Use cases for this template include:
|
Creating an External Fabric |
LAN_Classic | Fabric template that allows you to monitor and manage various Cisco Nexus Greenfield and Brownfield deployments, including the traditional 2 or 3-tier, vPC, and FabricPath data center topologies. | LAN Fabrics |
Fabric_Group | Fabric template that contains other LAN_Classic fabrics that allows visualization of groups of Classic LAN fabrics and their interconnections. | LAN Fabrics |
LAN_Monitor | Fabric template to support Fabric Discovery persona for monitoring purposes only. Cisco Nexus Dashboard Insights (NDI) can operate on such a fabric. No configuration provisioning or image management is supported. | LAN Fabrics |
MSD_Fabric | Fabric template for a VXLAN BGP EVPN Multi-Site Domain (MSD) deployment that can contain other VXLAN BGP EVPN fabrics with Layer-2/Layer-3 Overlay DCI Extensions. | Creating the MSD_Fabric and Associating Member Fabrics |
IPFM_Classic | Fabric template for existing deployments of IP Fabric for Media (IPFM). IPFM enables media content providers and broadcasters to use a flexible and scalable IP-based infrastructure. | Creating an IPFM Classic Fabric |
Easy_Fabric_IPFM | Fabric template for an easy greenfield deployment of an IP Fabric for Media (IPFM) fabric. IPFM enables media content providers and broadcasters to use a flexible and scalable IP-based infrastructure. | Creating an IPFM Easy Fabric |
Note |
Enhanced Classic LAN is a preview feature in Nexus Dashboard Fabric Controller, Release 12.1.2e. We recommend that you use this feature marked as BETA in your lab setup only. Do not use this features in your production deployment. To view Enhanced Classic LAN fabrics, you must enable this feature. On Web UI, navigate to Enable Preview Features check box. , then check the |
Prerequisites to Creating a Fabric
-
Update the ESXi host settings in the vSphere Client to accept overriding changes in promiscuous mode. For more information, see the Overriding the Changes in Promiscuous Mode section.
-
Configure the persistent IP addresses in Cisco Nexus Dashboard. For more information, see Cluster Configuration section in Cisco Nexus Dashboard User Guide.
Override ESXi Networking for Promiscuous Mode
For NDFC to run on top of the virtual Nexus Dashboard (vND) instance, you must enable promiscuous mode on port groups that are associated with Nexus Dashboard interfaces where External Service IP addresses are specified. vND comprises of Nexus Dashboard management interface and data interface. By default, for LAN deployments, 2 external service IP addresses are required for the Nexus Dashboard management interface subnet. Therefore, you must enable promiscuous mode for the associated port-group. If inband management or Endpoint Locator (EPL) is enabled, you must specify External Service IP addresses in the Nexus Dashboard data interface subnet. You must also enable the promiscuous mode for the Nexus Dashboard data/fabric interface port-group. For NDFC SAN Controller, promiscuous mode must be enabled only on the Nexus Dashboard data interface associated port-group. For NDFC SAN Controller, promiscuous mode only needs to be enabled on the Nexus Dashboard data interface associated port-group. For more information, refer to Cisco Nexus Dashboard Deployment Guide.
From Cisco NDFC Release , you can run NDFC on top of virtual Nexus Dashboard (vND) instance with promiscuous mode that is disabled on port groups that are associated with Nexus Dashboard interfaces where External Service IP addresses are specified. vND comprises Nexus Dashboard management interface and data interface. By default, for fabric controller persona, two external service IP addresses are required for the Nexus Dashboard management interface subnet.
Before the NDFC Release , if Inband management or Endpoint Locator or POAP feature was enabled on NDFC, you must also enable promiscuous mode for the Nexus Dashboard data or fabric interface port-group. This setting was mandatory for traffic flow that is associated for these features.
Enabling promiscuous mode raise risk of security issues in NDFC, it is recommended to set default setting for promiscuous mode.
Note |
|
If Inband management or EPL is enabled, you must specify External Service IP addresses in the Nexus Dashboard data interface subnet. You can disable promiscuous mode for the Nexus Dashboard data or fabric interface port-group. For more information, refer to Cisco Nexus Dashboard Deployment Guide
Note |
Default option for promiscuous mode is Reject. |
Procedure
Step 1 |
Log into your vSphere Client. |
Step 2 |
Navigate to the ESXi host. |
Step 3 |
Right-click the host and choose Settings. A sub-menu appears. |
Step 4 |
Choose Networking > Virtual Switches. All the virtual switches appear as blocks. |
Step 5 |
Click Edit Settings of the VM Network. |
Step 6 |
Navigate to the Security tab. |
Step 7 |
Update the Promiscuous mode settings as follows:
|
Step 8 |
Click OK. |
Create a Fabric
Procedure
Step 1 |
Choose . |
Step 2 |
From the Actions drop-down list, select Create Fabric. |
Step 3 |
Enter the fabric name and click Choose Template. |
Step 4 |
Specify the values for the fabric settings and click Save. |
VXLAN EVPN Fabrics Provisioning
Cisco Nexus Dashboard Fabric Controller provides an enhanced “Easy” fabric workflow for unified underlay and overlay provisioning of the VXLAN BGP EVPN configuration on Nexus 9000 and 3000 series of switches. The configuration of the fabric is achieved via a powerful, flexible, and customizable template-based framework. Using minimal user inputs, an entire fabric can be brought up with Cisco-recommended best practice configurations in a short period of time. The set of parameters exposed in the Fabric Settings allow you to tailor the fabric to your preferred underlay provisioning options.
Border devices in a fabric typically provide external connectivity via peering with appropriate edge/core/WAN routers. These edge/core routers may either be managed or monitored by Nexus Dashboard Fabric Controller. These devices are placed in a special fabric called the External Fabric. The same Nexus Dashboard Fabric Controller can manage multiple VXLAN BGP EVPN fabrics while also offering easy provisioning and management of Layer-2 and Layer-3 DCI underlay and overlay configuration among these fabrics using a special construct called a Multi-Site Domain (MSD) fabric.
The Nexus Dashboard Fabric Controller GUI functions for creating and deploying VXLAN BGP EVPN fabrics are as follows:
LAN > Fabrics > LAN Fabrics Create Fabric under Actions drop-down list.
Create, edit, and delete a fabric:
-
Create new VXLAN, MSD, and external VXLAN fabrics.
-
View the VXLAN and MSD fabric topologies, including connections between fabrics.
-
Update fabric settings.
-
Save and deploy updated changes.
-
Delete a fabric (if devices are removed).
Device discovery and provisioning start-up configurations on new switches:
-
Add switch instances to the fabric.
-
Provision start-up configurations and an IP address to a new switch through POAP configuration.
-
Update switch policies, save, and deploy updated changes.
-
Create intra-fabric and inter-fabric links (also called Inter-Fabric Connections [IFCs]).
LAN > Interfaces > LAN Fabrics Create New Interface under Actions drop-down list.
Underlay provisioning:
-
Create, deploy, view, edit, and delete a port-channel, vPC switch pair, Straight Through FEX (ST-FEX), Active-Active FEX (AA-FEX), loopback, subinterface, etc.
-
Create breakout and unbreakout ports.
-
Shut down and bring up interfaces.
-
Rediscover ports and view interface configuration history.
LAN > Switches > LAN Fabrics Add under Actions drop-down list.
Overlay network provisioning.
-
Create new overlay networks and VRFs (from the range specified in fabric creation).
-
Provision the overlay networks and VRFs on the switches of the fabric.
-
Undeploy the networks and VRFs from the switches.
-
Remove the provisioning from the fabric in Nexus Dashboard Fabric Controller.
LAN > Services menu option.
Provisioning of configuration on service leafs to which L4-7 service appliances may be attached. For more information, see L4-L7 Service Basic Workflow.
This chapter mostly covers configuration provisioning for a single VXLAN BGP EVPN fabric. EVPN Multi-Site provisioning for Layer-2/Layer-3 DCI across multiple fabrics using the MSD fabric, is documented in a separate chapter. The deployment details of how overlay Networks and VRFs can be easily provisioned from the Fabric Controller, is covered in the Creating Networks and Creating VRFs in the Networks and VRFs sections.
Guidelines for VXLAN BGP EVPN Fabrics Provisioning
-
For any switch to be successfully imported into Nexus Dashboard Fabric Controller, the user specified for discovery/import, should have the following permissions:
-
SSH access to the switch
-
Ability to perform SNMPv3 queries
-
Ability to run the show commands including show run, show interfaces, etc.
-
Ability to execute the guestshell commands, which are prefixed by run guestshell for the Nexus Dashboard Fabric Controller tracker.
-
-
The switch discovery user need not have the ability to make any configuration changes on the switches. It is primarily used for read access.
-
When an invalid command is deployed by Nexus Dashboard Fabric Controller to a device, for example, a command with an invalid key chain due to an invalid entry in the fabric settings, an error is generated displaying this issue. This error is not cleared after correcting the invalid fabric entry. You need to manually clean up or delete the invalid commands to clear the error.
Note that the fabric errors related to the command execution are automatically cleared only when the same failed command succeeds in the subsequent deployment.
-
LAN credentials are required to be set of any user that needs to be perform any write access to the device. LAN credentials need to be set on the Nexus Dashboard Fabric Controller, on a per user per device basis. When a user imports a device into the Easy Fabric, and LAN credentials are not set for that device, Nexus Dashboard Fabric Controller moves this device to a migration mode. Once the user sets the appropriate LAN credentials for that device, a subsequent Save & Deploy retriggers the device import process.
-
The Save & Deploy button triggers the intent regeneration for the entire fabric as well as a configuration compliance check for all the switches within the fabric. This button is required but not limited to the following cases:
-
A switch or a link is added, or any change in the topology
-
A change in the fabric settings that must be shared across the fabric
-
A switch is removed or deleted
-
A new vPC pairing or unpairing is done
-
A change in the role for a device
When you click Recalculate Config, the changes in the fabric are evaluated, and the configuration for the entire fabric is generated. Click Preview Config to preview the generated configuration, and then deploy it at a fabric level. Therefore, Deploy Config can take more time depending on the size of the fabric.
When you right-click on a switch icon, you can use the Deploy config to switches option to deploy per switch configurations. This option is a local operation for a switch, that is, the expected configuration or intent for a switch is evaluated against it’s current running configuration, and a config compliance check is performed for the switch to get the In-Sync or Out-of-Sync status. If the switch is out of sync, the user is provided with a preview of all the configurations running in that particular switch that vary from the intent defined by the user for that respective switch.
-
-
Persistent configuration diff is seen for the command line: system nve infra-vlan int force . The persistent diff occurs if you have deployed this command via the freeform configuration to the switch. Although the switch requires the force keyword during deployment, the running configuration that is obtained from the switch in Nexus Dashboard Fabric Controller doesn’t display the force keyword. Therefore, the system nve infra-vlan int force command always shows up as a diff.
The intent in Nexus Dashboard Fabric Controller contains the line:
system nve infra-vlan int force
The running config contains the line:
system nve infra-vlan int
As a workaround to fix the persistent diff, edit the freeform config to remove the force keyword after the first deployment such that it is system nve infra-vlan int .
The force keyword is required for the initial deploy and must be removed after a successful deploy. You can confirm the diff by using the Side-by-side Comparison tab in the Config Preview window.
The persistent diff is also seen after a write erase and reload of a switch. Update the intent on Nexus Dashboard Fabric Controller to include the force keyword, and then you need to remove the force keyword after the first deployment.
-
When the switch contains the hardware access-list tcam region arp-ether 256 command, which is deprecated without the double-wide keyword, the below warning is displayed:
WARNING: Configuring the arp-ether region without "double-wide" is deprecated and can result in silent non-vxlan packet drops. Use the "double-wide" keyword when carving TCAM space for the arp-ether region.
Since the original hardware access-list tcam region arp-ether 256 command doesn’t match the policies in Nexus Dashboard Fabric Controller, this config is captured in the switch_freeform policy. After the hardware access-list tcam region arp-ether 256 double-wide command is pushed to the switch, the original tcam command that does not contain the double-wide keyword is removed.
You must manually remove the hardware access-list tcam region arp-ether 256 command from the switch_freeform policy. Otherwise, config compliance shows a persistent diff.
Here is an example of the hardware access-list command on the switch:
switch(config)# show run | inc arp-ether switch(config)# hardware access-list tcam region arp-ether 256 Warning: Please save config and reload the system for the configuration to take effect switch(config)# show run | inc arp-ether hardware access-list tcam region arp-ether 256 switch(config)# switch(config)# hardware access-list tcam region arp-ether 256 double-wide Warning: Please save config and reload the system for the configuration to take effect switch(config)# show run | inc arp-ether hardware access-list tcam region arp-ether 256 double-wide
You can see that the original tcam command is overwritten.
Creating a VXLAN EVPN Fabric Using the Easy_Fabric Template
This topic describes how to create a new VXLAN EVPN fabric using the Easy_Fabric template and contains descriptions for the IPv4 underlay. For information about the IPv6 underlay, see IPv6 Underlay Support for Easy Fabric.
-
Navigate to the LAN Fabrics page:
-
Click
.The Create Fabric window appears.
-
Enter a unique name for the fabric in the Fabric Name field, then click Choose Fabric.
A list of all available fabric templates are listed.
-
From the available list of fabric templates, choose the Easy_Fabric template, then click Select.
-
Enter the necessary field values to create a fabric.
The tabs and their fields in the screen are explained in the following sections. The overlay and underlay network parameters are included in these tabs.
Note
If you’re creating a standalone fabric as a potential member fabric of an MSD fabric (used for provisioning overlay networks for fabrics that are connected through EVPN Multi-Site technology), see Multi-Site Domain for VXLAN BGP EVPN Fabrics before creating the member fabric.
-
When you have completed the necessary configurations, click Save.
-
Click on the fabric to display a summary in the slide-in pane.
-
Click on the Launch icon to display the Fabric Overview.
-
General Parameters
The General Parameters tab is displayed by default. The fields in this tab are described in the following table.
Field |
Description |
---|---|
BGP ASN |
Enter the BGP AS number the fabric is associated with. This must be same as existing fabric. |
Enable IPv6 Underlay |
Enable the IPv6 underlay feature. For information, see IPv6 Underlay Support for Easy Fabric. |
Enable IPv6 Link-Local Address |
Enables the IPv6 Link-Local address. |
Fabric Interface Numbering |
Specifies whether you want to use point-to-point (p2p) or unnumbered networks. |
Underlay Subnet IP Mask |
Specifies the subnet mask for the fabric interface IP addresses. |
Underlay Subnet IPv6 Mask |
Specifies the subnet mask for the fabric interface IPv6 addresses. |
Underlay Routing Protocol |
The IGP used in the fabric, OSPF, or IS-IS. |
Route-Reflectors (RRs) |
The number of spine switches that are used as route reflectors for transporting BGP traffic. Choose 2 or 4 from the drop-down box. The default value is 2. To deploy spine devices as RRs, Nexus Dashboard Fabric Controller sorts the spine devices based on their serial numbers, and designates two or four spine devices as RRs. If you add more spine devices, existing RR configuration won’t change. Increasing the count – You can increase the route reflectors from two to four at any point in time. Configurations are automatically generated on the other two spine devices designated as RRs. Decreasing the count – When you reduce four route reflectors to two, remove the unneeded route reflector devices from the fabric. Follow these steps to reduce the count from 4 to 2.
You can preselect RRs and RPs before performing the first Save & Deploy operation. For more information, see Preselecting Switches as Route-Reflectors and Rendezvous-Points. |
Anycast Gateway MAC |
Specifies the anycast gateway MAC address. |
Enable Performance Monitoring |
Check the check box to enable performance monitoring. Ensure that you do not clear interface counters from the Command Line Interface of the switches. Clearing interface counters
can cause the Performance Monitor to display incorrect data for traffic utilization. If you must clear the counters and the
switch has both |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Replication
The fields in the Replication tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
Replication Mode |
The mode of replication that is used in the fabric for BUM (Broadcast, Unknown Unicast, Multicast) traffic. The choices are Ingress Replication or Multicast. When you choose Ingress replication, the multicast related fields get disabled. You can change the fabric setting from one mode to the other, if no overlay profile exists for the fabric. |
||
Multicast Group Subnet |
IP address prefix used for multicast communication. A unique IP address is allocated from this group for each overlay network. The replication mode change isn’t allowed if a policy template instance is created for the current mode. For example, if a multicast related policy is created and deployed, you can’t change the mode to Ingress. |
||
Enable Tenant Routed Multicast (TRM) |
Check the check box to enable Tenant Routed Multicast (TRM) that allows overlay multicast traffic to be supported over EVPN/MVPN in the VXLAN BGP EVPN fabric. |
||
Default MDT Address for TRM VRFs |
The multicast address for Tenant Routed Multicast traffic is populated. By default, this address is from the IP prefix specified in the Multicast Group Subnet field. When you update either field, ensure that the TRM address is chosen from the IP prefix specified in Multicast Group Subnet. For more information, see Overview of Tenant Routed Multicast. |
||
Rendezvous-Points |
Enter the number of spine switches acting as rendezvous points. |
||
RP mode |
Choose from the two supported multicast modes of replication, ASM (for Any-Source Multicast [ASM]) or BiDir (for Bidirectional PIM [BIDIR-PIM]). When you choose ASM, the BiDir related fields aren’t enabled. When you choose BiDir, the BiDir related fields are enabled.
When you create a new VRF for the fabric overlay, this address is populated in the Underlay Multicast Address field, in the Advanced tab. |
||
Underlay RP Loopback ID |
The loopback ID used for the rendezvous point (RP), for multicast protocol peering purposes in the fabric underlay. |
||
Underlay Primary RP Loopback ID |
Enabled if you choose BIDIR-PIM as the multicast mode of replication. The primary loopback ID used for the phantom RP, for multicast protocol peering purposes in the fabric underlay. |
||
Underlay Backup RP Loopback ID |
Enabled if you choose BIDIR-PIM as the multicast mode of replication. The secondary loopback ID used for the phantom RP, for multicast protocol peering purposes in the fabric underlay. |
||
Underlay Second Backup RP Loopback Id |
Used for the second fallback Bidir-PIM Phantom RP. |
||
Underlay Third Backup RP Loopback Id |
Used for the third fallback Bidir-PIM Phantom RP. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
VPC
The fields in the VPC tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
vPC Peer Link VLAN |
VLAN used for the vPC peer link SVI. |
||
Make vPC Peer Link VLAN as Native VLAN |
Enables vPC peer link VLAN as Native VLAN. |
||
vPC Peer Keep Alive option |
Choose the management or loopback option. If you want to use IP addresses assigned to the management port and the management VRF, choose management. If you use IP addresses assigned to loopback interfaces (and a non-management VRF), choose loopback. If you use IPv6 addresses, you must use loopback IDs. |
||
vPC Auto Recovery Time |
Specifies the vPC auto recovery time-out period in seconds. |
||
vPC Delay Restore Time |
Specifies the vPC delay restore period in seconds. |
||
vPC Peer Link Port Channel ID |
Specifies the Port Channel ID for a vPC Peer Link. By default, the value in this field is 500. |
||
vPC IPv6 ND Synchronize |
Enables IPv6 Neighbor Discovery synchronization between vPC switches. The check box is enabled by default. Uncheck the check box to disable the function. |
||
vPC advertise-pip |
Select the check box to enable the Advertise PIP feature. You can enable the advertise PIP feature on a specific vPC as well. . |
||
Enable the same vPC Domain Id for all vPC Pairs |
Enable the same vPC Domain ID for all vPC pairs. When you select this field, the vPC Domain Id field is editable. |
||
vPC Domain Id |
Specifies the vPC domain ID to be used on all vPC pairs. |
||
vPC Domain Id Range |
Specifies the vPC Domain Id range to use for new pairings. |
||
Enable QoS for Fabric vPC-Peering |
Enable QoS on spines for guaranteed delivery of vPC Fabric Peering communication. .
|
||
QoS Policy Name |
Specifies QoS policy name that should be same on all fabric vPC peering spines. The default name is spine_qos_for_fabric_vpc_peering. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Protocols
The fields in the Protocols tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
Underlay Routing Loopback Id |
The loopback interface ID is populated as 0 since loopback0 is usually used for fabric underlay IGP peering purposes. |
||
Underlay VTEP Loopback Id |
The loopback interface ID is populated as 1 since loopback1 is used for the VTEP peering purposes. |
||
Underlay Anycast Loopback Id |
The loopback interface ID is greyed out and used for vPC Peering in VXLANv6 Fabrics only. |
||
Underlay Routing Protocol Tag |
The tag defining the type of network. |
||
OSPF Area ID |
The OSPF area ID, if OSPF is used as the IGP within the fabric.
|
||
Enable OSPF Authentication |
Select the check box to enable OSPF authentication. Deselect the check box to disable it. If you enable this field, the OSPF Authentication Key ID and OSPF Authentication Key fields get enabled. |
||
OSPF Authentication Key ID |
The Key ID is populated. |
||
OSPF Authentication Key |
The OSPF authentication key must be the 3DES key from the switch.
|
||
IS-IS Level |
Select the IS-IS level from this drop-down list. |
||
Enable IS-IS Network Point-to-Point |
Enables network point-to-point on fabric interfaces which are numbered. |
||
Enable IS-IS Authentication |
Select the check box to enable IS-IS authentication. Deselect the check box to disable it. If you enable this field, the IS-IS authentication fields are enabled. |
||
IS-IS Authentication Keychain Name |
Enter the Keychain name, such as CiscoisisAuth. |
||
IS-IS Authentication Key ID |
The Key ID is populated. |
||
IS-IS Authentication Key |
Enter the Cisco Type 7 encrypted key.
|
||
Set IS-IS Overload Bit |
When enabled, set the overload bit for an elapsed time after a reload. |
||
IS-IS Overload Bit Elapsed Time |
Allows you to clear the overload bit after an elapsed time in seconds. |
||
Enable BGP Authentication |
Select the check box to enable BGP authentication. Deselect the check box to disable it. If you enable this field, the BGP Authentication Key Encryption Type and BGP Authentication Key fields are enabled.
|
||
BGP Authentication Key Encryption Type |
Choose the 3 for 3DES encryption type, or 7 for Cisco encryption type. |
||
BGP Authentication Key |
Enter the encrypted key based on the encryption type.
|
||
Enable PIM Hello Authentication |
Select this check box to enable PIM hello authentication on all the intra-fabric interfaces of the switches in a fabric. This check box is editable only for the Multicast replication mode. Note this check box is valid only for the IPv4 underlay. |
||
PIM Hello Authentication Key |
Specifies the PIM hello authentication key. For more information, see Retrieving PIM Hello Authentication Key. To retrieve the PIM Hello Authentication Key, perform the following steps:
|
||
Enable BFD |
Check the check box to enable feature bfd on all switches in the fabric. This feature is valid only on IPv4 underlay and the scope is within a fabric. BFD within a fabric is supported natively. The BFD feature is disabled by default in the Fabric Settings. If enabled, BFD is enabled for the underlay protocols with the default settings. Any custom required BFD configurations must be deployed via the per switch freeform or per interface freeform policies. The following config is pushed after you select the Enable BFD check box:
For information about BFD feature compatibility, refer your respective platform documentation and for information about the supported software images, see Compatibility Matrix for Cisco Nexus Dashboard Fabric Controller. |
||
Enable BFD for iBGP |
Check the check box to enable BFD for the iBGP neighbor. This option is disabled by default. |
||
Enable BFD for OSPF |
Check the check box to enable BFD for the OSPF underlay instance. This option is disabled by default, and it is grayed out if the link state protocol is ISIS. |
||
Enable BFD for ISIS |
Check the check box to enable BFD for the ISIS underlay instance. This option is disabled by default, and it is grayed out if the link state protocol is OSPF. |
||
Enable BFD for PIM |
Check the check box to enable BFD for PIM. This option is disabled by default, and it is be grayed out if the replication mode is Ingress. Following are examples of the BFD global policies:
|
||
Enable BFD Authentication |
Check the check box to enable BFD authentication. If you enable this field, the BFD Authentication Key ID and BFD Authentication Key fields are editable.
|
||
BFD Authentication Key ID |
Specifies the BFD authentication key ID for the interface authentication. The default value is 100. |
||
BFD Authentication Key |
Specifies the BFD authentication key. For information about how to retrieve the BFD authentication parameters. . |
||
iBGP Peer-Template Config |
Add iBGP peer template configurations on the leaf switches to establish an iBGP session between the leaf switch and route reflector. If you use BGP templates, add the authentication configuration within the template and uncheck the Enable BGP Authentication check box to avoid duplicate configuration. In the sample configuration, the 3DES password is displayed after password 3.
The following fields can be used to specify different configurations:
In a brownfield migration, if the spine and leaf use different peer template names, both iBGP Peer-Template Config and Leaf/Border/Border Gateway iBGP Peer-Template Config fields need to be set according to the switch config. If spine and leaf use the same peer template name and content (except for the “route-reflector-client” CLI), only iBGP Peer-Template Config field in fabric setting needs to be set. If the fabric settings on iBGP peer templates do not match the existing switch configuration, an error message is generated and the migration will not proceed. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Advanced
The fields in the Advanced tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
VRF Template |
Specifies the VRF template for creating VRFs. |
||
Network Template |
Specifies the network template for creating networks. |
||
VRF Extension Template |
Specifies the VRF extension template for enabling VRF extension to other fabrics. |
||
Network Extension Template |
Specifies the network extension template for extending networks to other fabrics. |
||
Overlay Mode |
VRF/Network configuration using config-profile or CLI, default is config-profile. For more information, see Overlay Mode. |
||
Site ID |
The ID for this fabric if you are moving this fabric within an MSD. The site ID is mandatory for a member fabric to be a part of an MSD. Each member fabric of an MSD has a unique site ID for identification. |
||
Intra Fabric Interface MTU |
Specifies the MTU for the intra fabric interface. This value should be an even number. |
||
Layer 2 Host Interface MTU |
Specifies the MTU for the layer 2 host interface. This value should be an even number. |
||
Unshut Host Interfaces by Default |
Check this check box to unshut the host interfaces by default. |
||
Power Supply Mode |
Choose the appropriate power supply mode. |
||
CoPP Profile |
Choose the appropriate Control Plane Policing (CoPP) profile policy for the fabric. By default, the strict option is populated. |
||
VTEP HoldDown Time |
Specifies the NVE source interface hold down time. |
||
Brownfield Overlay Network Name Format |
Enter the format to be used to build the overlay network name during a brownfield import or migration. The network name should not contain any white spaces or special characters except underscore (_) and hyphen (-). The network name must not be changed once the brownfield migration has been initiated. See the Creating Networks for the Standalone Fabric section for the naming convention of the network name. The syntax is [<string> | $$VLAN_ID$$] $$VNI$$ [<string>| $$VLAN_ID$$] and the default value is Auto_Net_VNI$$VNI$$_VLAN$$VLAN_ID$$. When you create networks, the name is generated according to the syntax you specify. The following list describes the variables in the syntax:
An example overlay network name: Site_VNI12345_VLAN1234
|
||
Enable CDP for Bootstrapped Switch |
Enables CDP on management (mgmt0) interface for bootstrapped switch. By default, for bootstrapped switches, CDP is disabled on the mgmt0 interface. |
||
Enable VXLAN OAM |
Enables the VXLAM OAM functionality for devices in the fabric. This is enabled by default. Uncheck the check box to disable VXLAN OAM function. If you want to enable the VXLAN OAM function on specific switches and disable on other switches in the fabric, you can use freeform configurations to enable OAM and disable OAM in the fabric settings.
|
||
Enable Tenant DHCP |
Check the check box to enable feature dhcp and associated configurations globally on all switches in the fabric. This is a pre-requisite for support of DHCP for overlay networks that are part of the tenant VRFs.
|
||
Enable NX-API |
Specifies enabling of NX-API on HTTPS. This check box is checked by default. |
||
Enable NX-API on HTTP Port |
Specifies enabling of NX-API on HTTP. Enable this check box and the Enable NX-API check box to use HTTP. This check box is checked by default. If you uncheck this check box, the applications that use NX-API and supported by Cisco Nexus Dashboard Fabric Controller, such as Endpoint Locator (EPL), Layer 4-Layer 7 services (L4-L7 services), VXLAN OAM, and so on, start using the HTTPS instead of HTTP.
|
||
Enable Policy-Based Routing (PBR) |
Check this check box to enable routing of packets based on the specified policy. Starting with Cisco NX-OS Release 7.0(3)I7(1) and later releases, this feature works on Cisco Nexus 9000 Series switches with Nexus 9000 Cloud Scale (Tahoe) ASICs. This feature is used along with the Layer 4-Layer 7 service workflow. For information on Layer 4-Layer 7 service, refer the Layer 4-Layer 7 Service chapter. |
||
Enable Strict Config Compliance |
Enable the Strict Config Compliance feature by selecting this check box. It enables bi-directional compliance checks to flag additional configs in the running config that are not in the intent/expected config. By default, this feature is disabled. |
||
Enable AAA IP Authorization |
Enables AAA IP authorization, when IP Authorization is enabled in the remote authentication server. This is required to support Nexus Dashboard Fabric Controller in scenarios where customers have strict control of which IP addresses can have access to the switches. |
||
Enable NDFC as Trap Host |
Select this check box to enable Nexus Dashboard Fabric Controller as an SNMP trap destination. Typically, for a native HA Nexus Dashboard Fabric Controller deployment, the eth1 VIP IP address will be configured as SNMP trap destination on the switches. By default, this check box is enabled. |
||
Anycast Border Gateway advertise-pip |
Enables to advertise Anycast Border Gateway PIP as VTEP. Effective on MSD fabric 'Recalculate Config'. |
||
Greenfield Cleanup Option |
Enable the switch cleanup option for switches imported into Nexus Dashboard Fabric Controller with Preserve-Config=No, without a switch reload. This option is typically recommended only for the fabric environments with Cisco Nexus 9000v Switches to improve on the switch clean up time. The recommended option for Greenfield deployment is to employ Bootstrap or switch cleanup with a reboot. In other words, this option should be unchecked. |
||
Enable Precision Time Protocol (PTP) |
Enables PTP across a fabric. When you check this check box, PTP is enabled globally and on core-facing interfaces. Additionally, the PTP Source Loopback Id and PTP Domain Id fields are editable. For more information, see Precision Time Protocol for Easy Fabric. |
||
PTP Source Loopback Id |
Specifies the loopback interface ID Loopback that is used as the Source IP Address for all PTP packets. The valid values range from 0 to 1023. The PTP loopback ID cannot be the same as RP, Phantom RP, NVE, or MPLS loopback ID. Otherwise, an error will be generated. The PTP loopback ID can be the same as BGP loopback or user-defined loopback which is created from Nexus Dashboard Fabric Controller. If the PTP loopback ID is not found during Deploy Config, the following error is generated: Loopback interface to use for PTP source IP is not found. Create PTP loopback interface on all the devices to enable PTP feature. |
||
PTP Domain Id |
Specifies the PTP domain ID on a single network. The valid values range from 0 to 127. |
||
Enable MPLS Handoff |
Check the check box to enable the MPLS Handoff feature. For more information, see the MPLS SR and LDP Handoff chapter in External/WAN Layer 3 Connectivity for VXLAN BGP EVPN Fabrics. |
||
Underlay MPLS Loopback Id |
Specifies the underlay MPLS loopback ID. The default value is 101. |
||
Enable TCAM Allocation |
TCAM commands are automatically generated for VXLAN and vPC Fabric Peering when enabled. |
||
Enable Default Queuing Policies |
Check this check box to apply QoS policies on all the switches in this fabric. To remove the QoS policies that you applied on all the switches, uncheck this check box, update all the configurations to remove the references to the policies, and save and deploy. Pre-defined QoS configurations are included that can be used for various Cisco Nexus 9000 Series Switches. When you check this check box, the appropriate QoS configurations are pushed to the switches in the fabric. The system queuing is updated when configurations are deployed to the switches. You can perform the interface marking with defined queuing policies, if required, by adding the required configuration to the per interface freeform block. Review the actual queuing policies by opening the policy file in the template editor. From Cisco Nexus Dashboard Fabric Controller Web UI, choose Operations > Templates. Search for the queuing policies by the policy file name, for example, queuing_policy_default_8q_cloudscale. Choose the file. From the Actions drop-down list, select Edit template content to edit the policy. See the Cisco Nexus 9000 Series NX-OS Quality of Service Configuration Guide for platform specific details. |
||
N9K Cloud Scale Platform Queuing Policy |
Choose the queuing policy from the drop-down list to be applied to all Cisco Nexus 9200 Series Switches and the Cisco Nexus 9000 Series Switches that ends with EX, FX, and FX2 in the fabric. The valid values are queuing_policy_default_4q_cloudscale and queuing_policy_default_8q_cloudscale. Use the queuing_policy_default_4q_cloudscale policy for FEXes. You can change from the queuing_policy_default_4q_cloudscale policy to the queuing_policy_default_8q_cloudscale policy only when FEXes are offline. |
||
N9K R-Series Platform Queuing Policy |
Choose the queuing policy from the drop-down list to be applied to all Cisco Nexus switches that ends with R in the fabric. The valid value is queuing_policy_default_r_series. |
||
Other N9K Platform Queuing Policy |
Choose the queuing policy from the drop-down list to be applied to all other switches in the fabric other than the switches mentioned in the above two options. The valid value is queuing_policy_default_other. |
||
Enable MACsec |
Enables MACsec for the fabric. For more information, see Enabling MACsec. Freeform CLIs - Fabric level freeform CLIs can be added while creating or editing a fabric. They are applicable to switches across the fabric. You must add the configurations as displayed in the running configuration, without indentation. Switch level freeform configurations should be added via the switch freeform on NDFC. For more information, see Enabling Freeform Configurations on Fabric Switches. |
||
Leaf Freeform Config |
Add CLIs that should be added to switches that have the Leaf, Border, and Border Gateway roles. |
||
Spine Freeform Config |
Add CLIs that should be added to switches with a Spine, Border Spine, Border Gateway Spine, and Super Spine roles. |
||
Intra-fabric Links Additional Config |
Add CLIs that should be added to the intra-fabric links. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Resources
The fields in the Resources tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
Manual Underlay IP Address Allocation |
Do not check this check box if you are transitioning your VXLAN fabric management to Nexus Dashboard Fabric Controller.
|
||
Underlay Routing Loopback IP Range |
Specifies loopback IP addresses for the protocol peering. |
||
Underlay VTEP Loopback IP Range |
Specifies loopback IP addresses for VTEPs. |
||
Underlay RP Loopback IP Range |
Specifies the anycast or phantom RP IP address range. |
||
Underlay Subnet IP Range |
IP addresses for underlay P2P routing traffic between interfaces. |
||
Underlay MPLS Loopback IP Range |
Specifies the underlay MPLS loopback IP address range. For eBGP between Border of Easy A and Easy B, Underlay routing loopback and Underlay MPLS loopback IP range must be a unique range. It should not overlap with IP ranges of the other fabrics, else VPNv4 peering will not come up. |
||
Underlay Routing Loopback IPv6 Range |
Specifies Loopback0 IPv6 Address Range |
||
Underlay VTEP Loopback IPv6 Range |
Specifies Loopback1 and Anycast Loopback IPv6 Address Range. |
||
Underlay Subnet IPv6 Range |
Specifies IPv6 Address range to assign Numbered and Peer Link SVI IPs. |
||
BGP Router ID Range for IPv6 Underlay |
Specifies BGP router ID range for IPv6 underlay. |
||
Layer 2 VXLAN VNI Range |
Specifies the overlay VXLAN VNI range for the fabric (min:1, max:16777214). |
||
Layer 3 VXLAN VNI Range |
Specifies the overlay VRF VNI range for the fabric (min:1, max:16777214). |
||
Network VLAN Range |
VLAN range for the per switch overlay network (min:2, max:4094). |
||
VRF VLAN Range |
VLAN range for the per switch overlay Layer 3 VRF (min:2, max:4094). |
||
Subinterface Dot1q Range |
Specifies the subinterface range when L3 sub interfaces are used. |
||
VRF Lite Deployment |
Specify the VRF Lite method for extending inter fabric connections. The VRF Lite Subnet IP Range field specifies resources reserved for IP address used for VRF Lite when VRF Lite IFCs are auto-created. If you select Back2Back&ToExternal, then VRF Lite IFCs are auto-created. |
||
Auto Deploy Both |
This check box is applicable for symmetric VRF Lite deployment. When you select this check box, it would set the auto deploy flag to true for auto-created IFCs to turn on symmetric VRF Lite configuration. You can check or uncheck the checkbox when the VRF Lite Deployment field is not set to Manual. This configuration only affects the new auto-created IFCs and does not affect the existing IFCs. You can edit an auto-created IFC and check or uncheck the Auto Generate Configuration for Peer field. This setting takes priority always. |
||
VRF Lite Subnet IP Range and VRF Lite Subnet Mask |
These fields are populated with the DCI subnet details. Update the fields as needed. The values shown in your screen are automatically generated. If you want to update the IP address ranges, VXLAN Layer 2/Layer 3 network ID ranges or the VRF/Network VLAN ranges, ensure the following:
|
||
Service Network VLAN Range |
Specifies a VLAN range in the Service Network VLAN Range field. This is a per switch overlay service network VLAN range. The minimum allowed value is 2 and the maximum allowed value is 3967. |
||
Route Map Sequence Number Range |
Specifies the route map sequence number range. The minimum allowed value is 1 and the maximum allowed value is 65534. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Manageability
The fields in the Manageability tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
---|---|
Inband Management |
Enabling this allows the management of the switches over their front panel interfaces. The Underlay Routing Loopback interface is used for discovery. If enabled, switches cannot be added to the fabric over their out-of-band (OOB) mgmt0 interface. To manage easy fabrics through Inband management ensure that you have chosen Data in NDFC Web UI, Settings > Server Settings > Admin. Both inband management and out-of-band connectivity (mgmt0) are supported for this setting. For more information, see Inband Management and Inband POAP in Easy Fabrics. |
DNS Server IPs |
Specifies the comma separated list of IP addresses (v4/v6) of the DNS servers. |
DNS Server VRFs |
Specifies one VRF for all DNS servers or a comma separated list of VRFs, one per DNS server. |
NTP Server IPs |
Specifies comma separated list of IP addresses (v4/v6) of the NTP server. |
NTP Server VRFs |
Specifies one VRF for all NTP servers or a comma separated list of VRFs, one per NTP server. |
Syslog Server IPs |
Specifies the comma separated list of IP addresses (v4/v6) IP address of the syslog servers, if used. |
Syslog Server Severity |
Specifies the comma separated list of syslog severity values, one per syslog server. The minimum value is 0 and the maximum value is 7. To specify a higher severity, enter a higher number. |
Syslog Server VRFs |
Specifies one VRF for all syslog servers or a comma separated list of VRFs, one per syslog server. |
AAA Freeform Config |
Specifies the AAA freeform configurations. If AAA configurations are specified in the fabric settings, switch_freeform PTI with source as UNDERLAY_AAA and description as AAA Configurations will be created. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Bootstrap
The fields in the Bootstrap tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
Enable Bootstrap |
Select this check box to enable the bootstrap feature. Bootstrap allows easy day-0 import and bring-up of new devices into an existing fabric. Bootstrap leverages the NX-OS POAP functionality. Starting from Cisco NDFC Release 12.1.1e, to add more switches and for POAP capability, chose check box for Enable Bootstrap and Enable Local DHCP Server. For more information, see Inband Management and Inband POAP in Easy Fabrics After you enable bootstrap, you can enable the DHCP server for automatic IP address assignment using one of the following methods:
|
||
Enable Local DHCP Server |
Select this check box to initiate enabling of automatic IP address assignment through the local DHCP server. When you select this check box, the DHCP Scope Start Address and DHCP Scope End Address fields become editable. If you do not select this check box, Nexus Dashboard Fabric Controller uses the remote or external DHCP server for automatic IP address assignment. |
||
DHCP Version |
Select DHCPv4 or DHCPv6 from this drop-down list. When you select DHCPv4, the Switch Mgmt IPv6 Subnet Prefix field is disabled. If you select DHCPv6, the Switch Mgmt IP Subnet Prefix is disabled.
|
||
DHCP Scope Start Address and DHCP Scope End Address |
Specifies the first and last IP addresses of the IP address range to be used for the switch out of band POAP. |
||
Switch Mgmt Default Gateway |
Specifies the default gateway for the management VRF on the switch. |
||
Switch Mgmt IP Subnet Prefix |
Specifies the prefix for the Mgmt0 interface on the switch. The prefix should be between 8 and 30. DHCP scope and management default gateway IP address specification - If you specify the management default gateway IP address 10.0.1.1 and subnet mask 24, ensure that the DHCP scope is within the specified subnet, between 10.0.1.2 and 10.0.1.254. |
||
Switch Mgmt IPv6 Subnet Prefix |
Specifies the IPv6 prefix for the Mgmt0 interface on the switch. The prefix should be between 112 and 126. This field is editable if you enable IPv6 for DHCP. |
||
Enable AAA Config |
Select this check box to include AAA configurations from the Manageability tab as part of the device start-up config post bootstrap. |
||
DHCPv4/DHCPv6 Multi Subnet Scope |
Specifies the field to enter one subnet scope per line. This field is editable after you check the Enable Local DHCP Server check box. The format of the scope should be defined as: DHCP Scope Start Address, DHCP Scope End Address, Switch Management Default Gateway, Switch Management Subnet Prefix For example: 10.6.0.2, 10.6.0.9, 10.6.0.1, 24 |
||
Bootstrap Freeform Config |
(Optional) Enter additional commands as needed. For example, if you require some additional configurations to be pushed to the device and be available post device bootstrap, they can be captured in this field, to save the desired intent. After the devices boot up, they will contain the configuration defined in the Bootstrap Freeform Config field. Copy-paste the running-config to a freeform config field with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running config. For more information, see Enabling Freeform Configurations on Fabric Switches. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Configuration Backup
The fields in the Configuration Backup tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
Hourly Fabric Backup |
Select the check box to enable an hourly backup of fabric configurations and the intent. The hourly backups are triggered during the first 10 minutes of the hour. |
||
Scheduled Fabric Backup |
Check the check box to enable a daily backup. This backup tracks changes in running configurations on the fabric devices that are not tracked by configuration compliance. |
||
Scheduled Time |
Specify the scheduled backup time in a 24-hour format. This field is enabled if you check the Scheduled Fabric Backup check box. Select both the check boxes to enable both back up processes. The backup process is initiated after you click Save. The scheduled backups are triggered exactly at the time you specify with a delay of up to two minutes. The scheduled backups are triggered regardless of the configuration deployment status. The number of fabric backups that will be retained on NDFC is decided by the .The number of archived files that can be retained is set in the # Number of archived files per device to be retained: field in the Server Properties window.
You can also initiate the fabric backup in the fabric topology window. Click Backup Now in the Actions pane. |
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Flow Monitor
The fields in the Flow Monitor tab are described in the following table. Most of the fields are automatically generated based on Cisco-recommended best practice configurations, but you can update the fields if needed.
Field |
Description |
||
---|---|---|---|
Enable Netflow |
Check this check box to enable Netflow on VTEPs for this Fabric. By default, Netflow is disabled. On Enable, NetFlow configuration will be applied to all VTEPS that support netflow.
If netflow is not enabled at the fabric level, an error message is generated when you enable netflow at the interface, network, or vrf level. For information about Netflow support for Cisco NDFC, refer to Netflow Support. |
In the Netflow Exporter area, click Actions > Add to add one or more Netflow exporters. This exporter is the receiver of the netflow data. The fields on this screen are:
-
Exporter Name – Specifies the name of the exporter.
-
IP – Specifies the IP address of the exporter.
-
VRF – Specifies the VRF over which the exporter is routed.
-
Source Interface – Enter the source interface name.
-
UDP Port – Specifies the UDP port over which the netflow data is exported.
Click Save to configure the exporter. Click Cancel to discard. You can also choose an existing exporter and select Actions > Edit or Actions > Delete to perform relevant actions.
In the Netflow Record area, click Actions > Add to add one or more Netflow records. The fields on this screen are:
-
Record Name – Specifies the name of the record.
-
Record Template – Specifies the template for the record. Enter one of the record templates names. In Release 12.0.2, the following two record templates are available for use. You can create custom netflow record templates. Custom record templates saved in the template library are available for use here.
-
netflow_ipv4_record – to use the IPv4 record template.
-
netflow_l2_record – to use the Layer 2 record template.
-
-
Is Layer2 Record – Check this check box if the record is for Layer2 netflow.
Click Save to configure the report. Click Cancel to discard. You can also choose an existing record and select Actions > Edit or Actions > Delete to perform relevant actions.
In the Netflow Monitor area, click Actions > Add to add one or more Netflow monitors. The fields on this screen are:
-
Monitor Name – Specifies the name of the monitor.
-
Record Name – Specifies the name of the record for the monitor.
-
Exporter1 Name – Specifies the name of the exporter for the netflow monitor.
-
Exporter2 Name – (optional) Specifies the name of the secondary exporter for the netflow monitor.
The record name and exporters referred to in each netflow monitor must be defined in "Netflow Record" and "Netflow Exporter".
Click Save to configure the monitor. Click Cancel to discard. You can also choose an existing monitor and select Actions > Edit or Actions > Delete to perform relevant actions.
What's next: Complete the configurations in another tab if necessary, or click Save when you have completed the necessary configurations for this fabric.
Configuring Fabrics with eBGP Underlay
You can use the Easy_Fabric_eBGP fabric template to create a fabric with eBGP underlay. For more information, see Configuring a Fabric with eBGP Underlay.
IPv6 Underlay Support for Easy Fabric
You can create an Easy fabric with IPv6 only underlay. The IPv6 underlay is supported only for the Easy_Fabric template. For more information, see Configuring a VXLANv6 Fabric.
Overview of Tenant Routed Multicast
Tenant Routed Multicast (TRM) enables multicast forwarding on the VXLAN fabric that uses a BGP-based EVPN control plane. TRM provides multi-tenancy aware multicast forwarding between senders and receivers within the same or different subnet local or across VTEPs.
With TRM enabled, multicast forwarding in the underlay is leveraged to replicate VXLAN encapsulated routed multicast traffic. A Default Multicast Distribution Tree (Default-MDT) is built per-VRF. This is an addition to the existing multicast groups for Layer-2 VNI Broadcast, Unknown Unicast, and Layer-2 multicast replication group. The individual multicast group addresses in the overlay are mapped to the respective underlay multicast address for replication and transport. The advantage of using a BGP-based approach allows the VXLAN BGP EVPN fabric with TRM to operate as fully distributed Overlay Rendezvous-Point (RP), with the RP presence on every edge-device (VTEP).
A multicast-enabled data center fabric is typically part of an overall multicast network. Multicast sources, receivers, and multicast rendezvous points might reside inside the data center but also might be inside the campus or externally reachable via the WAN. TRM allows a seamless integration with existing multicast networks. It can leverage multicast rendezvous points external to the fabric. Furthermore, TRM allows for tenant-aware external connectivity using Layer-3 physical interfaces or subinterfaces.
For more information, see the following:
Overview of Tenant Routed Multicast with VXLAN EVPN Multi-Site
Tenant Routed Multicast with Multi-Site enables multicast forwarding across multiple VXLAN EVPN fabrics connected via Multi-Site.
The following two use cases are supported:
-
Use Case 1: TRM provides Layer 2 and Layer 3 multicast services across sites for sources and receivers across different sites.
-
Use Case 2: Extending TRM functionality from VXLAN fabric to sources receivers external to the fabric.
TRM Multi-Site is an extension of BGP-based TRM solution that enables multiple TRM sites with multiple VTEPs to connect to each other to provide multicast services across sites in most efficient possible way. Each TRM site is operating independently and border gateway on each site allows stitching across each site. There can be multiple Border Gateways for each site. In a given site, the BGW peers with Route Sever or BGWs of other sites to exchange EVPN and MVPN routes. On the BGW, BGP will import routes into the local VRF/L3VNI/L2VNI and then advertise those imported routes into the Fabric or WAN depending on where the routes were learnt from.
Tenant Routed Multicast with VXLAN EVPN Multi-Site Operations
The operations for TRM with VXLAN EVPN Multi-Site are as follows:
-
Each Site is represented by Anycast VTEP BGWs. DF election across BGWs ensures no packet duplication.
-
Traffic between Border Gateways uses ingress replication mechanism. Traffic is encapsulated with VXLAN header followed by IP header.
-
Each Site will only receive one copy of the packet.
-
Multicast source and receiver information across sites is propagated by BGP protocol on the Border Gateways configured with TRM.
-
BGW on each site receives the multicast packet and re-encapsulate the packet before sending it to the local site.
For information about guidelines and limitations for TRM with VXLAN EVPN Multi-Site, see Configuring Tenant Routed Multicast.
Configuring TRM for Single Site Using Cisco Nexus Dashboard Fabric Controller
This section is assumes that a VXLAN EVPN fabric has already been provisioned using Cisco Nexus Dashboard Fabric Controller.
Procedure
Step 1 |
Enable TRM for the selected Easy Fabric. If the fabric template is Easy_Fabric, from the Fabric Overview Actions drop-down, choose the Edit Fabric option. Click the Replication tab. The fields on this tab are: Enable Tenant Routed Multicast (TRM): Select the check box to enable Tenant Routed Multicast (TRM) that allows overlay multicast traffic to be supported over EVPN/MVPN in the VXLAN BGP EVPN fabric. Default MDT Address for TRM VRFs: When you select the Enable Tenant Routed Multicast (TRM) check box, the multicast address for Tenant Routed Multicast traffic is auto populated. By default, this address is from the IP prefix specified in the Multicast Group Subnet field. When you update either field, ensure that the TRM address is chosen from the IP prefix specified in Multicast Group Subnet. Click Save to save the fabric settings. At this point, all the switches turn “Blue” as it will be in the pending state. From the Fabric Overview Actions drop-down list, choose Recalculate Config and then choose Deploy Config to enable the following:
For VXLAN EVPN fabric created using Easy_Fabric_eBGP fabric template, Enable Tenant Routed Multicast (TRM) field and Default MDT Address for TRM VRFs field can be found on the EVPN tab. |
||
Step 2 |
Enable TRM for the VRF. Navigate to Fabric Overview > VRFs > VRFs and edit the selected VRF. Navigate to the Advanced tab and edit the following TRM settings: TRM Enable – Select the check box to enable TRM. If you enable TRM, then the RP address and the underlay multicast address must be entered. Is RP External – Enable this check box if the RP is external to the fabric. If this field is unchecked, RP is distributed in every VTEP.
RP Address – Specifies the IP address of the RP. RP Loopback ID – Specifies the loopback ID of the RP, if Is RP External is not enabled. Underlay Mcast Address – Specifies the multicast address associated with the VRF. The multicast address is used for transporting multicast traffic in the fabric underlay. Overlay Mcast Groups – Specifies the multicast group subnet for the specified RP. The value is the group range in “ip pim rp-address” command. If the field is empty, 224.0.0.0/24 is used as default. Click Save to save the settings. The switches go into the pending state, that is, blue color. These settings enable the following:
|
||
Step 3 |
Enable TRM for the network. Navigate to Fabric Overview > Networks > Networks. Edit the selected network and navigate to the Advanced tab. Edit the following TRM setting: TRM Enable – Select the check box to enable TRM. Click Save to save the settings. The switches go into the pending state, that is, the blue color. The TRM settings enable the following:
|
Configuring TRM for Multi-Site Using Cisco Nexus Dashboard Fabric Controller
This section assumes that a Multi-Site Domain (MSD) has already been deployed by Cisco Nexus Dashboard Fabric Controller and TRM needs to be enabled.
Procedure
Step 1 |
Enable TRM on the BGWs. Navigate to Fabric Overview > VRFs > VRFs. Make sure that the right DC Fabric is selected under the Scope and edit the VRF. Navigate to the Advanced tab. Edit the TRM settings. Repeat this process for every DC Fabric and its VRFs. TRM Enable – Select the check box to enable TRM. If you enable TRM, then the RP address and the underlay multicast address must be entered. Is RP External – Enable this check box if the RP is external to the fabric. If this field is unchecked, RP is distributed in every VTEP.
RP Address – Specifies the IP address of the RP. RP Loopback ID – Specifies the loopback ID of the RP, if Is RP External is not enabled. Underlay Mcast Address – Specifies the multicast address associated with the VRF. The multicast address is used for transporting multicast traffic in the fabric underlay. Overlay Mcast Groups – Specifies the multicast group subnet for the specified RP. The value is the group range in “ip pim rp-address” command. If the field is empty, 224.0.0.0/24 is used as default. Enable TRM BGW MSite - Select the check box to enable TRM on Border Gateway Multi-Site. Click on Save to save the settings. The switches go into the pending state, that is, blue color. These settings enable the following:
|
||
Step 2 |
Establish MVPN AFI between the BGWs. Double-click the MSD fabric to open the Fabric Overview window. Choose Links. Filter it by the policy - Overlays. Select and edit each overlay peering to enable TRM by checking the Enable TRM check box. Click Save to save the settings. The switches go into the pending state, that is, the blue color. The TRM settings enable the MVPN peering’s between the BGWs, or BGWs and Route Server. |
vPC Fabric Peering
vPC Fabric Peering provides an enhanced dual-homing access solution without the overhead of wasting physical ports for vPC Peer Link. This feature preserves all the characteristics of a traditional vPC. For more information, see Information about vPC Fabric Peering section in Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide.
You can create a virtual peer link for two switches or change the existing physical peer link to a virtual peer link. Cisco NDFC support vPC fabric peering in both greenfield as well as brownfield deployments. This feature is applicable for Easy_Fabric and Easy_Fabric_eBGP fabric templates.
Note |
The Easy_Fabric_eBGP fabric does not support brownfield import. |
Guidelines and Limitations
The following are the guidelines and limitations for vPC fabric pairing.
-
vPC fabric peering is supported from Cisco NX-OS Release 9.2(3).
-
Only Cisco Nexus N9K-C9332C Switch, Cisco Nexus N9K-C9364C Switch, Cisco Nexus N9K-C9348GC-FXP Switch as also the Cisco Nexus 9000 Series Switches that ends with FX, and FX2 support vPC fabric peering.
-
Cisco Nexus N9K-C93180YC-FX3S and N9K-C93108TC-FX3P platform switches support vPC fabric peering.
-
Cisco Nexus 9300-EX, and 9300-FX/FXP/FX2/FX3/GX/GX2 platform switches support vPC Fabric Peering. Cisco Nexus 9200 and 9500 platform switches do not support vPC Fabric Peering. For more information, see Guidelines and Limitations for vPC Fabric Peering section in Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide.
-
If you use other Cisco Nexus 9000 Series Switches, a warning will appear during Recalculate & Deploy. A warning appears in this case because these switches will be supported in future releases.
-
If you try pairing switches that do not support vPC fabric peering, using the Use Virtual Peerlink option, a warning will appear when you deploy the fabric.
-
You can convert a physical peer link to a virtual peer link and vice-versa with or without overlays.
-
Switches with border gateway leaf roles do not support vPC fabric peering.
-
vPC fabric peering is not supported for Cisco Nexus 9000 Series Modular Chassis and FEXs. An error appears during Recalculate & Deploy if you try to pair any of these.
-
Brownfield deployments and greenfield deployments support vPC fabric peering in Cisco NDFC.
-
However, you can import switches that are connected using physical peer links and convert the physical peer links to virtual peer links after Recalculate & Deploy. To update a TCAM region during the feature configuration, use the hardware access-list tcam ingress-flow redirect 512 command in the configuration terminal.
QoS for Fabric vPC-Peering
In the Easy_Fabric fabric settings, you can enable QoS on spines for guaranteed delivery of vPC Fabric Peering communication. Additionally, you can specify the QoS policy name.
Note the following guidelines for a greenfield deployment:
-
If QoS is enabled and the fabric is newly created:
-
If spines or super spines neighbor is a virtual vPC, make sure neighbor is not honored from invalid links, for example, super spine to leaf or borders to spine when super spine is present.
-
Based on the Cisco Nexus 9000 Series Switch model, create the recommended global QoS config using the switch_freeform policy template.
-
Enable QoS on fabric links from spine to the correct neighbor.
-
-
If the QoS policy name is edited, make sure policy name change is honored everywhere, that is, global and links.
-
If QoS is disabled, delete all configuration related to QoS fabric vPC peering.
-
If there is no change, then honor the existing PTI.
For more information about a greenfield deployment, see Creating a VXLAN EVPN Fabric Using the Easy_Fabric Template.
Note the following guidelines for a brownfield deployment:
Brownfield Scenario 1:
-
If QoS is enabled and the policy name is specified:
Note
You need to enable only when the policy name for the global QoS and neighbor link service policy is same for all the fabric vPC peering connected spines.
-
Capture the QoS configuration from switch based on the policy name and filter it from unaccounted configuration based on the policy name and put the configuration in the switch_freeform with PTI description.
-
Create service policy configuration for the fabric interfaces as well.
-
Greenfield configuration should make sure to honor the brownfield configuration.
-
-
If the QoS policy name is edited, delete the existing policies and brownfield extra configuration as well, and follow the greenfield flow with the recommended configuration.
-
If QoS is disabled, delete all the configuration related to QoS fabric vPC peering.
Note
No cross check for possible or error mismatch user configuration, and user might see the diff.
Brownfield Scenario 2:
-
If QoS is enabled and the policy name is not specified, QoS configuration is part of the unaccounted switch freeform config.
-
If QoS is enabled from fabric settings after Recalculate & Deploy for brownfield, QoS configuration overlaps and you will see the diff if fabric vPC peering config is already present.
For more information about a brownfield deployment, see Creating a VXLAN EVPN Fabric Using the Easy_Fabric Template.
Fields and Description
To view the vPC pairing window of a switch, from the fabric topology window, right-click the switch and choose vPC Pairing. The vPC pairing window for a switch has the following fields:
Field |
Description |
||
---|---|---|---|
Use Virtual Peerlink |
Allows you to enable or disable the virtual peer linking between switches. |
||
Switch name |
Specifies all the peer switches in a fabric.
|
||
Recommended |
Specifies if the peer switch can be paired with the selected switch. Valid values are true and false. Recommended peer switches will be set to true. |
||
Reason |
Specifies why the vPC pairing between the selected switch and the peer switches is possible or not possible. |
||
Serial Number |
Specifies the serial number of the peer switches. |
You can perform the following with the vPC Pairing option:
Creating a Virtual Peer Link
Procedure
Step 1 |
Choose .The LAN Fabrics window appears. |
||
Step 2 |
Choose a fabric with the Easy_Fabric or Easy_Fabric_eBGPfabric templates. |
||
Step 3 |
On the Topology window, right-click a switch and choose vPC Pairing from the drop-down list. The window to choose the peer appears.
You will get the following error when you choose a switch with the border gateway leaf role. <switch-name> has a Network/VRF attached. Please detach the Network/VRF before vPC Pairing/Unpairing
|
||
Step 4 |
Check the Use Virtual Peerlink check box. |
||
Step 5 |
Choose a peer switch and check the Recommended column to see if pairing is possible. If the value is true, pairing is possible. You can pair switches even if the recommendation is false. However, you will get a warning or error during Recalculate & Deploy. |
||
Step 6 |
Click Save. |
||
Step 7 |
In the Topology window, choose Recalculate & Deploy. The Deploy Configuration window appears. |
||
Step 8 |
Click the field against the switch in the Preview Config column. The Config Preview window appears for the switch. |
||
Step 9 |
View the vPC link details in the pending configuration and side-by-side configuration. |
||
Step 10 |
Close the window. |
||
Step 11 |
Click the pending errors icon next to Recalculate & Deploy icon to view errors and warnings, if any. If you see any warnings that are related to TCAM, click the Resolve icon. A confirmation dialog box about reloading switches appears. Click OK. You can also reload the switches from the topology window. For more information, see Guidelines and Limitations for vPC Fabric Peering and Migrating from vPC to vPC Fabric Peering sections in Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide. The switches that are connected through vPC fabric peering, are enclosed in a gray cloud. |
Converting a Physical Peer Link to a Virtual Peer Link
Before you begin
-
Perform the conversion from physical peer link to virtual peer link during the maintenance window of switches.
-
Ensure the switches support vPC fabric peering. Only the following switches support vPC fabric peering:
-
Cisco Nexus N9K-C9332C Switch, Cisco Nexus N9K-C9364C Switch, and Cisco Nexus N9K-C9348GC-FXP Switch.
-
Cisco Nexus 9000 Series Switches that ends with FX, FX2, and FX2-Z.
-
Cisco Nexus 9300-EX, and 9300-FX/FXP/FX2/FX3/GX/GX2 platform switches. For more information, see Guidelines and Limitations for vPC Fabric Peering section in Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide.
-
Procedure
Step 1 |
Choose .The LAN Fabrics window appears. |
||
Step 2 |
Choose a fabric with the Easy_Fabric or Easy_Fabric_eBGP fabric templates. |
||
Step 3 |
On the Topology window, right-click the switch that is connected using the physical peer link and choose vPC Pairing from the drop-down list. The window to choose the peer appears.
You will get the following error when you choose a switch with the border gateway leaf role. <switch-name> has a Network/VRF attached. Please detach the Network/VRF before vPC Pairing/Unpairing
|
||
Step 4 |
Check the Recommended column to see if pairing is possible. If the value is true, pairing is possible. You can pair switches even if the recommendation is false. However, you will get a warning or error during Recalculate & Deploy. |
||
Step 5 |
Check the Use Virtual Peerlink check box. The Unpair icon changes to Save. |
||
Step 6 |
Click Save.
|
||
Step 7 |
In the Topology window, choose Recalculate & Deploy. The Deploy Configuration window appears. |
||
Step 8 |
Click the field against the switch in the Preview Config column. The Config Preview window appears for the switch. |
||
Step 9 |
View the vPC link details in the pending configuration and the side-by-side configuration. |
||
Step 10 |
Close the window. |
||
Step 11 |
Click the pending errors icon next to the Recalculate & Deploy icon to view errors and warnings, if any. If you see any warnings that are related to TCAM, click the Resolve icon. A confirmation dialog box about reloading switches appears. Click OK. You can also reload the switches from the fabric topology window. The physical peer link between the peer switches turns red. Delete this link. The switches are connected only through a virtual peer link and are enclosed in a gray cloud. |
Converting a Virtual Peer Link to a Physical Peer Link
Before you begin
Procedure
Step 1 |
Choose .The LAN Fabrics window appears. |
||
Step 2 |
Choose a fabric with the Easy_Fabric or Easy_Fabric_eBGPfabric templates. |
||
Step 3 |
On the Topology window, right-click the switch that is connected through a virtual peer link and choose vPC Pairing from the drop-down list. The window to choose the peer appears.
|
||
Step 4 |
Uncheck the Use Virtual Peerlink check box. The Unpair icon changes to Save. |
||
Step 5 |
Click Save. |
||
Step 6 |
In the Topology window, choose Recalculate & Deploy. The Deploy Configuration window appears. |
||
Step 7 |
Click the field against the switch in the Preview Config column. The Config Preview window appears for the switch. |
||
Step 8 |
View the vPC peer link details in the pending configuration and the side-by-side configuration. |
||
Step 9 |
Close the window. |
||
Step 10 |
Click the pending errors icon next to the Recalculate & Deploy icon to view errors and warnings, if any. If you see any warnings that are related to TCAM, click the Resolve icon. The confirmation dialog box about reloading switches appears. Click OK. You can also reload the switches from the fabric topology window. The virtual peer link, represented by a gray cloud, disappears and the peer switches are connected through a physical peer link. |
Precision Time Protocol for Easy Fabric
In the fabric settings for the Easy_Fabric template, select the Enable Precision Time Protocol (PTP) check box to enable PTP across a fabric. When you select this check box, PTP is enabled globally and on core-facing interfaces. Additionally, the PTP Loopback Id and PTP Domain Id fields are editable.
The PTP feature works only when all the devices in a fabric are cloud-scale devices. Warnings are displayed if there are non-cloud scale devices in the fabric, and PTP is not enabled. Examples of the cloud-scale devices are Cisco Nexus 93180YC-EX, Cisco Nexus 93180YC-FX, Cisco Nexus 93240YC-FX2, and Cisco Nexus 93360YC-FX2 switches.
For more information, see the Configuring PTP chapter in Cisco Nexus 9000 Series NX-OS System Management Configuration Guide and Cisco Nexus Dashboard Insights User Guide.
For Nexus Dashboard Fabric Controller deployments, specifically in a VXLAN EVPN based fabric deployments, you have to enable PTP globally, and also enable PTP on core-facing interfaces. The interfaces could be configured to the external PTP server like a VM or Linux-based machine. Therefore, the interface should be edited to have a connection with the grandmaster clock.
It is recommended that the grandmaster clock should be configured outside of Easy Fabric and it is IP reachable. The interfaces toward the grandmaster clock need to be enabled with PTP via the interface freeform config.
All core-facing interfaces are auto-enabled with the PTP configuration after you click Deploy Config. This action ensures that all devices are PTP synced to the grandmaster clock. Additionally, for any interfaces that are not core-facing, such as interfaces on the border devices and leafs that are connected to hosts, firewalls, service-nodes, or other routers, the ttag related CLI must be added. The ttag is added for all traffic entering the VXLAN EVPN fabric and the ttag must be stripped when traffic is exiting this fabric.
Here is the sample PTP configuration:
feature ptp
ptp source 100.100.100.10 -> IP address of the loopback interface (loopback0) that is already created or user created loopback interface in the fabric settings
ptp domain 1 -> PTP domain ID specified in fabric settings
interface Ethernet1/59 -> Core facing interface
ptp
interface Ethernet1/50 -> Host facing interface
ttag
ttag-strip
The following guidelines are applicable for PTP:
-
The PTP feature can be enabled in a fabric when all the switches in the fabric have Cisco NX-OS Release 7.0(3)I7(1) or a higher version. Otherwise, the following error message is displayed:
PTP feature can be enabled in the fabric, when all the switches have NX-OS Release 7.0(3)I7(1) or higher version. Please upgrade switches to NX-OS Release 7.0(3)I7(1) or higher version to enable PTP in this fabric.
-
For hardware telemetry support in NIR, the PTP configuration is a prerequisite.
-
If you are adding a non-cloud scale device to an existing fabric which contains PTP configuration, the following warning is displayed:
TTAG is enabled fabric wide, when all devices are cloud scale switches so it cannot be enabled for newly added non cloud scale device(s).
-
If a fabric contains both cloud scale and non-cloud scale devices, the following warning is displayed when you try to enable PTP:
TTAG is enabled fabric wide, when all devices are cloud scale switches and is not enabled due to non cloud scale device(s).
Support for Super Spine Switch Role
Super Spine is a device that is used for interconnecting multiple spine-leaf PODs. You have an extra interconnectivity option with super spines. You can have multiple spine-leaf PODs within the same Easy Fabric that are interconnected via super spines such that, the same IGP domain extends across all the PODs, including the super spines. Within such a deployment, the BGP RRs and RPs (if applicable) are provisioned on the super spine layer. The spine layer becomes a pseudo interconnect between the leafs and super spines. VTEPs may be optionally hosted on the super spines if they have the border functionality.
The following super spine switch roles are supported in NDFC:
-
Super Spine
-
Border Super Spine
-
Border Gateway Super Spine
A border super spine handles multiple functionalities including the functionalities of a super spine, RR, RP (optionally), and a border leaf. Similarly, a border gateway super spine serves a super spine, RR, RP (optional), and a border gateway. It is not recommended to overload border functionality on the super spine or RR layer. Instead, attach border leafs or border gateways to the super spine layer for external connectivity. The super spine layer serves as the interconnect with the RR or RP functionality.
The following are the characteristics of super spine switch roles in NDFC:
-
Supported with Easy Fabrics only.
-
From Cisco NDFC Release 12.1.1e, Super Spine switch role and Border Super Spine switch role are also supported with the eBGP routed fabrics for IPv6 underlay using Easy_Fabric_eBGP template.
-
Can only connect to spines and borders. The valid connections are:
-
Spines to super spines
-
Spines to border super spines and border gateway super spines
-
Super spines to border leafs and border gateway leafs.
-
-
RR or RP (if applicable) functionality is always be configured on super spines if they are present in a fabric. The maximum number of 4 RRs and RPs are supported even with Super Spines.
-
Border Super Spine and Border Gateway Super Spine roles are supported for inter-fabric connections.
-
vPC configurations aren’t supported on super spines.
-
Super spines don’t support IPv6 underlay configuration.
-
During the Brownfield import of switches, if a switch has the super spine role, the following error is displayed:
Serial number: [super spine/border super spine/border gateway superspine] Role isn’t supported with preserved configuration yes option.
Supported Topologies for Super Spine Switches
NDFC supports the following topologies with super spine switches.
Topology 1: Super Spine Switches in a Spine Leaf Topology
In this topology, leaf switches are connected to spines, and spines are connected to super spine switches which can be super spines, border super spines, and border gateway super spines.
Topology 2: Super Spine Switches Connected to Border
In this topology, there are four leaf switches connecting to the spine switches, which are connected to two super spine switches. These super spine switches are connected to the border or border gateway leaf switches.
Adding a Super Spine Switch to an Existing VXLAN BGP EVPN Fabric
To add a super spine switch to an existing VXLAN BGP EVPN fabric, perform the following steps:
Procedure
Step 1 |
Choose . Double-click on the required fabric.The Fabric Overview window appears. |
||
Step 2 |
On the Switches tab, click . For more information, see Adding Switches to a Fabric. |
||
Step 3 |
Right-click on an existing switch or the newly added switch, and use the Set role option to set the appropriate super spine role.
|
||
Step 4 |
On the Fabric Overview window, click . The following error message is displayed: Super Spine role cannot be allowed in the existing fabric as it is disruptive. Please go to 'Event Analytics' and click on the resolve button to proceed. |
||
Step 5 |
Choose ID. , click on theThe Alarm ID slide-in pane appears. |
||
Step 6 |
Click Resolve. The Confirm action dialog box appears. |
||
Step 7 |
Click Confirm. |
||
Step 8 |
On the Fabric Overview window, click . Do not add a devices with super spine, border super spine, or border gateway super spine role if the device is connected to a border spine or border gateway spine. This action results in an error after you recalculate and deploy the configuration. To use existing devices with border spine roles, remove the device and add the device with appropriate roles. |
Overlay Mode
You can create a VRF or network in CLI or config-profile mode at the fabric level. The overlay mode of member fabrics of an MSD fabric is set individually at the member-fabric level. Overlay mode can only be changed before deploying overlay configurations to the switches. After the overlay configuration is deployed, you cannot change the mode unless all the VRF and network attachments are removed.
Note |
If you upgrade from Cisco DCNM Release 11.5(x), the existing config-profile mode functions the same. |
If the switch has config-profile based overlays, you can import it in the config-profile overlay mode only. If you import it in the cli overlay mode, an error appears during brownfield import.
For brownfield import, if overlay is deployed as config-profile mode, it can be imported in config-profile mode only. However, if overlay is deployed as cli, it can be imported in either config-profile or cli modes.
To choose the overlay mode of VRFs or networks in a fabric, perform the following steps:
-
Navigate to the Edit Fabric window.
-
Go to the Advanced tab.
-
From the Overlay Mode drop-down list, choose config-profile or cli.
The default mode is config-profile.
Sync up Out-of-Band Switch Interface Configurations
Any interface level configuration made outside of Nexus Dashboard Fabric Controller (via CLI) can be synced to Nexus Dashboard Fabric Controller and then managed from Nexus Dashboard Fabric Controller. Also, the vPC pair configurations are automatically detected and paired. This applies to the External_Fabric and LAN_Classic fabrics only. The vPC pairing is performed with the vpc_pair policy.
Note |
When Nexus Dashboard Fabric Controller is managing switches, ensure that all configuration changes are initiated from Nexus Dashboard Fabric Controller and avoid making changes directly on the switch. |
When the interface config is synced up to the Nexus Dashboard Fabric Controller intent, the switch configs are considered as the reference, that is, at the end of the sync up, the Nexus Dashboard Fabric Controller intent reflects what is present on the switch. If there were any undeployed intent on Nexus Dashboard Fabric Controller for those interfaces before the resync operation, they will be lost.
Guidelines
-
Supported in fabrics using the following templates: Easy_Fabric, External_Fabric, and LAN_Classic.
-
Supported for Cisco Nexus switches only.
-
Supported for interfaces that don’t have any fabric underlay related policy associated with them prior to the resync. For example, IFC interfaces and intra fabric links aren’t subjected to resync.
-
The time taken by host port resync depends on the number of switches/interfaces to be synchronized.
-
Supported for interfaces that do not have any custom policy (policy template that isn’t shipped with Cisco Nexus Dashboard Fabric Controller) associated with them prior to resync.
-
Supported for interfaces where the intent is not exclusively owned by a Cisco Nexus Dashboard Fabric Controller feature and/or application prior to resync.
-
Supported on switches that don’t have Interface Groups associated with them.
-
Interface mode (switchport to routed, trunk to access, and so on) changes aren’t supported with overlays attached to that interface.
The sync up functionality is supported for the following interface modes and policies:
Interface Mode | Policies |
trunk (standalone, po, and vPC PO) |
|
access (standalone, po, and vPC PO) |
|
dot1q-tunnel |
|
routed |
int_routed_host |
loopback |
int_freeform |
sub-interface |
int_subif |
FEX (ST, AA) |
|
breakout |
interface_breakout |
nve | int_freeform (only in External_Fabric/LAN_Classic) |
SVI | int_freeform (only in External_Fabric/LAN_Classic) |
mgmt0 | int_mgmt |
In an Easy fabric, the interface resync will automatically update the network overlay attachments based on the access VLAN or allowed VLANs on the interface.
After the resync operation is completed, the switch interface intent can be managed using normal Nexus Dashboard Fabric Controller procedures.
Syncing up Switch Interface Configurations
It is recommended to deploy all switch configurations from NDFC. In some scenarios, it may be necessary to make changes to the switch interface configuration out-of-band. This will cause configuration drift causing switches to be reported Out-of-Sync.
NDFC supports syncing up the out-of-band interface configuration changes back into its intent.
Guidelines and Limitations
The following limitations are applicable after Syncing up Switch Interface Configurations to NDFC:
-
The port channel membership changes (once the policy exists) is not supported.
-
Changing the interface mode (trunk to access etc.) that have overlays attached is not supported.
-
Resync for interfaces that belong to Interface Groups are not supported.
-
The vPC pairing in External_Fabric and LAN_Classic templates must be updated with the vpc_pair policy.
-
This feature is supported for easy fabric, external fabric and LAN classic fabric.
-
The resync can be performed for a set of switches and repeated as desired.
-
The time taken by host port resync depends on the number of switches/interfaces to be synchronized.
-
In Easy_Fabric fabrics, VXLAN overlay interface attachments are performed automatically based on the allowed VLANs.
Before you begin
-
We recommend taking a fabric backup before attempting the interface resync.
-
In External_Fabric and LAN_Classic fabrics, for the vPC pairing to work correctly, both the switches must be in the fabric and must be functional.
-
Ensure that the switches are In-Sync and switch mode must not be Migration or Maintenance.
-
From the Actions drop-list, choose to ensure that NDFC is aware of any new interfaces and other changes.
Procedure
Step 1 |
Choose and double-click on a fabric.The Fabric Overview window appears. |
||||
Step 2 |
Click the Switches tab and ensure that switches are present in the fabric and vPC pairings are completed. |
||||
Step 3 |
Click the Policies tab and select one or more switches where the interface intent resync is needed.
|
||||
Step 4 |
From the Actions drop-down list, choose Add Policy. The Create Policy window appears. |
||||
Step 5 |
On the Create Policy window, choose host_port_resync from the Policy drop-down list. |
||||
Step 6 |
Click Save. |
||||
Step 7 |
Check the Mode column for the switches to ensure that they report Migration. For a vPC pair, both switches are in the Migration-mode.
|
||||
Step 8 |
After the configuration changes are ready to sync up to NDFC, navigate to the Switches tab and select the required switches. |
||||
Step 9 |
Click Recalculate & Deploy to start the resync process.
|
||||
Step 10 |
The Deploy Configuration window is displayed if no errors are detected during the resync operation. The interface intent is updated in NDFC.
Close the Deploy Configuration window, and you can see that the switches are automatically moved out of the Migration-mode. Switches in a vPC pair that were not paired or paired with no_policy show up as paired and associated with the vpc_pair policy.
|
Configuration Compliance
The entire intent or expected configuration defined for a given switch is stored in NDFC. When you want to push this configuration down to one or more switches, the configuration compliance (CC) module is triggered. CC takes the current intent, the current running configuration, and then comes up with the set of configurations that are required to go from the current running configuration to the current expected configuration so that everything will be In-Sync.
When performing a software or firmware upgrade on the switches, the current running configuration on the switches is not changed. Post upgrade, if CC finds that the current running configuration does not have the current expected configuration or intent, it reports an Out-of-Sync status. There is no auto deployment of any configurations. You can preview the diffs that will get deployed to get one or more devices back In-Sync.
With CC, the sync is always from the NDFC to the switches. There is no reverse sync. So, if you make a change out-of-band on the switches that conflicts with the defined intent in NDFC, CC captures this diff, and indicates that the device is Out-of-Sync. The pending diffs will undo the configurations done out-of-band to bring back the device In-Sync. Note that such conflicts due to out-of-band changes are captured by the periodic CC run that occurs every 60 minutes by default, or when you click the RESYNC option either on a per fabric or per switch basis. From Cisco NDFC Release 12.1.1e, the periodic CC runs every 24 hours. You can configure the custom interval with the range of 30-3600 minutes. This configuration can be done by navigating to . Note that you can also capture the out-of-band changes for the entire switch by using the CC REST API. For more information, see Cisco NDFC REST API Guide.
To improve ease of use and readability of deployed configurations, CC in NDFC has been enhanced with the following:
-
All displayed configurations in NDFC are easily readable and understandable.
-
Repeated configuration snippets are not displayed.
-
Pending configurations precisely show only the diff configuration.
-
Side-by-side diffs has greater readability, integrated search or copy, and diff summary functions.
Top-level configuration commands on the switch that do not have any associated NDFC intent are not checked for compliance by CC. However, CC performs compliance checks, and attempts removal, of the following commands even if there is no NDFC intent:
-
configure profile
-
apply profile
-
interface vlan
-
interface loopback
-
interface Portchannel
-
Sub-interfaces, for example, interface Ethernet X/Y.Z
-
fex
-
vlan <vlan-ids>
CC performs compliance checks, and attempts removal, of these commands only when Easy_Fabric and Easy_Fabric_eBGP templates are used. On External_Fabric and LAN_Classic templates, top-level configuration commands on the switch, including the commands mentioned above, that do not have any associated NDFC intent are not checked for compliance by CC.
We recommend using the NDFC freeform configuration template to create additional intent and deploy these commands to the switches to avoid unexpected behavior
Now, consider a scenario in which the configuration that exists on the switch has no relationship with the configuration defined in the intent. Examples of such configurations are a new feature that has not been captured in the intent but is present on the switch or some other configuration aspect that has not been captured in the intent. Configuration compliance does not consider these configuration mismatches as a diff. In such cases, Strict Configuration Compliance ensures that every configuration line that is defined in the intent is the only configuration that exists on the switch. However, configuration such as boot string, rommon configuration, and other default configurations are ignored during strict CC checks. For such cases, the internal configuration compliance engine ensures that these config changes are not called out as diffs. These diffs are also not displayed in the Pending Config window. But, the Side-by-side diff utility compares the diff in the two text files and does not leverage the internal logic used in the diff computation. As a result, the diff in default configurations are highlighted in red in the Side-by-side Comparison window.
In NDFC, the diffs in default configurations are not highlighted in the Side-by-side Comparison window. The auto-generated default configuration that is highlighted in the Running config window is not visible in the Expected config window.
Any configurations that are shown in the Pending Config window are highlighted in red in the Side-by-side Comparison window if the configurations are seen in the Running config window but not in the Expected config window. Also, any configurations that are shown in the Pending Config window are highlighted in green in the Side-by-side Comparison window if the configurations are seen in the Expected config window but not in the Running config window. If there are no configurations displayed in the Pending Config window, no configurations are shown in red in the Side-by-side Comparison window.
All freeform configurations have to strictly match the show running configuration output on the switch and any deviations from the configuration will show up as a diff during Recalculate & Deploy. You need to adhere to the leading space indentations.
You can typically enter configuration snippets in NDFC using the following methods:
-
User-defined profile and templates
-
Switch, interface, overlay, and vPC freeform configurations
-
Network and VRF per switch freeform configurations
-
Fabric settings for Leaf, Spine, or iBGP configurations
Caution |
The configuration format should be identical to the show running configuration of the corresponding switch. Otherwise, any missing or incorrect leading spaces in the configuration can cause unexpected deployment errors and unpredictable pending configurations. If any unexpected diffs or deployment errors are displayed, check the user-provided or custom configuration snippets for incorrect values. |
If NDFC displays the "Out-of-Sync" status due to unexpected pending configurations, and this configuration is either unable to be deployed or stays consistent even after a deployment, perform the following steps to recover:
-
Check the lines of config highlighted under the Pending Config tab in the Config Preview window.
-
Check the same lines in the corresponding Side-by-side Comparison tab. This tab shows whether the diff exists in "intent", or "show run", or in both with different leading spaces. Leading spaces are highlighted in the Side-by-side Comparison tab.
-
If the pending configurations or switch with an out-of-sync status is due to any identifiable configuration with mismatched leading spaces in "intent" and "running configuration", this indicates that the intent has incorrect spacing and needs to be edited.
-
To edit incorrect spacing on any custom or user-defined policies, navigate to the switch and edit the corresponding policy:
-
If the source of the policy is UNDERLAY, you will need to edit this from the Fabric settings screen and save the updated configuration.
-
If the source is blank, it can be edited from the View/Edit policies window for that switch.
-
If the source of the policy is OVERLAY, but it is derived from a switch freeform configuration. In this case, navigate to the appropriate OVERLAY switch freeform configuration and update it.
-
If the source of the policy is OVERLAY or a custom template, perform the following steps:
-
Choose Settings > Server settings, set the template.in_use.check property to false and uncheck the Template In-Use Override check box and Save. This allows the profiles or templates to be editable.
-
Edit the specific profile or template from the Operations > Templates > Edit template properties edit window, and save the updated profile template with the right spacing.
-
Click Recalculate & Deploy to recompute the diffs for the impacted switches.
-
After the configurations are updated, set the template.in_use.check property to true and check the Template In-Use Override check box and Save, as it slows down the performance of the NDFC system, specifically for Recalculate & Deploy operations.
-
-
To confirm that the diffs have been resolved, click Recalculate & Deploy after updating the policy to validate the changes.
Note |
NDFC checks only leading spaces, as it implies hierarchy of the command, especially in case of multi-command sequences. NDFC does not check any trailing spaces in command sequences. |
Example 1: Configuration Compliance in Switch Freeform Policy
Let us consider an example with an incorrect spacing in the Switch Freeform Configuration field.
Create the switch freeform policy.
After deploying this policy successfully to the switch, NDFC persistently reports the diffs.
After clicking the Side-by-side Comparison tab, you can see the cause of the diff. The ip pim rp-address line has 2 leading spaces, while the running configuration has 0 leading spaces.
To resolve this diff, edit the corresponding Switch Freeform policy so that the spacing is correct.
After you save, you can use the Push Config or Recalculate & Deploy option to re-compute diffs.
The diffs are now resolved. The Side-by-side Comparison tab confirms that the leading spaces are updated.
Example 2: Resolving a Leading Space Error in Overlay Configurations
Let us consider an example with a leading space error that is displayed in the Pending Config tab.
In the Side-by-side Comparison tab, search for diffs line by line to understand context of the deployed configuration.
A matched count of 0 means that it is a special configuration that NDFC has evaluated to push it to the switch.
You can see that the leading spaces are mismatched between running and expected configurations.
Navigate to the respective freeform configs and correct the leading spaces, and save the updated configuration.
Navigate to Fabric Overview window for the fabric and click Recalculate & Deploy.
In the Deply Configuration window, you can see that all the devices are in-sync.
Configuration Compliance in External Fabrics
With external fabrics, any Nexus switches, Cisco IOS-XE devices, Cisco IOS XR devices, and Arista can be imported into the fabric, and there is no restriction on the type of deployment. It can be LAN Classic, VXLAN, FabricPath, vPC, HSRP, etc. When switches are imported into an external fabric, the configuration on the switches is retained so that it is non-disruptive. Only basic policies such as the switch username and mgmt0 interface are created after a switch import.
In the external fabric, for any intent that is defined in the Nexus Dashboard Fabric Controller, configuration compliance (CC) ensures that this intent is present on the corresponding switch. If this intent is not present on the switch, CC reports an Out-of-Sync status. Additionally, there will be a Pending Config generated to push this intent to the switch to change the status to In-Sync. Any additional configuration that is on the switch but not in intent defined in Nexus Dashboard Fabric Controller, will be ignored by CC, as long as there is no conflict with anything in the intent.
When there is user-defined intent added on Nexus Dashboard Fabric Controller and the switch has additional configuration under the same top-level command, as mentioned earlier, CC will only ensure that the intent defined in Nexus Dashboard Fabric Controller is present on the switch. When this user defined intent on Nexus Dashboard Fabric Controller is deleted as a whole with the intention of removing it from the switch and the corresponding configuration exists on the switch, CC will report an Out-of-Sync status for the switch and will generate Pending Config to remove the config from the switch. This Pending Config includes the removal of the top-level command. This action leads to removal of the other out-of-band configurations made on the switch under this top-level command as well. If you choose to override this behavior, the recommendation is that, you create a freeform policy and add the relevant top-level command to the freeform policy.
Let us see this behavior with an example.
-
A switch_freeform policy defined by the user in Nexus Dashboard Fabric Controller and deployed to the switch.
-
Additional configuration exists under router bgp in Running config that does not exist in user-defined Nexus Dashboard Fabric Controller intent Expected config. Note that there is no Pending Config to remove the additional config that exists on the switch without a user defined intent on Nexus Dashboard Fabric Controller.
-
The Pending Config and the Side-by-side Comparison when the intent that was pushed earlier via Nexus Dashboard Fabric Controller is deleted from Nexus Dashboard Fabric Controller by deleting the switch_freeform policy that was created in the Step 1.
-
A switch_freeform policy with the top-level router bgp command needs to be created. This enables CC to generate the configuration needed to remove only the desired sub-config which was pushed from Nexus Dashboard Fabric Controller earlier.
-
The removed configuration is only the subset of the configuration that was pushed earlier from Nexus Dashboard Fabric Controller.
For interfaces on the switch in the external fabric, Nexus Dashboard Fabric Controller either manages the entire interface or does not manage it at all. CC checks interfaces in the following ways:
-
For any interface, if there is a policy defined and associated with it, then this interface is considered as managed. All configurations associated with this interface must be defined in the associated interface policy. This is applicable for both logical and physical interfaces. Otherwise, CC removes any out-of-band updates made to the interface to change the status to In-Sync.
-
Interfaces created out-of-band (applies for logical interfaces such as port-channels, sub interfaces, SVIs, loopbacks, etc.), will be discovered by Nexus Dashboard Fabric Controller as part of the regular discovery process. However, since there is no intent for these interfaces, CC will not report an Out-of-Sync status for these interfaces.
-
For any interface, there can always be a monitor policy associated with it in Nexus Dashboard Fabric Controller. In this case, CC will ignore the interface’s configuration when it reports the In-Sync or Out-of-Sync config compliance status.
-
Special Configuration CLIs Ignored for Configuration Compliance
The following configuration CLIs are ignored during configuration compliance checks:
-
Any CLI having 'username’ along with ‘password’
-
Any CLI that starts with ‘snmp-server user’
Any CLIs that match the above will not show up in pending diffs and clicking Save & Deploy in the Fabric Builder window will not push such configurations to the switch. These CLIs will not show up in the Side-by-side Comparison window also.
To deploy such configuration CLIs, perform the following procedure:
Procedure
Step 1 |
Select LAN > Fabrics. Double click on the fabric name to view Fabric Overview screen. |
Step 2 |
On the Switches tab, double click on the switch name to view Switch Overview screen. On the Policies tab, all the policies applied on the switch within the chosen fabric are listed. |
Step 3 |
On the Policies tab, from the Actions drop-down list, select Add Policy. |
Step 4 |
Add a Policy Template Instances (PTIs) with the required configuration CLIs using the switch_freeform template and click Save. |
Step 5 |
Select the created policy and select Push Config from the Actions drop-down list to deploy the configuration to the switch(es). |
Resolving Diffs for Case Insensitive Commands
By default, all diffs generated in NDFC while comparing intent, also known as Expected Configuration, and Running Configuration, are case sensitive. However, the switch has many commands that are case insensitive, and therefore it may not be appropriate to flag these commands as differences. These are captured in the compliance_case_insensitive_clis.txt template that can be found under .
From Cisco NDFC Release 12.0.1a, compliance_case_insensitive_clis.txt file, along with compliance_strict_cc_exclude_clis.txt and compliance_ipv6_clis.txt files are now part of the shipped templates. You can find all the templates under . Modification of templates can be done after disabling Template In-Use Override.
There could be additional commands not included in the existing compliance_case_insensitive_clis.txt file that should be treated as case insensitive. If the pending configuration is due to the differences of cases between the Expected Configuration in NDFC and the Running Configuration, you can configure NDFC to ignore these case differences as follows:
-
Navigate to Template In-Use Override and then click Save.
, uncheck -
Navigate to compliance_case_insensitive_clis.txt file.
and search for -
Check compliance_case_insensitive_clis.txt and choose .
An example of the entries in the compliance_case_insensitive_clis.txt file is displayed in the following figure.
-
Remove the entries highlighted in the figure and click Finish.
-
If newer patterns are detected during deployment, and they are triggering pending configurations, you can add these patterns to this file. The patterns need to be valid regex patterns.
-
Navigate to Template In-Use Override and then click Save.
, checkThis enables NDFC to treat the documented configuration patterns as case insensitive while performing comparisons.
-
Click Recalculate & Deploy for fabrics to view the updated comparison outputs.
Resolving Configuration Compliance After Importing Switches
After importing switches in Cisco NDFC, configuration compliance for a switch can fail because of an extra space in the management interface (mgmt0) description field.
For example, before importing the switch:
interface mgmt0
description SRC=SDS-LB-LF111-mgmt0, DST=SDS-LB-SW001-Fa0/5
After importing the switch and creating a configuration profile:
interface mgmt0
description SRC=SDS-LB-LF111-mgmt0,DST=SDS-LB-SW001-Fa0/5
Navigate to Interface Manager and click the Edit icon after selecting the mgmt0 interface. Remove the extra space in the description.
Strict Configuration Compliance
Strict configuration compliance checks for diff between the switch configuration and the associated intent and generates no commands for the configurations that present on the switch but are not present in the associated intent. When you click Recalculate and Deploy, switch configurations that are not present on the associated intent are removed. You can enable this feature by choosing the Enable Strict Config Compliance check box under the Advanced tab in the Create Fabric or Edit Fabric window. By default, this feature is disabled.
The strict configuration compliance feature is supported on the Easy Fabric templates - Easy_Fabric and Easy_Fabric_eBGP. To avoid generating diff for commands that are auto-generated by the switch, such as vdc, rmon, and so on, a file that has a list of default commands is used by CC to ensure that diffs are not generated for these commands. This file is maintained in , compliance_strict_cc_exclude_clis.txt template.
Example: Strict Configuration Compliance
Let us consider an example in which the feature telnet command is configured on a switch but is not present in the intent. In such a scenario, the status of the switch is displayed as Out-of-sync after a CC check is done.
Now, click Preview Config of the out-of-sync switch. As the strict configuration compliance feature is enabled, the no form of the feature telnet command appears under Pending Config in the Preview Config window.
Click the Side-by-side Comparison tab to display the differences between the running configuration and the expected configuration. The Re-sync button is also displayed at the top right corner under the Side-by-side Comparison tab in the Preview Config window. Use this option to resynchronize NDFC state when there is a large scale out-of-band change, or if configuration changes do not register in the NDFC properly.
The re-sync operation does a full CC run for the switch and recollects “show run” and “show run all” commands from the switch. When you initiate the re-sync process, a progress message is displayed. During the re-sync, the running configuration is taken from the switch. The Out-of- Sync/In-Sync status for the switch is recalculated based on the intent defined in NDFC.
Now, close the Preview Config window and click Recalculate and Deploy. The strict configuration compliance feature ensures that the running configuration on the switch does not deviate from the intent by pushing the no form of the feature telnet command to the switch. The diff between the configurations is highlighted. The diff other than the feature telnet command are default switch and boot configurations and are ignored by the strict CC check.
You can right-click on a switch in the Fabric Overview window and select Preview Config to display the Preview Config window. This window displays the pending configuration that has to be pushed to the switch to achieve configuration compliance with the intent.
Custom freeform configurations can be added in NDFC to make the intended configuration on NDFC and the switch configurations identical. The switches are then in In-Sync status. For more information on how to add custom freeform configurations on NDFC, refer Enabling Freeform Configurations on Fabric Switches.
Enabling Freeform Configurations on Fabric Switches
In Nexus Dashboard Fabric Controller, you can add custom configurations through freeform policies in the following ways:
-
Fabric-wide:
-
On all leaf, border leaf, and border gateway leaf switches in the fabric, at once.
-
On all spine, super spine, border spine, border super spine, border gateway spine and border switches, at once.
-
-
On a specific switch at the global level.
-
On a specific switch on a per Network or per VRF level.
-
On a specific interface on a switch.
Leaf switches are identified by the roles Leaf, Border, and Border Gateway. The spine switches are identified by the roles Spine, Border Spine, Border Gateway Spine, Super Spine, Border Super Spine, and Border Gateway Super Spine.
Note |
You can deploy freeform CLIs when you create a fabric or when a fabric is already created. The following examples are for an existing fabric. However, you can use this as a reference for a new fabric. |
Deploying Fabric-Wide Freeform CLIs on Leaf and Spine Switches
-
Choose LAN > Fabrics > Fabrics.
-
Select the Fabric, and select Edit Fabric from Actions drop-down list.
(If you are creating a fabric for the first time, click Create Fabric).
-
Click the Advanced tab and update the following fields:
Leaf Freeform Config – In this field, add configurations for all leaf, border leaf, and border gateway leaf switches in the fabric.
Spine Freeform Config - In this field, add configurations for all Spine, Border Spine, Border Gateway Spine, Super Spine, Border Super Spine, and Border Gateway Super Spine switches in the fabric.
Note
Copy-paste the intended configuration with correct indentation, as seen in the running configuration on the Nexus switches. For more information, see Resolving Freeform Config Errors in Switches.
-
Click Save. The fabric topology screen comes up.
-
Click Deploy Config from the Actions drop-down list to save and deploy configurations.
Configuration Compliance functionality ensures that the intended configuration as expressed by those CLIs are present on the switches and if they are removed or there is a mismatch, then it flags it as a mismatch and indicate that the device is Out-of-Sync.
Incomplete Configuration Compliance - On some Cisco Nexus 9000 Series switches, in spite of configuring pending switch configurations using the Deploy Config option, there could be a mismatch between the intended and switch configuration. To resolve the issue, add a switch_freeform policy to the affected switch (as explained in the Deploy Freeform CLIs on a Specific Switch section). For example, consider the following persistent pending configurations:
line vty
logout-warning 0
After adding the above configurations in a policy and saving the updates, click Deploy Config in the topology screen to complete the deployment process.
To bring back the switch in-sync, you can add the above configuration in a switch_freeform policy saved and deployed onto the switch.
Deploying Freeform CLIs on a Specific Switch
-
Choose LAN > Fabrics > Fabrics.
-
Select the Fabric, and select Edit Fabric from Actions drop-down list.
-
Click Policies tab. From the Actions drop-down list, choose Add Policy.
The Create Policy screen comes up.
Note
To provision freeform CLIs on a new fabric, you have to create a fabric, import switches into it, and then deploy freeform CLIs.
-
In the Priority field, the priority is set to 500 by default. You can choose a higher priority (by specifying a lower number) for CLIs that need to appear higher up during deployment. For example, a command to enable a feature should appear earlier in the list of commands.
-
In the Description field, provide a description for the policy.
-
From the Template Name field, select freeform_policy.
-
Add or update the CLIs in the Freeform Config CLI box.
Copy-paste the intended configuration with correct indentation, as seen in the running configuration on the Nexus switches. For more information, see Resolving Freeform Config Errors in Switches.
-
Click Save.
After the policy is saved, it gets added to the intended configurations for that switch.
-
From the Fabric Overview window, click the Switches tab and choose the required switches.
-
On the Switches tab, click Actions drop-down list and choose Deploy.
Pointers for freeform_policy Policy Configuration:
-
You can create multiple instances of the policy.
-
For a vPC switch pair, create consistent freeform_policy policies on both the vPC switches.
-
When you edit a freeform_policy policy and deploy it onto the switch, you can see the changes being made (in the Side-by-side tab of the Preview option).
Freeform CLI Configuration Examples
Console line configuration
This example involves deploying some fabric-wide freeform configurations (for all leaf, and spine switches), and individual switch configurations.
Fabric-wide session timeout configuration:
line console
exec-timeout 1
Console speed configuration on a specific switch:
line console
speed 115200
IP Prefix List/Route-map configuration
IP prefix list and route-map configurations are typically configured on border devices. These configurations are global because they can be defined once on a switch and then applied to multiple VRFs as needed. The intent for this configuration can be captured and saved in a switch_freeform policy. As mentioned earlier, note that the configuration saved in the policy should match the show run output. This is especially relevant for prefix lists where the NX-OS switch may generate sequence numbers automatically when configured on the CLI. An example snippet is shown below:
ip prefix-list prefix-list-name1 seq 5 permit 20.2.0.1/32
ip prefix-list prefix-list-name1 seq 6 permit 20.2.0.2/32
ip prefix-list prefix-list-name2 seq 5 permit 192.168.100.0/24
ACL configuration
ACL configurations are typically configured on specific switches and not fabric-wide (leaf/spine switches). When you configure ACLs as freeform CLIs on a switch, you should include sequence numbers. Else, there will be a mismatch between the intended and running configuration. A configuration sample with sequence numbers:
ip access-list ACL_VTY
10 deny tcp 172.29.171.67/32 172.29.171.36/32
20 permit ip any any
ip access-list vlan65-acl
10 permit ip 69.1.1.201/32 65.1.1.11/32
20 deny ip any any
interface Vlan65
ip access-group vlan65-acl in
line vty
access-class ACL_VTY in
If you have configured ACLs without sequence numbers in a freeform_policy policy, update the policy with sequence numbers as shown in the running configuration of the switch.
After the policy is updated and saved, right click the device and select the per switch Deploy Config option to deploy the configuration.
Resolving Freeform Config Errors in Switches
Copy-paste the running-config to the freeform config with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running config. Otherwise, configuration compliance in Nexus Dashboard Fabric Controller marks switches as out-of-sync.
Let us see an example of the freeform config of a switch.
feature bash-shell
feature telemetry
clock timezone CET 1 0
# Daylight saving time is observed in Metropolitan France from the last Sunday in March (02:00 CET) to the last Sunday in October (03:00 CEST)
clock summer-time CEST 5 Sunday March 02:00 5 Sunday October 03:00 60
clock protocol ntp
telemetry
destination-profile
use-vrf management
The highlighted line about the daylight saving time is a comment that is not displayed in the show running config command output. Therefore, configuration compliance marks the switch as out-of-sync because the intent does not match the running configuration.
Let us check the running config in the switch for the clock protocol.
spine1# show run all | grep "clock protocol"
clock protocol ntp vdc 1
You can see that vdc 1 is missing from the freeform config.
In this example, let us copy-paste the running config to the freeform config.
Here is the updated freeform config:
feature bash-shell
feature telemetry
clock timezone CET 1 0
clock summer-time CEST 5 Sunday March 02:00 5 Sunday October 03:00 60
clock protocol ntp vdc 1
telemetry
destination-profile
use-vrf management
After you copy-paste the running config and deploy, the switch will be in-sync. When you click Recalculate Config, click the Pending Config column. The Side-by-Side Comparison to view information about the difference between the defined intent and the running config.
Deploying Freeform CLIs on a Specific Switch on a Per VRF/Network basis
-
Choose LAN > Fabrics > Fabrics.
-
Select the Fabric, and select Edit Fabric from Actions drop-down list.
-
Click VRFs tab. From the Actions drop-down list, select Create.
The Create VRF screen comes up.
-
Select an individual switch. The VRF attachment form shows up listing the switch that is selected. In case of a vPC pair, both switches belonging to the pair shows up.
-
Under the CLI Freeform column, select the button labeled Freeform config. This option allows a user to specify additional configuration that should be deployed to the switch along with the VRF profile configuration.
-
Add or update the CLIs in the Free Form Config CLI box. Copy-paste the intended configuration with correct indentation, as seen in the running configuration on the Nexus switches. For more information, see Resolving Freeform Config Errors in Switches.
-
Click Deploy Config.
Note
The Freeform config button will be gray when there is no per VRF per switch config specified. The button will be blue when some config has been saved by the user.
After the policy is saved, Click Save on the VRF Attachment pop-up to save the intent to deploy the VRF to that switch. Ensure that the checkbox on the left next to the switch is checked.
-
Now, optionally, click Preview to look at the configuration that will be pushed to the switch.
-
Click Deploy Config to push the configuration to the switch.
The same procedure can be used to define a per Network per Switch configuration.
MACsec Support in Easy Fabric and eBGP Fabric
MACsec is supported in the Easy Fabric and eBGP Fabric on intra-fabric links. You should enable MACsec on the fabric and on each required intra-fabric link to configure MACsec. Unlike CloudSec, auto-configuration of MACsec is not supported.
MACsec is supported on switches with minimum Cisco NX-OS Releases 7.0(3)I7(8) and 9.3(5).
Guidelines
-
If MACsec cannot be configured on the physical interfaces of the link, an error is displayed when you click Save. MACsec cannot be configured on the device and link due to the following reasons:
-
The minimum NX-OS version is not met.
-
The interface is not MACsec capable.
-
-
MACsec global parameters in the fabric settings can be changed at any time.
-
MACsec and CloudSec can coexist on a BGW device.
-
MACsec status of a link with MACsec enabled is displayed on the Links window.
-
Brownfield migration of devices with MACsec configured is supported using switch and interface freeform configs.
For more information about MACsec configuration, which includes supported platforms and releases, see the Configuring MACsec chapter in Cisco Nexus 9000 Series NX-OS Security Configuration Guide.
The following sections show how to enable and disable MACsec in Nexus Dashboard Fabric Controller:
Enabling MACsec
Procedure
Step 1 |
Navigate to LAN > Fabrics. |
||||
Step 2 |
Click Actions > Create to create a new fabric or click Actions > Edit Fabric on an existing Easy or eBGP fabric. |
||||
Step 3 |
Click the Advanced tab and specify the MACsec details. Enable MACsec – Select the check box to enable MACsec for the fabric. MACsec Primary Key String – Specify a Cisco Type 7 encrypted octet string that is used for establishing the primary MACsec session. For AES_256_CMAC, the key string length must be 130 and for AES_128_CMAC, the key string length must be 66. If these values are not specified correctly, an error is displayed when you save the fabric.
MACsec Primary Cryptographic Algorithm – Choose the cryptographic algorithm used for the primary key string. It can be AES_128_CMAC or AES_256_CMAC. The default value is AES_128_CMAC. You can configure a fallback key on the device to initiate a backup session if the primary session fails. MACsec Fallback Key String – Specify a Cisco Type 7 encrypted octet string that is used for establishing a fallback MACsec session. For AES_256_CMAC, the key string length must be 130 and for AES_128_CMAC, the key string length must be 66. If these values are not specified correctly, an error is displayed when you save the fabric. MACsec Fallback Cryptographic Algorithm – Choose the cryptographic algorithm used for the fallback key string. It can be AES_128_CMAC or AES_256_CMAC. The default value is AES_128_CMAC. MACsec Cipher Suite – Choose one of the following MACsec cipher suites for the MACsec policy:
The default value is GCM-AES-XPN-256.
MACsec Status Report Timer – Specifies MACsec operational status periodic report timer in minutes. |
||||
Step 4 |
Click a fabric to view the Summary in the side kick. Click the side kick to expand. Click Links tab. |
||||
Step 5 |
Choose an intra-fabric link on which you want to enable MACsec and click Actions > Edit. |
||||
Step 6 |
In the Link Management – Edit Link window, click Advanced in the Link Profile section, and select the Enable MACsec check box. If MACsec is enabled on the intra fabric link but not in the fabric settings, an error is displayed when you click Save. When MACsec is configured on the link, the following configurations are generated:
|
||||
Step 7 |
From the Fabric Actions drop-down list, select Deploy Config to deploy the MACsec configuration. |
Disabling MACsec
To disable MACsec on an intra-fabric link, navigate to the Link Management – Edit Link window, unselect the Enable MACsec check box, click Save. From the Fabric Actions drop-down list, select Deploy Config to disable MACsec configuration. This action performs the following:
-
Deletes MACsec interface policies from the link.
-
If this is the last link where MACsec is enabled, MACsec global policies are also deleted from the device.
Only after disabling MACsec on links, navigate to the Fabric Settings and unselect the Enable MACsec check box under the Advanced tab to disable MACsec on the fabric. If there’s an intra-fabric link in the fabric with MACsec enabled, an error is displayed when you click Actions > Recalculate Config from the Fabric Actions drop-down list.
Create Easy_Fabric for Cisco Catalyst 9000 Series Switches
You can add Cisco Catalyst 9000 Series Switches to an easy fabric using the Easy_Fabric_IOS_XE fabric template. You can add only Cisco Catalyst 9000 IOS XE switches to this fabric. This fabric supports OSPF as underlay protocol and BGP EVPN as the overlay protocol. Using this fabric template allows Nexus Dashboard Fabric Controller to manage all the configurations of a VXLAN EVPN Fabric composed of Cisco Catalyst 9000 IOS-XE switches. Backing up and restoring this fabric is the same as the Easy_Fabric.
Guidelines
-
EVPN VXLAN Distributed Anycast Gateway is supported when each SVI is configured with the same Anycast Gateway MAC.
-
StackWise Virtual switch is supported.
-
Brownfield is not supported.
-
Upgrade from earlier versions is not supported (However, it is a preview feature in 11.5).
-
IPv6 Underlay, VXLAN Multi-site, Anycast RP, and TRM is not supported.
-
ISIS, ingress replication, unnumbered intra-fabric link, 4 bytes BGP ASN, and Zero-Touch Provisioning (ZTP) is not supported.
Note |
For information about configuration compliance, see Configuration Compliance in External Fabrics. |
Creating Easy Fabric for Cisco Catalyst 9000 Series Switches
UI Navigation: Choose LAN > Fabrics.
Perform the following steps to create an easy fabric for Cisco Catalyst 9000 Series Switches:
-
Choose Create Fabric from the Actions drop-down list.
-
Enter a fabric name and click Choose Template.
The Select Fabric Template dialog appears.
-
Choose the Easy_Fabric_IOS_XE fabric template and click Select.
-
Fill in all the required fields and click Save.
Note
BGP ASN is the only mandatory field.
Adding Cisco Catalyst 9000 Series Switches to IOS-XE Easy Fabrics
Cisco Catalyst 9000 series switches are discovered using SNMP. Hence, before adding them to the fabric, configuring the Cisco Catalyst 9000 series switches includes configuring SNMP views, groups, and users. For more information, see the Configuring IOS-XE Devices for Discovery section.
For StackWise Virtual switches, configure the StackWise Virtual-related configuration before adding them to the fabric.
UI Navigation
Choose any one of the following navigation paths to add switch(es) in the Add Switches window.
-
Choose LAN > Fabrics. Choose a fabric that uses the Easy_Fabric_IOS_XE fabric template from the list, click Actions, and choose Add Switches.
-
Choose LAN > Fabrics. Choose a fabric that uses the Easy_Fabric_IOS_XE fabric template from the list. Click the Switches tab. Click Actions and choose Add Switches.
-
Choose LAN > Switches. Click Actions and choose Add Switches. Click Choose Fabric, choose the IOS-XE VXLAN fabric, and click Select.
Before you begin
Set the default credentials for the device in the LAN Credentials Management window if the default credentials are not set. To navigate to the LAN Credentials Management window from the Cisco Nexus Dashboard Fabric Controller Web UI, choose .
Procedure
Step 1 |
Enter values for the following fields:
|
||||||||||||
Step 2 |
Click Discover Switches. The switch details are populated. Cisco Nexus Dashboard Fabric Controller supports the import of Cisco Catalyst 9500 Switches running in StackWise Virtual. The StackWise Virtual configuration to form a pair of Cisco Catalyst 9500 Switches into a virtual switch has to be in place before the import. For more information on how to configure StackWise Virtual, see the Configuring Cisco StackWise Virtual chapter in the High Availability Configuration Guide (Catalyst 9500 Switches) for the required release. |
||||||||||||
Step 3 |
Check the check boxes next to the switches you want to import. You can import only switches with the manageable status. |
||||||||||||
Step 4 |
Click Add Switches. The switch discovery process is initiated and the discovery status is updated under the Discovery Status column in the Switches tab. |
||||||||||||
Step 5 |
(Optional) View the details of the device. After the discovery of the device, the discovery status changes to ok in green. |
What to do next
-
Set the appropriate role. The supported roles are:
-
Leaf
-
Spine
-
Border
To set the role, choose a switch and click Actions. Choose Set role. Choose a role and click Select.
Note
After discovering the switch(es), Nexus Dashboard Fabric Controller usually assigns Leaf as the default role.
-
-
Recalculate the configurations and deploy the configurations to the switches.
Recalculating and Deploying Configurations
To recalculate and deploy the configurations to the switch(es) in the IOS-XE easy fabric, perform the following steps to recalculate configurations:
Before you begin
Set the role of the switch(es) in the IOS-XE easy fabric.
Procedure
Step 1 |
Click Actions from Fabric Overview. |
Step 2 |
Choose Recalculate Config. Recalculation of configurations starts on the switch(es). |
Creating DCI Links for Cisco Catalyst Switches in IOS-XE Easy Fabrics
You can create VRF-Lite IFC between a Cisco Catalyst 9000 Series Switch with border role in IOS-XE easy fabrics, and another switch in a different fabric. The other switch can be a Nexus switch in External Fabric, LAN Classic fabric, or Easy Fabric. It can also be a Catalyst 9000 switch in External Fabric or IOS-XE Easy Fabric. The link can be created only from IOS-XE Easy Fabric.
For more information, see Links and Templates.
Note |
When creating DCI links for IOS-XE Easy Fabric, auto-deploy is supported only if the destination device is a Nexus switch. |
To create links for IOS-XE Easy Fabric, perform the following procedure:
-
Navigate to the Links tab in the fabric overview.
The list of previously created links is displayed. The list contains intra-fabric links, which are between switches within a fabric, and inter-fabric links, which are between border switches in this fabric and switches in other fabrics.
The inter-fabric links also support edge router switches in the External Fabric, apart from BGW and Border Leaf/Spine.
-
Click Actions and choose Create.
The Create Link window appears. By default, the Intra-Fabric option is chosen as the link type.
-
From the Link Type drop-down box, choose Inter-Fabric . The fields change correspondingly.
-
Choose VRF_LITE as the link sub-type, ext_fabric_setup template for VRF_LITE IFC, and IOS-XE fabric as the source fabric.
Link Template: The link template is populated.
The templates are autopopulated with corresponding pre-packaged default templates that are based on your selection. The template to use for VRF_LITE IFC is ext_fabric_setup.
Note
You can add, edit, or delete only the ext_routed_fabric template. For more information, see Templates.
-
Choose the IOS-XE fabric as the source fabric from the Source Fabric drop-down list.
-
Choose a destination fabric from the Destination Fabric drop-down list.
-
Choose the source device and Ethernet interface that connects to the destination device.
-
Choose the destination device and Ethernet interface that connects to the source device.
-
Enter values in other fields accordingly.
-
Click Save.
Note |
Instead of the create action, you can also use the Edit action to create VRF-Lite IFC(s) using the existing inter fabric link(s). Choose the VRF_Lite link subtype. By default, if you select Edit, then the data for the fields Link-Type, Source Fabric, Destination Fabric, Source Device, Destination Device, Source Interface and Destination Interface are auto-populated in the Edit Link window. Choose VRF_LITE as the link sub-type, ext_fabric_setup template for VRF_LITE IFC, and IOS-XE fabric as the source fabric. To complete the procedure, repeat step 4 to step 10 mentioned above. |
Creating VRFs for Cisco Catalyst 9000 Series Switches in IOS-XE Easy Fabrics
UI Navigation
-
Choose Fabric slide-in pane. Click the Launch icon. Choose .
. Click on a fabric to open the -
Choose
. Double-click on a fabric to open .
You can create VRFs for IOS-XE easy fabrics.
To create VRF from the Cisco Nexus Dashboard Fabric Controller Web UI, perform the following steps:
-
Click Actions and choose Create.
The Create VRF window appears.
-
Enter the required details in the mandatory fields. Some of the fields have default values.
The fields in this window are:
VRF Name - Specifies a VRF name automatically or allows you to enter a name for Virtual Routing and Forwarding (VRF). The VRF name should not contain any white spaces or special characters except underscore (_), hyphen (-), and colon (:).
VRF ID - Specifies the ID for the VRF or allows you to enter an ID for the VRF.
VLAN ID - Specifies the corresponding tenant VLAN ID for the network or allows you to enter an ID for the VLAN. If you want to propose a new VLAN for the network, click Propose Vlan.
VRF Template - A universal template is autopopulated. This is only applicable for leaf switches. The default template for IOS_XE Easy Fabric is the IOS_XE_VRF template.
VRF Extension Template - A universal extension template is autopopulated. This allows you to extend this network to another fabric. The default template for IOS_XE Easy Fabric is the IOS_XE_VRF template.
The VRF profile section contains the General Parameters and Advanced tabs.
- The fields on the General tab are:
VRF Description - Enter the a description for the VRF.
VRF Intf Description - Specifies the description for the VRF interface.
-
Click the Advanced tab to optionally specify the advanced profile settings. The fields on the Advanced tab are:
Redistribute Direct Route Map - Specifies the redistribute direct route map name.
Max BGP Paths - Specifies the maximum BGP paths. The valid value range is between 1 and 64.
Max iBGP Paths - Specifies the maximum iBGP paths. The valid value range is between 1 and 64.
Advertise Host Routes - Enable this check box to control advertisement of /32 and /128 routes to Edge routers.
Advertise Default Route - Enable this check box to control advertisement of default route internally.
Config Static 0/0 Route - Enable this check box to control configuration of static default route.
-
Click Create to create the VRF or click Cancel to discard the VRF.
A message appears indicating that the VRF is created.
The new VRF appears on the VRFs horizontal tab. The status is NA as the VRF is created but not yet deployed. Now that the VRF is created, you can create and deploy networks on the devices in the fabric.
What to do next
Attach the VRF.
Create a loopback interface selecting the VRF_LITE extension.
For more information about attaching and detaching VRFs, see VRF Attachments.
Attaching VRFs on Cisco Catalyst 9000 Series Switches in IOS-XE Easy Fabrics
To attach the VRFs on the Cisco Catalyst 9000 Series Switches in the IOS-XE easy fabric, see VRF Attachments.
Note |
Choose the VRF corresponding to the CAT9000 series switch by checking the check box next to it. |
Note |
Similarly, you can create a loopback interface, and select VRF_LITE extension. |
What to do next
Deploy the configurations as follows:
-
Click Actions in Fabric Overview.
-
Choose Deploy config to switches.
-
Click Deploy after the configuration preview is complete.
-
Click Close after the deployment is complete.
Creating and Deploying Networks in IOS-XE Easy Fabrics
The next step is to create and deploy networks in IOS-XE Easy Fabrics.
Note |
|
UI Navigation
The following options are applicable only for switch fabrics, easy fabrics, and MSD fabrics:
-
Choose Fabric slide-in pane. Click the Launch icon. Choose .
. Click on a fabric to open the -
Choose
. Double-click on a fabric to open .
Creating Networks for IOS-XE Easy Fabrics
To create network for IOX-XE easy fabric from the Cisco Nexus Dashboard Fabric Controller Web UI, perform the following steps:
-
On the Networks horizontal tab, click Actions and choose Create.
The Create Network window appears.
-
Enter the required details in the mandatory fields.
The fields in this window are:
Network ID and Network Name - Specifies the Layer 2 VNI and name of the network. The network name should not contain any white spaces or special characters except underscore (_) and hyphen (-).
Layer 2 Only - Specifies whether the network is Layer 2 only.
VRF Name - Allows you to select the Virtual Routing and Forwarding (VRF).
When no VRF is created, this field appears blank. If you want to create a new VRF, click Create VRF. The VRF name should not contain any white spaces or special characters except underscore (_), hyphen (-), and colon (:).
VLAN ID - Specifies the corresponding tenant VLAN ID for the network. If you want to propose a new VLAN for the network, click Propose VLAN.
Network Template - A universal template is autopopulated. This is only applicable for leaf switches.
Network Extension Template - A universal extension template is autopopulated. This allows you to extend this network to another fabric. The VRF Lite extension is supported. The template is applicable for border leaf switches.
Generate Multicast IP - If you want to generate a new multicast group address and override the default value, click Generate Multicast IP.
The network profile section contains the General and Advanced tabs.
-
The fields on the General tab are:
Note
If the network is a non Layer 2 network, then it is mandatory to provide the gateway IP address.
IPv4 Gateway/NetMask - Specifies the IPv4 address with subnet.
Specify the anycast gateway IP address for transporting the L3 traffic from a server belonging to MyNetwork_30000 and a server from another virtual network. The anycast gateway IP address is the same for MyNetwork_30000 on all switches of the fabric that have the presence of the network.
Note
If the same IP address is configured in the IPv4 Gateway and IPv4 Secondary GW1 or GW2 fields of the network template, Nexus Dashboard Fabric Controller does not show an error, and you will be able to save this configuration.
However, after the network configuration is pushed to the switch, it would result in a failure as the configuration is not allowed by the switch.
IPv6 Gateway/Prefix List - Specifies the IPv6 address with subnet.
Vlan Name - Enter the VLAN name.
Vlan Interface Description - Specifies the description for the interface. This interface is a switch virtual interface (SVI).
IPv4 Secondary GW1 - Enter the gateway IP address for the additional subnet.
IPv4 Secondary GW2 - Enter the gateway IP address for the additional subnet.
-
Click the Advanced tab to optionally specify the advanced profile settings. The fields on the Advanced tab are:
Multicast Group Address - The multicast IP address for the network is autopopulated.
Multicast group address is a per fabric instance variable and remains the same for all networks by default. If a new multicast group address is required for this network, you can generate it by clicking the Generate Multicast IP button.
DHCPv4 Server 1 - Enter the DHCP relay IP address of the first DHCP server.
DHCPv4 Server VRF - Enter the DHCP server VRF ID.
DHCPv4 Server 2 - Enter the DHCP relay IP address of the next DHCP server.
DHCPv4 Server2 VRF - Enter the DHCP server VRF ID.
Loopback ID for DHCP Relay interface (Min:0, Max:1023) - Specifies the loopback ID for DHCP relay interface.
Enable L3 Gateway on Border - Select the check box to enable a Layer 3 gateway on the border switches.
-
Click Create.
A message appears indicating that the network is created.
The new network appears on the Networks page that comes up.
The Status is NA since the network is created but not yet deployed on the switches. Now that the network is created, you can create more networks if needed and deploy the networks on the devices in the fabric.
Deploying Networks in IOS-XE Easy Fabrics
You can deploy networks in IOS-XE easy fabrics as follows:
-
The network configurations can also be deployed in the Fabric Overview window as follows:
-
Click Actions in the fabric overview.
-
Choose Deploy config to switches.
-
Click Deploy after the configuration preview is complete.
-
Click Close after the deployment is complete
-
-
To deploy the network in the IOS-XE easy fabric, see Network Attachments.
External Fabrics
You can add switches to the external fabric. Generic pointers:
NDFC will not generate "no router bgp". If you want to change it, go to the switch and do a “no feature bgp” followed by a re-sync, if you don't have anything and want to update the ASN.
-
The external fabric is a monitor-only or managed mode fabric.
-
From Cisco Nexus Dashboard Fabric Controller Release 12.0.1, Cisco IOS-XR family devices Cisco ASR 9000 Series Aggregation Services Routers and Cisco Network Convergence System (NCS) 5500 Series are supported in external fabric in managed mode and monitor mode. NDFC will generate and push configurations to these switches, and configuration compliance will also be enabled for these platforms.
-
From Cisco Nexus Dashboard Fabric Controller Release 12.1.1e, you can also add Cisco 8000 Series Routers to external fabrics both in managed mode and monitored mode, and configuration compliance is also supported.
-
You can import, remove, and delete switches for an external fabric.
-
For Inter-Fabric Connection (IFC) cases, you can choose Cisco 9000, 7000 and 5600 Series switches as destination switches in the external fabric.
-
You can use non-existing switches as destination switches.
-
The template that supports an external fabric is External_Fabric.
-
If an external fabric is an MSD fabric member, then the MSD topology screen displays the external fabric with its devices, along with the member fabrics and their devices.
When viewed from an external fabric topology screen, any connections to non-Nexus Dashboard Fabric Controller managed switches are represented by a cloud icon labeled as Undiscovered.
-
You can set up a Multi-Site or a VRF-lite IFC by manually configuring the links for the border devices in the VXLAN fabric or by using an automatic Deploy Border Gateway Method or VRF Lite IFC Deploy Method. If you are configuring the links manually for the border devices, we recommend using the Core Router role to set up a Multi-Site eBGP underlay from a Border Gateway device to a Core Router and the Edge Router role to set up a VRF-lite Inter-Fabric Connection (IFC) from a Border device to an Edge device.
-
If you are using the Cisco Nexus 7000 Series Switch with Cisco NX-OS Release 6.2(24a) on the LAN Classic or External fabrics, make sure to enable AAA IP Authorization in the fabric settings.
-
You can discover the following non-Nexus devices in an external fabric:
-
IOS-XE family devices: Cisco CSR 1000v, Cisco IOS XE Gibraltar 16.10.x, Cisco ASR 1000 Series routers, and Cisco Catalyst 9000 Series Switches
-
IOS-XR family devices: ASR 9000 Series Routers, IOS XR Release 6.5.2 and Cisco NCS 5500 Series Routers, IOS XR Release 6.5.3
-
Arista 4.2 (Any model)
-
-
Configure all the non-Nexus devices, except Cisco CSR 1000v, before adding them to the external fabric.
-
You can configure non-Nexus devices as borders. You can create an IFC between a non-Nexus device in an external fabric and a Cisco Nexus device in an easy fabric. The interfaces supported for these devices are:
-
Routed
-
Subinterface
-
Loopback
-
-
You can configure a Cisco ASR 1000 Series routers and Cisco Catalyst 9000 Series switches as edge routers, set up a VRF-lite IFC and connect it as a border device with an easy fabric.
-
Before a VDC reload, discover Admin VDC in the fabric. Otherwise, the reload operation does not occur.
-
You can connect a Cisco data center to a public cloud using Cisco CSR 1000v. See the Connecting Cisco Data Center and a Public Cloud chapter for a use case.
-
In an external fabric, when you add the switch_user policy and provide the username and password, the password must be an encrypted string that is displayed in the show run command.
For example:
username admin password 5 $5$I4sapkBh$S7B7UcPH/iVTihLKH5sgldBeS3O2X1StQsvv3cmbYd1 role network-admin
In this case, the entered password should be 5$5$I4sapkBh$S7B7UcPH/iVTihLKH5sgldBeS3O2X1StQsvv3cmbYd1.
-
For the Cisco Network Insights for Resources (NIR) Release 2.1 and later, and flow telemetry, feature lldp command is one of the required configuration.
Cisco Nexus Dashboard Fabric Controller pushes feature lldp on the switches only for the Easy Fabric deployments, that is, for the eBGP routed fabric or VXLAN EVPN fabric.
Therefore, NIR users need to enable feature lldp on all the switches in the following scenarios:
-
External fabric in Monitored or Managed Mode
-
LAN Classic fabric in Monitored or Managed Mode
-
-
Backup/restore is only supported for Nexus devices on external fabrics.
Note
Before you do fabric or switch restore, ensure that the target device is supported. If the target device is not supported, then per switch restore will be blocked, and the same will be shown as not supported during fabric-wide restore.
Move an External Fabric Under an MSD Fabric
You should go to the MSD fabric page to associate an external fabric as its member.
-
On Topology, click within the MSD-Parent-Fabric. From Actions drop-down list, select Move Fabrics.
The Move Fabric screen comes up. It contains a list of fabrics. The external fabric is displayed as a standalone fabric.
-
Select the radio button next to the external fabric and click Add.
Now, in the Scope drop-down box at the top right, you can see that the external fabric appears under the MSD fabric.
External Fabric Depiction in an MSD Fabric Topology
The MSD topology screen displays MSD member fabrics and external fabrics together. The external fabric External65000 is displayed as part of the MSD topology.
Note |
When you deploy networks or VRFs for the VXLAN fabric, the deployment page (MSD topology view) shows the VXLAN and external fabrics that are connected to each other. |
Creating an External Fabric
To create an external fabric using Cisco Fabric Controller Web UI, perform the following steps:
Procedure
Step 1 |
Choose LAN > Fabrics > Fabrics. |
||||
Step 2 |
From the Actions drop-down list, select Create Fabric. |
||||
Step 3 |
Enter a unique name for the fabric and click Choose Template. |
||||
Step 4 |
From the drop-down list, select External_Fabric template. The fields in this screen are: BGP AS # – Enter the BGP AS number. Fabric Monitor Mode – Clear the check box if you want Nexus Dashboard Fabric Controller to manage the fabric. Keep the check box selected to enable a monitor only external fabric. From Cisco Nexus Dashboard Fabric Controller Release 12.1.1e, you can also add Cisco 8000 Series Routers to external fabrics both in managed mode and monitored mode. When you create an Inter-Fabric Connection from a VXLAN fabric to this external fabric, the BGP AS number is referenced as the external or neighbor fabric AS Number. When an external fabric is set to Fabric Monitor Mode Only, you cannot deploy configurations on its switches. If you click Deploy Config, it displays an error message. The configurations must be pushed for non-Nexus devices before you discover them in the fabric. You cannot push configurations in the monitor mode. Enable Performance Monitoring – Check this check box to enable performance monitoring on NX-OS switches only. Ensure that you do not clear interface counters from the Command Line Interface of the switches. Clearing interface counters
can cause the Performance Monitor to display incorrect data for traffic utilization. If you must clear the counters and the
switch has both |
||||
Step 5 |
Enter values in the fields under the Advanced tab. Power Supply Mode – Choose the appropriate power supply mode. Enable MPLS Handoff – Select the check box to enable the MPLS Handoff feature. For more information, see the MPLS SR and LDP Handoff chapter in External/WAN Layer 3 Connectivity for VXLAN BGP EVPN Fabrics. Underlay MPLS Loopback Id – Specifies the underlay MPLS loopback ID. The default value is 101. Enable AAA IP Authorization – Enables AAA IP authorization, after IP Authorization is enabled on the AAA Server Enable Nexus Dashboard Fabric Controller as Trap Host – Select this check box to enable Nexus Dashboard Fabric Controller as a trap host. Enable CDP for Bootstrapped Switch – Select the check box to enable CDP for bootstrapped switch. Enable NX-API – Specifies enabling of NX-API on HTTPS. This check box is unchecked by default. Enable NX-API on HTTP – Specifies enabling of NX-API on HTTP. This check box is unchecked by default. Enable this check box and the Enable NX-API check box to use HTTP. If you uncheck this check box, the applications that use NX-API and supported by Cisco Nexus Dashboard Fabric Controller, such as Endpoint Locator (EPL), Layer 4-Layer 7 services (L4-L7 services), VXLAN OAM, and so on, start using the HTTPS instead of HTTP.
Inband Mgmt – For External and Classic LAN Fabrics, this knob enables Nexus Dashboard Fabric Controller to import and manage of switches with inband connectivity (reachable over switch loopback, or routed interface, or SVI interfaces) , in addition to management of switches with out-of-band connectivity (aka reachable over switch mgmt0 interface). The only requirement is that for Inband managed switches, there should be IP reachability from Nexus Dashboard Fabric Controller to the switches over the Nexus Dashboard data interface, also known as inband interface. For this purpose, static routes may be needed on the Nexus Dashboard Fabric Controller, that in turn can be configured from Administration > Customization > Network Preferences. After enabling Inband management, during discovery provide the IPs of all the switches to be imported using Inband Management and set maximum hops to 0. Nexus Dashboard Fabric Controller has a precheck that validates that the Inband managed switch IPs are reachable over the Nexus Dashboard data interface. After completing the precheck, Nexus Dashboard Fabric Controller discovers and learns about the interface on that switch that has the specified discovery IP in addition to the VRF that the interface belongs to. As part of the process of switch import/discovery, this information is captured in the baseline intent that is populated on the Nexus Dashboard Fabric Controller. For more information, see Inband Management in External Fabrics and LAN Classic Fabrics.
Enable Precision Time Protocol (PTP) – Enables PTP across a fabric. When you select this check box, PTP is enabled globally and on core-facing interfaces. You can also edit PTP Source Loopback Id and PTP Domain Id fields. For more information, see Precision Time Protocol for External Fabrics and LAN Classic Fabrics. PTP Source Loopback Id – Specifies the loopback interface ID Loopback that is used as the Source IP Address for all PTP packets. The valid values
range 0–1023. The PTP loopback ID cannot be the same as RP, Phantom RP, NVE, or MPLS loopback ID. Otherwise, an error will
be generated. The PTP loopback ID can be the same as BGP loopback or user-defined loopback which is created from Nexus Dashboard Fabric Controller. If the PTP loopback ID is not found during Save & Deploy, the following error is generated: PTP Domain Id – Specifies the PTP domain ID on a single network. The valid values range 0–127. Fabric Freeform – You can apply configurations globally across all the devices that are discovered in the external fabric using this freeform field. The devices in the fabric should belong to the same device-type and the fabric should not be in monitor mode. The different device types are:
Depending on the device types, enter the configurations accordingly. If some of the devices in the fabric do not support these global configurations, they go out-of-sync or fail during the deployment. Hence, ensure that the configurations you apply are supported on all the devices in the fabric or remove the devices that do not support these configurations. AAA Freeform Config – You can apply AAA configurations globally across all devices that are discovered in the external fabric using this freeform field. |
||||
Step 6 |
Fill up the Resources tab as explained in the following. Subinterface Dot1q Range – The subinterface 802.1Q range and the underlay routing loopback IP address range are autopopulated. Underlay MPLS Loopback IP Range – Specifies the underlay MPLS SR or LDP loopback IP address range. The IP range should be unique, that is, it should not overlap with IP ranges of the other fabrics. |
||||
Step 7 |
Fill up the Configuration Backup tab as shown below. The fields on this tab are: Hourly Fabric Backup – Select the check box to enable an hourly backup of fabric configurations and the intent. You can enable an hourly backup for fresh fabric configurations and the intent as well. If there is a configuration push in the previous hour, Nexus Dashboard Fabric Controller takes a backup. In case of the external fabric, the entire configuration on the switch is not converted to intent on Nexus Dashboard Fabric Controller as compared to the VXLAN fabric. Therefore, for the external fabric, both intent and running configuration are backed up. Intent refers to configurations that are saved in Nexus Dashboard Fabric Controller but yet to be provisioned on the switches. The hourly backups are triggered during the first 10 minutes of the hour. Scheduled Fabric Backup – Check the check box to enable a daily backup. This backup tracks changes in running configurations on the fabric devices that are not tracked by configuration compliance. Scheduled Time: Specify the scheduled backup time in a 24-hour format. This field is enabled if you check the Scheduled Fabric Backup check box. Select both the check boxes to enable both back up processes. The backup process is initiated after you click Save. The scheduled backups are triggered exactly at the time that you specify with a delay of up to two minutes. The scheduled backups are triggered regardless of the configuration deployment status. You can also initiate the fabric backup in the fabric topology window. Click Backup Fabric in the Actions pane. The backups contain running configuration and intent that is pushed by Nexus Dashboard Fabric Controller. Configuration compliance forces the running config to be the same as the Nexus Dashboard Fabric Controller config. Note that for the external fabric, only some configurations are part of intent and the remaining configurations are not tracked by Nexus Dashboard Fabric Controller. Therefore, as part of backup, both Nexus Dashboard Fabric Controller intent and running config from switch are captured. |
||||
Step 8 |
Click the Bootstrap tab. Enable Bootstrap – Select this check box to enable the bootstrap feature. After you enable bootstrap, you can enable the DHCP server for automatic IP address assignment using one of the following methods:
From Cisco NDFC Release 12.1.1e, you can choose Inband POAP or out-of-band POAP for External fabrics. Enable Inband POAP – Choose this check box to enable Inband POAP.
Enable Local DHCP Server – Select this check box to initiate enabling of automatic IP address assignment through the local DHCP server. When you choose this check box, all the remaining fields become editable. DHCP Version – Select DHCPv4 or DHCPv6 from this drop-down list. When you select DHCPv4, Switch Mgmt IPv6 Subnet Prefix field is disabled. If you select DHCPv6, the Switch Mgmt IP Subnet Prefix is disabled.
If you do not select this check box, Nexus Dashboard Fabric Controller uses the remote or external DHCP server for automatic IP address assignment. DHCP Scope Start Address and DHCP Scope End Address – Specifies the first and last IP addresses of the IP address range to be used for the switch out of band POAP. Switch Mgmt Default Gateway – Specifies the default gateway for the management VRF on the switch. Switch Mgmt IP Subnet Prefix – Specifies the prefix for the Mgmt0 interface on the switch. The prefix range is 8-30. DHCP scope and management default gateway IP address specification - If you specify the management default gateway IP address 10.0.1.1 and subnet mask 24, ensure that the DHCP scope is within the specified subnet, between 10.0.1.2 and 10.0.1.254. Switch Mgmt IPv6 Subnet Prefix – Specifies the IPv6 prefix for the Mgmt0 interface on the switch. The prefix should be from 112 through 126. This field is editable if you enable IPv6 for DHCP. Enable AAA Config – Select this check box to include AAA configs from Advanced tab during device bootup. Bootstrap Freeform Config - (Optional) Enter other commands as needed. For example, if you are using AAA or remote authentication-related configurations, add these configurations in this field to save the intent. After the devices boot up, they contain the intent that is defined in the Bootstrap Freeform Config field. Copy-paste the running-config to a freeform config field with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running config. For more information, see Enabling Freeform Configurations on Fabric Switches. DHCPv4/DHCPv6 Multi Subnet Scope - Specifies the field to enter one subnet scope per line. This field is editable after you check the Enable Local DHCP Server check box. The format of the scope should be defined as: DHCP Scope Start Address, DHCP Scope End Address, Switch Management Default Gateway, Switch Management Subnet Prefix for example: 10.6.0.2, 10.6.0.9, 10.6.0.1, 24 |
||||
Step 9 |
Click the Flow Monitor tab. The fields on this tab are as follows. Enable NetFlow – Check this check box to enable NetFlow on VTEPs for this Fabric. By default, NetFlow is disabled. On Enable, NetFlow configuration will be applied to all VTEPS that support NetFlow. Note: When NetFlow is enabled on the fabric, you can choose not to have NetFlow on a particular switch by having a dummy no_netflow PTI. If NetFlow is not enabled at the fabric level, an error message is generated when you enable NetFlow at the interface, network, or VRF level. For information about NetFlow support for Cisco NDFC, see Netflow Support. In the NetFlow Exporter area, click Actions > Add to add one or more NetFlow exporters. This exporter is the receiver of the NetFlow data. The fields on this screen are:
Click Save to configure the exporter. Click Cancel to discard. You can also choose an existing exporter and select Actions > Edit or Actions > Delete to perform relevant actions. In the NetFlow Record area, click Actions > Add to add one or more NetFlow records. The fields on this screen are:
Click Save to configure the report. Click Cancel to discard. You can also choose an existing record and select Actions > Edit or Actions > Delete to perform relevant actions. In the NetFlow Monitor area, click Actions > Add to add one or more NetFlow monitors. The fields on this screen are:
The record name and exporters referred to in each NetFlow monitor must be defined in Netflow Record and Netflow Exporter. Click Save to configure the monitor. Click Cancel to discard. You can also choose an existing monitor and select Actions > Edit or Actions > Delete to perform relevant actions. |
||||
Step 10 |
Click Save. After the external fabric is created, the external fabric topology page comes up. After creating the external fabric, add switches to it. |
Adding Switches to the External Fabric
Switches in each fabric are unique, and hence, each switch can only be added to one fabric. To add switches to the external fabric, perform he following steps:
Procedure
Step 1 |
Choose LAN > Switches. From the Actions drop-down list, select Add Switches You can also add switches to a Fabric from LAN > Fabrics. Select a fabric and view the Summary. On the Switches tab, from the Actions drop-down list, select Add switches to add switches to the selected Fabric. From Topology, right click on the Fabric and select Add Switches. |
Step 2 |
Select Discover to discover new switches. Select Move Neighbor Switches to add existing switches to the Fabric. |
Step 3 |
If you select Discover option, perform the following steps: The Scan Details section comes up shortly. Since the Max Hops field was populated with 2, the switch with the specified IP address and switches two hops from it are populated. Select the check boxes next to the concerned switches and click Add Switches into fabric. You can discover multiple switches at the same time. The switches must be properly cabled and connected to the Nexus Dashboard Fabric Controller server and the switch status must be manageable. The switch discovery process is initiated. The Progress column displays the progress. After Nexus Dashboard Fabric Controller discovers the switch, click Close to revert to the previous screen. |
Step 4 |
If you select Move Neighbor Switches option, select the switch and click Move Switch. The selected switch is moved to the External Fabric. |
Switch Settings for External Fabrics
External Fabric Switch Settings vary from the VXLAN fabric switch settings. Double-click on the switch to view the Switch Overview screen to edit/modify options.
The options are:
Set Role – By default, no role is assigned to an external fabric switch. You can assign desired role to the fabric. Assign the Core Router role for a Multi-Site Inter-Fabric Connection (IFC) and the Edge Router role for a VRF Lite IFC between the external fabric and VXLAN fabric border devices.
Note |
Changing of switch role is allowed only before executing Deploy Config. |
vPC Pairing – Select a switch for vPC and then select its peer.
Change Modes – Allows you to modify the mode of switch from Active to Operational.
Manage Interfaces – Deploy configurations on the switch interfaces.
Straight-through FEX, Active/Active FEX, and breakout of interfaces are not supported for external fabric switch interfaces.
View/edit Policies – Add, update, and delete policies on the switch. The policies you add to a switch are template instances of the templates available in the template library. After creating policies, deploy them on the switch using the Deploy option available in the View/edit Policies screen.
History – View per switch deployment history.
Recalculate Config – View the pending configuration and the side-by-side comparison of the running and expected configuration.
Deploy Config – Deploy per switch configurations.
Discovery – You can use this option to update the credentials of the switch, reload the switch, rediscover the switch, and remove the switch from the fabric.
Click Deploy from the Actions drop-down list. The template and interface configurations form the configuration provisioning on the switches.
When you click Deploy, the Deploy Configuration screen comes up.
Click Config at the bottom part of the screen to initiate pending configuration onto the switch. The Deploy Progress screen displays the progress and the status of configuration deployment.
Click Close after the deployment is complete.
Note |
If a switch in an external fabric does not accept default credentials, you should perform one of the following actions:
|
Discovering New Switches
Procedure
Step 1 |
Power on the new switch in the external fabric after ensuring that it is cabled to the Nexus Dashboard Fabric Controller server. Boot the Cisco NX-OS and setup switch credentials. |
||
Step 2 |
Execute the write, erase, and reload commands on the switch. Choose Yes to both the CLI commands that prompt you to choose Yes or No. |
||
Step 3 |
On the Nexus Dashboard Fabric Controller UI, select the External Fabric. Choose Edit Fabric from the Actions drop-down list. The Edit Fabric screen is displayed. |
||
Step 4 |
Click the Bootstrap tab and update the DHCP information. |
||
Step 5 |
Click Save at the bottom right part of the Edit Fabric screen to save the settings. |
||
Step 6 |
Double click on the Fabric to view the Fabric Overview. |
||
Step 7 |
On Switches tab, from the Actions drop-down list, select Add Switches. |
||
Step 8 |
Click the POAP tab. In an earlier step, the reload command was executed on the switch. When the switch restarts to reboot, Nexus Dashboard Fabric Controller retrieves the serial number, model number, and version from the switch and displays them on the Inventory Management along screen. Also, an option to add the management IP address, hostname, and password are made available. If the switch information is not retrieved, refresh the screen using the Refresh icon at the top right part of the screen.
Select the checkbox next to the switch and add switch credentials: IP address and host name. Based on the IP address of your device, you can either add the IPv4 or IPv6 address in the IP Address field. You can provision devices in advance. |
||
Step 9 |
In the Admin Password and Confirm Admin Password fields, enter and confirm the admin password. This admin password is applicable for all the switches displayed in the POAP window.
|
||
Step 10 |
(Optional) Use discovery credentials for discovering switches. |
||
Step 11 |
Click Bootstrap at the top right part of the screen. Nexus Dashboard Fabric Controller provisions the management IP address and other credentials to the switch. In this simplified POAP process, all ports are opened up. After the added switch completes POAP, the fabric builder topology screen displays the added switch with some physical connections. |
||
Step 12 |
Monitor and check the switch for POAP completion. |
||
Step 13 |
Click Deploy Config from the Actions drop-down list on the Fabric Overview screen to deploy pending configurations (such as template and interface configurations) onto the switches.
During fabric creation, if you have entered AAA server information (in the Manageability tab), you must update the AAA server password on each switch. Else, switch discovery fails. |
||
Step 14 |
After the pending configurations are deployed, the Progress column displays 100% for all switches. |
||
Step 15 |
On the Topology screen, click Refresh Topology icon to view the update. All switches must be in green color indicating that they are functional. The switch and the link are discovered in Nexus Dashboard Fabric Controller. Configurations are built based on various policies (such as fabric, topology, and switch generated policies). The switch image (and other required) configurations are enabled on the switch. |
||
Step 16 |
Right-click and select History to view the deployed configurations. Click the Success link in the Status column for more details. An example: |
||
Step 17 |
On the Nexus Dashboard Fabric Controller UI, the discovered switches can be seen in the fabric topology. Up to this step, the POAP is completed with basic settings. All the interfaces are set to trunk ports. You must setup interfaces through the LAN > Interfaces option for any additional configurations, but not limited to the following:
|
Adding Non-Nexus Devices to External Fabrics
From Cisco Nexus Dashboard Fabric Controller Release 12.0.1a, you can add Cisco IOS-XR devices to external fabrics in managed mode as well. You can manage the following Cisco IOS-XR devices in external fabrics:
-
Cisco ASR 9000 Series Routers
-
Cisco NCS 5500 Series Routers, IOS XR Release 6.5.3
From Cisco Nexus Dashboard Fabric Controller Release 12.1.1e, you can also add Cisco 8000 Series Routers to external fabrics both in managed mode and monitored mode.
You can discover non-Nexus devices in an external fabric and perform the configuration compliance of these devices as well. For more information, see the Configuration Compliance in External Fabrics section.
Refer the Cisco Nexus Dashboard Fabric Controller Compatibility Matrix to see the non-Nexus devices supported by Cisco Nexus Dashboard Fabric Controller.
Only Cisco Nexus switches support SNMP discovery by default. Hence, configure all the non-Nexus devices before adding it to the external fabric. Configuring the non-Nexus devices includes configuring SNMP views, groups, and users. See the Configuring non-Nexus Devices for Discovery section for more information.
Cisco CSR 1000v is discovered using SSH. Cisco CSR 1000v does not need SNMP support because it can be installed in clouds where SNMP is blocked for security reasons. See the Connecting Cisco Data Center and a Public Cloud chapter to see a use case to add Cisco CSR 1000v, Cisco IOS XE Gibraltar 16.10.x to an external fabric.
However, Cisco Nexus Dashboard Fabric Controller can only access the basic device information like system name, serial number, model, version, interfaces, up time, and so on. Cisco Nexus Dashboard Fabric Controller does not discover non-Nexus devices if the hosts are part of CDP or LLDP.
The settings that are not applicable for non-Nexus devices appear blank, even if you get many options when you right-click a non-Nexus device in the fabric topology window. You cannot add or edit interfaces for ASR 9000 Series Routers and Arista switches.
You can add IOS-XE devices like Cisco Catalyst 9000 Series switches and Cisco ASR 1000 Series Routers as well to external fabrics.
Configuration Compliance in External Fabrics
With external fabrics, any Nexus switches, Cisco IOS-XE devices, Cisco IOS XR devices, and Arista can be imported into the fabric, and there is no restriction on the type of deployment. It can be LAN Classic, VXLAN, FabricPath, vPC, HSRP, etc. When switches are imported into an external fabric, the configuration on the switches is retained so that it is non-disruptive. Only basic policies such as the switch username and mgmt0 interface are created after a switch import.
In the external fabric, for any intent that is defined in the Nexus Dashboard Fabric Controller, configuration compliance (CC) ensures that this intent is present on the corresponding switch. If this intent is not present on the switch, CC reports an Out-of-Sync status. Additionally, there will be a Pending Config generated to push this intent to the switch to change the status to In-Sync. Any additional configuration that is on the switch but not in intent defined in Nexus Dashboard Fabric Controller, will be ignored by CC, as long as there is no conflict with anything in the intent.
When there is user-defined intent added on Nexus Dashboard Fabric Controller and the switch has additional configuration under the same top-level command, as mentioned earlier, CC will only ensure that the intent defined in Nexus Dashboard Fabric Controller is present on the switch. When this user defined intent on Nexus Dashboard Fabric Controller is deleted as a whole with the intention of removing it from the switch and the corresponding configuration exists on the switch, CC will report an Out-of-Sync status for the switch and will generate Pending Config to remove the config from the switch. This Pending Config includes the removal of the top-level command. This action leads to removal of the other out-of-band configurations made on the switch under this top-level command as well. If you choose to override this behavior, the recommendation is that, you create a freeform policy and add the relevant top-level command to the freeform policy.
Let us see this behavior with an example.
-
A switch_freeform policy defined by the user in Nexus Dashboard Fabric Controller and deployed to the switch.
-
Additional configuration exists under router bgp in Running config that does not exist in user-defined Nexus Dashboard Fabric Controller intent Expected config. Note that there is no Pending Config to remove the additional config that exists on the switch without a user defined intent on Nexus Dashboard Fabric Controller.
-
The Pending Config and the Side-by-side Comparison when the intent that was pushed earlier via Nexus Dashboard Fabric Controller is deleted from Nexus Dashboard Fabric Controller by deleting the switch_freeform policy that was created in the Step 1.
-
A switch_freeform policy with the top-level router bgp command needs to be created. This enables CC to generate the configuration needed to remove only the desired sub-config which was pushed from Nexus Dashboard Fabric Controller earlier.
-
The removed configuration is only the subset of the configuration that was pushed earlier from Nexus Dashboard Fabric Controller.
For interfaces on the switch in the external fabric, Nexus Dashboard Fabric Controller either manages the entire interface or does not manage it at all. CC checks interfaces in the following ways:
-
For any interface, if there is a policy defined and associated with it, then this interface is considered as managed. All configurations associated with this interface must be defined in the associated interface policy. This is applicable for both logical and physical interfaces. Otherwise, CC removes any out-of-band updates made to the interface to change the status to In-Sync.
-
Interfaces created out-of-band (applies for logical interfaces such as port-channels, sub interfaces, SVIs, loopbacks, etc.), will be discovered by Nexus Dashboard Fabric Controller as part of the regular discovery process. However, since there is no intent for these interfaces, CC will not report an Out-of-Sync status for these interfaces.
-
For any interface, there can always be a monitor policy associated with it in Nexus Dashboard Fabric Controller. In this case, CC will ignore the interface’s configuration when it reports the In-Sync or Out-of-Sync config compliance status.
-
Special Configuration CLIs Ignored for Configuration Compliance
The following configuration CLIs are ignored during configuration compliance checks:
-
Any CLI having 'username’ along with ‘password’
-
Any CLI that starts with ‘snmp-server user’
Any CLIs that match the above will not show up in pending diffs and clicking Save & Deploy in the Fabric Builder window will not push such configurations to the switch. These CLIs will not show up in the Side-by-side Comparison window also.
To deploy such configuration CLIs, perform the following procedure:
Procedure
Step 1 |
Select LAN > Fabrics. Double click on the fabric name to view Fabric Overview screen. |
Step 2 |
On the Switches tab, double click on the switch name to view Switch Overview screen. On the Policies tab, all the policies applied on the switch within the chosen fabric are listed. |
Step 3 |
On the Policies tab, from the Actions drop-down list, select Add Policy. |
Step 4 |
Add a Policy Template Instances (PTIs) with the required configuration CLIs using the switch_freeform template and click Save. |
Step 5 |
Select the created policy and select Push Config from the Actions drop-down list to deploy the configuration to the switch(es). |
Managing Cisco IOS-XR Devices using NDFC
In general, workload requires communication with services outside of the data center domain in a data center fabric. This includes users accessing an application and services from the internet and WAN. VXLAN EVPN fabrics with border devices are considered as a handoff for north-south connectivity. These border devices are in peer with IOS-XR routers, which is a backbone routers for WAN and internet connectivity.
In DCNM Release 11.5(x), users with an admin role can control VXLAN EVPN fabrics with capabilities such as monitoring, automation, and compliance. You can only monitor the IOS-XR routers in monitored mode. Therefore, there is a requirement for a single fabric controller to manage, and automate configurations between these devices to balance and check configurations compliance for communicating between different services.
From NDFC Release 12.0.1a, users with an admin role can manage IOS-XR routers which is limited to automation and checking compliance. New templates and policies are introduced to automate and manage eBGP VRF Lite handoff between border switches and IOS-XR routers. NDFC allows you to check configuration compliance for IOS-XR devices similar to Cisco Nexus switches in the external fabrics.
Note |
For all non-Nexus devices, only MD5 protocol is supported for SNMPv3 authentication. |
Configuring IOS-XR as Edge Router
To extend VRF Lite from Cisco Nexus 9000 fabric with border devices for IOS-XR as edge router, refer to VRF Lite Between Cisco Nexus 9000 Based Border and Non-Nexus Device section.
For more information, see video at Managing and Configuring ASR 9000 using NDFC.
Configuring Non-Nexus Devices for Discovery
Before discovering any non-Nexus device in Cisco Nexus Dashboard Fabric Controller, configure it on the switch console.
Configuring IOS-XE Devices for Discovery
Note |
In case of failure or issues configuring devices contact Cisco Technical Assistance Center (TAC). |
Before you discover the Cisco IOS-XE devices in Nexus Dashboard Fabric Controller, perform the following steps:
Procedure
Step 1 |
Run the following SSH commands on the switch console.
|
Step 2 |
Before you run SNMP command on the switch, ensure that the IP addresses, username and SNMP related configurations are defined on the switch. Run the following SNMP command on the switch console.
|
Configuring Arista Devices for Discovery
Enable Privilege Exec mode using the following command:
switch> enable
switch#
switch# show running confiruation | grep aaa /* to view the authorization*/
aaa authorization exec default local
switch# configure terminal
switch (config)# username ndfc privilege 15 role network-admin secret cisco123
snmp-server view view_name SNMPv2 included
snmp-server view view_name SNMPv3 included
snmp-server view view_name default included
snmp-server view view_name entity included
snmp-server view view_name if included
snmp-server view view_name iso included
snmp-server view view_name lldp included
snmp-server view view_name system included
snmp-server view sys-view default included
snmp-server view sys-view ifmib included
snmp-server view sys-view system included
snmp-server community private ro
snmp-server community public ro
snmp-server group group_name v3 auth read view_name
snmp-server user username group_name v3 auth md5 password priv aes password
Note |
SNMP password should be same as the password for username. |
You can verify the configuration by running the show run command, and view the SNMP view output by running the show snmp view command.
Show Run Command
switch (config)# snmp-server engineID local f5717f444ca824448b00
snmp-server view view_name SNMPv2 included
snmp-server view view_name SNMPv3 included
snmp-server view view_name default included
snmp-server view view_name entity included
snmp-server view view_name if included
snmp-server view view_name iso included
snmp-server view view_name lldp included
snmp-server view view_name system included
snmp-server view sys-view default included
snmp-server view sys-view ifmib included
snmp-server view sys-view system included
snmp-server community private ro
snmp-server community public ro
snmp-server group group_name v3 auth read view_name
snmp-server user user_name
group_name v3 localized f5717f444ca824448b00 auth md5 be2eca3fc858b62b2128a963a2b49373 priv aes be2eca3fc858b62b2128a963a2b49373
!
spanning-tree mode mstp
!
service unsupported-transceiver labs f5047577
!
aaa authorization exec default local
!
no aaa root
!
username admin role network-admin secret sha512 $6$5ZKs/7.k2UxrWDg0$FOkdVQsBTnOquW/9AYx36YUBSPNLFdeuPIse9XgyHSdEOYXtPyT/0sMUYYdkMffuIjgn/d9rx/Do71XSbygSn/
username cvpadmin role network-admin secret sha512 $6$fLGFj/PUcuJT436i$Sj5G5c4y9cYjI/BZswjjmZW0J4npGrGqIyG3ZFk/ULza47Kz.d31q13jXA7iHM677gwqQbFSH2/3oQEaHRq08.
username ndfc privilege 15 role network-admin secret sha512 $6$M48PNrCdg2EITEdG$iiB880nvFQQlrWoZwOMzdt5EfkuCIraNqtEMRS0TJUhNKCQnJN.VDLFsLAmP7kQBo.C3ct4/.n.2eRlcP6hij/
Show SNMP View Command
configure terminal# show snmp view
view_name SNMPv2 - included
view_name SNMPv3 - included
view_name default - included
view_name entity - included
view_name if - included
view_name iso - included
view_name lldp - included
view_name system - included
sys-view default - included
sys-view ifmib - included
sys-view system - included
leaf3-7050sx#show snmp user
User name : user_name
Security model : v3
Engine ID : f5717f444ca824448b00
Authentication : MD5
Privacy : AES-128
Group : group_name
Configuring and Verifying Cisco IOS-XR Devices for Discovery
To configure IOS-XR devices, run the following commands on the switch console:
switch# configure terminal
switch (config)# snmp-server view view_name cisco included
snmp-server view view_name mib-2 included
snmp-server group group_name v3 auth read view_name write view_name
snmp-server user user_name
group_name v3 auth md5 password priv des56 password SystemOwner
Below shown example of configuring IOS-XR device on a switch.
RP/0/RSP0/CPU0:ios(config)#snmp-server view view_name cisco included
RP/0/RSP0/CPU0:ios(config)#snmp-server view view_name mib-2 included
RP/0/RSP0/CPU0:ios(config)#snmp-server group group_name v3 auth read view_name write view_name
RP/0/RSP0/CPU0:ios(config)#snmp-server user user_name group_name v3 auth md5 password priv des56 password SystemOwner
RP/0/RSP0/CPU0:ios(config)#commit
To verify IOS-XR devices, run the following command:
RP/0/RSP0/CPU0:ios(config)#
RP/0/RSP0/CPU0:ios(config)#show run snmp-server
snmp-server user user_name group1 v3 auth md5 encrypted 10400B0F3A4640585851 priv des56 encrypted 000A11103B0A59555B74 SystemOwner
snmp-server view view_name cisco included
snmp-server view view_name mib-2 included
snmp-server group group_name v3 auth read view_name write view_name
Discovering Non-Nexus Devices in an External Fabric
To add non-Nexus devices to an external fabric in the fabric topology window, perform the following steps:
Before you begin
Ensure that the configurations are pushed for non-Nexus devices before adding them to an external fabric. You cannot push configurations in a fabric in the monitor mode.
Procedure
Step 1 |
Click Add switches in the Actions pane. |
||||||||||||||
Step 2 |
Enter values for the following fields under the Discover Existing Switches tab:
|
||||||||||||||
Step 3 |
Click Start Discovery. The Scan Details section appears with the switch details populated. |
||||||||||||||
Step 4 |
Check the check boxes next to the switches you want to import. |
||||||||||||||
Step 5 |
Click Import into fabric. The switch discovery process is initiated. The Progress column displays the progress. Discovering devices takes some time. A pop-up message appears at the bottom-right about the device discovery after the discovery progress is 100%, or done. For example: <ip-address> added for discovery.
|
||||||||||||||
Step 6 |
Click Close. The fabric topology window appears with the switches. |
||||||||||||||
Step 7 |
(Optional) Click Refresh topology to view the latest topology view. |
||||||||||||||
Step 8 |
(Optional) Click Fabric Overview. The switches and links window appears, where you can view the scan details. The discovery status is discovering in red with a warning icon next to it if the discovery is in progress. |
||||||||||||||
Step 9 |
(Optional) View the details of the device. After the discovery of the device:
|
What to do next
If you added these devices under managed mode, you can add policies too.
Managing Non-Nexus Devices to External Fabrics
From Nexus Dashboard Fabric Controller 12.0.1a, IOS-XR is supported in managed mode.
Note |
Configuration compliance is enabled for IOS-XE and IOS-XR switches, similar to the way the Nexus switches are handled in External Fabric. For more information, see Configuration Compliance in External Fabrics. Nexus Dashboard Fabric Controller sends commit at the end of deployment for IOS-XR devices. Nexus Dashboard Fabric Controller provides a few templates for IOS-XR devices. Use the ios_xr_Ext_VRF_Lite_Jython.template for IOS-XR switch to be an edge router to establish eBGP peering with border. This will create config for vrf, eBGP peering for the vrf and the sub-interface. Similarly, ios_xe_Ext_VRF_Lite_Jython can be used for IOS-XE switch to be an edge router to establish eBGP peering with border. |
Creating a vPC Setup
Procedure
Step 1 |
Right-click one of the two designated vPC switches and choose vPC Pairing. The Select vPC peer dialog box comes up. It contains a list of potential peer switches. Ensure that the Recommended column for the vPC peer switch is updated as true.
|
||
Step 2 |
Click the radio button next to the vPC peer switch and choose vpc_pair from the vPC Pair Template drop-down list. Only templates with the VPC_PAIR template sub type are listed here. The vPC Domain and vPC Peerlink tabs appear. You must fill up the fields in the tabs to create the vPC setup. The description for each field is displayed at the extreme right. vPC Domain tab: Enter the vPC domain details. vPC+: If the switch is part of a FabricPath vPC + setup, enable this check box and enter the FabricPath switch ID field. Configure VTEPs: Check this check box to enter the source loopback IP addresses for the two vPC peer VTEPs and the loopback interface secondary IP address for NVE configuration. NVE interface: Enter the NVE interface. vPC pairing will configure only the source loopback interface. Use the freeform interface manager for additional configuration. NVE loopback configuration: Enter the IP address with the mask. vPC pairing will only configure primary and secondary IP address for loopback interface. Use the freeform interface manager for additional configuration. vPC Peerlink tab: Enter the vPC peer-link details. Switch Port Mode: Choose trunk or access or fabricpath. If you select trunk, then corresponding fields (Trunk Allowed VLANs and Native VLAN) are enabled. If you select access, then the Access VLAN field is enabled. If you select fabricpath, then the trunk and access port related fields are disabled. |
||
Step 3 |
Click Save. The vPC setup is created. To update vPC setup details, do the following:
After creating a vPC pair, you can view vPC details in vPC Overview window. |
Undeploying a vPC Setup
Procedure
Step 1 |
Right-click a vPC switch and choose vPC Pairing. The vPC peer screen comes up. |
||
Step 2 |
Click Unpair at the bottom right part of the screen. The vPC pair is deleted and the fabric topology window appears. |
||
Step 3 |
Click Deploy Config. |
||
Step 4 |
(Optional) Click the value under the Recalculate Config column. View the pending configuration in the Config Preview dialog box. The following configuration details are deleted on the switch when you unpair: vPC feature, vPC domain, vPC peerlink, vPC peerlink member ports, loopback secondary IPs, and host vPCs. However, the host vPCs and port channels are not removed. Delete these port channels from the Interfaces window if required.
|
IPFM Fabrics
This section describes how to configure fabrics related to IP Fabric for Media (IPFM). The IPFM fabric feature is a part of LAN fabric. To enable the IPFM fabrics feature, you must have enabled the following features on the LAN Fabric in
:-
IP Fabric for Media – Starts microservices corresponding to media controller.
-
PTP Monitoring – Enable if required. However, PTP monitoring is used for IPFM though it is independent of IPFM.
-
Performance Monitoring – Provides for base interface monitoring.
Beginning from Nexus Dashboard Fabric Controller version 12.0.1a, the IPFM fabric templates are of the following types:
-
IPFM_Classic Fabric – Use the IPFM_Classic fabric template to bring in switches from an existing IPFM fabric. This template works like an external or LAN Classic Fabric where only basic switch configuration such as management VRF/interface, and hostname can be imported. You can set the attribute of the fabric to Read/Write or Read-only. For the Read-only fabric, enable the monitor mode. This template supports IPFM_Classic and Generic_Multicast technologies.
-
Easy_Fabric_IPFM Fabric – Use the Easy_Fabric_IPFM template to create a new IPFM fabric with Easy Fabric management and build an underlay network for the IPFM fabric.
Note |
IPFM Easy Fabric supports only Greenfield deployments. |
We recommend that you deploy a 3-node cluster if you’ve more than 35 switches in your NDFC deployment. If you are using a Virtual Nexus Dashboard Cluster before you begin, ensure that the Persistent IP address and required settings are enabled for telemetry. Refer to Cisco Nexus Dashboard Fabric Controller Deployment Guide.
For a fresh installation, you can choose either IPFM Easy Fabric or IPFM Classic Fabric, based on your requirement.
Creating IPFM Fabrics
Perform the following procedures to create IPFM fabrics:
-
Create the required IPFM Fabric using the appropriate templates and set the parameters. For more information about IPFM_Classic template, see Creating an IPFM Classic Fabric. For more information about Easy_Fabric_IPFM template, see Creating an IPFM Easy Fabric.
-
Add switches to the fabric and set the switch roles (only spine and leaf are supported for IPFM Fabric). For more information about adding switches, discovering existing and new switches, assigning roles, and deploying switches, see Switches.
Note
IPFM Easy Fabric supports only Greenfield deployments.
-
In the Fabric Overview window of your fabric, choose Recalculate Config from the Actions drop-down list. Then, in the Deploy Configuration window, click the Deploy button to deploy the configuration. For more information, see Fabric Overview.
IPFM Easy Fabric: The underlay config of each switch is calculated based on the fabric settings, switch role, and switch platform.
IPFM Classic Fabric: If you choose to have Nexus Dashboard Fabric Controller manage the interfaces for your fabric, perform host_port_resync/Interface Config Resync to complete the migration process for the switch. For more information about host port resync, see Sync up Out-of-Band Switch Interface Configurations.
The time taken by host port resync depends on the number of switches/interfaces to be synchronized.
If you want to edit or delete an IPFM fabric, see Editing an IPFM Fabric or Deleting an IPFM Fabric respectively.
-
Edit the existing interfaces as required. For more information, see Editing an Interface for IPFM Fabrics. For more information about any new logical interfaces, see Creating an Interface for IPFM Fabrics.
Creating an IPFM Classic Fabric
This section describes the procedure to create an IPFM classic fabric from the IPFM_Classic template.
Procedure
Step 1 |
In the LAN Fabrics window, from the Actions drop-down list, choose Create Fabric. The Create Fabric window appears.
|
||
Step 2 |
In the Create Fabric window, enter a fabric name and click Choose Template. |
||
Step 3 |
Either search or scroll and choose the IPFM_Classic fabric template. Click Select. The Create Fabric window displays the following elements: Fabric Name - Displays the fabric name you entered. Pick Template - Displays the template type that you selected. If you want to change the template, click it. The Select Fabric Template window appears. Repeat the current step. General Parameters, Advanced, and Bootstrap tabs - Display the fabric settings for creating an IPFM classic fabric. |
||
Step 4 |
The General Parameters tab is displayed by default. The fields in this tab are: Fabric Technology – Choose one of the following technologies from the drop-down list:
Fabric Monitor Mode – Select this check box to only monitor the fabric, but not deploy the configuration. Enable Performance Monitoring – Select this check box to monitor the performance of the fabric.Ensure that you do not clear interface counters from the Command Line Interface of the switches. Clearing interface counters
can cause the Performance Monitor to display incorrect data for traffic utilization. If you must clear the counters and the
switch has both |
||
Step 5 |
Click the Advanced tab. The fields in this tab are: Power Supply Mode – Choose the appropriate power supply mode. Enable AAA IP Authorization– Enables AAA IP authorization, when IP Authorization is enabled in the AAA Server. Enable NDFC as Trap Host – Select this check box to enable Nexus Dashboard Fabric Controller as a trap host. Enable CDP for Bootstrapped Switch – Enables CDP on management interface. Inband Mgmt – For External and Class ic LAN Fabrics, this knob enables Nexus Dashboard Fabric Controller to import and manage of switches with inband connectivity (reachable over switch loopback, routed, or SVI interfaces), in addition to management of switches with out-of-band connectivity (that is, reachable over switch mgmt0 interface). The only requirement is that for Inband managed switches, there should be IP reachability from Nexus Dashboard Fabric Controller to the switches through the Nexus Dashboard data interface. After enabling Inband management, during discovery, provide the IPs of all the switches to be imported using Inband Management and set maximum hops to 0. Nexus Dashboard Fabric Controller has a pre-check that validates that the Inband managed switch IPs are reachable over the Nexus Dashboard data interface. Once the pre-check has passed, Nexus Dashboard Fabric Controller then discovers and learns about the interface on that switch that has the specified discovery IP in addition to the VRF that the interface belongs to. As part of the process of switch import/discovery, this information is captured in the baseline intent that is populated on the Nexus Dashboard Fabric Controller. For more information, see Inband Management in External Fabrics and LAN Classic Fabrics.
Fabric Freeform – You can apply configurations globally across all the devices discovered in the external fabric using this freeform field. AAA Freeform Config – Specifies the AAA freeform configurations. |
||
Step 6 |
Click the Bootstrap tab. The fields in this tab are: Enable Bootstrap (For NX-OS Switches Only) – Select this check box to enable the bootstrap feature for only Cisco Nexus switches. When this check box is selected, automatic IP assignment for POAP is enabled. After you enable bootstrap, you can enable the DHCP server for automatic IP address assignment for POAP using the following method:
Enable Local DHCP Server – Select this check box to initiate enabling of automatic IP address assignment through the local DHCP server. When you select this check box, all the remaining fields become editable. DHCP Version – Select either DHCPv4 or DHCPv6 from the drop-down list. When you select DHCPv4, the Switch Mgmt IPv6 Subnet Prefix field is disabled. If you select DHCPv6, the Switch Mgmt IP Subnet Prefix is disabled.
If you don’t select this check box, Nexus Dashboard Fabric Controller uses the remote or external DHCP server for automatic IP address assignment. DHCP Scope Start Address and DHCP Scope End Address – Specifies the first and the last IP addresses of the IP address range to be used for the switch out of band POAP. Switch Mgmt Default Gateway– Specifies the default gateway for the management VRF on the switch. Switch Mgmt IP Subnet Prefix – Specifies the prefix for the Mgmt0 interface on the switch. The prefix should be between 8 and 30. DHCP scope and management default gateway IP address specification - If you specify the management default gateway IP address 10.0.1.1 and subnet mask 24, ensure that the DHCP scope is within the specified subnet, between 10.0.1.2 and 10.0.1.254. Switch Mgmt IPv6 Subnet Prefix – Specifies the IPv6 prefix for the Mgmt0 interface on the switch. The prefix should be between 64 and 126. This field is editable if you enable IPv6 for DHCP. Bootstrap Freeform Config – (Optional) Enter extra commands as needed. For example, if you are using AAA or remote authentication related configurations, you need to add these configurations in this field to save the intent. After the devices boot up, they contain the intent defined in the Bootstrap Freeform Config field. Copy-paste the running-config to a freeform config field with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running-config. For more information about Resolving Freeform Config Errors in Switches, see Enabling Freeform Configurations on Fabric Switches. DHCPv4/DHCPv6 Multi Subnet Scope – Specifies the field to enter one subnet scope per line. This field is editable after you select the Enable Local DHCP Server check box. The format of the scope should be defined as: DHCP Scope Start Address,DHCP Scope End Address,Switch Management Default Gateway,Switch Management Subnet Prefix For example, 10.6.0.2,10.6.0.9,10.6.0.1,24. |
||
Step 7 |
Click Save. The IPFM classic fabric is created and displayed in the table in the Lan Fabrics window. |
What to do next
After creating the fabric, perform Recalculate Config and deploy the configuration to the switches. For more information, see Fabric Overview.
Then, edit or create an interface as appropriate. For more information, see Interface Configuration for IPFM Fabrics.
Creating an IPFM Easy Fabric
This section describes the procedure to create an IPFM Fabric from the Easy_Fabric_IPFM fabric template.
Procedure
Step 1 |
In the LAN Fabrics window, from the Actions drop-down list, choose Create Fabric. The Create Fabric window appears.
|
||||||
Step 2 |
In the Create Fabric window, enter a fabric name and click Choose Template. The Select Fabric Template window appears. |
||||||
Step 3 |
Either search or scroll and choose the Easy_Fabric_IPFM template. Click Select. The Create Fabric window displays the following elements: Fabric Name - Displays the fabric name you entered. Pick Template - Displays the template type that you selected. If you want to change the template, click it. The Select Fabric Template screen appears. Repeat the current step. General Parameters, Multicast, Protocols, Advanced, Manageability, and Bootstrap tabs - Display the fabric settings for creating an IPFM easy fabric. |
||||||
Step 4 |
The General Parameters tab is displayed by default. The fields in this tab are: Fabric Interface Numbering - Supports only numbered (point-to-point, that is, p2p) networks. Fabric Subnet IP Mask - Specifies the subnet mask for the fabric interface IP addresses. Fabric Routing Protocol - The IGP used in the fabric, OSPF, or IS-IS. Fabric Routing Loopback Id: The loopback interface ID is populated as 0 since loopback0 is usually used for fabric underlay IGP peering purposes. The valid value ranges from 0 to 1023. Manual Fabric IP Address Allocation - Select this check box to disable dynamic allocation of fabric IP address.
Fabric Routing Loopback IP Range - Specifies the range of loopback IP addresses for the protocol peering. Fabric Subnet IP Range - IP addresses for underlay P2P routing traffic between interfaces. Enable Performance Monitoring - Select this check box to monitor the performance of the fabric. Ensure that you do not clear interface counters from the Command Line Interface of the switches. Clearing interface counters
can cause the Performance Monitor to display incorrect data for traffic utilization. If you must clear the counters and the
switch has both |
||||||
Step 5 |
Click the Multicast tab. The fields in this tab are:
Enable NBM Passive Mode - Select this check box to enable NBM mode to pim-passive. If you enable NBM passive mode, the switch ignores all RP and MSDP configurations. This is a mandatory check box. If you select this check box, the remaining fields and check boxes are disabled. For more information, refer to the Configuring an NBM VRF for Static Flow Provisioning section of the Cisco Nexus 9000 Series NX-OS IP Fabric for Media Solution Guide, Release 10.2(x). Enable ASM - Select this check box to enable groups with receivers sending (*,G) joins. If you select this check box, the ASM-related section is enabled. NBM Flow ASM Groups for default VRF (w/wo SPT-Threshold Infinity) - This section comprises ASM-related information.
RP Loopback Id - The loopback ID used for the rendezvous point (RP), for multicast protocol peering purposes in the fabric underlay. The valid values range from 0 to 1023. Fabric RP Loopback IP Range - Specifies the RP Loopback IP address range. |
||||||
Step 6 |
Click the Protocols tab. The fields in this tab are: Fabric Routing Protocol Tag - Specifies the routing process tag for the fabric. OSPF Area Id - The OSPF area ID, if OSPF is used as the IGP within the fabric.
Enable OSPF Authentication - Select the check box to enable OSPF authentication. Clear the check box to disable it. If you enable this field, the OSPF Authentication Key ID and OSPF Authentication Key fields get enabled. OSPF Authentication Key ID - The key ID is populated. OSPF Authentication Key - The OSPF authentication key must be the 3DES key from the switch.
IS-IS Level - Select the IS-IS level from this drop-down list. Enable IS-IS Network Point-to-Point - Select the check box to enable network point-to-point on fabric interfaces which are numbered. Enable IS-IS Authentication - Select the check box to enable IS-IS authentication. Clear the check box to disable it. If you enable this field, the IS-IS authentication fields are enabled. IS-IS Authentication Keychain Name - Enter the Keychain name, for example, CiscoisisAuth. IS-IS Authentication Key ID - The Key ID is populated. IS-IS Authentication Key - Enter the Cisco Type 7 encrypted key.
Enable PIM Hello Authentication - Enables the PIM hello authentication. PIM Hello Authentication Key - Specifies the PIM hello authentication key. |
||||||
Step 7 |
Click the Advanced tab. The fields in this tab are: Intra Fabric Interface MTU - Specifies the MTU for the intra fabric interface. This value must be an even number. The valid values range from 576 to 9216. This is a mandatory field. Layer 2 Host Interface MTU - Specifies the MTU for the layer 2 host interface. This value must be an even number. The valid values range from 1500 to 9216. Power Supply Mode - Choose the appropriate power supply mode that will be the default mode for the fabric from the drop-down list. This is a mandatory field. Enable CDP for Bootstrapped Switch - Select this check box to enable CDP on management (mgmt0) interface for bootstrapped switch. By default, for bootstrapped switches, CDP is disabled on the mgmt0 interface. Enable AAA IP Authorization - Enables AAA IP authorization, when IP Authorization is enabled in the remote authentication server. This is required to support Nexus Dashboard Fabric Controller in scenarios where customers have strict control of which IP addresses can have access to the switches. Enable NDFC as Trap Host - Select this check box to enable Nexus Dashboard Fabric Controller as an SNMP trap destination. Typically, for a native HA Nexus Dashboard Fabric Controller deployment, the eth1 VIP IP address will be configured as SNMP trap destination on the switches. By default, this check box is enabled. Enable Precision Time Protocol (PTP) - Enables PTP across a fabric. When you select this check box, PTP is enabled globally and on intra-fabric interfaces. Additionally, the PTP Source Loopback Id and PTP Domain Id fields are editable. For more information, see Precision Time Protocol for Easy Fabric. PTP Source Loopback Id - Specifies the loopback interface ID Loopback that is used as the Source IP Address for all PTP packets. The valid values range from 0 to 1023. The PTP loopback ID cannot be the same as RP loopback ID. Otherwise, an error appears. The PTP loopback ID can be the same as BGP loopback or user-defined loopback which is created from Nexus Dashboard Fabric Controller. The PTP loopback will be created automatically if it is not created. PTP Domain Id - Specifies the PTP domain ID on a single network. The valid values range from 0 to 127. PTP Profile - Select a PTP profile from the list. PTP profile is enabled only on ISL links. The supported PTP Profiles are IEEE-1588v2, SMPTE-2059-2, and AES67-2015. Leaf Freeform Config - Add CLIs that should be added to switches that have the Leaf, Border, and Border Gateway roles. Spine Freeform Config - Add CLIs that should be added to switches with a Spine, Border Spine, Border Gateway Spine, and Super Spine roles. Intra-fabric Links Additional Config - Add CLIs that should be added to the intra-fabric links. |
||||||
Step 8 |
Click the Manageability tab. The fields in this tab are: DNS Server IPs - Specifies the comma separated list of IP addresses (v4/v6) of the DNS servers. DNS Server VRFs - Specifies one VRF for all DNS servers or a comma separated list of VRFs, one per DNS server. NTP Server IPs - Specifies comma separated list of IP addresses (v4/v6) of the NTP server. NTP Server VRFs - Specifies one VRF for all NTP servers or a comma separated list of VRFs, one per NTP server. Syslog Server IPs - Specifies the comma separated list of IP addresses (v4/v6) IP address of the syslog servers, if used. Syslog Server Severity - Specifies the comma separated list of syslog severity values, one per syslog server. The minimum value is 0 and the maximum value is 7. To specify a higher severity, enter a higher number. Syslog Server VRFs - Specifies one VRF for all syslog servers or a comma separated list of VRFs, one per syslog server. AAA Freeform Config - Specifies the AAA freeform Configurations. If AAA configurations are specified in the fabric settings, switch_freeform PTI with source as UNDERLAY_AAA and description as AAAConfigurations will be created. |
||||||
Step 9 |
Click the Bootstrap tab. The fields in this tab are: Enable Bootstrap - Select this check box to enable the bootstrap feature. Bootstrap allows easy day-0 import and bring-up of new devices into an existing fabric. Bootstrap leverages the NX- OS POAP functionality. After you enable bootstrap, you can enable the DHCP server for automatic IP address assignment for POAP using one of the following methods:
Enable Local DHCP Server - Select this check box to initiate enabling of automatic IP address assignment through the local DHCP server. When you select this check box, the DHCP Scope Start Address and DHCP Scope End Address fields become editable. If you do not select this check box, Nexus Dashboard Fabric Controller uses the remote or external DHCP server for automatic IP address assignment. DHCP Version - Select DHCPv4 or DHCPv6 from this drop-down list. When you select DHCPv4, the Switch Mgmt IPv6 Subnet Prefix field is disabled. If you select DHCPv6, the Switch Mgmt IP Subnet Prefix field is disabled.
DHCP Scope Start Address - Specifies the first IP address in the IP address range to be used for the switch out-of-band POAP. DHCP Scope End Address - Specifies the last IP address in the IP address range to be used for the switch out-of-band POAP. Switch Mgmt Default Gateway - Specifies the default gateway for the management VRF on the switch. Switch Mgmt IP Subnet Prefix - Specifies the prefix for the Mgmt0 interface on the switch. The prefix should be between 8 and 30. DHCP scope and management default gateway IP address specification - If you specify the management default gateway IP address 10.0.1.1 and subnet mask 24, ensure that the DHCP scope is within the specified subnet, between 10.0.1.2 and 10.0.1.254. Switch Mgmt IPv6 Subnet Prefix - Specifies the IPv6 prefix for the Mgmt0 interface on the switch. The prefix should be between 64 and 126. This field is editable if you enable IPv6 for DHCP. Enable AAA Config - Select this check box to include AAA configurations from the Manageability tab as part of the device startup config post bootstrap. Bootstrap Freeform Config - (Optional) Enter additional commands as needed. For example, if you require some additional configurations to be pushed to the device and be available post device bootstrap, they can be captured in this field, to save the desired intent. After the devices boot up, they will contain the configuration defined in the Bootstrap Freeform Config field. Copy-paste the running-config to a freeform config field with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running-config. For more information about Resolving Freeform Config Errors in Switches, see Enabling Freeform Configurations on Fabric Switches. DHCPv4/DHCPv6 Multi Subnet Scope - Specifies the field to enter one subnet scope per line. This field is editable after you check the Enable Local DHCP Server check box. The format of the scope should be defined as: DHCP Scope Start Address, DHCP Scope End Address, Switch Management Default Gateway,Switch Management Subnet Prefix For example, 10.6.0.2,10.6.0.9,10.6.0.1,24 |
||||||
Step 10 |
Click Save. The Easy Fabric IPFM is created and displayed in the table in the Lan Fabrics window. |
What to do next
After creating the fabric, perform Recalculate Config and deploy the configuration to the switches. For more information, see Fabric Overview.
Then, edit or create an interface as appropriate. For more information, see Interface Configuration for IPFM Fabrics.
Retrieving the Authentication Key
Retrieving the 3DES Encrypted OSPF Authentication Key
-
SSH into the switch.
-
On an unused switch interface, enable the following:
config terminal feature ospf interface Ethernet1/1 no switchport ip ospf message-digest-key 127 md5 ospfAuth
In the example, ospfAuth is the unencrypted password.
Note
This Step 2 is needed when you want to configure a new key.
-
Enter the show run interface Ethernet1/1 command to retrieve the password.
Switch # show run interface Ethernet1/1 interface Ethernet1/1 no switchport ip ospf message-digest key 127 md5 3 sd8478f4fsw4f4w34sd8478fsdfw no shutdown
The sequence of characters after md5 3 is the encrypted password.
-
Update the encrypted password into the OSPF Authentication Key field.
Retrieving the Encrypted IS-IS Authentication Key
To get the key, you must have access to the switch.
-
SSH into the switch.
-
Create a temporary keychain.
config terminal key chain isis key 127 key-string isisAuth
In the example, isisAuth is the plaintext password. This will get converted to a Cisco type 7 password after the CLI is accepted.
-
Enter the show run | section “key chain” command to retrieve the password.
key chain isis key 127 key-string 7 071b245f5a
The sequence of characters after key-string 7 is the encrypted password. Save it.
-
Update the encrypted password into the ISIS Authentication Key field.
-
Remove any unwanted configuration made in Step 2.
Retrieving the 3DES Encrypted BGP Authentication Key
-
SSH into the switch and enable BGP configuration for a non-existent neighbor.
Note
Non-existent neighbor configuration is a temporary BGP neighbor configuration for retrieving the password.
router bgp neighbor 10.2.0.2 remote-as 65000 password bgpAuth
In the example, bgpAuth is the unencrypted password.
-
Enter the show run bgp command to retrieve the password. A sample output:
neighbor 10.2.0.2 remote-as 65000 password 3 sd8478fswerdfw3434fsw4f4w34sdsd8478fswerdfw3434fsw4f4w3
The sequence of characters after password 3 is the encrypted password.
-
Update the encrypted password into the BGP Authentication Key field.
-
Remove the BGP neighbor configuration.
Retrieving the Encrypted BFD Authentication Key
-
SSH into the switch.
-
On an unused switch interface, enable the following:
switch# config terminal switch(config)# int e1/1 switch(config-if)# bfd authentication keyed-SHA1 key-id 100 key cisco123
In the example, cisco123 is the unencrypted password and the key ID is 100.
Note
This Step 2 is needed when you want to configure a new key.
-
Enter the show running-config interface command to retrieve the key.
switch# show running-config interface Ethernet1/1 interface Ethernet1/1 description connected-to- switch-Ethernet1/1 no switchport mtu 9216 bfd authentication Keyed-SHA1 key-id 100 hex-key 636973636F313233 no ip redirects ip address 10.4.0.6/30 no ipv6 redirects ip ospf network point-to-point ip router ospf 100 area 0.0.0.0 no shutdown
The BFD key ID is 100 and the encrypted key is 636973636F313233.
-
Update the key ID and key in the BFD Authentication Key ID and BFD Authentication Key fields.
Editing an IPFM Fabric
In the LAN Fabrics window, select the fabric that you want to edit. From the Actions drop-down list, choose Edit Fabric. Edit the fields in the template as required. Click Save.
Note |
After the fabric settings are changed, perform Recalculate Config, and deploy the configuration to the switches. |
Deleting an IPFM Fabric
In the LAN Fabrics window, select the fabric that you want to delete. From the Actions drop-down list, choose Delete Fabric. When a message appears asking whether you want to delete the fabric, click Confirm.
Interface Configuration for IPFM Fabrics
Cisco Nexus Dashboard Fabric Controller Web UI allows you to configure IPFM External-Links for each switch in your fabric. The external device can connect to the network through this interface by marking it as IPFM External-Link.
Note |
A user with the network operator role in Nexus Dashboard Fabric Controller cannot save, deploy, undeploy, or edit interface configs. |
Beginning with NDFC Release 12.0.1a, Interfaces in IPFM fabrics are managed by the Nexus Dashboard Fabric Controller Interface Manager. The default interface policy for IPFM is int_ipfm_l3_port.
The following issues are seen when NBM VRF is deleted from NDFC after interface is enabled with NBM external-link and unicast BW setting. When this occurs, the affected interfaces continues to show external-link and ucast BW as set. Perform the following steps to cleanup:
-
Select all the switches that has these interface issues under Policies tab using Add Policy.
-
Choose host_port_resync template and click Save.
-
Select Recalculate & Deploy. This syncs switch configuration with NDFC.
-
Select Resync All.
The non-fabric ethernet interface policy templates for IPFM fabrics are int_ipfm_l3_port, int_ipfm_access_host, and int_ipfm_trunk_host.
The port channel interface policy templates for IPFM fabrics are int_ipfm_port_channel_access_host, int_ipfm_port_channel_trunk_host, int_ipfm_port_channel_access_member, and int_ipfm_port_channel_trunk_member.
The Switch Virtual Interface (SVI) template for IPFM fabrics is int_ipfm_vlan.
Creating an Interface for IPFM Fabrics
This section describes the procedure to create a new interface for an IPFM fabric based on the template that you have selected from the available IPFM fabric interface templates.
Note |
IPFM fabrics do not support V6 underlay. |
Procedure
Step 1 |
Navigate to the Fabric Overview window for your fabric and click the Interfaces tab. |
Step 2 |
Choose Create new interface from the Actions drop-down list. The Create new interface window appears. |
Step 3 |
Select either Port Channel, Loopback, or SVI as the interface type for IPFM. |
Step 4 |
Select a device from the drop-down list. The switches (spine and leaf) that are a part of the fabric are displayed in the drop-down list. |
Step 5 |
Enter the Port Channel ID, Loopback ID, or VLAN ID, based on your choice of the interface type. |
Step 6 |
Click the No Policy Selected link to select a policy that is specific to IPFM. In the Select Attached Policy Template dialog box, choose the required interface policy template and click Save. |
Step 7 |
Enter the appropriate values in the Policy Options area. Note that the appropriate Policy Options fields are displayed based on the policy.
|
Step 8 |
Based on your requirements, click one of the following buttons:
|
What to do next
If you want to edit the interface, see Editing an Interface for IPFM Fabrics.
If your interface is ready, add a policy for configuring the IPFM fabric. For more information, see Adding a Policy for Configuring an IPFM Fabric
PTP Configuration for IPFM Fabrics
The Precision Time Protocol (PTP) is a protocol used to synchronize clocks throughout a computer network. When creating an interface, if you enable the Enable PTP check box, PTP is enabled across the fabric and on all the intrafabric interfaces. The supported PTP profiles for IPFM fabrics are IEEE-1588v2, SMPTE-2059-2, and AES67-2015.
A few things to note about the per-interface PTP profile for nonfabric ethernet interfaces are as follows:
-
You must enable PTP and select PTP profile on each nonfabric ethernet interface.
-
PTP profile can be different from the fabric level one.
-
PTP must be enabled in the fabric settings before PTP can be configured on a nonfabric ethernet interface.
If PTP is disabled from the fabric settings, the PTP config will be removed from all the interfaces, that is, both the fabric and nonfabric interfaces.
For more information about PTP monitoring for IPFM fabrics, see PTP (Monitoring).
Editing an Interface for IPFM Fabrics
This section describes the procedure to edit an existing IPFM fabric interface template. You can either change a template or edit the values for any of the editable parameters in the Policy Options area.
Procedure
Step 1 |
Navigate to the Fabric Overview window for your fabric and click the Interfaces tab. |
Step 2 |
Choose Edit interface from the Actions drop-down list. The Edit interface window appears. |
Step 3 |
This step is optional. To change a policy, click the policy link and select a policy that is specific to IPFM. In the Select Attached Policy Template dialog box, choose the required interface policy template and click Save. |
Step 4 |
Edit the required values in the Policy Options area. Note that the appropriate Policy Options fields are displayed based on the policy. For more information about the parameters, see Creating an Interface for IPFM Fabrics. Note that the following fields are specific to the int_ipfm_l3_port policy: IPFM Unicast Bandwidth Percentage - Specifies the dedicated percentage of bandwidth to the unicast traffic. The remaining percentage is automatically reserved for the multicast traffic. If this field is left blank, Global Unicast Bandwidth reservation is used. IPFM External-Link - Select this check box to specify that the interface is connected to an external router. Border Router - Select this check box to enables the border router configuration on the interface. The interface is a boundary of a PIM domain. Interface Description - Enter description for the interface. The maximum size limit is 254 characters. |
Step 5 |
Based on your requirements, click one of the following buttons:
|
What to do next
Add a policy for configuring the IPFM fabric. For more information, see Adding a Policy for Configuring an IPFM Fabric.
Adding a Policy for Configuring an IPFM Fabric
For configuration that is not uniform for all leafs or spines, additional templates are provided to help you complete the configuration of an IPFM fabric.
For example, if you enable NAT on a 9300 switch, you can create an ipfm_tcam_nat_9300 policy to configure the required NAT TCAM for the switch.
Use the ipfm_telemetry policy for telemetry and ipfm_vrf policy for VRF config (routing, pim, asm).
Procedure
Step 1 |
Navigate to the Fabric Overview window for your fabric and click the Policies tab. |
Step 2 |
Choose Add Policy from the Actions drop-down list. The Create Policy window appears. |
Step 3 |
Click the right arrow in the Select Switches field. The Select Switches dialog box appears. |
Step 4 |
Select one or more switches and click Select. |
Step 5 |
In the Create Policy window, click Choose Template. |
Step 6 |
In the Select a Policy Template dialog box, select the required template for IPFM fabric, for example, ipfm_tcam_nat_9300. Click Select. |
Step 7 |
Enter a priority for the template. The valid value ranges from 1 to 1000. |
Step 8 |
Enter the values in the TCAM-related fields. Make sure that you enter the TCAM size in increments of 256 and click Save. |
Editing a Policy for an IPFM Fabric
You can edit a policy for any switch in the IPFM fabric.
Procedure
Step 1 |
Navigate to the Fabric Overview window for your fabric and click the Policies tab. |
Step 2 |
Search for the policy template. |
Step 3 |
Select the policy and choose Edit Policy from the Actions drop-down list. The Edit Policy window appears. |
Step 4 |
Make the required changes and click Save. |
Netflow Support
Configuring Netflow at the fabric level allows you to collect, record, export, and monitor network flow and data to determine network traffic flow and volume for further analysis and troubleshooting. From Cisco NDFC Release 12.0.2, you can configure Netflow for Easy Fabrics, Easy Fabric eBGP, External Fabric, and LAN Classic templates.
After netflow is enabled for fabric, you can configure netflow on a network, or an interface (VLAN, SVI, physical interface, sub-interface, or port-channel). Before enabling netflow on the interface or network, ensure that the specified monitor name is defined in the fabric settings.
When Netflow is enabled at the Fabric level, the configuration is generated for netflow capable switches (FX/GX/EX) in the fabric except for spine/super-spine or switches with no_netflow policy. In a Multi-Site domain configuration, netflow is configured per Easy Fabric and not for the entire Multi-Site domain.
Note |
NDFC does not validate the Netflow Monitor name. |
The following are the guidelines for Netflow configuration on other networks elements:
-
For VRF Lite IFC, the netflow configuration is not inside the configuration profile, regardless of overlay mode.
-
For networks, netflow configurations are not inside the configuration profile, regardless of overlay mode.
-
You can configure netflow for Layer 2 Interface on trunk ports, access ports, dot1q tunnels, Layer2 port-channel, and VPC ports.
-
You can configure netflow for the Layer 3 interface on SVI, Routed host, L3 Port-Channel, and sub-interfaces.
-
Netflow configuration for VLANs uses vlan_netflow Record Template. In Brownfield deployment, the netflow configuration for VLANs is in switch freeform.
-
You can enable Netflow under SVI (for routed traffic) or Vlan Configuration (for switched traffic).
-
To configure IPv6 flow monitoring, use switch_freeform or interface freeform.
-
Netflow configuration under the trunk or routed port is in interface freeform.
-
For Host port resync, netflow configuration is captured in interface freeform.
-
There is no explicit support for netflow in Intra-Fabric link or Multisite Underlay IFC. Note that you can use freeform configuration.
Netflow Support for Brownfield deployments
For Brownfield deployments, global netflow configuration for export, record, and monitor are not captured due to the telemetry use case. After brownfield import, to avoid global level netflow command being removed, you can perform the following actions:
-
Do not turn on strict CC.
-
Include the netflow global configuration in switch freeform.
-
Enable Netflow in the fabric setting matching with the switch configuration.
Interface and VLAN level netflow configuration on the switch will be captured in freeform.
-
SVI netflow config is captured in switch_freeform tied to the network.
-
Netflow configuration for trunk or routed ports is in the interface freeform.
-
Netflow configuration for VLANs is in the switch_freeform.
-
The sub-interface configuration for VRF-Lite extensions is in int_freeform.
Precision Time Protocol for External Fabrics and LAN Classic Fabrics
In the Fabric settings for the External Fabric or LAN_Classic template, select the Enable Precision Time Protocol (PTP) check box to enable PTP across a fabric. When you select this check box, PTP is enabled globally and on core-facing interfaces. Additionally, the PTP Loopback Id and PTP Domain Id fields are editable.
The PTP feature is supported with Cisco Nexus 9000 Series cloud-scale switches, with NX-OS version 7.0(3)I7(1) or later. Warnings are displayed if there are non-cloud scale devices in the fabric, and PTP is not enabled. Examples of the cloud-scale devices are Cisco Nexus 93180YC-EX, Cisco Nexus 93180YC-FX, Cisco Nexus 93240YC-FX2, and Cisco Nexus 93360YC-FX2 switches. For more information, refer to https://www.cisco.com/c/en/us/products/switches/nexus-9000-series-switches/index.html.
Note |
PTP global configuration is supported with Cisco Nexus 3000 Series switches; however, PTP and ttag configurations are not supported. |
For more information, see the Configuring PTP chapter in Cisco Nexus 9000 Series NX-OS System Management Configuration Guide and Cisco Nexus Insights for Cisco Nexus Dashboard Fabric Controller User Guide.
For External and LAN_Classic fabric deployments, you have to enable PTP globally, and also enable PTP on core-facing interfaces. The interfaces could be configured to the external PTP server like a VM or Linux-based machine. Therefore, the interface should be edited to have a connection with the grandmaster clock. For PTP and TTAG configurations to be operational on External and LAN_Classic Fabrics, you must sync up of Switch Configs to Nexus Dashboard Fabric Controller using the host_port_resync policy. For more information, see Sync up Out-of-Band Switch Interface Configurations.
It is recommended that the grandmaster clock should be configured outside of Easy Fabric and it is IP reachable. The interfaces toward the grandmaster clock need to be enabled with PTP via the interface freeform config.
All core-facing interfaces are auto-enabled with the PTP configuration after you click Deploy Config. This action ensures that all devices are PTP synced to the grandmaster clock. Additionally, for any interfaces that are not core-facing, such as interfaces on the border devices and leafs that are connected to hosts, firewalls, service-nodes, or other routers, the ttag related CLI must be added. The ttag is added for all traffic entering the VXLAN EVPN fabric and the ttag must be stripped when traffic is exiting this fabric.
Here is the sample PTP configuration: feature ptp
feature ptp
ptp source 100.100.100.10 -> IP address of the loopback interface (loopback0)
that is already created, or user-created loopback interface in the fabric settings
ptp domain 1 -> PTP domain ID specified in fabric settings
interface Ethernet1/59 -> Core facing interface
ptp
interface Ethernet1/50 -> Host facing interface
ttag
ttag-strip
The following guidelines are applicable for PTP:
-
The PTP feature can be enabled in a fabric when all the switches in the fabric have Cisco NX-OS Release 7.0(3)I7(1) or a higher version. Otherwise, the following error message is displayed:
PTP feature can be enabled in the fabric, when all the switches have NX-OS Release 7.0(3)I7(1) or higher version. Please upgrade switches to NX-OS Release 7.0(3)I7(1) or higher version to enable PTP in this fabric.
-
For hardware telemetry support in NIR, the PTP configuration is a prerequisite.
-
If you are adding a non-cloud scale device to an existing fabric which contains PTP configuration, the following warning is displayed:
TTAG is enabled fabric wide, when all devices are cloud-scale switches so it cannot be enabled for newly added non cloud-scale device(s).
-
If a fabric contains both cloud-scale and non-cloud scale devices, the following warning is displayed when you try to enable PTP:
TTAG is enabled fabric wide when all devices are cloud-scale switches and is not enabled due to non cloud-scale device(s).
-
TTAG configuration is generated for all the devices if host configuration sync up is performed on all the devices. Ttag configuration will not be generated for any newly added devices if host configuration sync up is not performed on all newly added devices.
If the configuration is not synced, the following warning is displayed:
TTAG on interfaces with PTP feature can only be configured for cloud-scale devices. It will not be enabled on any newly added switches due to the presence of non cloud-scale devices.
-
PTP and TTAG configurations are deployed on host interfaces.
-
PTP and TTAG Configurations are supported between switches in the same fabric (intra-fabric links). PTP is created for inter-fabric links, and ttag is created for the inter-fabric link if the other fabric (Switch) is not managed by Nexus Dashboard Fabric Controller. Inter-fabric links do not support PTP or ttag configurations if both fabrics are managed by Nexus Dashboard Fabric Controller.
-
TTAG configuration is configured by default after the breakout. After the links are discovered and connected post breakout, perform Deploy Config to generate the correct configuration based on the type of port (host, intra-fabric link, or inter fabric link).
Brownfield Deployment-Transitioning VXLAN Fabric Management to Nexus Dashboard Fabric Controller
Nexus Dashboard Fabric Controller supports Brownfield deployments, wherein you transition your VXLAN BGP EVPN fabric management to Nexus Dashboard Fabric Controller. The transition involves migrating existing network configurations to Nexus Dashboard Fabric Controller. For information, see Managing a Brownfield VXLAN BGP EVPN Fabric.
Inband Management in External Fabrics and LAN Classic Fabrics
Inband Management
Cisco Nexus devices have dedicated out-of-band (OOB) management ports (mgmt0) to manage devices via telnet or SSH connections.
Now you can manage Cisco Nexus devices via Inband using front panel ports either by assigning management IP addresses on one of the ports or using loopback or SVI. By default, (mgmt0) interface is part of management VRF.
In NDFC by default, VRF is used for Inband management, you can use other defined VRFs for inband management for nexus devices. Inband Management is the ability to administer a network through LAN connection.
You can import or discover switches with inband connectivity for External and LAN Classic fabrics in Brownfield deployments only. Enable inband management per fabric, while configuring or editing the Fabric settings. You cannot import or discover switches with inband connectivity using POAP.
After configuration, the Fabric tries to discover switches based on the VRF of the inband management. The fabric template determines the VRF of the inband switch using seed IP. If there are multiple VRFs for the same seed IP, then no intent will be learned for seed interfaces. You must create intent or configuration manually.
After configuring or editing the Fabric settings, you must Deploy Config. You cannot change the Inband Mgmt settings after you import inband managed switches to the Fabric. If you uncheck the check box, the following error message is generated.
Inband IP <<IP Address>> cannot be used to import the switch,
please enable Inband Mgmt in fabric settings and retry.
After the switches are imported to the Fabric, you must manage the interfaces to create intent. Create the intent for the interfaces that you are importing the switch. Edit\update the Interface configuration. When you try to change the Interface IP, for this inband managed switch, an error message is generated:
Interface <<interface_name>> is used as seed or next-hop egress interface
for switch import in inband mode.
IP/Netmask Length/VRF changes are not allowed for this interface.
While managing the interfaces, for switches imported using inband management, you cannot change the seed IP for the switch. The following error will be generated:
<<switch-name>>: Mgmt0 IP Address (<ip-address>) cannot be changed,
when is it used as seed IP to discover the switch.
Create a policy for next-hop interfaces. Routes to Cisco Nexus Dashboard Fabric Controller from 3rd party devices can contain multiple interfaces, which are known as ECMP routes. Find the next-hop interface and create an intent for the switch. Interface IP and VRF changes are not allowed.
If inband management is enabled, during Image management, the data interface of nexus dashboard is used to copy images on the switch, in ISSU, EPLD, RPM & SMU installation flows.
If you import the switches using inband connectivity in the fabric and later disable the inband Mgmt in the Fabric settings after deployment, the following error message is generated:
The fabric <<fabric name>> was updated with below message:
Fabric Settings cannot be changed for Inband Mgmt when switches are already imported using inband Ip.
Please remove the existing switches imported using Inband IP from the fabric, then change the Fabric Settings.
However, the same fabric can contain switches imported using both inband and out-of-band connectivity.
Prerequisites
The following are the prerequisites for using Inband Management:
-
Configure appropriate Data Network Routes for reachability to the switch Inband interfaces on Cisco Nexus Dashboard. On Nexus Dashboard, choose Admin Console > Infrastructure > Cluster Configuration. On General tab, enter route IP addresses.
-
On NDFC Web UI, navigate to Server settings > Admin and choose Data from LAN Device Management Connectivity drop-down list to manage easy fabrics through inband management, or an error message is displayed. If you choose Data, ensure that the required 'Data Service IPs' are available in the Nexus Dashboard External Service Pools tab.
Note
When server settings changed from Data to Management or vice-versa, allow some time for syslog or poap functionalities to be online and ensure that the IP addresses in Cluster configuration are moved to the appropriate pool.
Guidelines and Limitations
The following are the guidelines and limitations for Inband Management:
-
Both Inband and out-of-band switches in the same fabric is not supported.
-
When you add switches to fabric, ensure that the switches are not in maintenance mode.
Inband POAP Management in External Fabrics and LAN Classic Fabrics
Inband POAP
Power On Auto Provisioning (POAP) automates the process of upgrading software images and installing configuration files on devices that are deployed on the network for the first time. POAP allows devices to bring up without performing any manual configuration.
When a POAP feature enabled device boots and does not find the startup configuration, the device enters POAP mode, locates a DHCP server, and bootstraps itself with its interface IP address, gateway, and DNS server IP addresses. The device obtains the IP address of a TFTP server and downloads a configuration script that enables the switch to download and install the appropriate software image and configuration file.
By using the POAP (Power On Auto Provisioning) feature of Nexus switches, Cisco NDFC (Nexus Dashboard Fabric Controller) can automate the deployment of new datacenters reducing overall time and effort.
Starting NDFC 12.1.1e, External Fabrics and LAN Classic fabrics support adding switches through POAP from inband interfaces.
The Inband POAP is supported for all the roles for fabrics with External and LAN Classic templates.
Prerequisites
The following are the prerequisites for using Inband poap:
-
Configure appropriate Data Network Routes for reachability to the switch Inband interfaces on Cisco Nexus Dashboard. On Nexus Dashboard, choose Admin Console > Infrastructure > Cluster Configuration. On General tab, enter route IP addresses.
-
On NDFC Web UI, navigate to Server settings > Admin and choose Data from LAN Device Management Connectivity drop-down list to manage easy fabrics through inband management, or an error message is displayed. If you choose Data, ensure that the required 'Data Service IPs' are available in the Nexus Dashboard External Service Pools tab.
Note
When server settings changed from Data to Management or vice-versa, allow some time for syslog or poap functionalities to be online and ensure that the IP addresses in Cluster configuration are moved to the appropriate pool.
-
Inband POAP on Bootstrap tab is supported only when Inband Management is enabled on Advanced tab in the Fabric settings.
Each subnet for the defined DHCP subnet scope that is mentioned in fabric settings must have a valid route for reverse traffic.
Ensure that the DHCP relay functionality is set on intermediate routers.
Guidelines and Limitations
The following are the guidelines and limitations for Inband POAP:
-
Inband POAP is supported for NX-OS switches only.
-
You can enable Inband POAP with NDFC as a Local DHCP Server or on External DHCP Servers.
-
Inband POAP supports Multi Subnet scope.
-
Inband POAP requires the external router connected seed switches to have the following capabilities:
-
DHCP relay functionality
-
eBGP peering
-
Enabling Inband Management and POAP on External Fabrics and LAN Classic Fabrics
To enable Inband POAP on a fabric, perform the following steps:
Procedure
Step 1 |
On the Advanced tab, check Inband Mgmt check box. |
Step 2 |
On Bootstrap tab, do the following:
|
Adding Switches
To add or discover switches through Inband POAP, you must follow below steps:
-
Pre-provisioning Switches to a Fabric
-
Add an Interface
-
Add a policy to fabric
-
Import switches using Bootstrap Mechanism
Pre-Provisioning Switches to a Fabric
To add switches to fabric, perform the following steps:
Procedure
Step 1 |
On Fabric window, double-click on appropriate fabric and navigate to Fabric Overview window. |
||
Step 2 |
Navigate to Switches tab and click Actions > Add Switches. The Add Switches window appears. |
||
Step 3 |
Choose Pre-provision radio button. |
||
Step 4 |
Click Actions and add switches. You can add switches one at a time using the Add option or add multiple switches at the same time using the Import option. If you use the Add option, ensure you enter all the required details. |
||
Step 5 |
Choose a switch. |
||
Step 6 |
Enter the password in the Admin password field. |
||
Step 7 |
Click Pre-provision. The pre-provisioned switch is added.
|
Importing Switches Using Bootstrap Mechanism
Note |
Ensure that you have pre-provisioned switches, added interface, and policy before importing the switces using bootstrap mechanism. |
To import switches using the bootstrap mechanism.
Procedure
Step 1 |
On the Fabric Overview window, click . The Add Switches window appears. You can view the existing added switches in the Switches to Bootstrap area. |
Step 2 |
Choose Bootstrap (POAP) radio button and enter a password in Admin password field. |
Step 3 |
Choose the required switches and click Import Selected Switches to bootstrap switches. |
Adding an Interface
To add the interfaces from the Cisco Nexus Dashboard Fabric Controller Web UI, perform the following steps:
Before you begin
Ensure that you add required configurations on switches such as IP addresses and static routes.
Add an interface to add interface IP addresses on required switch.
Procedure
Step 1 |
On the Fabric Overview window, navigate to Interface tab. |
Step 2 |
Click .The Create New Interface window appears. |
Step 3 |
Choose Ethernet type from drop-down list. |
Step 4 |
Choose appropriate switch from Select a device drop-down list and enter a name in Interface name field. |
Step 5 |
Choose int_routed_host policy from the list. |
Step 6 |
Enter the required configuration details in Interface IP and IP Netmask Length fields. |
Step 7 |
Enter appropriate details in mandatory fields and ensure that you check Enable Interface check box and then click Save. |
Adding a Policy to a Fabric
You can add a freeform policy to define external routes in the switch. To add a policy, perform the following steps:
Procedure
Step 1 |
On the Fabric Overview tab, click Policy tab. |
Step 2 |
Choose an appropriate switch in the Switch window and click Choose Template. |
Step 3 |
Choose switch_freeform policy and click Select. This policy type allows you to add configurations in CLI format. The Create Policy window appears. |
Step 4 |
Click . |
Step 5 |
Enter the appropriate configuration in Switch freeform configuration field in the window and click Save. |
Recalculating and Deploying Configurations on a Switch
To push pending configurations on switches, perform the following steps:
Procedure
Step 1 |
On Fabric Overview window, navigate to Switches tab. You can view Config status column displays Pending status. |
Step 2 |
Click .The Deploy Configuration window appears. It displays the configuration status on the switches. You can also view the pending configurations by clicking the respective link in the Pending Config column. The Pending Config window appears. The Pending Config tab on this window displays the pending configurations on the switch. The Side-by-Side Comparison tab displays the running configuration and expected configuration side by side. |
Step 3 |
Close the Pending Config window. |
Step 4 |
You can view the Config status column displays In-Sync status. |
Inband Management and Inband POAP in Easy Fabrics
Starting from Cisco NDFC Release 12.1.1e, you can manage switches with Inband connectivity and Inband POAP for Easy Fabrics. For Inband Management, the Loopback0 interface of the devices is used in the Fabric Settings.
If you want POAP Layer-3 adjacency to switches, you must add Nexus Dashboard Node IP address as DHCP Relay address, perform the following:
-
On NDFC UI, navigate to Admin tab. If default value Management is chosen from LAN Device Management Connectivity drop-down list , then DHCP Relay address must be set to the management interface IP (bond1br) in all Nexus Dashboard Nodes.
, click -
On NDFC UI, navigate to Admin tab. If value Data is chosen from LAN Device Management Connectivity drop-down list , then DHCP Relay address must be set to the data interface IP (bond0br) in all Nexus Dashboard Nodes.
, click
You can add switches with Inband Management enabled for easy fabrics either in Greenfield or brownfield deployment with Inband POAP or pre-provision and Inband POAP.
-
For Brownfield deployment, check Preserve Config check box.
-
For Greenfield deployment, uncheck Preserve Config check box.
The seed switches connect the external routers, and it provides management connectivity to the other switches in the fabric. Switches connected to external routers to provide connectivity to the fabrics are termed as seed switches. The interfaces on the seed switches which connects to the external routers are termed as bootstrap interfaces.
Prerequisites for Inband Management
On NDFC Web UI, navigate to Server settings > Admin and choose Data from LAN Device ManagementConnectivity to manage easy fabrics through Inband management. If you choose Data, ensure that the required Data Service IPs are available in the Nexus Dashboard External Service Pools tab.
Note |
When server settings changed from Data to Management or vice-versa, allow some time for syslog or poap functionalities to be online and ensure that the IP addresses in Cluster configuration are moved to the appropriate pool. |
This server setting is required for both Inband and out-of-band connectivity. Configure below static routes over data interface in Cisco Nexus Dashboard:
Enter static routes IP address required for external route and route over data interface in Cisco Nexus Dashboard.
Inband POAP requires the external router IP address connected to the seed switches to have the following capabilities:
-
Routes for External router
-
Route for Routing Loopback subnet range for Easy Fabric
-
Route for Underlay Routing subnet range for Easy Fabric
Inband POAP requires the external router connected seed switches to have the following capabilities:
-
DHCP relay functionality
-
eBGP peering
To add switches for Inband Management and Inband POAP, see Discovering New Switches.
Guidelines and Limitations
The following are the guidelines and limitations for Inband Management:
-
Ensure that the Inband Management is enabled for Inband interface. Both Inband and out-of-band switches for a same fabric is not supported.
-
It is supported only for IPv4 underlay and OSPF routing protocol.
-
You can change switch management from Inband to out-of-band and conversely after creating a fabric.
-
For the Inband managed switches, the following roles are supported:
-
Spine
-
Leaf
-
Border
-
Border Spine
-
Border Gateway
-
Border Gateway Spine
-
-
Inband management is supported for both numbered and unnumbered fabric interface numbering
-
Ensure that the same role switches are assigned as seed switches. If spine role switch is assigned as a seed switch, all the spine role switches in that fabric must be assigned as seed switches. It is recommended to assign switch as seed switches.
-
When you add switches to fabric, ensure that the switches are not in maintenance mode.
-
You can add switches in Brownfield deployment (check Preserve Config check box) only when the fabric is created. To add more switches, use Inband POAP with import switches option.
-
Set vPC Peer Keep Alive option to loopback if the vPC switches mgmt0 interfaces are not configured.
The following are the guidelines and limitations for Inband POAP:
-
Inband POAP for a fabric can be enabled only if Inband Management is enabled.
-
Inband POAP requires the fabric or core facing interfaces to be cabled consistently for seed switches and spine switches.
-
All spine switches in fabric must use same set of fabric interface numbers.
-
If a fabric has set of leaf switches which are seed switches, then the switches must use same fabric interface number.
-
The seed switches must have eBGP peering with the external router. Therefore, the external router must have the required eBGP route peering capabilities and display the configuration for External router for DHCP relay and Static routes configured for the Subnets used in Easy Fabrics.
-
DHCP relay must be configured on external routers interface which connects the seed switch in Inband interfaces. Ensure that the DHCP relay destination configured is same for all cluster node data interface on Cisco Nexus Dashboard.
-
DHCP server can be internal NDFC or the external server.
Enabling Inband POAP on Easy Fabrics
To enable Inband POAP on Easy Fabrics, perform the following steps:
Procedure
Step 1 |
On the Manageability tab check Inband Management check box. |
Step 2 |
On Bootstrap tab, do the following: |
Step 3 |
For fabrics with unnumbered interface, do the following: |
Importing Switches to Brownfield Deployment
Before you begin
Make sure that you follow prerequisites procedure before adding switches.
Procedure
Step 1 |
Create a fabric using a template Easy_Fabric. For instructions, see Create a Fabric. Ensure that you add switches in the order of Seed switches, Spine switches, and other switches. You can add spine switches as the seed switches. |
Step 2 |
In Brownfield deployment for each fabric, enable Inband Management on the Manageability tab and import the fabric. |
Step 3 |
Add the switches to the fabric with the Preserve Config check box. |
Step 4 |
Enter hostname, Role, enable Seed Switch, and enter appropriate IP address. |
Step 5 |
Enter the IP addresses for all the seed switches, click Import Selected Switches to add them to the fabric. |
Step 6 |
Navigate to Policy tab, click Actions > Add Policy. Choose ext_bgp_neighbor policy so the seed switches establish eBGP peering. Enter the required details, and click Save. |
Step 7 |
Assign the appropriate switch roles. For more instructions, see Adding Switches Using Bootstrap Mechanism. |
Pre-provisioning switches through Inband POAP
Procedure
Step 1 |
On Switches tab, choose Actions > Add Switches. The Add Switches window appears. |
Step 2 |
Choose Pre-provision radio button. |
Step 3 |
On Switches to Pre-provision table, click Actions> Add. The Pre-provision a switch window appears. |
Step 4 |
Enter appropriate details such as Serial Number, Model, IP Address, and click Add. |
Step 5 |
Enter single switch at once and enter the required information. If you have multiple switches. |
Step 6 |
Click Import Switches to Fabric to add switches. |
Adding policy for Easy Fabric
Procedure
Step 1 |
Navigate to LAN > Fabrics window, double-click on appropriate easy fabric to add policy. The Fabric Overview window appears. |
Step 2 |
On Fabric Overview tab, click on Policy tab. |
Step 3 |
Choose appropriate switch from Switch window and click Choose Template. |
Step 4 |
Choose ext_bgp_neighbor policy and click Select. The Create Policy window appears. |
Step 5 |
Click Actions > Add Policy. The Create Policy window appears. |
Step 6 |
Enter the appropriate details in the window and click Save. |
Step 7 |
On Fabric Overview window, click Actions > Recalculate and Deploy. |
Changing Fabric Management Mode
You can change the fabric from out-of-band to Inband Management and conversely.
Procedure
Step 1 |
To change fabric management from out-of-band to Inband Management, perform the following steps: |
Step 2 |
To change fabric management from Inband Management to out-of-band, perform the following steps: |