Working with Connectivity in Your Nexus Dashboard LAN Fabrics

 
Updated August 14, 2025
PDF
Is this helpful? Feedback

New and changed information

The following table provides an overview of the significant changes up to this current release. The table does not provide an exhaustive list of all changes or of the new features up to this release.

Release Version Feature Description

Nexus Dashboard 4.1.1

Improved navigation and workflow when working with connectivity for Nexus Dashboard LAN fabrics

Beginning with Nexus Dashboard 4.1.1, the navigation and workflow when working with connectivity in Nexus Dashboard LAN fabrics have been enhanced.

Nexus Dashboard 4.1.1

Switch Virtual Interface (SVI) device search

Nexus Dashboard 4.1.1, in the Create Interface page, you can now type the characters to search for a device or vPC pair name in the drop-down list. For more information, see Add interfaces.

Nexus Dashboard 4.1.1

External connectivity workflow enhancements and wizard for Data Center VXLAN fabrics

Beginning with Nexus Dashboard 4.1.1, external connectivity workflow enhancements and a wizard are available for Data Center VXLAN fabrics, where you can use routing policies to define and control how routes are distributed, filtered, or manipulated between two VXLAN EVPN fabrics or between a VXLAN EVPN fabric and an external fabric in your Nexus Dashboard.

For more information, see Routing policies.

Nexus Dashboard 4.1.1

Introduction of VLAN mapping knob for trunk interfaces

Beginning with Nexus Dashboard 4.1.1, the trunk interface policy includes VLAN mapping option, allowing enhanced control over VLAN configurations. This provides flexibility to map customer VLANs to provider VLANs directly within the policy settings.

For more information, see Edit interfaces.

Navigate to the Connectivity page

To navigate to the Connectivity page:

  1. Navigate to the main Fabrics page:

    Manage > Fabrics

  2. In the table showing all of the Nexus Dashboard fabrics that you have already created, locate the LAN or IPFM fabric where you want to configure connectivity.

  3. Single-click on that fabric.

    The Overview page for that fabric appears.

  4. Click the Connectivity tab.

    These subtabs provide more focused connectivity options:

Interfaces

The Interfaces option displays all the interfaces that are discovered for the switch, Virtual Port Channels (vPCs), and intended interfaces missing on the device.

An invalid interface error appears for the following scenarios:

  • Interface Mode 'routed' is invalid. Allowed mode is trunk & access.

  • Access port which is already allocated to other network.

  • Interface which is not available in the switch.

You can use the following functions:

  • Create, deploy, view, edit and delete a port channel, vPC, Straight-through FEX, Active-Active FEX, loopback, and subinterface.

note.svg

  • The following features are unsupported for the brownfield migration of switches with the Cisco NX-OS Release 7.0(3)I4(8b) and 7.0(4)I4(x) images:

    • FEX on switches other than Cisco Nexus 9300 Series switches and Cisco Nexus 9500 Series switches with X9500 line cards

    • AA-FEX

    For information about the platform support for FEX, refer to your platform and NX-OS documentation to check the feature compatibility.

    • To edit interfaces associated with fabric links such as intra-fabric links and inter-fabric links, see Edit interfaces associated with links.

    • The flowcontrol or priority-flow-control config is not supported for HIF ports or PO with HIF ports as members.

    • When using the REST API for configurations, make sure to set consistent values for the primary fields and NV pairs fields. For example, a REST API post for a single port channel that has different values in certain fields, such as:

      • ifName: Port-testing123

      • PO_ID: Port-channel1000

        results in two interfaces being created rather than the intended single interface.

  • Create tunnel interfaces for Cisco Cloud Services Router 1000v Series (Cisco CSR 1000v Series).

  • Create breakout and unbreakout ports.

  • Shut down and bring up interfaces.

  • Rediscover ports and view interface configuration history.

  • Apply host policies on interfaces and vPCs. For example, int_trunk_host, int_access_host, and so on.

  • View interface information such as its admin status, operation status, reason, policy, speed, MTU, mode, VLANs, IP/Prefix, VRF, port channel, and the neighbor of the interface.

note.svg

The Neighbor column provides details of connected switches that are discovered, intent links, and Virtual Machine Manager (VMM) connectivity.

The Status column displays the following status of an interface:

  • Blue: Pending

  • Green: In Sync/Success

  • Red: Out-of-Sync/Failed

  • Yellow: In Progress

  • Grey: Unknown/NA

  • If an interface is created out-of-band, you need to perform fabric resync or wait for Config Compliance poling before this interface can be deleted. Otherwise, Config Compliance does not generate the correct diff.

However, you cannot add or edit interfaces for ASR 9000 Series Routers and Arista switches.

You can filter and view information for any of the given fields (such as Device Name).

note.svg

  • Ensure that appropriate configurations are deployed on the Fabric before deploying from the Interfaces option, including proper vPC pair configurations. If you add or edit an interface before configurations are deployed on the Fabric, the configuration may fail on the device.

  • Deploy any underlays including vPC Pairing in the fabric before deploying any configurations from the interface manager.

The following table describes the action items available in Actions menu drop down list when you select an interface.

Field Description

Actions

Create interface

Allows you to add a logical interface such as a port channel, vPC, Straight-through FEX, Active-Active FEX, and loopback.

Actions

Edit configuration

Allows you to edit and change policies that are associated with an interface.

note.svg

Access-admin user role cannot edit interfaces associated with link policy such as inter-fabric link or intra-fabric link for easy fabrics. The user role can edit interfaces for LAN classic and IPFM fabrics. If you select the int_monitor interface policy, you are responsible for the interface configuration and management. Nexus Dashboard does not apply any interface configurations nor perform configuration compliance for interfaces that have the int_monitor policy.

Actions > Configuration

Create subinterface

Allows you to add a logical subinterface.

Multi-attach

Allows you to attach multiple networks when you add an interface from an interface group in the Interfaces.

Multi-detach

Allows you to detach multiple networks when you remove an interface from an interface group in the Interfaces.

Preview

Allows you to preview the interface configuration.

Deploy

Allows you to deploy or redeploy saved interface configurations.

No Shutdown

Allows you to enable an interface (no shutdown or admin up).

Shutdown

Allows you to shut down the interface.

Breakout

Allows you to breakout an interface.

Un-Breakout

Allows you to unbreakout interfaces that are in breakout state.

Actions > Interface group

Add

Allows you to add or remove an interface to an interface group.

Remove

Allows option to edit an interface group.

Actions > Maintenance

Rediscover

Allows you to rediscover or recalculate the compliance status on the selected interfaces.

Show commands

Allows you to display the interface show commands. A show command requires show templates in the template library.

History

Allows you to display the interface deployment history details.

Actions > Bulk actions

Import

Allows you to import the edited interfaces. The following are the limitations during importing the interfaces:

  • You are not allowed to import interfaces with these policy templates:

    • All fabric templates with int_fabric or int_ipfm_fabric

    • int_vpc_peer and int_vpc_leaf_tor_assoc

    • int_freeform templates

  • You must update the mandatory fields fabric name, serial number, interface name, and policy name.

  • You are not allowed to import the interfaces with the interface name nve and vlan except int_ipfm_vlan policy. You can import the interface with the int_ipfm_vlan policy.

  • The allowed MTU range for integer values is between 576 and 9216.

  • The allowed MTU string values is either default or jumbo.

  • The fabric name, serial number, and interface name must be unique.

  • You can only import a single policy type for an interface per .csv file. Importing a .csv file with multiple policy types is not allowed.

note.svg

There is a server property to set the maximum number of rows that can be imported. By default, the property is 200 for import.

Export

Allows you to export the selected interfaces with multiple types of policies to a .csv file.

While there is technically no limit on the number of interfaces to export, the number of interfaces included in each exported .csv file is limited to the number of rows that are displayed on the page. For example, if you select all of the interfaces in the window and you have 50 as the entry in the Rows per page field at the bottom of the window, then only the 50 interfaces displayed in this page are exported to the .csv file.

Normalize

Allows you to apply the same interface policies and its parameters on selected interfaces in one shot.

Actions

Delete

Allows you to delete a logical interface that is created from the Interfaces screen. An interface having a policy that is attached from an overlay and underlay cannot be deleted.

You can disable deployments, or freeze, a fabric in Nexus Dashboard as a network administrator. However, you cannot perform all actions when you freeze the fabric or if the fabric is in monitor mode.

The following table describes the actions you can perform when you freeze a fabric and when you enable the monitor mode for a fabric.

Operations

Nexus Dashboard Mode

Freeze Mode

Monitor Mode

Add

Save, Preview

Blocked

Breakout

Blocked

Blocked

Unbreakout

Blocked

Blocked

Edit

Save, Preview

Blocked

Delete

Save, Preview

Blocked

Shutdown

Save, Preview

Blocked

No Shutdown

Save, Preview

Blocked

Show

Supported

Supported

Rediscover

Supported

Supported

Deploy

Blocked

Blocked

Import

Supported

Supported

Export

Supported

Supported

The buttons for the associated operations are grayed out accordingly.

If you perform admin operations (shutdown/no shutdown) on an SVI, which is part of a config profile, successive Save & Deploy operations generate the no interface vlan command.

For an SVI with no policy, on performing admin operation, that is, shutdown/no shutdown command pushed from Interface Manager, the int_vlan_admin_state policy is associated with the SVI.

For example, create and deploy the SVI from switch_freeform.

interface vlan1234
  description test
  no shutdown
  no ip redirects
  no ipv6 redirects

If you shutdown the SVI from the interface manager, the int_vlan_admin_state policy is associated with the SVI.

Pending diff is shown as:

interface Vlan1234
  shutdown
  no ip redirects
  no ipv6 redirects
  description test
  no shutdown

Remove the no shutdown CLI from the free-form config.

If you have performed an admin operation on the SVI, the device has an interface as a running config. Therefore, post network detach interface vlan is still present and the interface is discovered. You need to manually delete the interface from the Interface Manager.

The following table describes the fields that appear on the Manage > Fabrics > Overview > Connectivity > Interfaces tab.

Field Description

Interface

Specifies the interface name.

Switch

Specifies the switch name.

Config-sync status

Specifies the configuration sync status of the switch.

Admin Status

Specifies the administrative status of the interface. The status can be either Up or Down.

Oper-Status

Specifies the operational status of the interface. The status can be either Up or Down.

Reason

Specifies the reason.

Policies Group

Specifies the policy name.

Overlay Network

Specifies the overlay network.

Sync Status

Specifies the sync status. Specifies if the interface status is In-Sync or Out-Of-Sync.

Interface Groups

Specifies the interface group to which the interface belongs to.

Port Channel ID

Specified the port channel ID.

vPC ID

Specifies the vPC ID.

Speed

Specifies the interface speed.

MTU

Specifies the MTU size.

Mode

Specifies the interface mode.

VLANs

Specifies the VLANs.

IP/Prefix

Specifies the interface IP/prefix.

VRF

Specifies virtual routing and forwarding instances (VRFs).

Neighbor

Specifies the interface neighbor.

Description

Specifies the interface description.

note.svg

There is a known issue where the description entry is truncated to 64 characters. If the interface description is more than 64 characters, run the snmp ifmib ifalias long command on the switch to increase the description entry length to 256 characters.

Add interfaces

Follow these steps to add interfaces.

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Click Actions > Create interface to add a logical interface.

    The Create interface page appears.

  4. From the Type drop-down list, choose the type of the interface.

    Valid values are Port Channel, virtual Port Channel (vPC), Straight-through (ST) FEX, Active-Active (AA) FEX, Loopback, Subinterface, Tunnel Ethernet, and Switch Virtual Interface (SVI). The respective interface ID field is displayed when you choose an interface type.

    • When you create a port channel through Nexus Dashboard, add interfaces of the same speed. A port channel that is created from interfaces of varying speeds won’t come up. For example, a port channel with two 10 Gigabit Ethernet ports is valid. However, a port channel with a 10-Gigabit Ethernet + 25-Gigabit Ethernet port combination isn’t valid.

    • To add vPC hosts, you must designate vPC switches in the fabric topology and deploy vPC and peer-link configurations using the Save Deploy option. After the vPC pair configurations are deployed, it appears in the Select a vPC pair drop-down box.

      You can create a vPC using the int_vpc_trunk_host policy.

    • When adding a subinterface, you must choose a routed interface from the interface table before clicking the Add button.

    • You can preprovision Ethernet interfaces on the Interfaces page. This preprovisioning feature is supported in VXLAN, eBGP, and External fabrics.

    • After preprovisioning the Ethernet interface, you can preprovision a subinterface on a physical interface.

  5. In the Select a device drop-down list, choose a device.

    Devices are listed by fabric, switch, and interface type. To narrow your search, you can also type the characters in the drop-down list. For vPC or Active to Active FEX, choose the vPC switch pair.

  6. Enter the ID value in the respective interface ID field (Port Channel ID,vPC ID,Loopback ID, Tunnel ID, Interface name, VLAN ID, and Subinterface ID) that is displayed, based on the chosen interface.

    You can override this value. The new value is used only if it’s available in the Resource Manager pool. Else, it results in an error.

  7. Under the Policy field, choose a policy to apply on an interface.

    The field only lists the Interface Python Policy with tag interface_edit_policy and filtered based on the interface type.

    You must not create a _upg interface policy. For example, you should not create a policy using the vpc_trunk_host_upg, port_channel_aa_fex_upg, port_channel_trunk_host_upg, and trunk_host_upg options.

    note.svg

    The policies are filtered based on the interface type you choose in the Type drop-down list and the device you choose in the Select a device drop-down list.

  8. Enter values in the required fields under Policy Options.

    The fields vary according to the interface type you chose.

    note.svg

    • You can mirror the configurations of Peer-1 on Peer-2 while creating a vPC. When you check the Enable Config Mirroring check box, the Peer-2 fields will be grayed out. The configurations that you enter in the Peer-1 fields will be copied to Peer-2 fields.

    • You can set Native Vlan for the interface which has int_trunk_host or int_port_channel_trunk_host, or int_vpc_trunk_host policy template.

    A trunk port can carry nontagged packets simultaneously with tagged packets. When you assign a default port VLAN ID to the trunk port, all untagged traffic travels on the default port VLAN ID for the trunk port, and all untagged traffic is assumed to belong to this VLAN. This VLAN is referred to as the native VLAN ID for a trunk port. That is, the native VLAN ID is the VLAN that carries untagged traffic on trunk ports.

    1. If you are creating a port channel or virtual port channel interface, you can edit these general parameter fields:

      • Configure BPDU Filter--Enables or disables the spanning tree BPDU filter. If enabled, the interface cannot send nor receive BPDUs.

      • Spanning-tree Link-type--Specifies the link type for the spanning tree protocol (STP) to use.

      • Enable Auto-Negotiation--Enables or disables auto-negotiation. Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet standard that enables devices to automatically exchange information over a link about speed and duplex abilities.

      • Bandwidth in kilobits--Specifies the allowed bandwidth in kilobits of the interface.

      • Inherit Bandwidth in kilobits--Specifies the allowed bandwidth in kilobits of all sub-interfaces of this interface.

      • Debounce Timer--Specifies the link debounce timer in milliseconds, which is the wait time for the interface when there is a flap in the link. After the specified time passes, Nexus Dashboard checks the link status again to re-confirm the event. If the link is okay at this time, then the interface remains up.

      • Debounce Link-up Timer--Specifies the link debounce link-up timer, which is the wait time before bringing up the interface after it was taken down due to a flap.

      • Enable Error Detection--Enables or disables error detection for access control list. When enabled, if the software on the switch detects an error situation on the interface, the software shuts down that interface and no traffic is sent nor received on that interface.

      • Forwarding Error Correction--Specifies the Forwarding Error Correction (FEC) mode. Forwarding Error Correction is a method of obtaining error control in data transmission over an unreliable or noisy channel in which the source (transmitter) encodes the data in a redundant way using an Error Correcting Code, and the destination (receiver) recognizes it and corrects the errors without requiring a retransmission.

    2. If you are creating a port channel or virtual port channel interface, you can edit these storm control fields:

      • Broadcast Storm Control Level in Percentage--Specifies the broadcast traffic utilization threshold at which point storm control begins to manage broadcast traffic.

      • Multicast Storm Control Level in Percentage--Specifies the multicast traffic utilization threshold at which point storm control begins to manage broadcast traffic.

      • Unicast Storm Control Level in Percentage--Specifies the unicast traffic utilization threshold at which point storm control begins to manage broadcast traffic.

      • Broadcast Storm Control Level in PPS--Specifies the threshold level for broadcast traffic in packets per second (pps). The interface blocks all traffic when traffic utilization exceeds this level.

      • Multicast Storm Control Level in PPS--Specifies the threshold level for multicast traffic in packets per second. The interface blocks all traffic when traffic utilization exceeds this level.

      • Unicast Storm Control Level in PPS--Specifies the threshold level for unicast traffic in packets per second. The interface blocks all traffic when traffic utilization exceeds this level.

  9. Click Save to save the configurations.

    note.svg

    To apply QoS policies on the interface, create the interface freeform with references accordingly.

    Only saved configurations are pushed to the device. While adding the interface, you can only modify the policy attribute after the first save. If you try to use an ID that is already used, you encounter the Resource could not be allocated error.

  10. To view configurations for a new interface, double-click on the policy name in the Policies tab.

  11. (Optional) Click the Preview option to preview the configurations to be deployed.

  12. Click Deploy to deploy the specified logical interface.

    The newly added interface appears in the screen.

Breakout

To breakout an interface, from Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the appropriate interface from the list.

  4. On the Interfaces page, click Actions > Configuration > Breakout.

    The Breakout Interfaces page appears.

  5. Choose the required option on the page and click Breakout.

    The available options are 10g-4x, 25g-4x, 50g-2x, 50g-4x, 100g-2x, 100g-4x, 200g-2x, and Unbreakout.

UnBreakout

You can unbreakout interfaces that are in a breakout state.

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. On the Interfaces page, click Actions > Configuration > UnBreakout.

note.svg

The unbreakout option is grayed out for interfaces that are not in breakout state.

Edit interfaces

The Edit interface(s) page allows you to configure interfaces, modify applied policies, and manage interface assignments for port channels or virtual port channels (vPCs).

Follow these steps to edit interfaces.

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interface that you want to edit.

    You can choose multiple interfaces at the same time to edit them sequentially.

    note.svg

    You cannot edit multiple port channels and vPCs. You cannot edit interfaces of different types at the same time.

  4. From the Actions drop-down list, choose Edit configuration.

    The Edit interface(s) page displays parameters based on the template and the policy that you chose.

    note.svg

    Nexus Dashboard does not support interface description configuration for FEX fabric ports with fabric resource templates. While the FEX fabric ports and FEX are provisioned correctly, the description configured through Nexus Dashboard is not displayed on the leaf switch interfaces, the fabric port channel, or the APIC interface configuration wizard.

    1. Optional: Click the policy name, choose a different policy, and then click Select. The choice of policies depends on the interface type. Ensure that you choose an appropriate policy for the interface.

    2. If you are editing a trunk host, you can edit these fields under the General Parameters tab.

      • Enable BPDU Guard — Enables or disables the spanning tree BPDU guard. If enabled, it prevents BPDU traffic.

      • Configure BPDU Filter — Enables or disables the spanning tree BPDU filter. If enabled, the interface cannot send nor receive BPDUs.

      • Spanning-tree Link-type — Specifies the link type for the spanning tree protocol (STP) to use.

      • Enable Port Type Fast — Enables or disables the spanning tree edge port behavior.

      • MTU — Maximum transmission unit (MTU) size of the interface.

      • SPEED — Interface speed.

      • Trunk Allowed Vlans — Specifies the VLANs allowed on the trunk.

      • Native Vlan — Specifies the native VLAN.

      • Interface Description — Add a description for the interface.

      • Enable Auto-Negotiation — Enables or disables auto-negotiation. Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet standard that enables devices to automatically exchange information over a link about speed and duplex abilities.

      • Enable CDP — Enables or disables Cisco Discovery Protocol (CDP) on the interface.

      • Enable vPC Orphan Port — Enables or disables vPC orphan port functionality. When enabled, you can configure the interface as a vPC orphan port, and the secondary peer suspends it during vPC failures.

      • Port Duplex Mode — Configures the communication mode of the port to operate in either full-duplex or half-duplex mode.

      • Bandwidth in kilobits — Specifies the allowed bandwidth in kilobits of the interface.

      • Inherit Bandwidth in kilobits — Specifies the allowed bandwidth in kilobits of all sub-interfaces of this interface.

      • Debounce Timer — Specifies the link debounce timer in milliseconds, which is the wait time for the interface when there is a flap in the link. After the specified time passes, Nexus Dashboard checks the link status again to re-confirm the event. If the link is okay at this time, then the interface remains up.

      • Debounce Link-up Timer — Specifies the link debounce link-up timer, which is the wait time before bringing up the interface after it was taken down due to a flap.

      • Enable Error Detection — Enables or disables error detection for access control list. When enabled, if the software on the switch detects an error situation on the interface, the software shuts down that interface and no traffic is sent nor received on that interface.

      • Forwarding Error Correction — Specifies the Forwarding Error Correction (FEC) mode. Forwarding Error Correction is a method of obtaining error control in data transmission over an unreliable or noisy channel in which the source (transmitter) encodes the data in a redundant way using an Error Correcting Code, and the destination (receiver) recognizes it and corrects the errors without requiring a retransmission.

      • Freeform Config — Allows custom configurations.

      • Enable Interface — Enables or disables the interface.

      • Enable Netflow — Enables or disables Netflow monitoring. Netflow monitoring is supported only if it is enabled on fabric.

      • Netflow Monitor — Configures Netflow monitoring settings.

      • Netflow Sampler — Configures Netflow sampling settings.

      • Enable priority flow control — Enables or disables priority flow control.

      • Enable QoS Configuration — Enables or disables quality of service (QoS) settings. When enabled, you can configure a QoS policy specific to the interface. If AI queuing is active on the fabric, Nexus Dashboard applies the QOS_CLASSIFICATION policy by default. You must provide a custom policy in the Custom QoS Policy field to override this default behavior.

      • Custom QoS Policy — Applies a custom QoS policy.

      • Custom Queuing Policy — Applies a custom queuing policy.

      • Switchport monitor — Enables or disables switchport monitoring.

      • Enable VLAN Mapping — Enables or disables VLAN mapping.

        The feature is applicable to these trunk interface types.

        • Ethernet

        • Port channel

        • Virtual port channel (vPC)

          For more information, see Enable VLAN mapping.

    3. If you are editing a trunk host, you can edit these fields under the Storm Control tab.

      • Configure Traffic Storm Control — Enables or disables storm control on the interface. Storm control prevents excessive broadcast, multicast, or unicast traffic from disrupting the network by monitoring traffic levels and applying thresholds.

      • Storm Control Action — Specifies the action to take when a traffic storm is detected. You can see these options.

        • Shutdown — Disables the port when a storm is detected.

        • Trap — Sends an SNMP trap notification when a storm is detected.

        • No — Returns to default settings.

      • Broadcast Storm Control Level in Percentage — Specifies the broadcast traffic utilization threshold at which point storm control begins to manage broadcast traffic.

      • Multicast Storm Control Level in Percentage — Specifies the multicast traffic utilization threshold at which point storm control begins to manage broadcast traffic.

      • Unicast Storm Control Level in Percentage — Specifies the unicast traffic utilization threshold at which point storm control begins to manage broadcast traffic.

      • Broadcast Storm Control Level in PPS — Specifies the threshold level for broadcast traffic in packets per second (pps). The interface blocks all traffic when traffic utilization exceeds this level.

      • Multicast Storm Control Level in PPS — Specifies the threshold level for multicast traffic in packets per second. The interface blocks all traffic when traffic utilization exceeds this level.

      • Unicast Storm Control Level in PPS — Specifies the threshold level for unicast traffic in packets per second. The interface blocks all traffic when traffic utilization exceeds this level.

    4. Edit the other policy options fields as necessary.

    5. Click Save, and then click Deploy.

Additional information

This information applies for editing interfaces.

  • In a vPC setup, the two switches are in the order the switch names are displayed on the Edit page. For example, if Switch Name is displayed as LEAF1:LEAF2, then Leaf1 is peer switch one and Leaf2 is peer switch two.

  • During overlay network deployment on switches, the network can be associated with trunk interfaces. The Interface tab displays the trunk interface to network association. You can update such interfaces.

Enable VLAN mapping

You can configure VLAN mapping on trunk interfaces to enhance network management. To enable VLAN mapping, configure the switch to map customer VLANs to provider VLANs. This configuration segregates traffic and ensures proper handling of VLAN IDs across networks.

Follow these steps to configure VLAN mapping on a trunk interface.

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interface that you want to edit.

    You can choose multiple interfaces at the same time to edit them sequentially.

  4. In the Edit interface(s) page, check the Enable VLAN Mapping check box.

    The Vlan Mapping Entries table is enabled.

    nd-vlan-mapping-table.jpg

    The Vlan Mapping Entries table displays these information.

    • Customer Vlan — Represents the Vlan ID used within the customer’s network.

    • Selective dot1q-tunnel — Allows selective tunneling of specific Vlans by mapping a range of customer Vlans to provider Vlan.

      note.svg

      Selective dot1q-tunnel and port Vlan mapping cannot be present on the same interface.

    • Customer Inner Vlan — Refers to the VLAN tag located inside the header of an incoming packet from the customer.

    • Provider Vlan — Represents the Vlan ID assigned by the service provider to encapsulate customer traffic for transport across the provider’s network.

  5. Add a new mapping entry.

    Follow these steps to add a new mapping entry.

    1. From the Actions drop-down list, click Add.

      The Add Item dialog box opens.

    2. In the Customer Vlan field, provide the customer Vlan ID or a range of Vlan IDs.

    3. Check the Selective dot1q-tunnel check box, if needed.

      note.svg

      Ensure that you configure the Selective dot1q-tunnel option to all the customer Vlans. You cannot configure both selective dot1q-tunnel and port Vlan mapping on the same interface.

    4. Optional: In the Customer Inner Vlan field, provide the inner Vlan ID from the customer network.

      note.svg

      You cannot provide Customer Inner Vlan if you choose the Selective dot1q-tunnel check box. When you choose Selective dot1q-tunnel, Nexus Dashboard uses provider Vlan for tunneling and does not require customer inner Vlan.

    5. In the Provider Vlan field, enter the provider Vlan ID to map the customer Vlan.

    6. Click Save to save the configuration.

Limitations

  • For PVLAN interfaces, you can associate interfaces with the networks only for access and trunk port types.

  • For interface policies that are not created from the Manage > Inventory > Interfaces > Interfaces page, you can edit some configurations but not change the policy itself. The policy and fields that cannot be edited are grayed out.

  • These are some examples of policies that you cannot edit.

    • Loopback interface policies. You use the int_fabric_loopback policy to create a loopback interface. You can edit the loopback IP address and description, but not the int_fabric_loopback policy instance.

      You cannot edit the loopback IP addresses for loopback interfaces that are created automatically while creating and attaching the VRF instances.

    • Fabric underlay network interface policies, such as int_fabric_num, and fabric overlay network interface (NVE) policies.

    • Policies associated with port channels and member ports of port channels, including the port channels and member ports associated with a vPC.

    • SVIs created during network and VRF instance creation. The associated VLANs appear in the interfaces list.

Edit interfaces associated with links

There are two types of links, namely intra-fabric links and inter-fabric links. As the name implies, intra-fabric links are set up between devices within the same VXLAN fabric and are typically used for spine-leaf connectivity. Inter-fabric links are set up between a VXLAN fabric, and typically other External or VXLAN fabrics. They are used for external WAN and/or DCI connectivity. A policy is associated with each link that effectively states the configuration that is applied to both ends of the link. In other words, the link policy becomes the parent of the individual child interface policies that are associated with the two interfaces that form the link. In this scenario, you must edit the link policy to edit the interface policy fields such as description, IP address, and any per interface freeform configuration.

Follow these steps to edit the interfaces associated with links:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose a link and click Actions > Maintenance > Rediscover.

Delete interfaces

To delete the interfaces from Nexus Dashboard, perform the following steps:

note.svg

  • This option allows you to delete only logical ports, port channels, and vPCs. You can delete the interface if it does not have overlay or underlay policy attached.

  • When a port channel or vPC is removed, the corresponding member ports get the default policy associated. The default policy can be configured in server.properties file.

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interfaces and click Actions > Delete.

    You cannot delete logical interfaces created in the fabric underlay.

  4. Click Save.

  5. Click Deploy to delete the interface.

Shut down and bring up interfaces

To shut down and bring up the interfaces from Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interfaces that you want to shut down or bring up.

    Note: For all interfaces except VLANs, you cannot perform a Shutdown or No Shutdown on interfaces that do not have a policy attached.

  4. Click Actions > Configuration > Shutdown to disable the selected interfaces. For example, you may want to isolate a host from the network or a host that is not active in the network.

    A confirmation page appears where you can save, preview, and deploy the changes.

  5. Click Save to preview or deploy the changes.

  6. Click Actions > Configuration > No Shutdown to bring up the selected interfaces.

    A confirmation page appears where you can save, preview, and deploy the changes.

  7. Click Save to preview or deploy the changes.

View interface configuration

To view the interface configuration commands and execute them from Nexus Dashboard, perform the following steps:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interface with configurations that you want to view and choose Actions > Maintenance > Show Commands.

  4. On the Interface show commands page, select the action from the Commands drop-down list and click Execute.

    The interface configurations are displayed on the right of the screen.

    For show commands, you must have corresponding show templates for interface or interface sub types like port channel or vPC, defined in the Templates.

Rediscover interfaces

To rediscover the interfaces from Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interfaces that you want to rediscover and choose Actions > Maintenance > Rediscover to rediscover the selected interfaces.

    For example, after you edit or enable an interface, you can rediscover the interface.

View interface history

To view the interface history from Nexus Dashboard, perform the following steps:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Select the interface and choose Actions > Maintenance > History to view the configuration history on the interface.

  4. Click Status to view each command that is configured for that configuration instance.

Deploy interface configurations

To deploy the interface configuration from Nexus Dashboard, perform the following steps:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose an interface that you want to deploy and choose Actions > Configuration > Deploy to deploy or redeploy configurations that are saved for the interface.

    note.svg

    You can select multiple interfaces and deploy pending configurations.

    After you deploy the interface configuration, the interface status information is updated. However, the overall switch-level state may be in the pending state, which is in blue. The overall switch-level state goes to the pending state whenever there is a change in intent from any module, such as interface, link, policy template update, top-down, or so on. In the pending state, a switch may have pending configurations or switch-level recomputation. The switch-level recomputation occurs when:

    • You deploy for the switch

    • During a deploy

    • During hourly sync

Create external fabric interfaces

You can add and edit port channel, vPC, subinterface, and loopback interfaces for external fabric devices. You cannot add Straight-through FEX and Active-Active FEX functions.

The Breakout port function is only supported for the Cisco Nexus 9000, 3000, and 7000 Series Switches in the external fabric.

When you add an interface to an external fabric device, the Resource Manager is not in sync with the device. So, ensure that the value populated in the ID field (Port-channel ID, vPC ID, Loopback ID, etc) is not previously configured on the switch.

If you want to configure a portchannel in the external fabric, you should add and deploy the feature_lacp policy on the switches where the portchannel will be configured.

When an external fabric is set to Fabric Monitor Mode Only, you cannot deploy configurations on its switches. If you click Save & Deploy in the fabric topology screen, it displays an error message. However, the following settings (available when you right-click the switch icon) are allowed:

  • vPC pairing — You can designate a vPC switch pair, but it is only for reference.

  • View/edit policy — You can add a policy but you cannot deploy it on the switch.

  • Manage interfaces — You can only create intent for adding interfaces. If you try to deploy, edit, or delete interfaces, it results in an error message.

Sync up out-of-band switch interface configurations

Any interface level configuration made outside of Nexus Dashboard (via CLI) can be synced to Nexus Dashboard and then managed from Nexus Dashboard. Also, the vPC pair configurations are automatically detected and paired. This applies to the External and Classic LAN fabrics only. The vPC pairing is performed with the vpc_pair policy.

note.svg

When Nexus Dashboard is managing switches, ensure that all configuration changes are initiated from Nexus Dashboard and avoid making changes directly on the switch.

When the interface config is synced up to the Nexus Dashboard intent, the switch configs are considered as the reference, that is, at the end of the sync up, the Nexus Dashboard intent reflects what is present on the switch. If there were any undeployed intent on Nexus Dashboard for those interfaces before the resync operation, they will be lost.

Guidelines

  • Supported in fabrics using the following fabric templates: Data Center VXLAN EVPN, External, and Classic LAN.

  • Supported for Cisco Nexus switches only.

  • Supported for interfaces that do not have any fabric underlay related policy associated with them prior to the resync. For example, IFC interfaces and intra fabric links are not 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 is not shipped with Cisco Nexus Dashboard) associated with them prior to resync.

  • Supported for interfaces where the intent is not exclusively owned by a Cisco Nexus Dashboard feature and/or application prior to resync.

  • Supported on switches that do not have Interface Groups associated with them.

  • Interface mode (switchport to routed, trunk to access, and so on) changes are not 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)

  • int_trunk_host

  • int_port_channel_trunk_host

  • int_vpc_trunk_host

access (standalone, po, and vPC PO)

  • int_access_host

  • int_port_channel_access_host

  • int_vpc_access_host

dot1q-tunnel

  • int_dot1q_tunnel_host

  • int_port_channel_dot1q_tunnel_host

  • int_vpc_ dot1q_tunnel_host

routed

int_routed_host

loopback

int_freeform

sub-interface

int_subif

FEX (ST, AA)

  • int_port_channel_fex

  • int_port_channel_aa_fex

breakout

interface_breakout

nve

int_freeform (only in External_Fabric/Classic LAN)

SVI

int_freeform (only in External_Fabric/Classic LAN)

mgmt0

int_mgmt

The interface resync automatically updates the network overlay attachments based on the access VLAN or allowed VLANs on the interface.

After Nexus Dashboard completes the resync operation, the switch interface intent can be managed using normal Nexus Dashboard procedures.

Sync up switch interface configurations

We recommend that you deploy all switch configurations from Nexus Dashboard. 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.

Nexus Dashboard 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 the switch interface configurations to Nexus Dashboard:

  • This feature is not supported on ToR/Access switches, or on leaf switches with ToR pairing present.

  • The port channel membership changes (once the policy exists) are not supported.

  • Changing the interface mode (trunk to access and so on) 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 Classic LAN templates must be updated with the vpc_pair policy.

  • 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 Data Center VXLAN EVPN 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 Classic LAN 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 Discovery > Rediscover to ensure that Nexus Dashboard is aware of any new interfaces and other changes.

Procedure

  1. Choose Manage > Fabrics and single-click on a fabric.

    The Fabric Overview window appears.

  2. Click Inventory > Switches and ensure that switches are present in the fabric.

  3. Click Inventory > vPC Pairs and ensure that vPC pairings are completed.

  4. Click Configuration Policies > Policies tab and choose one or more switches where the interface intent resync is needed.

    note.svg

    • If a pair of switches is already paired with either no_policy or vpc_pair, select only one switch of the pair.

    • If a pair of switches is not paired, then select both the switches.

  5. From the Actions drop-down list, choose Add policy.

    The Create Policy window appears.

  6. On the Create Policy window, choose host_port_resync from the Policy drop-down list.

  7. Click Save.

  8. Click Inventory > Switches, then check the Mode column for the switches to ensure that they report Migration. For a vPC pair, both switches are in the Migration-mode.

    • After this step, the switches in the Topology view are in Migration-mode.

    • Both the switches in a vPC pair are in the migration mode even if one of the switches is placed into this mode.

    • If switches are unintentionally put into the resync mode, they can be moved back to the normal mode by identifying the host_port_resync policy instance and deleting it from the Policies tab.

  9. After the configuration changes are ready to sync up to Nexus Dashboard, navigate to the Switches tab and select the required switches.

  10. Click Actions > Recalculate and deploy to start the resync process.

    note.svg

    This process might take some time to complete based on the size of the switch configuration and the number of switches involved.

  11. The Deploy Configuration window is displayed if no errors are detected during the resync operation. The interface intent is updated in Nexus Dashboard.

    note.svg

    If the External_Fabric or Classic LAN fabric is in Monitored Mode, an error message indicating that the fabric is in the read-only mode is displayed. This error message can be ignored and doesn’t mean that the resync process has failed.

    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.

    note.svg

    The host_port_resync policy that was created for the switch is automatically deleted after the resync process is completed successfully.

Interface groups

An interface group consists of multiple interfaces with same attributes. You can create an interface group that allows grouping of host-facing interfaces at a fabric level. Specifically, you can create an interface group for physical Ethernet interfaces, Layer 2 port-channels, and vPCs. You can attach or detach multiple overlay networks to the interfaces in an interface group.

Shared Policy

You can create and add a shared policy for an interface group. This policy ensures update of appropriate configurations for all the interfaces in the Interface group. In the shared policy, all the interfaces will have the same underlay and overlay attributes. When you change the configuration in the shared policy, then that configuration is applied to all the interfaces.

You can see the details of shared policy under the Policies column.

Custom policy can also be created by selecting the policy from the template list and Duplicate Template to add the additional information. The shared policy must contain the tags interface_edit_policy,interface_edit_shared_policy, and int_trunk.

Guidelines

  • Interface groups are only supported for the following fabric template types:

    • Campus VXLAN EVPN

    • Data Center VXLAN EVPN

    • Enhanced Classic LAN

  • An interface group is specific to a fabric. For example, consider two fabrics: Fab1 and Fab 2. The interface group IG1 in Fab1 isn’t applicable to Fab 2.

  • An interface group can only have interfaces of a certain type. For example, you need three separate interface groups if you want to group three types of interfaces such as IG1 for physical Ethernet trunk interfaces, IG2 for Layer 2 trunk port-channels, and IG3 for vPC host trunk ports.

  • An interface group can also be created using preprovisioned interfaces.

  • Interface groups are supported only to switches with leaf or border roles. For Border Gateway roles, Interface Groups are supported only on vPC BGWs but not on Anycast BGW, BGW Spine, or BGW SuperSpine.

  • You can include Layer 2 ToR interfaces in the interface groups.

  • Interfaces added to an interface group with a shared policy replaces the individual policy and get the shared policy.

  • You can change description and status of each interface in interface group.

  • Interface removed from an interface group with a shared policy will set to a default policy.

  • VMs should have the same configuration for all the interfaces under the shared policy.

  • Shared policy is supported only for Ethernet interface type in interface group.

  • Ethernet interface groups now have a common policy.

  • Port-Channel and vPC interface types are not supported for adding shared policy in interface group.

  • When the MTU value in the shared policy has to be changed, make sure to update the fabric settings with the same value across all switches of that fabric.

  • When the ptp, ttag, and ttag-strip option from the shared policy has to be used, make sure to enable PTP globally in fabric settings.

  • When the netflow option has to be used, make sure all the interfaces of interface groups are capable of netflow configuration and that it is enabled globally in fabric settings.

  • For Layer 2 port-channels and vPCs that are part of an interface group, they can’t be deleted until they are de-associated from the interface group even if there are no networks associated with the interface group. Similarly, a trunk port that has no overlay networks but is part of an IG can’t be converted to an access port. In other words, you can’t change policies for interfaces that are part of an interface group. However, you can edit certain fields for policies.

  • For L4-L7 services configuration on leaf switches, trunk ports that are used for services attachment can’t be part of interface groups.

  • When you perform a per fabric backup of an easy fabric, if there are interface groups created in that fabric, all the associated interface group state is backed up.

  • If an easy fabric contains an interface group, then this fabric can’t be imported into the MSO. Similarly, if an easy fabric has been added to the MSO, you can’t create interface groups for interfaces that belong to switches in the easy fabric.

  • The Add to interface group and Remove from interface group button is enabled only for Admin and Stager users. For all other users, this button is disabled.

  • The Interface Groups button is disabled in the following circumstances:

    • Select any other interface apart from vPC, Port-channel, and Ethernet.

    • If the interface has a policy attached from another source, for example:

      • If the interface is member of a port-channel or vPC.

      • If the port-channel is member of vPC.

      • If the interface has a policy from underlay or links.

    note.svg

    If you select different types of interfaces, the Interface Group button is enabled. However, when you try to create or save different types of interfaces to an interface group, an error is displayed.

Create an interface group

To create an interface group from Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Interface Groups tab.

  3. Choose Actions > Create interface group.

  4. In the Create interface group window, provide an interface group name in the Interface Group Name field, choose an Interface Type, and click Save.

    An interface group name can have a maximum length of 64 characters.

    note.svg

    An interface can be added to single interface group only.

  5. Click on the Policy field.

    The Select Policy window appears.

  6. Choose int_shared_trunk_host policy and then click Select.

    You can add a shared policy to the interface group which can be shared by the interfaces existing in that group. Shared Policy is optional, for upgrades, all the existing interface group will not have a policy.

    note.svg

    The policy field supports the Ethernet interface type only.

  7. Enter the mandatory parameters in the text field and click Save.

  8. In the Interfaces tab, select the interfaces to group and choose Actions > Add to interface Group.

    The Add new interface Group window appears.

  9. To create a custom interface group, enter an interface group name in the Select Interface Group field and click Create custom.

    If you have already created an interface group, select it from the Select Interface Group drop-down list. Also, if an interface is already part of an interface group, you can move it to a different interface group by selecting the new group from the Select Interface Group drop-down list.

    You can create interface groups from either the Interfaces Groups window or the Interfaces window under Fabric Overview.

  10. Click Save.

    In the Interfaces window, you can see the interface group name under the Interface Group column.

  11. To edit an interface group, choose Actions > Edit Interface Group. You can update the policy options after you assign the shared policy.

    note.svg

    You cannot edit or delete the shared policy template.

Remove interfaces from an interface group

To remove interfaces from an interface group from Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Interface Groups tab.

  3. Select the interfaces to disassociate from an interface group and choose Actions > Remove from interface Group.

    A dialog box appears asking whether you want to clear all the associated interfaces.

  4. Click Yes to proceed.

    Note that if there are any networks attached to these interfaces, they are detached as well when you click Clear.

Attach networks to an interface group

To attach networks to an interface group from the Nexus Dashboard Web UI:

  1. Click on the fabric to launch Fabric Overview.

  2. Click Segmentation and Security > Networks.

  3. On the Networks tab, select the networks that you need to attach to an interface group and click Interface Group.

    note.svg

    An overlay network can belong to multiple interface groups. You can select only the networks with a VLAN ID. Otherwise, an error message is displayed.]

  4. In the Interface Groups window, you can perform the following:

    • Select an existing interface group from the Select Interface Group drop-down list and click Save.

      For example, you select three networks and the interface group test, and click the Save button, the following operations are performed in the background:

      1. Nexus Dashboard retrieves interfaces that are part of the interface group test.

      2. Nexus Dashboard determines that three networks are added to the interface group test. Therefore, it autoattaches these networks to all the interfaces that are part of the interface group test.

      3. For each interface, Nexus Dashboard pushes the "switchport trunk allowed vlan add xxxx" command three times for each selected network.

        note.svg

        Nexus Dashboard ensures that there’s no duplicate configuration intent.

    If you click Clear, Nexus Dashboard pushes "switchport trunk allowed vlan remove xxx' config intent.

    • Create a custom interface group by entering an interface group name in the Select Interface Group field and click Create new interface group. Click Save.

      If you choose this option, make sure to add interfaces to this Interface Group in the Interfaces window. As a result, Nexus Dashboard performs the following operations:

      • Removes all existing overlay networks that don’t belong to the interface group from these interfaces.

      • Adds new overlay networks to these interfaces that are part of the interface group but not yet attached to these interfaces.

        For more information about associating interfaces to interface groups, see Create an interface group.

  5. Click Actions > Recalculate and deploy to deploy the selected networks on the switches.

Detach a network from an interface group

This procedure shows how to detach a network from an interface group in the Networks window. Also, you can detach networks when you remove an interface from an interface group in the Interfaces window. For more information, see Removing Interfaces from an Interface Group.

  1. Click on the fabric to launch Fabric Overview.

  2. Click Segmentation and Security > Networks.

  3. On the Networks tab, select the networks that you need to detach to an interface group and click Add to interface group.

  4. In the Add to interface groups window, select the interface group from the Select Interface Group drop-down list and click Clear to detach a network.

  5. (Optional) Navigate to Manage > Connectivity > Interfaces.

    Under the Overlay Network column, you can see the detached network in the red color for the corresponding interface. Click the network to view the expected config that is struck through.

  6. Navigate to Segmentation and Security > Networks and choose Actions > Recalculate and deploy.

Delete an interface group

An interface group is automatically deleted when it’s not in use. You can perform an explicit delete by clicking on Interface Groups > Actions > Delete interface group. This check is performed whenever you click the Clear button in the Edit Interface Group window. There may be exception scenarios where you need to clean up the interface groups explicitly.

For example, assume that you create an interface group called storageIG and you add an interface to it. Later, you want to change the interface mapping to another group (diskIG). In this case, you would go through these steps:

  1. Navigate to the Connectivity page.

  2. Click the Interfaces tab.

  3. Choose the interfaces that you want to remove from the storageIG interface group.

  4. Click Actions > Remove from interface group.

  5. With the same interfaces chosen, click Actions > Add to interface group and add the interfaces to the diskIG interface group.

  6. Click the Interface Groups tab.

  7. Assuming that the storageIG interface group no longer has any interfaces because they were moved to the diskIG interface group, choose the storageIG interface group and click Actions > Delete interface group.

Links

You can add links between border switches of different fabrics (inter-fabric links) or between switches in the same fabric (intra-fabric links). You can only create an inter-fabric connection (IFC) for a switch that is managed by Nexus Dashboard.

There are scenarios where you might want to define links between switches before connecting them physically. The links could be inter-fabric or intra-fabric links. Doing so, you can express and represent your intent to add links. The links with intent are displayed in a different color till they are actually converted to functional links. Once you physically connect the links, they are displayed as connected.

Management links might show up in the fabric topology as red colored links. To remove such links, right-click the link and click Delete Link.

The Border Spine and Border Gateway Spine roles are added to switch roles for border switches.

You can create links between existing and pre-provisioned devices as well by selecting the pre-provisioned device as the destination device.

These are the subtabs available under Links:

Links

The following table describes the fields that appear on the Links tab.

Field

Description

Fabric Name

Specifies the name of the Fabric.

Name

Specifies the name of the link. 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.

Policy

Specifies the link policy.

Info

Provides more information about the link.

Admin State

Displays the administrative state of the link.

Oper State

Displays the operational state of the link.

The following table describes the action items, in the Actions menu drop-down list, that appear on Fabric Overview > Links > Links.

Action Item

Description

Create

Allows you to create the following links:

Edit

Allows you to edit the selected fabric.

Delete

Allows you to delete the selected fabric.

Import

You can import a CSV file containing details of links to add new links to the fabric. The CSV file should have the following details of links: link template, source fabric, destination fabric, source device, destination device, source switch name, destination switch name, source interface, destination interface, and nvPairs.

note.svg

You cannot update existing links.
The Import Links icon is disabled for an external fabric.

Export

Select Actions > Export to export the links in a CSV file.

The following details of links are exported: link template, source fabric, destination fabric, source device, destination device, source switch name, destination switch name, source interface, destination interface, and nvPairs. The nvPairs field consists JSON object.

Protocol View

This tab displays the protocols for the links in the selected fabric.

The following table describes the fields that appear on Protocol View tab.

Field Description

Fabric Name

Specifies the name of the fabric.

Name

Specifies the name of the link.

Is Present

Specifies if the link is present.

Link Type

Specifies the type of link.

Link State

Specifies the state of link.

UpTime

Specifies the time duration from when the link was up.

To delete a protocol for links in a selected fabric, choose the protocol and click Actions > Delete.

Create intra-fabric links

To create intra-fabric links:

  1. Navigate to the Connectivity page.

  2. Click the Links tab.

  3. Click Actions > Create.

    The Link Management - Create Link page appears.

  4. From the Link Type drop-down list, choose Intra-Fabric since you are creating an IFC. The screen changes correspondingly.

    The fields are:

    • Link Type — Choose Intra-Fabric to create a link between two switches in a fabric.

    • Link Sub-Type — This field populates the fabric indicating that this is a link within the fabric.

    • Link Template — You can choose any of the following link templates.

      • int_intra_fabric_num_link — If the link is between two ethernet interfaces assigned with IP addresses, choose int_intra_fabric_num_link.

      • int_intra_fabric_unnum_link — If the link is between two IP unnumbered interfaces, choose int_intra_fabric_unnum_link.

      • int_intra_vpc_peer_keep_alive_link — If the link is a vPC peer keep-alive link, choose int_intra_vpc_peer_keep_alive_link.

      • int_pre_provision_intra_fabric_link — If the link is between two pre-provisioned devices, choose int_pre_provision_intra_fabric_link. After you click Save & Deploy, an IP address is picked from the underlay subnet IP pool.

        Correspondingly, the Link Profile section field is updated.

    • Source Fabric — The fabric name populates this field since the source fabric is known.

    • Destination Fabric — Choose the destination fabric. For an intra-fabric link, source and destination fabrics are the same.

    • Source Device and Source Interface — Choose the source device and interface.

    • Destination Device and Destination Interface — Choose the destination device and interface.

      note.svg

      Select the pre-provisioned device as the destination device if you are creating a link between an existing device and a pre-provisioned device.

      In the General tab in the Link Profile section:

    • Interface VRF — Name of a non-default VRF for this interface.

    • Source IP and Destination IP — Specify the source and destination IP addresses of the source and destination interfaces, respectively.

      note.svg

      The Source IP and Destination IP fields do not appear if you choose the int_pre_provision_intra_fabric_link template.

    • Interface Admin State — Check or uncheck the check box to enable or disable the admin state of the interface.

    • MTU — Specify the maximum transmission unit (MTU) through the two interfaces.

    • Source Interface Description and Destination Interface Description — Describe the links for later use. For example, if the link is between a leaf switch and a route reflector device, you can enter the information in these fields (link from leaf switch to RR 1 and link from RR 1 to leaf switch). This description gets converted into a configuration, but will not be pushed into the switch. After Save & Deploy, it is reflected in the running configuration.

    • Disable BFD Echo on Source Interface and Disable BFD Echo on Destination Interface — Check the check box to disable BFD echo packets on the source and the destination interface.

      Note that the BFD echo fields are applicable only when you have enabled BFD in the fabric settings.

    • Source Interface Freeform CLIs and Destination Interface Freeform CLIs — Enter the freeform configurations specific to the source and destination interfaces. You should add the configurations as displayed in the running configuration of the switch, without indentation. For more information, see Enabling Freeform Configurations on Fabric Switches.

  5. Click Save at the bottom right part of the page.

    You can see that the IFC is created and displayed in the list of links.

  6. On the Fabric Overview Actions drop-down list, choose Recalculate Config.

    The Deploy Configuration page 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. It lists the pending configurations on the switch. The Side-by-Side Comparison tab displays the running configuration and the expected configuration side-by-side.

    Close the Pending Config page.

  7. From the Fabric Overview Actions drop-down list, click Deploy Config.

    The pending configurations are deployed.

    After ensuring that the progress is 100% in all the rows, click Close at the bottom part of the page. The Links page displays again. In the fabric topology, you can see that the link between the two devices is displayed.

Create inter-fabric links

  1. Navigate to the Connectivity page.

  2. Click the Links tab.

    note.svg

    In external fabrics, inter-fabric links support BGW, Border Leaf/Spine, and edge router switches. To create inter-fabric links, perform the following steps:

  3. Click Actions > Create.

    The Link Management - Create Link page appears.

  4. From the Link Type drop-down box, choose Inter-Fabric since you are creating an IFC. The page changes correspondingly.

    The fields for inter-fabric link creation are as follows:

    Field Description

    Link Type

    Choose Inter-Fabric to create an inter-fabric connection between two fabrics, over their border switches.

    Link Sub-Type

    This field populates the IFC type. From the drop-down list, choose VRF_LITE, MULTISITE_UNDERLAY, or MULTISITE_OVERLAY.

    For information about VXLAN MPLS interconnection, see Editing Data Center VXLAN EVPN Fabric Settings.

    For information about routed fabric interconnection, see the section "Creating Inter-Fabric Links Between a Routed Fabric and an External Fabric" in Managing BGP-Based Routed Fabrics.

    Link Template

    The link template is populated.

    The templates are autopopulated with corresponding prepackaged default templates that are based on your selection.

    note.svg

    You can add, edit, or delete user-defined templates. See Managing Your Template Library for more details.

    Source Fabric

    This field is prepopulated with the source fabric name.

    Destination Fabric

    Choose the destination fabric from this drop-down box.

    Source Device and Source Interface

    Choose the source device and Ethernet interface that connects to the destination device.

    Destination Device and Destination Interface

    Choose the destination device and Ethernet interface that connects to the source device.

    Based on the selection of the source device and source interface, the destination information is autopopulated based on Cisco Discovery Protocol information, if available. There is an extra validation that is performed to ensure that the destination external device is indeed part of the destination fabric.

  5. Navigate to the General Parameters tab.

    Field Description

    Source BGP AS#

    In this field, the AS number of the source fabric is autopopulated.

    Source IP Address/Mask

    In this field, enter the IPv4 address with a netmask of the source interface that connects to the destination device.

    Destination IP Address

    In this field, enter the IPv4 address of the destination interface.

    Source IPv6 Address/Mask

    In this field, enter the IPv6 address with a netmask of the source interface.

    Destination IPv6 Address

    In this field, enter the IPv6 address of the destination interface.

    Destination BGP ASN Address

    Specifies the BGP autonomous system number for the destination fabric.

    BGP Maximum Paths

    Specifies the maximum number of iBGP/eBGP paths. The valid value is between 1 and 64.

    Routing TAG

    Specifies the routing tag associated with the interface IP.

    Link MTU

    Specifies the interface MTU for both ends of the inter-fabric link.

  6. Click Save at the bottom-right part of the screen.

    You can see that the IFC is created and displayed in the list of links.

  7. On the Fabric Overview > Actions drop-down list, select Recalculate Config.

    The Deploy Configuration page displays.

    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. It lists the pending configurations on the switch. The Side-by-side Comparison tab displays the running configuration and expected configuration side by side.

    Close the Pending Config screen.

  8. From the Fabric Overview > Actions drop-down list, select Deploy Config.

    The pending configurations are deployed.

    After ensuring that the progress is 100% in all the rows, click Close at the bottom part of the page. The Links page comes up again. In the fabric topology, you can see that the link between the two devices is displayed.

    If the two fabrics are member fabrics of an MSD, then you can see the link in the MSD topology too.

What’s next:
When you enable the VRF-Lite function using the ToExternalOnly method or using a VXLAN fabric group for inter-fabric connectivity, IFCs are automatically created between the (VXLAN fabric) border/BGW device and connected (external fabric) edge router or core device. When you remove the ER/core/border/BGW device, the corresponding IFCs (link PTIs) to/from that switch are deleted on Nexus Dashboard. Next, Nexus Dashboard removes the corresponding IFC configurations, if any, from the remaining devices on the next Save & Deploy operation. Also, if you want to remove a device that has an IFC and overlay extensions over those IFCs, you should undeploy all the overlay extensions corresponding to those IFCs for switch delete to be possible.

  1. To undeploy VRF extensions, select the VXLAN fabric and the extended VRFs, and undeploy the VRFs on the VRF deployment page.

  2. To delete the IFCs, delete the IFCs from the Links tab.

  3. Ensure that the fabric switch names are unique. If you deploy VRF extensions on switches with the same name, it leads to an erroneous configuration.

    The new fabric is created, the fabric switches are discovered in Nexus Dashboard, the underlay networks that are provisioned on those switches, and the configurations between Nexus Dashboard and the switches are synced.

    The remaining tasks are:

Establishing inter-fabric connectivity using VRF Lite

External connectivity from data centers is a prime requirement where workloads that are part of a data center fabric can communicate with an outside fabric over WAN or backbone services. To enable Layer 3 for north-south traffic flow, use virtual routing and forwarding instances (VRF)-Lite peering between data center border devices and the external fabric edge routers.

A VXLAN (Virtual Extensible Local Area Network) EVPN (Ethernet Virtual Private Network) based data center fabrics provide connectivity by distributing IP-MAC reachability information among various devices within the fabric. The VRF Lite feature is used for connecting the fabric to an external Layer 3 domain. This can be a border router or a Border Gateway router.

You can enable VRF Lite on the following devices:

  • Border

  • Border Spine

  • Border Gateway

  • Border Gateway Spine

  • Border Super Spine

  • Border Gateway Super Spine

Prerequisites and guidelines

  • VRF Lite requires Cisco Nexus 9000 Series Cisco Nexus Operating System (NX-OS) Release 7.0(3)I6(2) or later.

  • Familiarity with VXLAN BGP EVPN data center fabric architecture and VXLAN overlay provisioning through Nexus Dashboard.

  • Fully configured VXLAN BGP EVPN fabrics including underlay and overlay configurations for the various leafs and spine devices, external fabric configuration through Nexus Dashboard, and relevant external fabric device configuration (edge routers, for example).

    • You can configure a VXLAN BGP EVPN fabric (and connectivity to an external Layer 3 domain for north-south traffic flow) manually or using Nexus Dashboard.

      This document explains the process to connect the fabric to an edge router (outside the fabric, toward the external fabric) through Nexus Dashboard. You must know how to configure and deploy VXLAN BGP EVPN and external fabrics through Nexus Dashboard.

    • You can enable VRF Lite on a physical ethernet interface or on a Layer 3 port channel. A subinterface over a physical interface or Layer 3 port-channel interface is created in Nexus Dashboard at the VRF extension moment for each VRF-Lite link for which the VRF is extended over.

  • When you create a VXLAN VRF, ensure that you check the following three fields:

    Field Description

    Advertise Host Routes

    By default, over the VRF-Lite peering session, only nonhost (/32 or /128) prefixes are advertised. If host routes (/32 or /128) must be enabled and advertised from the border device to the edge/WAN router, check the Advertise Host Routes check box. Route-map does outbound filtering. By default, this check box is disabled.

    Advertise Default Route

    This field controls whether a network statement 0/0 is enabled under the VRF. This in turn advertises 0/0 route in BGP. By default, this field is enabled. When you choose this check box, this ensures that a 0/0 route is advertised inside the fabric over EVPN route type 5 to the leafs, thereby providing a default route out of the leafs toward the border devices.

    Config Static 0/0 Route

    By default, this check box is checked. This field controls whether a static 0/0 route to the edge/WAN router must be configured under the VRF on the border device. By default, this field is enabled. If WAN/edge routers are advertising a default route over the VRF-Lite peering to the border device in the fabric, then this field must be disabled. In addition, the Advertise Default Route field must be disabled. The 0/0 route that is advertised over the External Border Gateway Protocol sends over EVPN to the leafs without requiring more configuration. The clean IBGP EVPN separation inside the fabric with eBGP for external out-of-fabric peering provides for this desired behavior.

  • To delete a VRF-Lite inter-fabric connections (IFC), remove all the VRF extensions that are enabled on the IFC. Otherwise an error message displays. After you remove the VRF-Lite attachments, recalculate and deploy the fabric to remove any pending Layer 3 extension configurations. Nexus Dashboard removes the per-VRF subinterface and per-VRF External Border Gateway Protocol configuration on the devices.

Sample scenarios

These sections explain different use cases for configuring VRF Lite:

This is a typical use case of a Cisco ASR 9000-based edge router in managed mode.

Automatic VRF-Lite configuration

Guidelines and limitations for automatic VRF-Lite configuration

  • Auto inter-fabric connection (IFC) is supported on Cisco Nexus devices only.

  • You can configure Cisco ASR 1000 series routers and Cisco Catalyst 9000 series switches as edge routers. To configure, set up a VRF Lite IFC, and connect it as a border device with easy fabric.

  • You can configure Cisco ASR 9000 Series routers as edge routers in managed mode.

  • If the device in the External fabric is non-Nexus, you must create IFC manually.

  • Ensure that no user policy is enabled on the interface that connects to the edge router. If a policy exists, then the interface will not be configured.

  • Autoconfiguration is supported for the following use cases:

    • Border role in the VXLAN fabric and Edge Router role in the connected external fabric device

    • Border Gateway role in the VXLAN fabric and Edge Router role in the connected external fabric device

    • Border role to another Border role directly

      note.svg

      Auto configuration is not provided between two Border Gateways (BGWs).

      If VRF Lite is required between other roles, you must deploy it manually on Nexus Dashboard.

  • To deploy configurations in the external fabric, you must uncheck the Fabric Monitor Mode check box in the external fabric settings. When an external fabric is set to Fabric Monitor Mode Only, you cannot deploy configurations on the switches.

VXLAN fabric settings

The following are the two modes in which you can deploy VRF Lite. By default, VRF Lite deployment is set to Manual. You can change the settings based on your requirement.

  • Manual — Use this option to deploy the VRF Lite IFCs manually between the source and the destination devices.

  • Back2Back&ToExternal — Use this option to automatically configure VRF Lite IFCs between a border switch and the edge or core switches in external fabric or between back-to-back border switches in VXLAN EVPN fabric.

    note.svg

    Though VRF Lite mode is set to Manual for Nexus Dashboard resource handling, a Data Center Interconnectivity (DCI) subnet is required.

The Manual mode is the default mode in VXLAN fabric settings. To change the default mode to another mode, click Edit fabric settings. On the Resource tab, modify the VRF Lite Deployment field to the above mentioned auto configuration mode.

Field Description

Auto Deploy Peer

This check box is applicable for VRF Lite deployment. When you check this check box, IFCs are automatically created for peer devices. You can check or uncheck this check box when the VRF Lite Deployment field is not set to Manual. The value you choose takes priority. This configuration only affects the new auto-created IFCs and does not affect the existing IFCs.

Auto Deploy Default VRF

When you select this check box, the Auto Generate Configuration on default VRF field is automatically enabled for auto-created VRF Lite IFCs. You can check or uncheck this checkbox when the VRF Lite Deployment field is not set to Manual. The Auto Generate Configuration on default VRF field when set, automatically configures the physical interface for the border device in the default VRF, and establishes an EBGP connection between the border device and the edge device or another border device in a different VXLAN EVPN fabric.

Auto Deploy Default VRF for Peer

When you check this checkbox, the Auto Generate Configuration for NX-OS Peer on default VRF field is automatically enabled for auto-created VRF Lite IFCs. You can check or uncheck this checkbox when the VRF Lite Deployment field is not set to Manual. The Auto Generate Configuration for NX-OS Peer on default VRF field when set, automatically configures the physical interface and the EBGP commands for the peer NX-OS switch.

note.svg

You can access the Auto Generate Configuration on default VRF and Auto Generate Configuration for NX-OS Peer on default VRF fields for an IFC link by navigating to Actions > Edit > VRF Lite.

Redistribute BGP Route-map Name

Defines the route map for redistributing the BGP routes in the default VRF.

VRF Lite Subnet IP Range

The IP address for VRF Lite IFC deployment is chosen from this range. The default value is 10.33.0.0/16. Ensure that each fabric has its own unique range and is distinct from any underlay range to avoid possible duplication. These addresses are reserved with the Resource Manager.

VRF Lite Subnet Mask

By default, it is set to /30, which is a best practice for point-to-point (P2P) links.
VRF Lite between a Cisco Nexus 9000-based border and a Cisco Nexus 9000-based edge device

In the following example topology, the DC-VXLAN fabric is on a WAN-VXLAN cloud. The VXLAN fabric has a border leaf role and the WAN-VXLAN cloud has a device with the role edge router. Nexus Dashboard shows the physical and logical representation of the topology with Cisco Discovery Protocol/Link Layer Discovery Protocol (LLDP) link discovery.

452367.jpg

In this example, enable a VRF-Lite connection between a DC-VXLAN border leaf and a WAN-VXLAN edge router.

For a VRF-Lite configuration, you must enable External Border Gateway Protocol (EBGP) peering between the fabric’s border interfaces and the edge router’s interfaces through point-to-point (P2P) connections.

The border physical interfaces are:

  • eth1/1 on border1-Vxlan, toward eth1/1 on WAN1-Vxlan.

  • eth1/2 on border2-Vxlan, toward eth1/2 on WAN1-Vxlan.

Workflow for configuring an IPv4 or an IPv6 overlay network

Follow these steps to configure an IPv4 or IPv6 overlay network.

  1. Create an inter-fabric connection using source and destination IPv4 or IPv6 addresses.

    For more information, see Create inter-fabric links.

  2. Add a VRF-Lite extension.

  3. Attach the VRF and the VRF-Lite extension to the border device.

    For more information, see Attach the VRF and the VRF-Lite extension to the border device.

  4. Create a network configured with an IPv4 or an IPv6 gateway.

    For more information, see the section "Create a network" in Working with Segmentation and Security for your Nexus Dashboard VXLAN Fabric.

  5. Add a switch to your network. For more information, see the "Configure switches" section in Working with Inventory in Your Nexus Dashboard LAN or IPFM Fabrics.

  6. Recalculate and deploy the configuration.

Create a Layer 2 DCI link

Nexus Dashboard added a Layer 2 link template, ext_l2_dci_link, for configuring a Layer 2 link for MACsec with QKD. For more information on MACsec with QKD, see About connecting two NX-OS fabrics with MACsec using QKD.

Follow these steps to create a Layer 2 DCI link.

  1. On the Manage > Fabrics page, click on a Data Center VXLAN EVPN fabric.

    The Overview page appears.

  2. Navigate to the Connectivity > Links tab.

  3. On the Links tab, click Actions > Create Link.

    The Link Management - Create Link page appears.

  4. To configure a Layer 2 DCI link, enter the following parameters on the Link Management - Create Link page:

    Field Description

    Link Type

    Choose Inter-Fabric from the drop-down menu.

    Link Sub-Type

    Choose L2_DCI as the Link Sub-Type.

    Link Template

    Choose ext_I2_dci_link as the link template for a DCI link.

    The link template enables the source and destination interfaces as Layer 2 interfaces.

  5. When you have completed the necessary configurations, click Save.

Attach the VRF and the VRF-Lite extension to the border device

  1. Navigate to the main Fabrics page: Manage > Fabrics.

  2. Click the name of the fabric for which you want to attach the VRF and the VRF-Lite extension.

    The Overview page displays.

  3. Click the Segmentation and security > VRFs tab.

  4. Choose a VRF Name and click Actions > Edit.

    The VRF Attachments page appears.

  5. Click the VRF Attachments tab.

  6. Click Actions > Edit.

  7. You can edit details in the Extension table by clicking the Edit link.

  8. Toggle the knob to Attach.

  9. In Extend, choose VRF_LITE from the drop-down list.

  10. In the Extension table, choose one switch at a time.

    You can edit details in the Extension table by clicking the Edit link.

    The Edit Extension Details page displays.

  11. In the Neighbor ASN field, you can specify an alternate value for the Neighbor ASN field. By default, the Neighbor ASN field always takes the ASN from the VRF Lite inter-fabric link. Beginning with Nexus Dashboard 4.1.1, you can edit the Neighbor ASN field.

    If the neighbor is an edge or a core device in an External fabric, Nexus Dashboard uses the local-as command in the policy configuration if the Autonomous System Number (ASN) is different from the ASN of the External fabric.

    For the pending configurations after editing the Neighbor ASN field, see Pending VRF-Lite extension configurations after modifying a neighbor ASN value.

  12. Enter the details for PEER_VRF_NAME.

    This auto deploys the VRF on the neighboring device.

    When you extend a VRF-Lite consecutive scenario, the VRF must be in the peer fabric and the VRF name must be the same. If the VRF is not in the peer fabric and if you try to extend VRF Lite, an error message is generated displaying the issue.

    When you extend VRF Lite between a VXLAN EVPN fabric and an External fabric, the VRF name can be the same as the name of the source fabric, or the default name, or another VRF name.

  13. Enter the required VRF name in the PEER_VRF_NAME field.

    The child Policy Template Instances (PTIs) for subinterface, VRF creation, and BGP peering on the External fabric have source values that are populated in the PTI. You cannot edit or delete the policies.

  14. Follow the above procedure for adding other inter-fabric links.

  15. On the Edit page, click Attach-all, to attach the required VRF extension to the border device.

  16. Click Save.

Recalculate and deploy the configuration on the VXLAN or the External fabric

  1. Navigate to the main Fabrics page: Manage > Fabrics.

  2. Click on the appropriate fabric to navigate to the Overview page.

  3. Click Actions > Recalculate and deploy.

  4. Perform the same operation by choosing the required VRF Name on the VRF Attachments tab and clicking Actions > Deploy to initiate the VRF or VRF-Lite configuration on the border device.

  5. Alternatively, on the Overview page, click Actions > Recalculate and deploy.

    You can also choose the VRF attachment, edit, and click Deploy.

    Nexus Dashboard pushes VRF and VRF-Lite configurations to the border devices.

VRF Lite between a Cisco Nexus 9000-based border and a non-Cisco device

This section describes the procedure for enabling a VRF-Lite connection between a VXLAN EVPN border leaf device and a non-Cisco device in an External fabric.

We recommend using the meta definition of a device instead of importing devices in an external fabric. This allows VRF-Lite configurations to extend Cisco Nexus 9000-managed border devices in VXLAN fabric. Nexus Dashboard does not manage destination non-Cisco devices. You must configure the relevant VRF-Lite configuration on the destination device.

Create new IFC links between a border device and an edge router

Follow the steps documented in Create inter-fabric links to create new IFC links between a border device and an edge router.

Attach the VRF and the VRF-Lite extension to the border device

Follow these steps to attach the VRF and the VRF-Lite extension to the border device.

  1. On the Manage > Fabrics page, click on the Data Center VXLAN EVPN fabric.

  2. On the Overview page, navigate to the Segmentation and security > VRFs tab.

  3. Click on a VRF Name.

    The VRF Attachments page displays.

  4. Click the VRF Attachments tab.

  5. Choose a VRF Name and click Actions > Edit.

    The Extension page displays.

  6. Click Attach-all to attach the required VRF-Lite extension to the border device and then click Save.

Recalculate and deploy the configuration on the VXLAN fabric

  1. On the Manage > Fabrics page, click on the appropriate fabric to navigate to the Overview page.

  2. Click Actions > Recalculate, sync and deploy.

  3. Perform the same action by choosing the required VRF Name on the Segmentation and security > VRF attachments tab and clicking Actions > Deploy to initiate the VRF or VRF-Lite configuration on the border device.

VRF Lite between a Cisco Nexus 9000-based border and a non-Nexus device

In this example, you can enable VRF-Lite connections between a DC-VXLAN border leaf and a non-Nexus device in an External fabric.

The following are the supported platforms:

  • ASR 9000 and ASR 1000

  • Cisco Catalyst 9000

  • CSR 1000v

  • NCS 5501 and NCS 5001

  • Cisco 8000

note.svg

The ASR 9000 series switch is supported in managed mode with an edge router role.

Configuration compliance is enabled for IOS XR switches in an External fabric, similar to Cisco Nexus switches configured on an External fabric. Nexus Dashboard pushes the configuration at the end of the deployment.

note.svg

Ensure that the VXLAN BGP EVPN border device is active.

Follow these steps to configure VRF Lite between a Cisco Nexus 9000-based border and a non-Nexus device.

  1. Navigate to Manage > Fabrics to create an External fabric.

  2. Choose Create Fabric. For information on how to create a fabric, see Creating LAN and ACI Fabrics and Fabric Groups.

  3. After configuring your External fabric, navigate to the Manage > Inventory tab and click Actions > Add Switches. For more information, see Working with Inventory in Your Nexus Dashboard LAN or IPFM Fabrics.

    You do not need to configure the Simple Network Management Protocol (SNMP) for IOS-XR discovery of switches. Nexus Dashboard uses Secure Shell (SSH) for IOS XR device discovery.

    To add non-Nexus devices to External fabrics, see the section "Adding Non-Nexus Devices to External Fabrics" in External Connectivity Network.

  4. On the Add Switches page, click Choose Fabric.

  5. Click IOS-XR from the Device Type drop-down list.

  6. After the router is discovered, you can view the switch name in the Discovery Results field.

  7. Choose the discovered router and add it to the External fabric.

    Ensure that the Discovery Status displays OK in the Status column.

    An edge router role is supported.

    After successful discovery, you can view the links between the devices on the Links tab.

  8. To create a VRF-Lite Inter-Fabric Connection (IFC) for an External fabric with a Cisco Nexus 9000 border leaf, choose the appropriate link and click Edit from the Actions drop-down list.

    note.svg

    You need to perform this step from the VXLAN fabric, not the External fabric.

  9. On the Link Management-Edit Link page, fill in the required details for creating an inter-fabric connection link. For more information, see Create inter-fabric links.

    A few fields are auto-populated.

    If the Auto Generate Configuration for Peer field is enabled, and the edge device is an IOS XR device, enter ios_xr_Ext_VRF_Lite_Jython in the Template for Configuration Generation on Peer field. If Auto Generate Configuration for Peer is enabled, and the edge device is an IOS XE device, enter ios_xe_Ext_VRF_Lite_Jython in the Template for Configuration Generation on Peer field.

  10. Deploy the configuration on the IOS XR router.

VRF-Lite configurations
Cisco Nexus 9000 border device configurations

Border-VXLAN (base border configurations) generated by template ext_base_border_vrflite_11_1

switch configure terminal
switch(config)#
ip prefix-list default-route seq 5 permit 0.0.0.0/0 le 1
ip prefix-list host-route seq 5 permit 0.0.0.0/0 eq 32
route-map extcon-rmap-filter deny 10
    match ip address prefix-list default-route
route-map extcon-rmap-filter deny 20
    match ip address prefix-list host-route
route-map extcon-rmap-filter permit 1000
route-map extcon-rmap-filter-allow-host deny 10
    match ip address prefix-list default-route
route-map extcon-rmap-filter-allow-host permit 1000
ipv6 prefix-list default-route-v6 seq 5 permit 0::/0
ipv6 prefix-list host-route-v6 seq 5 permit 0::/0 eq 128
route-map extcon-rmap-filter-v6 deny 10
    match ipv6 address prefix-list default-route-v6
route-map extcon-rmap-filter-v6 deny 20
    match ip address prefix-list host-route-v6
route-map extcon-rmap-filter-v6 permit 1000
route-map extcon-rmap-filter-v6-allow-host deny 10
    match ipv6 address prefix-list default-route-v6
route-map extcon-rmap-filter-v6-allow-host permit 1000
Border-VXLAN VRF-Lite extension configuration
switch configure terminal
vrf context CORP
  ip route 0.0.0.0/0 2.2.2.2
exit
router bgp 100
  vrf CORP
    address-family ipv4 unicast
      network 0.0.0.0/0
      exit
    neighbor 2.2.2.2
      remote-as 200
      address-family ipv4 unicast
        send-community both
        route-map extcon-rmap-filter out
configure terminal
interface ethernet1/1.2
  encapsulation dot1q 2
  mtu 9216
  vrf member CORP
  ip address 2.2.2.22/24
  no shutdown
configure terminal
WAN-VXLAN (External fabric edge device) VRF-Lite extension configuration
switch configure terminal
vrf context CORP
  address-family ipv4 unicast
exit
router bgp 200
  vrf CORP
    address-family ipv4 unicast
    neighbor 10.33.0.2
      remote-as 100
      address-family ipv4 unicast
        send-community both
        exit
      exit
    neighbor 10.33.0.6
      remote-as 100
      address-family ipv4 unicast
        send-community both
configure terminal
interface ethernet1/1.2
  mtu 9216
  vrf member CORP
  encapsulation dot1q 2
  ip address 10.33.0.1/30
  no shutdown
interface ethernet1/2.2
  vrf member CORP
  mtu 9216
  encapsulation dot1q 2
  ip address 10.33.0.5/30
  no shutdown
configure terminal
Pending VRF-Lite extension configurations after modifying a neighbor ASN value

Pending configuration on an edge device

vrf context dsvni-1
  address-family ipv4 unicast
exit
router bgp 50000
  vrf dsvni-1
    address-family ipv4 unicast
    neighbor 14.100.0.1
      remote-as 400.4000
      local-as 50012
      address-family ipv4 unicast
        send-community both
configure terminal
interface ethernet1/8.2
  vrf member dsvni-1
  mtu 9216
  encapsulation dot1q 2
  ip address 14.100.0.2/30
  no shutdown
configure terminal

Pending configuration on a border device

router bgp 400.4000
  vrf dsvni-1
    address-family ipv4 unicast
      advertise l2vpn evpn
      redistribute direct route-map fabric-rmap-redist-subnet
      maximum-paths ibgp 2
      network 0.0.0.0/0
      exit
    address-family ipv6 unicast
      advertise l2vpn evpn
      redistribute direct route-map fabric-rmap-redist-subnet
      maximum-paths ibgp 2
      exit
    neighbor 14.100.0.2
      remote-as 50012
      address-family ipv4 unicast
        send-community both
        route-map extcon-rmap-filter out
configure terminal

About connecting two NX-OS fabrics with MACsec using QKD

Media Access Control Security (MACsec) is the IEEE 802.1AE standard for authenticating and encrypting packets between two MACsec-capable devices.

With this feature, you can connect two fabrics using inter-fabric links with MACsec, either using a quantum key distribution (QKD) server for secure exchange of encryption keys, or by providing a preshared key. If you choose not to enable QKD, Nexus Dashboard configures preshared keys supplied by the user instead of using quantum keys generated by the QKD server. You need to enable MACsec to enable the use of the QKD server for MACsec.

note.svg

Nexus Dashboard does not manage the QKD server.

Nexus Dashboard provides support for MACsec for inter-fabric links for the following fabric types:

  • Data Center VXLAN EVPN

  • Enhanced Classic LAN

  • External Connectivity Network

Connecting two fabrics with MACsec using QKD

The following sections provide information about connecting two fabrics with MACsec using QKD:

Benefits of connecting two fabrics with MACsec using QKD

  • Supports generation of quantum keys for encryption using a QKD server for protecting the privacy and authenticity of data.

  • Instead of using preshared keys between the endpoints, Nexus Dashboard uses the keys from the QKD server that are difficult to break.

  • Helps to ensure data confidentiality by providing strong encryption at Layer 2 for VRF-Lite inter-fabric links. For more information, see the section "Create a VRF-Lite Inter-Fabric Link" in VRF Lite.

  • Provides a secure connectivity association between fabrics.

Supported switches and Cisco NX-OS releases for connecting two fabrics with MACsec using QKD

For more information about MACsec configuration, which includes supported platforms and releases, see the Configuring MACsec chapter in the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.

Supported configurations for connecting two fabrics with MACsec using QKD

You can connect two fabrics with MACsec using QKD for the following use cases:

First Fabric Type Second Fabric Type

Data Center VXLAN EVPN

Data Center VXLAN EVPN

Data Center VXLAN EVPN

External Connectivity Network

Data Center VXLAN EVPN

Enhanced Classic LAN

Enhanced Classic LAN

Enhanced Classic LAN

Enhanced Classic LAN

External Connectivity Network
Guidelines for connecting two fabrics with MACsec using QKD

  • You can change MACsec global parameters in the fabric settings at any time.

  • MACsec and CloudSec can coexist on a border gateway (BGW) device.

  • MACsec status of a link with MACsec enabled is displayed on the Links page.

  • Brownfield migration of devices with MACsec configured is supported using switch and interface freeform configurations.

Limitations for connecting two fabrics with MACsec using QKD

This feature does not support the following fabric types:

  • BGP

  • Campus VXLAN EVPN

  • VXLAN EVPN Multi-Site

This feature does not support inter-fabric links between two External Connectivity Network fabrics. You can use a freeform configuration to achieve this use case.

Workflow for connecting two fabrics with MACsec using QKD

  1. Before enabling MACsec using QKD on the fabric and the associated switches, you need to do the following:

    1. Create the RSA keys.

    2. Associate the key pair to the trust point.

    3. Get the signed certificate and upload it to Nexus Dashboard. For more information, see Upload a certificate for connecting two fabrics with MACsec using QKD.

    4. Manually add the signed certificate to the appropriate switches.

      For more information, see the section "Configuring CAs and Digital Certificates" in the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.

  2. Create or edit one of the supported fabric types to enable MACsec and the QKD server.

    For more information, see the following sections:

  3. Create a VRF-Lite inter-fabric link or a Layer 2 inter-fabric link.

    For more information, see Working with Connectivity in Your Nexus Dashboard LAN Fabrics.

Troubleshooting connecting two fabrics with MACsec using QKD

If you cannot configure MACsec with QKD on the physical interfaces of the link, an error displays when you click Save.

The error may occur for the following reasons:

Upload a certificate for connecting two fabrics with MACsec using QKD

  1. Navigate to Admin > Certificate Management > CA Certificates.

  2. Click Add CA Certificate.

    The Upload Certificate - CA dialog box displays.

  3. Drag and drop your CA certificate file to the dialog box or browse to the location of your certificate file.

    The following are the accepted file types:

    • .pem

    • .cer

    • .key

    • .crt

  4. Click Save.

Edit fabric settings for connecting two fabrics with MACsec using QKD

Enable MACsec on the fabric and on each inter-fabric link to configure MACsec using a quantum key distribution server (QKD).

When you enable MACsec on an inter-fabric link, Nexus Dashboard uses the local fabric settings for prepopulating the MACsec parameters. Switches in an External Connectivity Network fabric take MACsec settings from a Data Center VXLAN EVPN fabric or from an Enhanced Classic LAN fabric. An External Connectivity Network fabric, Data Center VXLAN EVPN fabric, or an Enhanced Classic LAN fabric can be either the source or the destination fabric.

Each MACsec-enabled inter-fabric link includes an override option to use the link’s local settings instead of from the fabric settings. The override option, Use Link MACsec Setting, allows switches in external fabrics to use a different QKD server from the one used in the Data Center VXLAN EVPN fabric or the Enhanced Classic LAN fabric. Nexus Dashboard autopopulates MACsec parameters from the fabric settings if the Use Link MACsec Setting option is not enabled.

Edit fabric settings for an Enhanced Classic LAN fabric for enabling MACsec using QKD

  1. Choose Manage > Fabrics.

  2. Create a new fabric or edit an existing one.

    note.svg

    If you are editing an Enhanced Classic LAN fabric, you can change MACsec parameters at any time. You need to perform a Recalculate and deploy operation to generate new configurations based on the updated fabric settings.

    • If you are creating a new fabric:

      1. Click Create Fabric.

      2. Click Create new LAN fabric, then click Next.

      3. Choose the Classic LAN fabric type, then click Next.

      4. Click Advanced in the Configuration mode field, then configure the necessary settings to create the new fabric.

        See Editing Classic LAN Fabric Settings for more information.

      5. In the Advanced settings step in the fabric creation process, click Security.

        Go to Step 3.

    • If you are editing an existing fabric:

      1. Choose an existing Enhanced Classic LAN fabric.

        The Overview window for that fabric appears.

      2. Choose Actions > Edit Fabric Settings.

      3. Click Fabric Management.

      4. Click the Security tab.

  3. Locate these fields in Security and make the necessary configurations:

    Field Description

    Enable DCI MACsec

    Check the check box to enable MACsec on DCI links.

    Enable QKD

    Check the check box to enable the QKD server for generating quantum keys for encryption.

    note.svg

    If you choose to not enable the Enable QKD option, Nexus Dashboard uses preshared keys provided by the user instead of using the QKD server to generate the keys. If you disable the Enable QKD option, all the fields pertaining to QKD are grayed out.

    DCI MACsec Cipher Suite

    Choose one of the following DCI MACsec cipher suites for the DCI MACsec policy:

    • GCM-AES-128

    • GCM-AES-256

    • GCM-AES-XPN-128

    • GCM-AES-XPN-256

    The default value is GCM-AES-XPN-256.

    DCI MACsec Primary Key String

    Specify a Cisco Type 7 encrypted octet string that is used for establishing the primary DCI 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.

    note.svg

    The default key lifetime is infinite.

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

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

    note.svg

    This parameter is mandatory if Enable QKD is not selected.

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

    QKD Profile Name

    Specify the crypto profile name.

    The maximum size of the crypto profile is 63.

    KME Server IP

    Specify the IPv4 address for the Key Management Entity (KME) server.

    KME Server Port Number

    Specify the port number for the KME server.

    Trustpoint Label

    Specify the authentication type trustpoint label.

    The maximum size is 64.

    Ignore Certificate

    Enable this check box to skip verification of incoming certificates.

    MACsec Status Report Timer

    Specify the MACsec operational status periodic report timer in minutes.

  4. Click Save to save the fabric settings.

  5. From the Actions drop-down list, choose Recalculate and deploy to apply the new MACsec settings to links that have MACsec enabled and where the Use Link MACsec Setting option is disabled.

Edit fabric settings for a Data Center VXLAN fabric for enabling MACsec using QKD

  1. Choose Manage > Fabrics.

  2. Create a new fabric or edit an existing one.

    note.svg

    If you are editing an Enhanced Classic LAN fabric, you can change MACsec parameters at any time. You need to perform a Recalculate and deploy operation to generate new configurations based on the updated fabric settings.

    • If you are creating a new fabric:

      1. Click Create Fabric.

      2. Click Create new LAN fabric, then click Next.

      3. Choose the VXLAN fabric type, then choose the Data Center VXLAN EVPN subtype, then click Next.

      4. Click Advanced in the Configuration mode field, then configure the necessary settings to create the new fabric.

        See Editing Data Center VXLAN EVPN Fabric Settings for more information.

      5. In the Advanced settings step in the fabric creation process, click Security.

        Go to Step 3.

    • If you are editing an existing fabric:

      1. Choose an existing Enhanced Classic LAN fabric.

        The Overview window for that fabric appears.

      2. Choose Actions > Edit Fabric Settings.

      3. Click Fabric Management.

      4. Click the Security tab.

        The DCI MACsec parameters are the same as for the Enhanced Classic LAN fabric type, as the Data Center VXLAN EVPN fabric type has MACsec parameters for intra-fabric links. For more information, see Edit fabric settings for an Enhanced Classic LAN fabric for enabling MACsec using QKD.

        For more information about the remaining fields, see Editing Data Center VXLAN EVPN Fabric Settings.

  3. Click Save to configure the MACsec with QKD feature on each switch in the fabric.

  4. From the Actions drop-down list, choose Recalculate and deploy.

Edit fabric settings for an External Connectivity Network fabric for enabling MACsec using QKD
note.svg

With this release, no MACsec parameters are added to the External Connectivity Network fabric.

Switches in an External Connectivity Network fabric take MACsec settings from a Data Center VXLAN EVPN fabric or from an Enhanced Classic LAN fabric.

For more information, see the section "Creating an External Fabric" in Editing External Fabric Settings.

Disable MACsec using QKD

The process described in this section is for disabling MACsec for an inter-fabric link for the supported fabric type. For the supported fabric types, see About connecting two NX-OS fabrics with MACsec using QKD.

The following operations will disable MACsec and QKD from a link:

  • Disables MACsec on the inter-fabric link using QKD or a preshared key.

  • If this is the last link where MACsec is enabled, Nexus Dashboard deletes the switch-level MACsec configuration from the switch.

    1. Navigate to the Links window for your fabric.

      1. Navigate to Manage > Fabrics.

      2. Click on the fabric where you want to disable MACsec using QKD

        The Overview window for that fabric appears.

      3. Choose Connectivity > Links.

    2. Choose the link on which you want to disable MACsec with QKD.

    3. From the Link Management - Edit Link page, navigate to the Security tab and unselect the following options:

      • Enable MACsec

      • Enable QKD

    4. Click Save.

    5. From the Fabric Overview > Inventory > Switches tab, select Actions > Deploy to remove the MACsec configuration from the switch.

Routing policies

Introduced in Nexus Dashboard release 4.1.1, routing policies are used to define and control how routes are distributed, filtered, or manipulated between two VXLAN EVPN fabrics or between a VXLAN EVPN fabric and an external fabric in your Nexus Dashboard. These policies give you granular control over routing behavior, enabling the implementation of specific network requirements.

You will use these components to define routing policies in your Nexus Dashboard:

Navigate to the Routing policies page

  1. Navigate to the main Fabrics page:

    Manage > Fabrics

  2. In the table showing all of the Nexus Dashboard fabrics that you have already created, locate the VXLAN EVPN or external fabric where you want to configure routing policies.

  3. Single-click on that fabric.

    The Overview page for that fabric appears.

  4. Click the Connectivity tab.

  5. Click the Routing policies subtab.

L3Outs

An L3Out (Layer 3 Outside) refers to a logical construct that enables connectivity between two VXLAN EVPN fabrics or between a VXLAN EVPN fabric and an external fabric.

Guidelines and limitations: L3Outs

Supported

L3Outs are supported in these areas:

  • On these fabric types:

    • VXLAN EVPN (iBGP)

    • VXLAN EVPN (eBGP)

    • External and Inter-Fabric Connectivity

    • AI VXLAN EVPN

Unsupported

L3Outs are not supported in these areas:

  • On these fabric types:

    • Both fabrics in an L3Out cannot be external fabrics. At least one fabric must be another type.

    • You cannot create an L3Out from multi-site/fabric group context. You should create the L3Out from one of the member fabrics or from the standalone fabrics.

  • These switch roles:

    • Leaf

    • Spine

    • Super spine

    • ToR

    • Access

Configure L3Outs

To view information about L3Outs in your Nexus Dashboard:

  1. Navigate to the Routing policies page.

  2. Click the L3Outs subtab.

    Any already-configured L3Outs are displayed with this information:

    Field Description

    Name

    Shows the name of the L3Out. Click the link in the Name column to display information for this L3Out.

    Connected fabric

    Shows the destination fabric that is connected in this L3Out.

    Nexus Dashboard connects two fabrics using an L3Out (for example, you might use an L3Out to connect fabric1 and fabric2). In this example, if you are in fabric1 and you click on the link in the Connected fabric column, the page for fabric2 appears, which is the destination fabric that fabric1 is connected to using this L3Out.

    IP version

    Shows the IP version used in this L3Out.

    Routing interface type

    Shows the routing interface type used in this L3Out.

    Reachability protocol

    Shows the reachability protocol used in this L3Out.

    Attach

    Shows if this L3Out is attached or not.

    Fabric 1 VRF

    Shows the VRF associated with fabric 1 in this L3Out.

    Fabric 2 VRF

    Shows the VRF associated with fabric 2 in this L3Out.

    Physical links

    Shows the number of physical links used in this L3Out.

  3. Configure an L3Out, if necessary.

    These options are available to configure L3Outs:

Create an L3Out

To create an L3Out:

  1. Navigate to the Routing policies page.

  2. Click the L3Outs subtab.

  3. Choose Actions > Create L3Out.

  4. Navigate through the steps in the L3Out wizard:

1. Connect fabrics

  1. Make the necessary configurations in the Connect fabrics page:

    Field Description

    Name

    Enter the name of the L3Out connection.

    Fabric 1

    Choose the source fabric.

    Fabric 2

    Choose the destination fabric.

    Fabric 1 VRF

    Choose the VRF to use for fabric 1 or click + Create VRF to create a new VRF for this fabric. See the "Create a VRF" section in the Working with Segmentation and Security for Your Nexus Dashboard VXLAN Fabric for more information.

    Fabric 2 VRF

    Choose the VRF to use for fabric 2 or click + Create VRF to create a new VRF for this fabric. See the "Create a VRF" section in the Working with Segmentation and Security for Your Nexus Dashboard VXLAN Fabric for more information.

    Configure L3Out connections for

    Choose whether you want to configure L3Out connections for:

    • Both fabric 1 and fabric 2,

    • Fabric 1 only, or

    • Fabric 2 only.

    Configuration changes will only be pushed to the switches in the selected fabrics.

    IP version

    Choose the IP version for this L3Out:

    • IPv4

    • IPv6

    • Both

    Reachability protocol

    Choose the reachability protocol for this L3Out:

    • BGP

    • Static routes

    Routing interface type

    Choose the routing interface type for this L3Out:

    • Subinterface

    • Routed

    • SVI

    note.svg

    If you change the interface type, all the previously configured values become invalid as they no longer apply to the new interface type. Therefore, it is essential to review and update the configuration to ensure it accurately reflects the new interface type.

    Attach

    Toggle the switch to the right to attach the L3Out connection or to the left to unattach the L3Out connection.

  2. Click Next.

    You advance to the 2. Reachability configuration step in the process.

2. Reachability configuration

  1. Review the existing reachability configurations displayed in the Reachability configuration page, if necessary.

    Existing links with the appropriate policy between the two selected fabrics will be displayed here. The link templates used are:

    • ext_fabric_setup for the sub-interface type,

    • ext_l2_dci_link for the SVI type, and

    • ext_l3_dci_link for the routed type.

      Wherever possible, Nexus Dashboard will attempt to allocate non-conflicting IP addresses, Dot1Q tags or VLAN IDs for these links. If Nexus Dashboard is not able to auto-allocate these configurations, fill in the details manually before proceeding.

    Resources are allocated from the following ranges, specified in the fabric settings of VXLAN fabrics.

    • VLAN ID: VRF VLAN Range

    • Dot1q tag: Subinterface Dot1q Range

    • IPv4 addresses: VRF Lite Subnet IP Range / VRF Lite Subnet Mask

    • IPv6 addresses: VRF Lite IPv6 Subnet Range / VRF Lite IPv6 Subnet Mask

      note.svg

      IPv4 and/or IPv6 information will be displayed in the table based on the choice that you made in the IP version field.

      For each link, the table will display this information:

      Field Description

      Fabric 1 switch

      Shows the switch in fabric 1 that is part of the link.

      Fabric 1 interface

      Shows the interface in the fabric 1 switch that is part of the link. If you chose Subinterface in the Routing interface type field, this will specify the name of the subinterface (for example, Ethernet1/1.20).

      Fabric 2 switch

      Shows the switch in fabric 2 that is part of the link.

      Fabric 2 interface

      Shows the interface in the fabric 2 switch that is part of the link. If you chose Subinterface in the Routing interface type field, this will specify the name of the subinterface (for example, Ethernet2/1.20).

      Fabric 1 IPv4

      Specifies the IP address assigned to the inter-fabric connection in fabric 1. This is assigned either to the physical interface, the subinterface, or the SVI based on the choice that you made in the Routing interface type field in 1. Connect fabrics.

      The IP subnet should be unique (that is, it should not overlap with existing IP subnets of both the fabrics).

      Fabric 1 IPv6

      Fabric 2 IPv4

      Specifies the IP address assigned to the inter-fabric connection in fabric 2. This is assigned either to the physical interface, the subinterface, or the SVI based on the choice that you made in the Routing interface type field in 1. Connect fabrics.

      The IP subnet should be unique (that is, it should not overlap with existing IP subnets of both the fabrics).

      Fabric 2 IPv6

      IPv4 mask length

      Specifies the IPv4 mask or IPv6 prefix length.

      IPv6 prefix length

      Dot1q tag

      Displayed if you chose Subinterface in the Routing interface type field in 1. Connect fabrics.

      Specifies the 802.1Q tag assigned to the subinterface for this link (min:2, max:4093).

      MTU

      Shows the MTU configuration for the link.

      PIM

      Specifies whether PIM/PIMv6 is enabled on the interface in switch 1.

      For VXLAN fabrics, ensure that the corresponding fabric settings are enabled when enabling this setting:

      • Enable IPv4 Tenant Routed Multicast (TRM)

      • Enable IPv6 Tenant Routed Multicast (TRMv6)

      PIMv6

      Fabric 1 interface description

      Shows the interface description in the fabric 1 switch that is part of the link.

      Fabric 2 interface description

      Shows the interface description in the fabric 2 switch that is part of the link.

      VLAN ID

      Displayed if you chose SVI in the Routing interface type field in 1. Connect fabrics.

      Specifies the VLAN associated with the SVI in this L3Out.

      Switch1 netflow

      Specifies whether netflow is enabled on the interface in switch 1.

      For VXLAN fabrics, ensure that the corresponding fabric settings are enabled when enabling netflow-related options:

      Enable Netflow

      Switch1 netflow monitor

      Specifies the netflow monitor for the link in switch 1.

      Switch2 netflow

      Specifies whether netflow is enabled on the interface in switch 2.

      For VXLAN fabrics, ensure that the corresponding fabric settings are enabled when enabling netflow-related options:

      Enable Netflow

      Switch2 netflow monitor

      Specifies the netflow monitor for the link in switch 2.

  2. Determine the action to take for reachability configurations for this L3Out.

    • If you want to create a new link for this L3Out, go to Step 3.

    • If you want to edit the configuration of a link in this table, click the box next to that row to choose it and click Actions > Edit.

    • If you want to remove the configuration of a link in this table, click the box next to that row in the table to choose it and click Actions > Remove link from L3Out.

  3. Determine if you are adding an already-configured link or adding a new physical link.

    • If you are adding an already-configured link:

      1. Click Actions > Add link to configure.

      2. In the Add link to configure page, locate the link that you want to add.

        The table in the Add link to configure page displays all the discovered links.

      3. Click Add.

        You are returned to the Reachability configuration page with the link displayed in the table. Go to Step 4.

    • If you are creating a new link for this L3Out:

      1. Click Actions > Add physical link.

        The Add physical link page appears.

      2. In the Add physical link page, choose the switches and interfaces that is part of the link:

        Field Description

        Fabric 1

        Switch

        Choose the switch in fabric 1 that is part of the link.

        Interface

        Choose the interface in fabric 1 that is part of the link.

        Fabric 2

        Switch

        Choose the switch in fabric 2 that is part of the link.

        Interface

        Choose the interface in fabric 2 that is part of the link.

        MTU

        Enter the MTU configuration for the link.

        Speed

        Choose the speed for the link.

      3. Click Save.

        You are returned to the Reachability configuration page with the link displayed in the table.

        note.svg

        • Any links that you create in the Add physical link or Add link to configure page will remain as link policies in the system even if you cancel the L3Out creation. You can view, edit, or delete these link policies through Connectivity > Links.

        • If you want to add a link where one end is a meta switch, then add the link in Links (Connectivity > Links), outside of the L3Out workflow.

  4. Complete your configurations in the Reachability configuration page.

    • Repeat Step 3 to create additional links for this L3Out, if necessary.

    • When you have finished configuring links for this L3Out, click Next.

3. Peering and filters

The Peering and filters page is displayed only if you chose BGP in the Reachability protocol field in 1. Connect fabrics.

note.svg

IPv4 and/or IPv6 information will be displayed in the table based on the choice that you made in the IP version field.

  1. Make the necessary configurations in the Peering and filters page:

    Field Description

    General

    The following fields provide general configuration options that are applied to both fabrics in this L3Out.

    BGP authentication

    Put a check in the box to enable BGP authentication.

    note.svg

    If you enable this option in the L3Out, you must also enable the Enable BGP Authentication field in the fabric settings in the VXLAN fabrics that are part of this L3Out. See Editing Data Center VXLAN Fabric Settings for more information.

    BFD

    Put a check in the box to enable the BFD feature.

    note.svg

    If you enable this option in the L3Out, you must also enable the Enable BFD field in the fabric settings in the VXLAN fabrics that are part of this L3Out. See Editing Data Center VXLAN Fabric Settings for more information.

    BGP keep alive timer

    Specify the amount of time for the BGP keep alive timer. The value that you enter in the BGP keep alive timer field should be less than the value that you enter in the BGP hold timer field.

    BGP hold timer

    Specify the amount of time for the BGP hold timer. The value that you enter in the BGP hold timer field should be greater than the value that you enter in the BGP keep alive timer field.

    Fabric 1 settings and Fabric 2 settings

    The following fields are available under the Fabric 1 settings and Fabric 2 settings columns. The descriptions are identical but will apply to either fabric 1 or fabric 2, depending on which column you apply the settings in.

    BGP authentication key type

    Choose the BGP authentication key type to use for the fabric:

    • 3des

    • Cisco Type6

    • Cisco Type7

    Encrypted BGP authentication key

    Specify the Encrypted BGP authentication key to use for the fabric.

    Fabric IPv4/IPv6 route-map in

    Choose the IP route-map in to use for the fabric or click + Add route-map to create a new route-map (see Create a route-map for more information).

    Fabric IPv4/IPv6 route-map out

    Choose the IP route-map out to use for the fabric or click + Add route-map to create a new route-map (see Create a route-map for more information).

    Advertise default route (VXLAN fabric only)

    Field is enabled by default. Check the box to advertise the default route internally.

    Advertise host route (VXLAN fabric only)

    Check the box to advertise /32 and /128 host routes to the L3Out BGP peer.

    Configure static default route (VXLAN fabric only)

    Field is enabled by default. Check the box to enable the flag to automatically generate a static default route configuration.

    Soft-reconfiguration

    Choose the soft-configuration to use for the fabric:

    • Inbound always

    • Inbound

    • Disabled

    default-originate

    Check the box to originate a default route towards this peer. This advertises a default route (0.0.0.0/0) to a specific neighbor in the fabric, even if the router itself doesn’t have a default route in its routing table.

    Local ASN

    Choose the local ASN for the fabric if you want the router to appear as a different ASN to the L3Out BGP neighbor.

    no-prepend

    Check the box to prevent the real ASN from being prepended to the AS-path in the fabric.

    replace-as

    Available if the no-prepend option is checked above. Check the box to replace the private AS number from outbound updates. This prepends only the local-as number to update to the eBGP neighbor in the fabric.

    as-override

    Check the box to override the matching AS-number while sending updates. This replaces the neighbor ASN in the AS-path with the local ASN when advertising routes to that neighbor in the fabric.

    allowas-in

    Specify the number of times the local ASN can occur in the AS path. This allows the BGP router to accept routes that contain its own ASN in the AS-path, bypassing the BGP’s default loop prevention.

    disable-peer-as-check

    Check the box to disable the checking of the peer AS-number while advertising. This allows routers in the fabric to advertise routes even when the peer ASN is present in the AS-PATH.

    Log neighbor change

    Check the box to enable the BGP log neighbor change function.

  2. Click Next.

    Because you chose BGP in the Reachability protocol field in the 1. Connect fabrics step in the process, you advance to the Summary step in the process.

3. Fabric 1 routes

The Fabric 1 routes page is displayed only if you chose Static routes in the Reachability protocol field in 1. Connect fabrics.

  1. Review the existing fabric 1 routes displayed in the Fabric 1 routes page, if necessary.

    The existing fabric 1 routes are displayed with this information:

    Field Description

    Switch

    Shows the switch in fabric 1 used in this route.

    IP version

    Shows the IP version in fabric 1 used in this route.

    IP prefix/mask

    Shows the IPv4 prefix/mask in fabric 1 used in this route.

    Next hop address

    Shows the next hop address in fabric 1 used in this route.

    Route preference

    Shows the route preference in fabric 1 used in this route.

    Next hop name

    Shows the next hop name in fabric 1 used in this route.

    Routing tag

    Shows the routing tag in fabric 1 used in this route.

    Track object number

    Shows the track object number in fabric 1 used in this route. See Configure a track for more information.

    Next hop VRF

    Shows the next hop VRF in fabric 1 used in this route.

  2. Click Actions > Create to create a route for fabric 1.

    The Create Fabric 1 routes page appears.

  3. Make the necessary configurations in the Create Fabric 1 routes page:

    Field Description

    Switch

    Choose the switch to use in fabric 1 in this route.

    IP version

    Choose the IP version to use in fabric 1 in this route. Options are IPv4, IPv6, or both.

    IPv4 prefix/mask

    Field available if you chose IPv4 or both in the IP version field above.

    Enter the IPv4 prefix/mask to use in fabric 1 in this route.

    IPv6 prefix/mask

    Field available if you chose IPv6 or both in the IP version field above.

    Enter the IPv6 prefix/mask to use in fabric 1 in this route.

    Next hop address

    Enter the next hop address to use in fabric 1 in this route.

    Route preference

    Enter the route preference to use in fabric 1 in this route.

    Next hop name

    Enter the next hop name to use in fabric 1 in this route.

    Routing tag

    Enter the routing tag to use in fabric 1 in this route.

    Track object number

    Enter the track object number to use in fabric 1 in this route, where the static route is installed in the routing table only if the track is up. See Configure a track for more information before using this option.

    Next hop VRF

    Enter the next hop VRF to use in fabric 1 in this route.

  4. Click Add.

    You return to the Fabric 1 routes page.

    • If you want to create another route for fabric 1, click Actions > Create and repeat these steps.

    • If you are finished creating routes for fabric 1, click Next.

      You advance to the 4. Fabric 2 routes step in the process.

4. Fabric 2 routes

The Fabric 2 routes page is displayed only if you chose Static routes in the Reachability protocol field in 1. Connect fabrics.

  1. Review the existing fabric 2 routes displayed in the Fabric 2 routes page, if necessary.

    The existing fabric 2 routes are displayed with this information:

    Field Description

    Switch

    Shows the switch in fabric 2 used in this route.

    IP version

    Shows the IP version in fabric 2 used in this route.

    IP prefix/mask

    Shows the IPv4 prefix/mask in fabric 2 used in this route.

    Next hop address

    Shows the next hop address in fabric 2 used in this route.

    Route preference

    Shows the route preference in fabric 2 used in this route.

    Next hop name

    Shows the next hop name in fabric 2 used in this route.

    Routing tag

    Shows the routing tag in fabric 2 used in this route.

    Track object number

    Shows the track object number in fabric 2 used in this route. See Configure a track for more information.

    Next hop VRF

    Shows the next hop VRF in fabric 2 used in this route.

  2. Click Actions > Create to create a route for fabric 2.

    The Create Fabric 2 routes page appears.

  3. Make the necessary configurations in the Create Fabric 2 routes page:

    Field Description

    Switch

    Choose the switch to use in fabric 2 in this route.

    IP version

    Choose the IP version to use in fabric 2 in this route. Options are IPv4, IPv6, or both.

    IPv4 prefix/mask

    Field available if you chose IPv4 or both in the IP version field above.

    Enter the IPv4 prefix/mask to use in fabric 2 in this route.

    IPv6 prefix/mask

    Field available if you chose IPv6 or both in the IP version field above.

    Enter the IPv6 prefix/mask to use in fabric 2 in this route.

    Next hop address

    Enter the next hop address to use in fabric 2 in this route.

    Route preference

    Enter the route preference to use in fabric 2 in this route.

    Next hop name

    Enter the next hop name to use in fabric 2 in this route.

    Routing tag

    Enter the routing tag to use in fabric 2 in this route.

    Track object number

    Enter the track object number to use in fabric 2 in this route, where the static route is installed in the routing table only if the track is up. See Configure a track for more information before using this option.

    Next hop VRF

    Enter the next hop VRF to use in fabric 2 in this route.

  4. Click Add.

    You return to the Fabric 2 routes page.

    • If you want to create another route for fabric 2, click Actions > Create and repeat these steps.

    • If you are finished creating routes for fabric 2, click Next.

      You advance to the Summary step in the process.

Summary

  1. Review the information provided in the Summary page and verify that the information is correct for this L3Out.

    If any information is incorrect, click Back to navigate back to the necessary area to correct that information.

  2. If the information provided in the Summary page is correct for this L3Out, click Save.

    You are returned to the L3Outs page, with the newly-configured L3Out listed. Go to Attach an L3Out to attach the newly-configured L3Out, if necessary.

Edit an L3Out

To edit an L3Out:

  1. Navigate to the Routing policies page.

  2. Click the L3Outs subtab.

  3. Choose an L3Out from the configured L3Outs listed in the L3Outs page.

  4. Choose Actions > Edit.

  5. Make the necessary changes in the appropriate pages in the configured L3Out, then click Save.

Attach an L3Out

You must attach a configured L3Out for the configuration to be generated for the specified fabrics.

note.svg

For any VRFs that you associated with the L3Out, if you did not attach those VRFs while you configuring the L3Out, attaching the L3Out will automatically attach those VRFs as well.

To attach an L3Out:

  1. Navigate to the Routing policies page.

  2. Click the L3Outs subtab.

  3. Choose an L3Out from the configured L3Outs listed in the L3Outs page.

  4. Choose Actions > Attach.

    A Success routing-policy-name attached successfully message appears at the bottom right corner of the page.

Detach an L3Out

You must detach an L3Out before you can delete it.

To detach an L3Out:

  1. Navigate to the Routing policies page.

  2. Click the L3Outs subtab.

  3. Choose an L3Out from the configured L3Outs listed in the L3Outs page.

  4. Choose Actions > Detach.

    A Success routing-policy-name detached successfully message appears at the bottom right corner of the page.

Delete an L3Out

You must detach an L3Out before you can delete it. See Detach an L3Out for more information.

To delete an L3Out:

  1. Navigate to the Routing policies page.

  2. Click the L3Outs subtab.

  3. Choose an L3Out from the configured L3Outs listed in the L3Outs page.

  4. Detach the L3Out using the procedures in Detach an L3Out.

  5. Choose Actions > Delete.

  6. Click Confirm in the confirmation message to delete the L3Out.

Configure a track

In order to use the Track object number option, you must first configure a track using a freeform configuration. For more information, see "Enabling Freeform Configurations on Fabric Switches" in Configuring Switches for LAN and IPFM Fabrics.

You will see an error message similar to the following if you attempt to push the static route with a track without having configured a track first:

C01-BGW-1(config)# ip route 1.1.1.0/24 10.1.1.1 track 1 name test tag 12345
% Track object for object-id 1 associated with the route is not yet created, command rejected.

After configuring a track using a freeform configuration, you should see a message similar to the following, indicating that the operation was successful:

DC01-BGW-1(config)# track 1 ip route 10.1.1.1/24 reachability
DC01-BGW-1(config-track)# ip route 1.1.1.0/24 10.1.1.1 track 1 name test tag 12345
DC01-BGW-1(config)#
DC01-BGW-1(config)# sh track 1
Track 1
IP Route 10.1.1.1/24 Reachability
Reachability is DOWN
0 changes, last change never
Tracked by:
IPv4 Static Route 1

Route-maps

A route-map is a policy-based tool used to control and manipulate route redistribution, filtering, and policy application within a Nexus Dashboard fabric. Route-maps provide a flexible way to match specific conditions and apply actions to influence the behavior of routing protocols or traffic flows.

To view information about route-maps in your Nexus Dashboard:

  1. Navigate to the Routing policies page.

  2. Click the Route-maps subtab.

    Any already-configured route-maps are displayed with this information:

    Field Description

    Name

    Shows the name for that route-map.

    Type

    Shows the type of route-map.

    List items

    Shows the number of items that this route-map has. Each item under the route-map has an unique sequence number and one or more match/set rules.

    Associations

    Shows the number of L3Outs that the route-map is associated with.

  3. Configure a route-map, if necessary.

    These options are available to configure route-maps:

Create a route-map

To create a route-map:

  1. Navigate to the Routing policies page.

  2. Click the Route-maps subtab.

  3. Choose Actions > Create route-map.

  4. In the Create route-map page, enter a name for the route-map in the Name field.

  5. Review the existing route-map items, if necessary.

    Any already-configured route-map items are displayed with this information:

    Field Description

    Sequence number

    Shows the sequence number of the route-map item.

    Action

    Shows the action assigned to this route-map item.

    Route-map entries

    Shows the number of route-map entries in this route-map item.

  6. In the Route-map items area, click Actions > Add route-map item.

  7. In the Add route-map item page, enter the following information:

    1. In the Sequence number field, enter the sequence number.

    2. In the Action field, choose the action:

      • permit: The route-map permits set operations.

      • deny: The route-map denies set operations.

    3. In the Route-map entries area, click + Add route-map entry.

    4. In the Rule type field, choose the type:

      • Match: A match rule is a condition-based filter or selector that defines the criteria for identifying traffic or routes in a policy. See Match rules for the options available under Match.

      • Set: A set rule defines the actions to take when a route or traffic matches specific criteria (defined by a match rule). These actions typically involve modifying attributes such as metrics, next-hop addresses, route tags, or BGP communities. See Set rules for the options available under Set.

Match rules

  1. Choose Match as the Rule type.

  2. In the Rule area, choose the rule for your match rule.

    This table provides the information necessary to configure the different match rules.

    Match rule type Description Options

    match-ipv4-acl

    Used to evaluate and match IPv4 routes based on Access Control Lists (ACLs). These ACLs define specific matching criteria for IPv4 addresses or subnets, enabling you to filter or apply actions to routes that meet the specified conditions.

    In the Matched IPv4 Access-list Name field, choose an existing ACL or click + Create ACL to create a new one. See Create an ACL for more information.

    match-ipv6-acl

    Used to evaluate and match IPv6 routes based on Access Control Lists (ACLs). These ACLs define specific matching criteria for IPv6 addresses or subnets, enabling you to filter or apply actions to routes that meet the specified conditions.

    In the Matched IPv6 Access-list Name field, choose an existing ACL or click + Create ACL to create a new one. See Create an ACL for more information.

    match-ipv4-prefix-list

    Used to match IPv4 routes based on a prefix list. A prefix list is a collection of rules that specify which IPv4 address ranges (prefixes) should be matched or filtered. The match-ipv4-prefix-list statement enables you to apply routing policies that act on routes matching these prefixes.

    In the Matched IPv4 Prefix-list Names field, choose an existing prefix-list or click + Create prefix-list to create a new one. See Create a prefix-list for more information.

    match-ipv6-prefix-list

    Used to match IPv6 routes based on a prefix list. A prefix list is a collection of rules that specify which IPv6 address ranges (prefixes) should be matched or filtered. The match-ipv6-prefix-list statement enables you to apply routing policies that act on routes matching these prefixes.

    In the Matched IPv6 Prefix-list Names field, choose an existing prefix-list or click + Create prefix-list to create a new one. See Create a prefix-list for more information.

    match-community

    Used to evaluate and filter routes based on their BGP community attributes. This feature allows you to create routing policies that act on specific routes tagged with one or more BGP communities or patterns of communities.

    In the Matched Community-list Name field, choose an existing community-list or click + Create community-list to create a new one. See Create a community-list for more information.

    match-extcommunity

    Used to evaluate and filter routes based on their BGP extended community attributes. This feature allows you to create routing policies that act on routes tagged with specific BGP extended communities, which are 64-bit values providing additional granularity beyond standard 32-bit BGP communities.

    In the Matched Extended community-list Name field, choose an existing extended community-list or click + Create extended community-list to create a new one. See Create a community-list for more information.

    match-tag

    Used to evaluate and filter routes based on their route tags. A route tag is a numeric identifier applied to routes, often used for marking or categorizing routes for specific policy actions, such as filtering, redistribution, or prioritization.

    In the Matched Tag Values field, enter the appropriate match tag values.

  3. Click Save.

    You are returned to the Add route-map item page.

  4. Make additional configurations in the Add route-map item page, if necessary.

    • If you want to create another route-map entry, click + Add route-map entry.

    • If you want to delete the route-map entry that you’ve already created, click Delete in that route-map entry area.

    • If you are finished adding the route-map list item, click Save.

      You are returned to the Create route-map page, with the newly-created route-map list item listed.

  5. Make additional configurations in the Create route-map page, if necessary.

    • If you want to create another route-map item, click Actions > Add route-map item.

    • If you want to edit an existing route-map item, choose the route-map item and click Actions > Edit.

    • If you want to delete an existing route-map item, choose the route-map item and click Actions > Delete.

    • If you are finished creating or editing route-map items, click Save.

      You are returned to the Route-maps page.

Set rules

  1. Choose Set as the Rule type.

  2. In the Rule area, choose the rule for your set rule.

    This table provides the information necessary to configure the different set rules.

    Set rule type Description Options

    set-community

    Used to modify the BGP community attributes of routes. This action allows you to tag routes with specific BGP community values during routing operations, which can then be used for filtering, prioritization, traffic engineering, or other routing policies.

    In the Community Numbers in ASN2:NN Format field, enter the appropriate set-community values in the ASN:NN format.

    set-extcomm-list

    Used to modify the BGP extended community attributes of routes by removing specific extended communities. It works by referencing a predefined extended community list and applying the action to the selected routes that match the conditions of the route map.

    In the ExtCommunity Name to Delete field, choose the extended commmunity-list to delete or click + Create extended community-list to create a new one. See Create a community-list for more information.

    set-ip-next-hop

    set-ipv6-next-hop

    Used to modify the next-hop IP address of a route. This action enables you to redirect traffic by specifying a new next-hop IP address for packets matching certain conditions defined in the route map. It is a critical feature for implementing advanced routing policies, such as policy-based routing (PBR), traffic engineering, or route redistribution.

    In the Parameters area, make these configurations:

    1. Next Hop Addresses: Enter the next hop addresses to be used in this set rule.

      You can enter multiple comma-separated next-hops in this field.

    2. Put a check in the box for one or more of these options, if necessary:

      • Drop on Failure

      • Enable Load Sharing

      • Force Order

      • Verify Availability

      • Use Peer Address

      • Redistribute Unchanged

      • Unchanged

    3. In the Track ID field, enter a track ID, if necessary. See Configure a track for more information.

    set-local-preference

    Used to modify the BGP local preference (LocalPref) attribute of routes. The local preference is a well-known BGP path selection attribute used to influence outbound traffic by determining which path is preferred for sending traffic out of an Autonomous System (AS). The higher the local preference value, the more preferred the route.

    In the Preference Value field, enter the appropriate preference value.

  3. Click Save.

    You are returned to the Add route-map item page.

  4. Make additional configurations in the Add route-map item page, if necessary.

    • If you want to create another route-map entry, click + Add route-map entry.

    • If you want to delete the route-map entry that you’ve already created, click Delete in that route-map entry area.

    • If you are finished adding the route-map list item, click Save.

      You are returned to the Create route-map page, with the newly-created route-map list item listed.

  5. Make additional configurations in the Create route-map page, if necessary.

    • If you want to create another route-map item, click Actions > Add route-map item.

    • If you want to edit an existing route-map item, choose the route-map item and click Actions > Edit.

    • If you want to delete an existing route-map item, choose the route-map item and click Actions > Delete.

    • If you are finished creating or editing route-map items, click Save.

      You are returned to the Route-maps page.

Edit a route-map

To edit a route-map:

  1. Navigate to the Routing policies page.

  2. Click the Route-maps subtab.

  3. Choose a route-map from the configured route-maps listed in the Route-maps page.

  4. Choose Actions > Edit.

  5. Make the necessary changes in the appropriate pages in the configured route-map, then click Save.

Delete a route-map

To delete a route-map:

  1. Navigate to the Routing policies page.

  2. Click the Route-maps subtab.

  3. Choose a route-map from the configured route-maps listed in the Route-maps page.

  4. Choose Actions > Delete.

ACLs

An Access Control List (ACL) is an ordered set of rules that you can use to filter traffic. Each rule specifies a set of conditions that a packet must satisfy to match the rule.

To view information about ACLs in your Nexus Dashboard:

  1. Navigate to the Routing policies page.

  2. Click the ACLs subtab.

    Any already-configured ACLs are displayed with this information:

    Field Description

    Name

    Shows the name of the ACL. Click the link in the Name column to display information for this ACL.

    Type

    Shows the type of ACL.

    Entries

    Shows the number of entries in this ACL.

    Associations

    Shows the number of associations in this ACL.

  3. Configure an ACL, if necessary.

    These options are available to configure ACLs:

Create an ACL

To create a route-map:

  1. Navigate to the Routing policies page.

  2. Click the ACLs subtab.

  3. Choose Actions > Create ACL.

  4. Enter a name for the access control list in the Name field.

  5. In the Type field, choose IPv4 or IPv6.

  6. Review the existing access-list entries, if any are already configured.

    Any already-configured access-list entries are displayed with this information:

    Field Description

    Sequence number

    Shows the sequence to insert to or delete from the existing access-list.

    Action

    Shows the action that this access-list entry will take:

    • permit

    • deny

    • remark

    IP protocol/options

    Shows the IP protocol/option:

    • TCP

    • ICMP

    • IP

    • UDP

    • EIGRP

    • OSPF

    • PIM

    • IGMP

    • Custom: Provide the value for the Custom Protocol Number when choosing this option.

      • You must provide a protocol number between 0-255.

      • You cannot use the following reserved protocol numbers for the Custom Protocol Number:

        • IPv4: 0, 1, 2, 6, 17, 47, 50, 51, 88, 89, 94, 103, 108

        • IPv6: 1 ,6, 17, 41, 50, 51, 88, 103, 108

    Source port match operator

    Shows the source port match operator:

    • equalTo

    • greaterThan

    • lessThan

    • notEqualTo

    • portRange

    • none

    Source port

    Shows the source port.

    Source port range start

    Shows the port range start.

    Source port range end

    Shows the source port range end.

    Source address

    Shows the source IP address.

    Destination port match operator

    Shows the destination port match operator:

    • equalTo

    • greaterThan

    • lessThan

    • notEqualTo

    • portRange

    • none

    Destination port

    Shows the destination port.

    Destination port range start

    Shows the destination port range start.

    Destination port range end

    Shows the destination port range end.

    Destination address

    Shows the destination IP address.

    TCP session rules

    Shows the TCP session rule:

    • ack

    • fin

    • established

    • psh

    • rst

    • syn

    ICMP options

    Shows the ICMP option:

    • Administratively Prohibited

    • Echo

    • Echo Reply

    • General Parameter Problem

    • Host Isolated

    • Host Precedence Unreachable

    • Host Redirect

    • Host Tos Unreachable

  7. In the Access-list entries area, click Actions > Create ACL entry.

  8. In the Create ACL entry page, enter the following information:

    Field Description

    Sequence number

    Enter the sequence to insert to the existing access-list entry. Valid value is between 1-4294967295.

    Action

    Enter the action that this access-list entry will take:

    • permit

    • deny

    • remark

    IP protocol/options

    Choose the IP protocol/option:

    • TCP

    • ICMP

    • IP

    • UDP

    • EIGRP

    • OSPF

    • PIM

    • IGMP

    • Custom: Provide the value for the Custom Protocol Number when choosing this option.

      • You must provide a protocol number between 0-255.

      • You cannot use the following reserved protocol numbers for the Custom Protocol Number:

        • IPv4: 0, 1, 2, 6, 17, 47, 50, 51, 88, 89, 94, 103, 108

        • IPv6: 1 ,6, 17, 41, 50, 51, 88, 103, 108

    Source port match operator

    Displayed if you chose TCP or UDP as the IP protocol/option.

    Choose the source port match operator:

    • equalTo

    • greaterThan

    • lessThan

    • notEqualTo

    • portRange

    • none

    Source port

    Displayed if you chose TCP or UDP as the IP protocol/option and any option other than portRange as the Source port match operator.

    Enter the source port. It must be a valid port number (0-65535) or service name.

    Examples of valid entries include:

    bgp|chargen|cmd|daytime|discard|domain|drip|echo|exec|finger|ftp|ftp-data|gopher|hostname|ident|irc|klogin|kshell|login|lpd|nntp|pim-auto-rp|pop2|pop3|smtp|sunrpc|tacacs|talk|telnet|time|uucp|www|([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])

    Source port range start

    Displayed if you chose TCP or UDP as the IP protocol/option and portRange as the Source port match operator.

    Enter the source port range start. It must be a valid port number (0-65535) or service name.

    Examples of valid entries include:

    bgp|chargen|cmd|daytime|discard|domain|drip|echo|exec|finger|ftp|ftp-data|gopher|hostname|ident|irc|klogin|kshell|login|lpd|nntp|pim-auto-rp|pop2|pop3|smtp|sunrpc|tacacs|talk|telnet|time|uucp|www|([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])

    Source port range end

    Displayed if you chose TCP or UDP as the IP protocol/option and portRange as the Source port match operator.

    Enter the source port range end. It must be a valid port number (0-65535) or service name.

    Examples of valid entries include:

    bgp|chargen|cmd|daytime|discard|domain|drip|echo|exec|finger|ftp|ftp-data|gopher|hostname|ident|irc|klogin|kshell|login|lpd|nntp|pim-auto-rp|pop2|pop3|smtp|sunrpc|tacacs|talk|telnet|time|uucp|www|([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])

    Source address

    Displayed if you chose any option other than TCP or UDP as the IP protocol/option.

    Enter the source IP address. Source IP address must be either:

    • any

    • A valid IPv4 address, preferably with CIDR (for example, 192.168.1.1, 10.0.0.0/8)

    • A valid IPv6 address, preferably with CIDR (for example, 2001:db8::1, 2001:db8::/32)

    Destination port match operator

    Displayed if you chose TCP or UDP as the IP protocol/option.

    Choose the destination port match operator:

    • equalTo

    • greaterThan

    • lessThan

    • notEqualTo

    • portRange

    • none

    Destination port

    Displayed if you chose TCP or UDP as the IP protocol/option and any option other than portRange as the Source port match operator.

    Enter the destination port. It must be a valid port number (0-65535) or service name.

    Examples of valid entries include:

    bgp|chargen|cmd|daytime|discard|domain|drip|echo|exec|finger|ftp|ftp-data|gopher|hostname|ident|irc|klogin|kshell|login|lpd|nntp|pim-auto-rp|pop2|pop3|smtp|sunrpc|tacacs|talk|telnet|time|uucp|www|([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])

    Destination port range start

    Displayed if you chose TCP or UDP as the IP protocol/option and any option other than portRange as the Destination port match operator.

    Enter the destination port range start. It must be a valid port number (0-65535) or service name.

    Examples of valid entries include:

    bgp|chargen|cmd|daytime|discard|domain|drip|echo|exec|finger|ftp|ftp-data|gopher|hostname|ident|irc|klogin|kshell|login|lpd|nntp|pim-auto-rp|pop2|pop3|smtp|sunrpc|tacacs|talk|telnet|time|uucp|www|([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])

    Destination port range end

    Displayed if you chose TCP or UDP as the IP protocol/option and any option other than portRange as the Destination port match operator.

    Enter the destination port range end. It must be a valid port number (0-65535) or service name.

    Examples of valid entries include:

    bgp|chargen|cmd|daytime|discard|domain|drip|echo|exec|finger|ftp|ftp-data|gopher|hostname|ident|irc|klogin|kshell|login|lpd|nntp|pim-auto-rp|pop2|pop3|smtp|sunrpc|tacacs|talk|telnet|time|uucp|www|([0-9]|[1-9][0-9]{1,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])

    Destination address

    Displayed if you chose any option other than TCP or UDP as the IP protocol/option.

    Enter the destination IP address. Destination IP address must be either:

    • any

    • A valid IPv4 address, preferably with CIDR (for example, 192.168.1.1, 10.0.0.0/8)

    • A valid IPv6 address, preferably with CIDR (for example, 2001:db8::1, 2001:db8::/32)

    TCP flags

    Displayed if you chose TCP as the IP protocol/option.

    Choose the TCP session rule:

    • ack

    • fin

    • established

    • psh

    • rst

    • syn

    ICMP options

    Displayed if you chose ICMP as the IP protocol/option.

    Choose the ICMP option.

    • If you chose IPv4 in the Type field, these options are available:

      Beyond Scope, Destination Unreachable, Echo Request, Echo Reply, Hop Limit, Mid Query, Mid Report, Mid Reduction, Mldv2, Nd Ns, Nd Na, No Admin, No Route, Packet Too Big, Parameter Problem, Port Unreachable, Reassembly Timeout, Router Advertisement, Router Solicitation, Unreachable

    • If you chose IPv6 in the Type field, these options are available:

      Administratively Prohibited, Echo, Echo Reply, General Parameter Problem, Host Isolated, Host Precedence Unreachable, Host Redirect, Host Tos Unreachable, Host Unknown, Host Unreachable, Net Unreachable, Network Unknown, Option Missing, Packet Too Big, Parameter Problem, Port Unreachable, Router Advertisement, Router Solicitation, TTL Exceeded, Unreachable
    note.svg

    Nexus Dashboard will perform checks on certain options and will not allow you to continue if the necessary information is not provided in those options.

  9. Click Save.

    You are returned to the Create ACL page.

  10. Verify that the information displayed for the newly-created access control list is correct, then click Save.

    You are returned to the ACLs page.

Edit an ACL

To edit an ACL:

  1. Navigate to the Routing policies page.

  2. Click the ACLs subtab.

  3. Choose an ACL from the configured ACLs listed in the ACLs page.

  4. Choose Actions > Edit.

  5. Make the necessary changes in the appropriate pages in the configured ACL, then click Save.

Delete an ACL

To delete an ACL:

  1. Navigate to the Routing policies page.

  2. Click the ACLs subtab.

  3. Choose an ACL from the configured ACLs listed in the ACLs page.

  4. Choose Actions > Delete.

Prefix-list

A prefix list is a mechanism to define and manage IP address ranges or prefixes. These lists are primarily employed for configuring network policies, such as route filtering, access control, or traffic redirection in the Nexus Dashboard fabric.

To view information about prefix-lists in your Nexus Dashboard:

  1. Navigate to the Routing policies page.

  2. Click the Prefix-list subtab.

    Any already-configured prefix-lists are displayed with this information:

    Field Description

    Name

    Shows the name of the prefix-list. Click the link in the Name column to display information for this prefix-list.

    Type

    Shows the type of prefix-list.

    Entries

    Shows the number of entries in this prefix-list.

    Associations

    Shows the number of associations in this prefix-list.

  3. Configure a prefix-list, if necessary.

    These options are available to configure prefix-lists:

Create a prefix-list

To create a prefix-list:

  1. Navigate to the Routing policies page.

  2. Click the Prefix-list subtab.

  3. Choose Actions > Create prefix-list.

  4. Enter a name for the prefix-list in the Name field.

  5. In the Type field, choose IPv4 or IPv6.

  6. In the Description field, enter a description for the prefix-list, if necessary.

  7. In the Prefix-list entries area, click Actions > Create prefix-list entry.

  8. In the Create prefix-list entry page, enter the following information:

    Field Description

    Sequence number

    Enter the sequence to insert to the existing prefix-list entry. Valid value is between 1-4294967294.

    Action

    Enter the action that this prefix-list entry will take:

    • permit

    • deny

    Prefix

    Enter the IP prefix network/length (for example, 192.168.1.0/24).

    Exact prefix length

    Enter the exact prefix length to be matched.

    Minimum prefix length

    Enter the minimum prefix length to be matched.

    Maximum prefix length

    Enter the maximum prefix length to be matched.

    Explicit match mask

    Enter the mask that specifies the bits of a prefix address in a prefix-list that are compared to, in format A.B.C.D.

  9. Click Save.

    You are returned to the Create prefix-list page.

  10. Verify that the information displayed for the newly-created prefix-list entry is correct, then click Save.

    You are returned to the Prefix-list page.

Edit a prefix-list

To edit a prefix-list:

  1. Navigate to the Routing policies page.

  2. Click the Prefix-list subtab.

  3. Choose a prefix-list from the configured route-maps listed in the Prefix-list page.

  4. Choose Actions > Edit.

  5. Make the necessary changes in the appropriate pages in the configured prefix-list, then click Save.

Delete a prefix-list

To delete a prefix-list:

  1. Navigate to the Routing policies page.

  2. Click the Prefix-list subtab.

  3. Choose a prefix-list from the configured route-maps listed in the Route-maps page.

  4. Choose Actions > Delete.

  5. In the Warning message that pops up, click Confirm.

About community lists and extended community lists

Under Routing policies in Nexus Dashboard, there are two types of community-lists available:

  • Community-lists

  • Extended community-lists

The primary difference between community lists and extended community lists lies in the type of attributes they match and how they are used in BGP (Border Gateway Protocol) routing policies.

Here’s a detailed comparison:

Key differences between community-lists and extended community lists

Feature

Community lists

Expanded community lists

Purpose

Match standard BGP community attributes, which are 32-bit values used to tag routes for filtering, redistribution, or prioritization.

Match extended BGP community attributes, which are 64-bit values providing additional tagging capabilities for more advanced use cases, such as VPN route targets, QoS, or Site-of-Origin (SOO).

Attribute size

Operate on 32-bit community attributes. Examples: 65000:100 or 100:1.

Operate on 64-bit extended community attributes. Examples: RT:65000:100 (Route Target) or SOO:65000:200 (Site-of-Origin).

Use cases

Used for general route tagging and filtering based on standard BGP community values.

Examples: Route prioritization, route filtering, or marking routes to influence path selection.

Used for more complex scenarios requiring additional tagging information.

Examples: MPLS VPNs (to match Route Targets), Site-of-Origin tagging, QoS policies, traffic engineering.

Types

  • Standard community lists: Match exact 32-bit community values.

  • Expanded community lists: Match patterns of 32-bit community values using regex.

  • Standard extended community lists: Match exact 64-bit extended community values.

  • Expanded extended community lists: Match patterns of 64-bit extended community attributes using regex.

Flexibility

Limited to matching standard 32-bit communities, which are less flexible for complex scenarios.

Provide greater flexibility due to their ability to match 64-bit extended communities and support advanced use cases like MPLS VPNs or SOO tagging.

Refer to these sections for configuration procedures for each of these types of community-lists:

Community-list

Community-lists are used to define and group Border Gateway Protocol (BGP) community attributes. These attributes allow you to tag and group routes in a BGP environment, enabling more granular control over how routes are distributed, filtered, or prioritized within the Nexus Dashboard fabric or between external networks.

In Nexus Dashboard, standard community lists and expanded community lists are two types of BGP community lists used to manage and filter routes based on their BGP community attributes. The primary difference lies in the way they match community attributes and their flexibility.

Key differences between standard and expanded community lists
Feature Standard Community Lists Expanded Community Lists

Matching method

Matches specific BGP community values exactly.

Matches BGP community values using regular expressions (regex).

Flexibility

Less flexible; only exact matches are supported.

More flexible; can match patterns or ranges of community values.

Examples of usage

Useful for simple, predefined community tags.

Useful for more complex scenarios where multiple patterns need to be matched.

Configuration simplicity

Easier to configure, as it only requires the exact value.

More complex configuration due to the use of regex.

To view information about standard or expanded community-lists in your Nexus Dashboard:

  1. Navigate to the Routing policies page.

  2. Click the Community-list subtab.

    Any already-configured community-lists are displayed with this information:

    Field Description

    Name

    Shows the name of the community-list. Click the link in the Name column to display information for this community-list.

    Type

    Shows the type of community-list.

    Entries

    Shows the number of entries in this community-list.

    Associations

    Shows the number of associations in this community-list.

  3. Configure a community-list, if necessary.

    These options are available to configure community-list:

Create a community-list

To create a community-list:

  1. Navigate to the Routing policies page.

  2. Click the Community-list subtab.

  3. Choose Actions > Create community-list.

  4. Enter a name for the community-list in the Name field.

  5. In the Type field, choose standard or expanded.

    The information displayed in the Create community-list page, and the create action, varies depending on the type of community-list that you choose.

Create standard community-list entry

  1. Review the existing standard community-list entries, if any are already configured.

    Any already-configured standard community-list entries are displayed with this information:

    Field Description

    Sequence number

    Shows the sequence to insert to the existing community-list entry.

    Action

    Shows the action that this community-list entry will take:

    • permit

    • deny

    No-advertise

    Shows if the No-advertise option is enabled.

    Blackhole

    Shows if the Blackhole option is enabled.

    No-export

    Shows if the No-export option is enabled.

    Internet

    Shows if the Internet option is enabled.

    Graceful shutdown

    Shows if the Graceful shutdown option is enabled.

    Local-As

    Shows if the Local-As option is enabled.

    Community numbers

    Shows the community numbers, in the ASN:NN format.

  2. In the Standard community-list entries area, click Actions > Create standard community-list entry.

  3. In the Create standard community-list entry page, enter the following information:

    Field Description

    Sequence number

    Enter the sequence to insert to the existing community-list entry. Valid value is between 1-4294967294.

    Action

    Enter the action that this community-list entry will take:

    • permit

    • deny

    No-advertise

    Put a check in the box to not advertise to any peer.

    Blackhole

    Put a check in the box to enable the blackhole option.

    BGP blackhole routing is a destination-based packet filtering technology that uses the Border Gateway Protocol (BGP) to “advertise” or communicate a blackhole route for a specific IP address to other routers within the BGP network.

    note.svg

    The blackhole option is supported on switches running NX-OS 10.3(2) or later.

    No-export

    Put a check in the box to not export to next AS.

    Internet

    Put a check in the box to enable the internet option.

    Graceful shutdown

    Put a check in the box to signal the graceful shutdown of paths. Use this community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately (for example, for planned maintenance).

    Local-As

    Put a check in the box to not send outside local AS.

    Community numbers

    Enter the community numbers, in the ASN:NN format.

  4. Click Save.

    You are returned to the Create community-list page.

  5. Verify that the information displayed for the newly-created community-list entry is correct, then click Save.

    You are returned to the Community-list page.

Create expanded community-list entry

  1. Review the existing expanded community-list entries, if any are already configured.

    Any already-configured expanded community-list entries are displayed with this information:

    Field Description

    Sequence number

    Shows the sequence to insert to the existing expanded community-list entry.

    Action

    Shows the action that this expanded community-list entry will take:

    • permit

    • deny

    Community number REGEX

    Shows the community number REGEX value.

  2. In the Expanded community-list entries area, click Actions > Create expanded community-list entry.

  3. In the Create expanded community-list entry page, enter the following information:

    Field Description

    Sequence number

    Enter the sequence to insert to the existing expanded community-list entry. Valid value is between 1-4294967294.

    Action

    Enter the action that this expanded community-list entry will take:

    • permit

    • deny

    Community number REGEX

    Enter the community number regular-expression (REGEX) in aa:nn format.

  4. Click Save.

    You are returned to the Create community-list page.

  5. Verify that the information displayed for the newly-created community-list entry is correct, then click Save.

    You are returned to the Community-list page.

Edit a community-list

To edit a community-list:

  1. Navigate to the Routing policies page.

  2. Click the Community-list subtab.

  3. Choose a community-list from the configured community-lists shown in the Community-list page.

  4. Choose Actions > Edit.

  5. Make the necessary changes in the appropriate pages in the configured community-list, then click Save.

Delete a community-list

To delete a community-list:

  1. Navigate to the Routing policies page.

  2. Click the Community-list subtab.

  3. Choose a community-list from the configured community-lists shown in the Community-list page.

  4. Choose Actions > Delete.

  5. In the Warning message that pops up, click Confirm.

Extended community-list

Extended community lists are used to match BGP extended community attributes, which provide additional tagging and control over BGP routes. Extended communities are an enhancement to the standard BGP communities, and offer more flexibility and granularity in applying routing policies.

Extended communities are 64-bit values (compared to the 32-bit community attributes) that allow for more complex route tagging. They are commonly used in scenarios such as:

  • VPN route target (RT) attributes in MPLS Layer 3 VPNs.

  • Route origin information.

  • Site-of-origin (SOO) tagging to prevent routing loops.

  • Traffic engineering or QoS policies.

Similar to community lists as described in Community-list, extended community lists can be of two types:

  • Standard extended community lists:

    • Matches specific extended community values exactly.

    • Best suited for scenarios where you know the exact extended community attributes.

  • Expanded extended community lists:

    • Uses regular expressions (regex) to match patterns of extended community attributes.

    • Useful when dealing with ranges or subsets of extended communities.

To view information about extended community-lists in your Nexus Dashboard:

  1. Navigate to the Routing policies page.

  2. Click the Extended community-list subtab.

    Any already-configured extended community-lists are displayed with this information:

    Field Description

    Name

    Shows the name of the extended community-list. Click the link in the Name column to display information for this community-list.

    Type

    Shows the type of extended community-list.

    Entries

    Shows the number of entries in this extended community-list.

    Associations

    Shows the number of associations in this extended community-list.

  3. Configure an extended community-list, if necessary.

    These options are available to configure extended community-lists:

Create an extended community-list

To create an extended community-list:

  1. Navigate to the Routing policies page.

  2. Click the Extended community-list subtab.

  3. Choose Actions > Create extended community-list.

  4. Enter a name for the extended community-list in the Name field.

  5. In the Type field, choose standard or expanded.

    The information displayed in the Create community-list page, and the create action, varies depending on the type of community-list that you choose.

Create standard extended community-list entry

  1. Review the existing standard extended community-list entries, if any are already configured.

    Any already-configured standard extended community-list entries are displayed with this information:

    Field Description

    Sequence number

    Shows the sequence to insert to the existing standard extended community-list entry.

    Action

    Shows the action that this standard extended community-list entry will take:

    • permit

    • deny

    Router MAC list

    Shows the router MAC list.

    Route target list

    Shows the route target list.

    Site-of-Origin list

    Shows the site-of-origin list.

    Transitive generic extended community

    Shows the transitive generic extended community.

    Non-transitive generic extended community

    Shows the non-transitive generic extended community.

  2. In the Standard extended community-list entries area, click Actions > Create standard extended community-list entry.

  3. In the Create standard extended community-list entry page, enter the following information:

    Field Description

    Sequence number

    Enter the sequence to insert to the existing standard extended community-list entry. Valid value is between 1-4294967294.

    Action

    Enter the action that this standard extended community-list entry will take:

    • permit

    • deny

    Router MAC list

    Enter a comma-separated router MAC list. For example:

    d478:111.57b8, d478.1111.2222

    Route target list

    Enter a comma-separated route target list. For example:

    1:2, 2:2

    Site-of-Origin list

    Enter a comma-separated site-of-origin list. For example:

    11:12, 15:15

    Transitive generic extended community

    Enter the transitive generic extended community. For example:

    12:22

    Non-transitive generic extended community

    Enter the non-transitive generic extended community. For example:

    10:10, 11:11

  4. Click Save.

    You are returned to the Create extended community-list page.

  5. Verify that the information displayed for the newly-created extended community-list entry is correct, then click Save.

    You are returned to the Extended community-list page.

Create expanded extended community-list entry

  1. Review the existing expanded extended community-list entries, if any are already configured.

    Any already-configured expanded extended community-list entries are displayed with this information:

    Field Description

    Sequence number

    Shows the sequence to insert to the existing expanded extended community-list entry.

    Action

    Shows the action that this expanded extended community-list entry will take:

    • permit

    • deny

    Community number REGEX

    Shows the community number REGEX value.

  2. In the Expanded extended community-list entries area, click Actions > Create expanded extended community-list entry.

  3. In the Create expanded extended community-list entry page, enter the following information:

    Field Description

    Sequence number

    Enter the sequence to insert to the existing expanded extended community-list entry. Valid value is between 1-4294967294.

    Action

    Enter the action that this expanded extended community-list entry will take:

    • permit

    • deny

    Community number REGEX

    Enter the community number regular-expression (REGEX) in aa:nn format.

  4. Click Save.

    You are returned to the Create extended community-list page.

  5. Verify that the information displayed for the newly-created extended community-list entry is correct, then click Save.

    You are returned to the Extended community-list page.

Edit an extended community-list

To edit an extended community-list:

  1. Navigate to the Routing policies page.

  2. Click the Extended community-list subtab.

  3. Choose an extended community-list from the configured extended community-lists listed in the Extended community-list page.

  4. Choose Actions > Edit.

  5. Make the necessary changes in the appropriate pages in the configured extended community-list, then click Save.

Delete an extended community-list

To delete an extended community-list:

  1. Navigate to the Routing policies page.

  2. Click the Extended community-list subtab.

  3. Choose an extended community-list from the configured extended community-lists listed in the Extended community-list page.

  4. Choose Actions > Delete.

  5. In the Warning message that pops up, click Confirm.

Inter-Fabric

To work with inter-fabric connectivity in a fabric:

  1. Navigate to the Connectivity page.

  2. Click the Inter-Fabric tab.

    A page showing the information for previously-configured inter-fabric connections appears.

The following table describes the fields that appear on the Inter-Fabric tab.

Field Description

Status

Provides one of the following states as the status of the inter-fabric connections:

  • Connected

  • Degraded

  • Failed

Physical Links

Shows how many physical links in the inter-fabric connections are are up or down.

Overlay BGP Peers

Shows how many overlay BGP peers in the inter-fabric connections are are up or down.

Overlay Tunnels

Shows how many overlay tunnels in the inter-fabric connections are are up or down.

Fabric Type

Shows the fabric types used in the inter-fabric connections.

L3 Neighbors

Nexus Dashboard provides a unified view of all L3Outs and their neighbors in your fabric. This information provides visibility into operational data reported by the fabrics controller about fabric-level connectivity and simplifies troubleshooting by showing the various Layer 3 adjacencies (neighbors) for each L3Out.

Use the L3 Neighbors page to view L3 neighbors for this fabric. You can filter the results based on neighbor, local switch, routing protocol, VRF, and operational status. OSPF and OSPFv3 support includes OSPF and OSPFv3 statistics, operational statistics, interface statistics, and neighbor statistics. Click the IP address in the Neighbor column to view details on this neighbor.

Nexus Dashboard updates information on this page in real-time upon modification or change of the properties.

View L3 neighbors in a fabric

Follow these steps to view L3 neighbors in a fabric.

  1. Navigate to the Connectivity page.

  2. Click the L3 Neighbors tab.

    A page showing the information for previously-configured L3 neighbors appears.

    The L3 Neighbors page provides a unified view of all neighbors based on L3Out configuration for that fabric in tabular format. You can Filter or sort the table based on each column.

  3. Click an entry in the Neighbor column to view that neighbor’s details.

    Here, you can view the Local Switch information (including its name, IP address, ASN, interface information, and so forth) and Neighbor Details (such as its IP address, ASN, route ID, port, and so forth).

    For example, the following figure shows sample information for BGP L3Out neighbors:

    l3-neighbors-bgp.jpg

  4. If the displayed information is not accurate, verify L3Out configurations.

    If the L3Out neighbors are not present in the table view:

    • Verify that the L3Out policy is configured in Nexus Dashboard and deployed successfully. The information is displayed only for L3Outs that are configured in Nexus Dashboard.

    • Verify that the L3Out neighbors are present in Nexus Dashboard’s inventory using the APIs.

      • For BGP: GET /mso/api/v1/inventorybgpneighbors?status.fabric=<fabric-id>

      • For OSPF: GET /mso/api/v1/inventoryospfneighbors?status.fabric=<fabric-id>

    If the L3Out neighbors' operational state is not green:

    • Verify that the switch interfaces are not in the shut state on either of the switches.

    • Verify that the protocol settings are configured correctly and there is no mismatch in the peer device configuration.

      • For BGP, check the authentication, eBGP MultiHop TTL, and ASN are configured correctly.

      • For OSPF, check authentication, Area ID, and MTU configurations.

Guidelines and limitations for L3 neighbors

These guidelines and limitations apply for L3 neighbors:

  • In an NX-OS fabric, OSPFv3 is supported on switches with the Cisco NX-OS 10.5.x release and later.

  • Up to 20 GUI sessions at one time can see real-time updates. You must close one of the previous sessions for a new session to be able to see real-time updates.

Endpoints

The Endpoints page provides information on the endpoints for this fabric. You can filter the results based on MAC address, IP addresses, hostname, anomaly level, interface, status, VRF instance, Layer 3 switches, and Layer 3 interfaces.

Nexus Dashboard updates the information on this page in real-time upon modification or change of the properties.

View endpoints in a fabric

Follow these steps to view endpoints in a fabric.

  1. Navigate to the Connectivity page.

  2. Click the Endpoints tab.

    A page showing the information for previously-configured endpoints appears.

  3. Click a MAC address in the MAC column to get the following additional information on that endpoint:

    • Overview

      • General

        • VM Name

        • Hypervisor

        • MAC Address

        • IP Address

        • Hostname

        • Last Updated

        • Status

      • Network Configuration

        • Tenant

        • VRF

        • EPG/L3 Out

        • BD

        • Encap

      • Connected To

        • Nodes

        • Interface

    • Endpoint history — Determine how you want to show endpoint history. The time range for the history is only based on the time selector chosen at the fabric level.

    • Anomalies

You can also click the IP address or the hostname (if clickable) to view additional information about them.

Guidelines and limitations for endpoints

  • Endpoint page updates can take up to 60 seconds and therefore are not always in real-time.

  • A maximum of 20 GUI sessions can view real-time updates simultaneously. To enable a new session to access real-time updates, you must close one of the previous sessions.

Routes

The Routes page provides information on the routes for this fabric. You can filter the results based on route, protocol, VRF instance, or next hop.

Nexus Dashboard updates information on this page in real-time upon modification or change of the properties.

View routes in a fabric

Follow these steps to view routes in a fabric.

  1. Navigate to the Connectivity page.

  2. Click the Routes tab.

    A page showing the information for previously-configured routes appears.

  3. Choose whether you want to view the details for IPv4, IPv6, or multicast routes.

View IPv4 or IPv6 routes

Click the IPv4 or IPv6 vertical tab.

  • Click Download to download any route table from the last 7 days.

  • You can filter the table based on route, protocol or VRF.

  • The Routes per VRF graph shows the number of routes per VRF for the top 10 VRFs.

  • The Change Summary helps view the number of the added, modified, and deleted routes. Click Change Summary to list all the routes which have had modified or deleted change made in a tabular form.

  • The Routes table displays information such as route, node name, protocol, VRF, and Next Hop. The Routes table only displays 10,000 route table entries and 10,000 history events. The Routes table always shows the current route table irrespective of the time range selected.

  • Click on any route listed to view General and Route History view along with the timeline for the change. The General page list of all the next hops available for that route. The Route History page shows detail of last 50 route events. The route history events shows deleted or modified events. Route add events are shown under modified routes category.

  • Each Next Hop IP address is subscripted with the node name and interface where it is configured.

  • Click View Details in the routing page banner to list any unsupported nodes, inactive nodes, switch connection, failure and if data is inconsistent for the selected time range.

Guidelines and limitations for routes

These guidelines and limitations apply for routes:

  • Routes information for NX-OS switches is updated in real-time.

  • A maximum of 20 GUI sessions can view real-time updates simultaneously. To enable a new session to access real-time updates, you must close one of the previous sessions.

Multicast routes

In the multicast dashboard, you can view the following multicast route information for an NX-OS fabric:

  • Top groups by traffic

  • Top groups by receivers

Prerequisites for multicast routes

Execute the following commands on the Nexus switch:

switch(config)# hardware profile multicast flex-stats-enable

switch(config)# multicast flow-path export

switch(config)# copy running-config startup-config

switch(config)# reload
note.svg

You must execute the commands copy running-config startup-config and reload for the changes to take effect.

Guidelines and limitations for multicast routes

These guidelines and limitations apply for multicast routes.

  • Multicast routing analytics is supported on Cisco NX-OS release 10.4(1)F and later for VXLAN and 10.3(3)F and later for classic LAN.

  • Multicast routing analytics is supported for Classic VLAN and VXLAN fabrics.

  • Multicast routing analytics is only supported for IPv4 addresses.

  • Supported scale limits per fabric: 2000 multicast groups, 16000 S,G entries, 8K routed interfaces.

  • When First Hop Router for multicast or the multicast source is configured outside the fabric, multicast routes are not displayed in the GUI.

View multicast routes

Follow these steps to view multicast routes.

  1. Navigate to the Connectivity page.

  2. Click the Routes tab.

  3. Click the Multicast vertical tab.

  4. In the Multicast area, you can view the information such as multicast groups, sources sending to this group, sending rate per source, number of receivers for this group, and VRF instances.

  5. Click a multicast group to view additional information for sources and receivers.

    1. Click Overview to view information such as multicast underlay group information for all tenant routed multicast sources, and trend graphs showing the sender traffic rate, sender packet rate, and number of receivers. The Overview displays by default.

    2. Click Sources to view information such as source IP address, switch name, and interface.

    3. Click Receivers to view information such as switch name,receiver count, uptime, and L3 interface.

  6. Click a Sources entry to view the list of all source IP addresses for that multicast group.

    1. Click one of the source IP addresses in the list to view additional information about that source.

Flows

Flows provides deep insights at a flow level giving details such as average latency and packet drop indicator. It also raises anomalies when the latency of the flows increase or when packets get dropped because of congestion or forwarding errors.

Each flow has a packet counter representing the number of packets entering the ASIC for that flow over a period of time. This period of time is called aggregation interval. There are several points where flow statistics for a given flow can be aggregated. Aggregation can happen in the ASIC, switch software, and server software.

The Flows section of Nexus Dashboard displays the telemetry information collected from various devices in the fabric that were added to the fabric.

For details on Flow Telemetry support for Cisco Nexus series switches and line cards, see the "Compatibility Information" section in the Nexus Dashboard Release Notes.

Flows hardware requirements

For details on Flow Telemetry support for Cisco Nexus platform switches, see the "Compatibility Information" section in the Nexus Dashboard Release Notes.

Flows guidelines and limitations for NX-OS fabrics

For details on Flow Telemetry hardware support, see the "Compatibility Information" section in the Nexus Dashboard Release Notes.

  • Output port information for outgoing traffic from N9K-C93180YC-EX, N9K-C93108TC-EX, and N9K-C93180LC-EX line cards will not be displayed.

  • Flows does not support multicast traffic. The access list must be provisioned to exclude the multicast traffic flows.

  • A maximum of 63 VRFs are supported on flow telemetry nodes.

  • The number of anomalies in the Fabric Overview dashboard will not match the number of anomalies in the flow browse page. The Fabric Dashboard contains the total anomaly count for the time range you selected. The flow records are not aggregated in the flow browse view, where multiple flow records can point to the same anomaly entry.

  • The L3-VNI flows show as L2-VNI flows when the VXLAN flow is dropped in the ingress node. When VXLAN packets are dropped in the first-hop, the exported VXLAN flow telemetry records will indicate the drop. However, they don’t carry the VNI information in it. The Ingress interface from the flow telemetry export along with the VRF associated with the interface, does not deduce if the flow is L2-VNI or L3-VNI. In this case Nexus Dashboard associates the L2-VNI for the flow.

  • When a VXLAN encapsulated packet enters an Cisco Nexus 9500-EX switch and feature overlay (EVPN) is configured, the packet will be treated like a VXLAN transit node packet. Also the ingress interface and egress interface are set as zeros in the flow telemetry export. The ingress and egress interfaces are needed to consider this record for flows. The limitation on these switches results in the Cisco Nexus 9500-EX switch not being considered in the path stitching and correlation if the switch is in ingress, transit, or egress direction. Cisco Nexus 9500-EX switches will be treated like a transit node for an overlay packet.

  • For Nexus Dashboard to work in VXLAN deployments, you must have symmetric configuration on the switches involved in the overlay. This enables Nexus Dashboard to correlate and stitch the overlay flows. When such a symmetric configuration is not present, the VXLAN feature and forwarding will work, but Nexus Dashboard will not stitch the flows correctly. See the following examples to understand what is meant by symmetric configuration on switches:

    • For Layer 2 VXLAN VNI cases: If vlan-x is mapped VNI-A in PE1, then the same vlan-x must be mapped to VNI-A in PE2, where PE1 and PE2 are VTEP endpoints for the Layer 2 overlay.

    • For Layer 3 VXLAN VNI cases: If SVI-x is mapped to VRF-A mapped VNI-P on PE1, then the same SVI-x must be mapped to VRF-A mapped VNI-P in PE2, where PE1 and PE2 are VTEP end points for the Layer 3 overlay.

  • The ingress and VRF information will not be shown for all interfaces which use the flow telemetry 'tenant-id' for encoding the logical interface ID, as this ID will be used for 'overlay-id'. It’s not possible to derive the logical interface (SVI with trunk port, sub interface, SVI with trunk and port channel) and get the VRF associated with it. This results in the flow browse page and details page not showing the ingress and egress VRFs.

  • On the Cisco Nexus 9500-EX switches connected to VPC pair, the current design limits in identifying the ingress leaf nodes between VPC pairs causing the loss of flow in Nexus Dashboard.

  • When there are 29 million anomalies in the indices, flow database writes are too slow, which causes KAFKA lag on 350 nodes supported for software telemetry and flow telemetry. The KAFKA lag results in partial data in Nexus Dashboard user interface.

  • Flows information is retained for 7 days or until flow database reaches 80%, which ever happens first, then older flows information is deleted from the database.

  • Flow telemetry and flow telemetry events will not export drop bit if there is an egress ACL drop in Cisco Nexus FX switches.

  • For Nexus Dashboard to receive Flow Telemetry data, the TCAM region for ing-netflow must be set to 512. See Nexus 9000 TCAM Carving.

  • For flows, if the time range you have selected is greater than 6 hours, the data may not get displayed. Select a time range that is less than or equal to 6 hours.

  • When the scale limit for anomalies is reached, some of the unhealthy flows may not be displayed as anomalies in the Flow Record Details page. A system issue is raised when this condition happens. Navigate to Admin > System Settings > System Issues to view the system issue.

  • For Layer 4 to Layer 7 Services only intra VRF is supported for flows. For Layer 4 to Layer 7 Services inter VRF is not supported for flows.

  • Multicast is not supported for Flow Telemetry.

  • When traffic flows through sub-interfaces, in the Flow Record Details page, sub-interface is displayed only in the ingress direction in the Flow Path area. In the egress direction the parent interface is displayed.

  • For unicast routes in Flow Telemetry, Layer 4 to Layer 7 Services traffic path visibility is supported on Cisco Nexus 9300 -GX2 and -FX3 platform switches.

  • Configuring Netflow on a switch before onboarding a Standalone NX-OS fabric on Nexus Dashboard and then enabling Flow Telemetry on the corresponding fabric from Nexus Dashboard could lead to anomalies being generated for incorrect configurations being pushed to the switch.

    To resolve the issue, perform the following steps:

    1. Remove switch from the Standalone NX-OS fabric.

    2. Use the command no feature netflow to remove Netflow from the switch.

    3. Add the switch back to the Standalone NX-OS fabric.

    4. Enable Flow Telemetry.

  • When Flow Telemetry is disabled while one of the switches is unreachable, the fabric goes into the Disable Failed state. This is expected behavior. Following this condition, when the switch becomes available and you enable Flow Telemetry, the ACL configurations get corrupted.

    We recommend either of these workarounds:

    • When this condition occurs and the fabric is in a Disable Failed state, retry the switch that is in this state. This will trigger the ACL to unconfigure successfully. Thereafter, when you enable the fabric, start a disable acl job to clean any existing ACLs in the switch.

    • If you have already enabled Flow Telemetry without cleaning the existing ACLs in the switch, then perform these actions:

      1. Disable Flow Telemetry and then enable it.

      2. Remove the switch that has the issue from the DCNM fabric and add it back in the fabric.

Extending flows to Cisco ACI tier-3 topologies in Nexus Dashboard

Flows implements 3-tier topology where a second tier of leaf nodes are connected to first tier of leaf nodes. In the 3-tier topology when flow packet traverses from one host to the other using multiple tiers, before they reach the destination host, the packet becomes an iVXLAN packet when it traverses through a tier-1 leaf node.

Guidelines and limitations

  • The Cisco APIC Release 4.2(4o) does not support a leaf node exporting flow telemetry in case of iVXLAN packet, resulting in an incomplete flow path and inadequate information to stitch together all the flows.

View flows

The Flows page displays telemetry information collected from various devices in an online fabric. The Flows records let the user visualize the flows per fabric. For a particular fabric, you can view flows by Anomaly Score, Packet Drop Indicator, and Average Latency.

The flows engine also runs machine-learning algorithms on the behavior of the flows to raise anomalies in the behavior, such as average latency and packet drop indicator. The graph represents the anomalies in the behavior over a period of time.

Flow telemetry and analytics gives in-depth visibility of the data plane. Flows collects the flow records streamed from the nodes and converts to understandable EPG-based flow records. Top nodes by flow anomalies displays the nodes in the network with the most anomalies.

note.svg

To view flow details, you must first enable flows.

  1. Click Manage > Fabrics, then click on the appropriate fabric.

  2. Click Actions > Edit Fabric Settings.

  3. Under General, verify that the Telemetry option is enabled in the Enabled features area.

  4. Under Telemetry, verify that the Flow telemetry option is enabled in the Mode area.

To view flows:

  1. Navigate to Connectivity > Flows.

  2. Select a time range.

  3. In the Fabric Flows by area select an option from the drop-down list to view flows by Anomaly Score, Packet Drop Indicator, and Average Latency. The graph displays a time series plot for flows properties recorded in the entire fabric. The flows recorded for Top Sources and Top Destinations are also displayed.

    Anomaly Score—The score is based on the number of detected anomalies logged in the database.

    Packet Drop Indicator—The flow records are analyzed for drops. The primary method of detecting drops is based on the drop bit received from the switch (flow records).

    Average Latency—The time taken by a packet to traverse from source to destination in the fabric. A prerequisite for fabric latency measurement is that all the nodes shall be synchronized with uniform time.

  4. The Flows table displays information such as anomaly score, flow record time, nodes, flow type, protocol, latency, packet drop indicator.

  5. Use the search bar to filter the flows. The Flows table displays the filtered flows. Click the column heading to sort the flows in the table.

  6. Click Record Time to view the flow record details. The details include record time, flow type, aggregated flow information, ingress and egress information, flow path, anomalies, and trends for average latency, traffic, packet drop indicator, bursts.

Layer 4 to Layer 7 services traffic path visibility

You have expanded visibility in the Flow Path to Layer 4 to Layer 7 services external devices such as firewalls. Nexus Dashboard tracks the end-to-end flow across the service chain in real-time and helps locate data plane issues across the device silos. A non-NAT environment across all third-party vendors is supported.

For Layer 4 to Layer 7 services traffic path visibility, your flow telemetry must be enabled and the appropriate rules must be configured.

  1. Click Manage > Fabrics, then click on your fabric.

  2. Click Actions > Edit Fabric Settings.

  3. Under General, verify that the Telemetry option is enabled in the Enabled features area.

  4. Under Telemetry > Flow Collection, verify that the Flow telemetry option is enabled in the Mode area.

Based on your rules, if the flow is passing through Policy Based Redirects (for example, a firewall), it will display that information in the flow path.

View Layer 4 to Layer 7 services traffic path visibility

Follow these steps to view Layer 4 to Layer 7 services traffic path visibility.

  1. Navigate to Manage > Fabrics.

  2. Select Online Fabrics from the drop-down list.

  3. Click a fabric name to view the fabric details.

  4. Navigate to Connectivity > Flows.

  5. Select a time range.

  6. In the flows table, click Record Time to view the flow record details.

    In the Path area, a graphical flow path will display the end-to-end information, from source to destination, and it will also identify the firewall in the path if a firewall is present. The graph also captures the end-to-end flow path network latency that is occurring. In the graph, if there are any anomalies, a red dot is displayed next to the symbol for the leaf switch or the spine switch.

  7. Click Anomalies in the Flow Details page to view further details related to the anomaly.

note.svg

In the current release firewalls are not supported for anomalies.

Guidelines and limitations for Layer 4 to Layer 7 services traffic path visibility

These guidelines and limitations are for Layer 4 to Layer 7 services traffic path visibility.

  • This feature is currently recommended only if policy-based redirect can be configured using the service graph for a Cisco ACI fabric or Layer 4 to Layer 7 services for an NX-OS fabric.

  • In the current release, firewalls are not supported for anomalies.

  • In the current release, the latency information that is being displayed is the network latency, and it does not capture the latency that is occurring in the firewall.

  • In the current release, NAT is not supported.

  • This feature is currently supported if you use these switches:

    • Cisco Nexus 9300-FX Platform Switches

    • Cisco Nexus 9300-FX2 Platform Switches

    • Cisco Nexus 9300-FX3 Platform Switches

    • Cisco Nexus 9300-GX Platform Switches

  • Policy-based redirect destinations on L3Out are not supported because such configurations use an internal VRF because of which only a partial flow path would be available.

  • In a Cisco ACI fabric, when the Layer 4 to Layer 7 services traffic is forwarding in Layer 2 (bridged mode), the flow analytics support is limited. Ingress and egress nodes detection is not accurate, and path summary is not available.

  • The service node displays as unknown for Layer 4 to Layer 7 traffic path visibility.

  • Without a service graph for Layer 4 to Layer 7 services, if the client > service node is VRF_A and the service node > server is VRF_B, the paths will be recorded as separate flows as there is no common or single contract to stitch the flows.

  • Load balancers are not supported.

Flow telemetry events

Flow telemetry events are enabled implicitly when flow telemetry is enabled, and on NX-OS fabrics flow rules are configured. The flow telemetry enables triggering events when a configured rule is met, where packets are exported to the collector for analysis.

Flow telemetry events enhance and complement current flows in Nexus Dashboard. They enrich anomaly generation for flow telemetry and flow telemetry events.

It monitors security, performance, and troubleshooting. This is achieved using the periodic flow table event records exported every second.

The data export to Nexus Dashboard is done directly from the hardware without control plane needing to handle the data. Statistics are assembled as a packet with a configurable MTU size and a defined header. These packets are sent as in-band traffic from the fabric. Headers are configured by software, and packets streamed are UDP packets.

When flow telemetry is available for a triggered flow telemetry event, then you can navigate to flow details page for aggregated information. These events are based on the following drop events:

  • Cisco ACL Drop—In an NX-OS fabric, when packet hits sup-tcam rules and the rule is to drop the packet, the dropped packet is counted as ACL_Drop and it will increment the forward drop counter. When this occurred, it usually means the packet is about to be forwarded against basic Cisco ACI forwarding principals. The sup-tcam rules are mainly to handle some exceptions or some of control plane traffic and not intended to be checked or monitored by users.

  • Buffer Drop—When the switch receives a frame and there are no buffer credits available for either ingress or egress interface, the frame is dropped with buffer. This typically hints at a congestion in the network. The link that is showing the fault could be full or the link containing the destination may be congested. In this case a buffer drop is reported in flow telemetry events.

  • Forward Drop—The packets that are dropped on the LookUp block (LU) of the Cisco ASIC. In a LU block a packet forwarding decision is made based on the packet header information. If the packet is dropped, forward drop is counted. There may be a variety of reasons when forward drop is counted.

  • RTO Inside—In a Cisco ACI fabric, when a TCP retransmission happens for a flow due to a drop inside the fabric, an RTO inside anomaly is raised. This anomaly is aggregated across flows based on ingress node.

  • RTO Outside—In a Cisco ACI fabric, when a flow experiences TCP retransmission, but there is no drop inside the fabric for that flow, then an RTO outside anomaly is raised. This anomaly is aggregated across flows based on ingress node.

Flow telemetry events compared to flow telemetry

  • The flow telemetry event packets are exported only when configured events occur, whereas flow telemetry packets are streamed continuously.

  • The flow telemetry events are captured for all traffic, where as flow telemetry is captured for filtered traffic.

  • The total number of collectors between flow telemetry and flow telemetry events is 256.

Guidelines and limitations for flow telemetry events

  • In a standalone NX-OS fabric, flow telemetry event anomalies are aggregated. For example, a packet drop anomaly occurred from time T0 to T1. No packet drop anomaly occurred from time T1 to T2. Another packet drop anomaly occurred from time T2 to T3. Although there is no anomaly from T1 to T2, the time stamp for the aggregated packet drop anomalies is from T0 to T3.

  • The flow telemetry events do not report policing drop anomalies in Nexus Dashboard, when the egress data plane policer is configured on front-panel ports and there is traffic drop.

  • To export flow telemetry events on FX platform switches, you must configure flow telemetry filters. In a Cisco ACI fabric, starting with Cisco ACI-Mode Switch release 16.0(3), FX switches export flow telemetry events to indicate only buffer drops experienced by flows without the need to configure flow telemetry filters.

  • Standalone NX-OS fabrics do not support TCP packet RTO anomalies.

Navigate to the Flows page

To navigate to the Flows page:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

The Flows tab includes the following subtabs:

Flow Status

To navigate to the Flow Status page:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Flow Status subtab.

Generic multicast flow status

Cisco Nexus Dashboard allows you to view the flow status pictorially and statistically.

Generic multicast flow status

In the generic multicast mode, the switch reports the receiver interface IP address instead of the receiver endpoint IP address. This IP is displayed in the Flow Status and Topology pages as a host. In the Sender and Receiver fields, the IPs are suffixed with a blue dot and the word Remote to indicate that those IPs are remote hosts. Also, as there’s no policing of the traffic, switch reports only display allowed bytes/packets and not denied bytes/packets.

Multicast Traffic Conversion
Field Description

MUNAT

Specifies that the multicast traffic at the egress interface is converted to unicast traffic at the receiver interface.

Umcat

Specifies that the received multicast traffic at the egress interface is converted into unicast traffic at the sender interface.

  1. Click the Unicast or Multicast link in the Receiver or the Sender Interface columns to view the IP route table for this interface.

  2. Click the active link in the Flow Link State column to view the details for a given flow such as all pre or post multicast and source IP-addresses, post group, post S/DST ports, pre/post NAT policy ID, starting and destination node details, as well as view the topology for a particular multicast IP.

    In VXLAN TRM, sources and receivers associated with an overlay flow are in a customer, also known as a tenant VRF. This tenant traffic is encapsulated in an underlay header that has Encap Source and Encap Group (located in the default VRF) on the sender VTEP side. The underlay encapsulated flow then reaches the receiver VTEP and is decapsulated here.

    The flow topology in Nexus Dashboard shows the overlay and underlay parts of the flow in different colors (purple for the underlay and green for the overlay).

    Separation Between Default and Tenant VRFs
    Field Description

    Type

    Specifies the name of the virtual routing and forwarding (VRF).

    L3VNI

    Specifies the tenant VNI.

    Encap Source

    Specifies the IP address of the encapsulated source from the default VRF.

    Encap Group

    Specifies the IP address of the encapsulated group from the default VRF.

  3. Click on the Telemetry Sync Status link above the table on the top-right corner.

    The Telemetry Sync Status page displays the sync status and the IP address of the telemetry collector for each switch, along with the timestamp at the last sync.

  4. To view the load on each telemetry collector, use the Telemetry Collector == <IP address of the collector> filter.

    You can balance the collector performance based on the flows it is currently handling.

Flow Policies

Use this window to configure the flow policies.

To navigate to the Flow Policies page:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Flow Policies subtab.

note.svg

When you log in to Nexus Dashboard with a network operator role, all the buttons or options to add, delete, modify, import, export, or deploy policies are disabled. This user can only view policies, and deployment status or history.

The default policies are displayed on the Flow Policies tab. By default, the bandwidth of these policies is 0. You can configure the bandwidth such that any flow that matches the default flow policy will accordingly use the bandwidth and QOS/DSCP parameters. The policy is deployed to all the devices when you save the configuration.

note.svg

When you undeploy a default policy, it will be reset to default values, that is, Bandwidth:0gbps, DSCP:Best Effort, and Policer:Enabled.

Policies are automatically deployed to switches whenever they are created, edited, or imported. You can choose to undeploy or redeploy the policies, by choosing the appropriate actions in the Actions drop-down list. The policies will not be deployed correctly if the device is rebooting while the policy was deployed. In such case, the Failed message appears in the Deployment Status column.

The default flow policies must be deployed successfully to the switch before you deploy the custom flow policies on that switch. Otherwise, the custom policies will fail to deploy. Ensure that you deploy all default policies successfully to all the switches before you add, edit, import, or deploy custom policies.

note.svg

If you have created a custom or non-default VRF, although the host and flow policies are automatically created for the VRF, use the action options in this window to manually deploy the flow policies to the switches in the fabric.

The following table describes the fields that appear on this page.

Flow Policies Table Field and Description
Field Description

VRF

Specifies the name of the VRF for the flow policy.

Policy Name

Specifies the flow policy name.

Multicast IP Range

Specifies the multicast IP address for the traffic. Click view to view the details such as starting and ending IP addresses of the multicast range as well as the flow priority in the Multicast Range List box.

Bandwidth

Specifies the bandwidth that is allotted for the traffic.

QoS/DSCP

Specifies the Switch-defined QoS Policy.

Deployment Action

Specifies the action that is performed on the switch for that host policy.

  • Create - The policy is deployed on the switch.

  • Delete - The policy is undeployed from the switch.

Deployment Status

Specifies if the flow policy is deployed successfully, not deployed, or failed.

In Use

Specifies if the flow policy is in use or not.

Policer

Specifies whether the policer for a flow policy is enabled or disabled.

note.svg

In adding or editing a flow policy, the default policer state is Enabled.

Last Updated

Specifies the date and time at which the flow policy was last updated.

The format is Day MMM DD YYYY HH:MM:SS Timezone.

Click the table header to sort the entries in alphabetical order of that parameter.

The following table describes the action items, in the Actions drop-down list, that appears in the Flow Policies horizontal tab on the Flows tab in the Fabric Overview window.

note.svg

A new flow policy or an edited flow policy is effective only under the following circumstances:
- If the new flow matches the existing flow policy.
- If the flow expires and reforms, while the new policy is already created or edited, that matches with the flow policy.

Flow Policies Actions and Description
Field Description

Create flow policy

Allows you to create a new flow policy. For more information, see Create a flow policy.

Edit flow policy

Allows you to view or edit the selected flow policy parameters.

note.svg

The default flow policies must be deployed successfully to the switch before you deploy the custom flow policies on that switch. Otherwise, the custom policies will fail to deploy. Ensure that you deploy all default policies successfully to all the switches before you edit custom policies.

To edit a flow policy for a VRF, select the check box next to the VRF and choose Edit flow policy action. In the Edit flow policy window, you can make the required changes and click Save & Deploy to deploy the changes or click Cancel to discard the changes.

The deployment completed message appears at the bottom of the window. You can click Refresh to refresh the current deployment status in the window or click View Details to verify the deployment details.

Delete flow policy

Allows you to delete the user-defined flow policy.

note.svg

  • You cannot delete the default flow policies.

  • Undeploy policies from all switches before deleting them from Nexus Dashboard.

  • You can select more than one flow policy to delete.

To delete a flow policy, select the check box next to that VRF and choose the Delete flow policy action. A warning message appears asking you to undeploy policies from the switches. Click Confirm to proceed with deletion and leave the policies on the switches or click Cancel to discard the delete operation.

Purge

Allows you to delete all the flow policies at a single instance.

note.svg

Undeploy policies from all switches before deleting them from Nexus Dashboard.

To delete all flow policies, choose the Purge action. A warning message appears asking you to undeploy policies from all the switches. Click Confirm to proceed with deletion and leave the policies on the switches or click Cancel to discard the delete operation.

Import

Allows you to import flow policies from a csv file.

note.svg

The default flow policies must be deployed successfully to the switch before you deploy the custom flow policies on that switch. Otherwise, the custom policies will fail to deploy. Ensure that you deploy all default policies successfully to all the switches before you import custom policies.
After import, all policies imported from a csv file are applied to all managed switches automatically.

To import the flow policies, choose the Import action. Browse the directory and select the .csv file that contains the flow policy configuration information. The policy will not be imported if the format in the .csv file is incorrect. Click Open. The imported policies are automatically deployed to all the switches in the fabric.

Export

Allows you to export flow policies to a csv file.

To export the flow policies, choose the Export action. Select a location on your local system directory to store the flow policy details file. Click Save. The flow policy file is exported to your local directory. The file name is appended with the date on which the file is exported. The format of the exported file is .csv.

Deploy selected policies

Select this option to deploy only the selected policies to the devices. You can deploy other policies when required.

Select one or more check boxes next to the policy name. Select this option to deploy selected policies to the switch.

Deploy all custom policies

Select this option to deploy all the custom or user-defined policies at a single instance.

The policies are deployed even if the switch is rebooting. In such case, the deployment fails and a status message Failed appears in the Deployment Status column.

Deploy all default policies

Select this option to deploy all default policies to the switch.

Undeploy Selected Policies

Select this option to undeploy the selected policies.

To undeploy the selected policies, select one or more check boxes next to the VRFs. Select this option from the drop-down list to undeploy the selected policies.

Undeploy All Custom Policies

Select this option to undeploy all the custom or user-defined policies at a single instance.

Undeploy All Default Policies

Select this option to undeploy all the default policies at a single instance.

Redo All Failed Policies

The deployment or undeployment of policies may fail due to various reasons. Select this option to deploy all the failed policies.

All the deployments that failed on switches previously will be deployed again to only those switches. All the undeployments that failed on switches previously will be undeployed again from only those switches.

Deployment History

Select this option to view the deployment history of the selected policy for the switch in the Deployment History pane.

The Deployment History pane displays the following fields:

  • Policy Name - Specifies the selected policy name.

  • VRF - Specifies the VRF for the selected policy.

  • Switch Name - Specifies the name of the switch that the policy was deployed to.

  • Deployment Status - Displays the status of deployment. It shows if the deployment was a success, failed, or not deployed. Click on the deployment status, for example, Success, to see more details. For more information about the deployment status, see Deployment Status.

  • Action - Specifies the action that is performed on the switch for that flow policy.

    • Create - Implies that the policy has been deployed on the switch.

    • Delete - Implies that the policy has been undeployed from the switch.

  • Deployment Date/Time - Specifies the date and time at which the host policy was last updated. The format is Day MMM DD YYYY HH:MM:SS Timezone .

  • Failed Reason - Species why the policy was not successfully deployed.
Deployment Status

The following table describes the fields that appear on the Deployment Status page.

Deployment Status Field and Description
Field Description

Policy Name

Specifies the name of the flow policy.

VRF

Specifies the name of the VRF.

Switch Name

Specifies the switch on which the VRF is deployed.

IP Address

Specifies the IP address of the switch.

Deployment Status

Displays the status of the deployment. It shows if the deployment was a Success or Failed along with the reason why the deployment failed.

Action

Specifies the action that is performed on the switch, for example, Create.

Deployment Date/Time

Displays the date and time when the deployment was initialized.
Create a flow policy
note.svg

The default host policies must be deployed successfully to the switch before you deploy the custom host policies on that switch. Otherwise, the custom policies will fail to deploy. Ensure that you deploy all the default policies successfully to all the switches before you add custom policies.

To create a flow policy from Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Flow Policies subtab.

  4. Click Actions > Create flow policy.

    The Create flow policy window is displayed.

  5. In the Create flow policy window, specify the parameters in the following fields.

    • VRF — Click the Select a VRF link to open the Select a VRF window. The default VRF is also listed in the window. Search and select a VRF for the host and click Save.

      note.svg

      • Policy names can be repeated across VRFs, that is, they are unique only within a VRF.

      • Across the VRF, host policies may be same or different.

      • Sequence number for the host policies is per VRF

    • Policy Name — Specify a unique policy name for the flow policy.

    • Bandwidth — Specifies the bandwidth that is allocated for the flow policy. Select of the radio buttons to choose Gbps, Mbps, or Kbps.

  6. From the QoS/DSCP drop-down list, choose an appropriate ENUM value.

  7. Click the Policer check box to enable or disable policer for a flow.

  8. In Multicast IP Range, enter the beginning IP and ending IP Address for the multicast range in the From and To fields. The valid range is between 224.0.0.0 and 239.255.255.255.

    From the Flow Priority drop-down list, choose the priority for the flow. You can choose either Default or Critical. The default value is Default.

    The flow priority is used during the following scenarios:

    • Error Recovery - Unicast Routing Information Base (URIB) reachability changes on flows, and a re-Reverse-path forwarding (RPF) is being performed. When a set of existing flows is retried, the recovery starts from the flows with Critical priority.

    • Flow Retry - When pending flows are retried, the Critical priority flows are retried first.

    Actions - Actions has a variety of icons to perform various actions. Click the tick mark icon if you have entered the correct details; if not, click the check mark icon to add the multicast range to the policy. Click the edit icon if you want to modify the details or click the bin icon to delete the row. Click the Plus (+) mark to add another row.

  9. Click Save & Deploy to deploy the new policy or click Cancel to discard the changes. The deployment completed message appears at the bottom of the window. You can click Refresh to refresh the current deployment status in the window or click View Details to verify the deployment details.

Flow Alias

Use this tab to configure flow alias.

To navigate to the Flow Alias page:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Flow Alias subtab.

Using the Flow Alias feature, you can specify names for multicast groups. The multicast IP addresses are difficult to remember, thus by assigning a name to the multicast IP address, you can search and add policies based on the name.

The following table describes the fields that appear in this window.

Flow Alias Table Field and Description
Field Description

VRF

Specifies the VRF for the flow alias.

Policy Name

Specifies the policy name.

Multicast IP Range

Specifies the multicast IP address for the traffic.

Description

Description added to the flow alias.

Last Updated

Specifies the date on which the flow alias was last updated.

The following table describes the action items, in the Actions drop-down list, that appears in the Flow Alias horizontal tab on the Flows tab of the Fabric Overview window.

Flow Alias Actions and Description
Action Item Description

Create flow alias

Allows you to create a new flow alias. For instructions about creating a new flow alias, see Create a flow alias.

Edit flow alias

Allows you to view or edit the selected flow alias parameters.

To edit the flow alias, select the check box next to the flow alias that you want to delete and choose Edit flow alias. In the Edit flow alias window, edit the required values and click Submit to apply the changes or click Cancel to discard the flow alias. The edited flow alias is shown in the table in the Flow Alias window.

Delete flow alias

Allows you to delete the flow alias.

To delete a flow alias, select the check box next to the flow alias that you want to delete and choose Delete flow alias. You can select multiple flow alias entries and delete them at the same instance.

Import

Allows you to import flow aliases for devices in the fabric.

To import flow aliases, choose Import. Browse the directory and select the .csv file that contains the flow IP address and corresponding unique flow name information. Click Open. The flow aliases are imported and displayed in the Flow Alias window.

Export

Allows you to export flow aliases for devices in the fabric.

To export a flow alias, choose Export. Select a location on your local system directory to store the flow aliases configuration from Nexus Dashboard and click Save. The flow alias configuration file is exported to your local directory. The file name is appended with the date and time at which the file was exported. The format of the exported file is .csv.
Create a flow alias

To create a flow alias from the Cisco Nexus Dashboard:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Flow Alias subtab.

  4. On the Flow Alias page, click Actions > Create flow alias.

  5. On the Create flow alias page, enter the following:

    note.svg

    All the fields are mandatory.

    • VRF — Select the VRF from this drop-down list. The default value is default.

      note.svg

      Host and IP Address are unique per VRF, that is, same host name with the same IP Address can exist in multiple VRFs.

    • Flow Name — Enter a fully qualified unique flow name for identification of the flow alias.

    • Multicast IP Address — Enter the multicast IP address for the flow alias.

    • Description — Enter a description for the flow alias.

  6. Click Submit to apply the changes.

    Click Cancel to discard the flow alias.

    The new flow alias is shown in the table on the Flow Alias page.

Static Flow

You configure a static receiver using the Static Flow window. Use the Select an Option field to select a switch before creating a static flow for it.

To navigate to the Static Flow page:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Static Flow subtab.

Static Flow Actions and Description
Field Description

Create static flow

Allows you to create a static flow. For more information, see Create a static flow.

Delete static flow

Allows you to delete the static flow.Select a static flow that you need to delete and click the Delete static flow action to delete the selected static flow.
Static Flow Table Field and Description
Field Description

VRF

Specifies the VRF for a static flow.

Group

Specifies the group for a static flow.

Source

Specifies the source IP address for the static flow.

Interface Name

Specifies the interface name for the static flow. If it is not specified while creating the static flow, it is displayed as N/A.

Deployment Action

Specifies the action that is performed on the switch for the rule. Create implies that the static flow has been deployed on the switch. Delete implies that the static flow has been undeployed from the switch.

Deployment Status

Specifies if the static flow is deployed or not. If there is a deployment failure, hover over the information icon to view the failure reason.

Last Updated

Specifies the date and time at which the static flow was last updated.The format is Day MMM DD YYYY HH:MM:SS Timezone.
Create a static flow
Before you begin:

Choose a switch in the Static Flow tab of the Fabric Overview page before creating a static flow for it.

To create a static flow for the chosen switch:

  1. Navigate to the Connectivity page.

  2. Click the Flows tab.

  3. Click the Static Flow subtab.

  4. Click Actions > Create static flow.

    The Create static flow page displays.

  5. On the Add Static Flow page, specify the parameters in the following fields.

    • Selected Switch — Specifies the switch name. This field is read-only, and it is based on the switch selected in the Static Flow window.

    • VRF — Choose the VRF that you will associate with this static flow.

    • Group — Specifies the multicast group that you will associate with this static flow.

    • Source IP — Enter the source IP address.

    • Interface Name — Specify the interface name for the static flow. This field is optional. If you do not specify an interface name, the host IP 0.0.0.0 is passed to the API and config is created using Null0 interface.

  6. Click Save & Deploy to save the static flow.

    Click Cancel to discard it.

Virtual Infrastructure

To work with virtual infrastructure connectivity in a fabric:

  1. Navigate to the Connectivity page.

  2. Click the Virtual Infrastructure tab.

    A page showing the information for previously-configured virtual infrastructure connectivity appears.

View virtual machine VMs

The Actions drop-down list displays only for fabrics with security groups enabled. For fabrics with security groups enabled, you need to perform a Recalculate and deploy operation only once. For every Actions > Set group ID or Actions > Reset Group ID operation, Recalculate and deploy is not needed. For more information on security groups, see Working with Segmentation and Security for Your Nexus Dashboard VXLAN Fabric.

Follow these steps to navigate to the Virtual Machine VMs page.

  1. Navigate to the Connectivity page.

  2. Click the Virtual Infrastructure tab.

  3. Click the Virtual Machine VMs subtab.

    The Virtual Machine VMs subtab displays detailed information for VMs.

    Field Description

    VM Name

    Specifies the name of the virtual machine.

    IP Address

    Specifies the IP address of the virtual machine.

    MAC Address

    Specifies the MAC address of the virtual machine.

    VLAN

    Specifies the VLAN associated with the virtual machine.

    Network

    Specifies the network associated with the virtual machine.

    VRF

    Specifies the VRF associated with the virtual machine.

    Switch

    Specifies the switch connected to the virtual machine.

    Switch interface

    Specifies the switch interface connected to virtual machine.

    State

    Specifies the state of the VM adapter.

You can search and filter VMs by using the Filter by attributes search field.

These are the options available through the Actions menu in the Virtual Machine VMs page:

Field Description

Set group ID

Used to associate a VM with a security group.

  1. Choose the VM that you want to associate with a security group.

  2. Click Actions > Set group ID.

  3. Choose an existing security group, or click Add Security Group.

    See the section "Create a security group" in Working with Segmentation and Security for Your Nexus Dashboard VXLAN Fabric for more information.

  4. Click Submit.

    This action configures an IP selector for the VRF on the switches.

Remove group ID

Used to remove an association with a security group on a VM.

To remove an association with a security group on a VM, choose that VM and click Actions > Remove group ID.

You can search and filter VMs by using the Filter by attributes search field.

View Kubernetes pods

The Actions drop-down list displays only for fabrics with security groups enabled. For fabrics with security groups enabled, you need to perform a Recalculate and deploy operation only once. For every Actions > Set group ID or Actions > Reset Group ID operation, Recalculate and deploy is not needed. For more information on security groups, see Working with Segmentation and Security for Your Nexus Dashboard VXLAN Fabric.

Follow these steps to view Kubernetes pods on the Fabrics page.

  1. Navigate to the Connectivity page.

  2. Click the Virtual Infrastructure tab.

  3. Click the Kubernetes Pods subtab.

    You can search and filter Kubernetes pods by using the filter by attributes search field.

    The Kubernetes Pods subtab displays detailed information for Kubernetes pods.

    Field Description

    Pod Name

    Specifies the name of the Kubernetes pod.

    Pod IP

    Displays the IP address of the Kubernetes pod.

    Phase

    Specifies the phase (state) of the pod.

    Reason

    Specifies the reason.

    Applications

    Specifies the applications of the pod.

    Namespace

    Specifies the namespace of the pod.

    Node Name

    Specifies the node name of the pod.

    Node IP

    Specifies the node IP address.

    Cluster Type

    Displays the type of cluster.

    Physical NIC

    Displays the physical NIC of the node.

    Physical Switch

    Specifies the physical switch connected to cluster node.

    Switch Interface

    Specifies the switch interface connected to cluster node.

    Cluster Name

    Specifies the name of the cluster.

    Port Channel

    Specifies the port channel (if cluster node is connected to a VPC).

    VLAN

    Specifies the VLAN.

    Fabric

    Specifies the fabric name.

First Published: 2025-01-31
Last Modified: 2025-01-31

Need help?