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 |
---|---|---|
NDFC release 12.1.3 |
Reorganized content |
Content within this document was originally provided in the Cisco NDFC-Fabric Controller Configuration Guide or the Cisco NDFC-SAN Controller Configuration Guide. Beginning with release 12.1.3, this content is now provided solely in this document and is no longer provided in those documents. |
Managing BGP-Based Routed Fabrics
This chapter describes how to configure a typical spine-leaf based routed fabric with eBGP as the routing protocol of choice. This is the preferred deployment choice for Massively Scalable Data Center (MSDC) networks. Both Same-Tier-AS and Multi-AS options are supported. A routed fabric has no Layer-2 stretch or subnet stretch across leafs. In other words, networks are localized to a pair of leafs or a rack, with leafs hosting the default gateway for the directly attached server workloads. Subnet advertisement across racks are communicated over eBGP via the spine thereby providing any-to-any reachability within the routed fabric. Routed Fabric can be IPv4 or IPv6 based. IPv6 routed fabric uses IPv6 to build the intra-fabric connectivity and route advertisement. IPv6 routed fabric assigns link local address for intra-fabric links and support RFC 5549 to allow IPv4 route advertising using IPv6 next hop. Switch roles leaf, spine, border, super spine, and border super spine are supported.
Creating an eBGP-based Fabric
-
Choose LAN > Fabrics.
-
From the Actions drop-down list, choose Create Fabric.
The Create Fabric window appears.
The fields are explained:
Fabric Name - Enter the name of the fabric.
Fabric Template - Click on this to choose the BGP Fabric fabric template. The fabric settings for creating a standalone fabric appear. Click Select.
-
The General Parameters tab is displayed by default.
-
Click the EVPN tab and uncheck the Enable EVPN VXLAN Overlay check box.
-
The fields in the General Parameters tab are:
BGP ASN for Spines: Enter the BGP AS number of the fabric’s spine switches.
BGP ASN for Super Spines: Enter the BGP AS number that is used for super spine and border super spines, if the fabric contains any super spine or border super spine.
BGP AS Mode: Choose Multi-AS or Same-Tier-AS.
In a Multi-AS fabric, the spine switches have a unique BGP AS number and each leaf switch has a unique AS number. If two leaf switches form a vPC switch pair, then they have the same AS number.
In a Same-Tier-AS fabric, the spine switches have a unique BGP AS number and the leaf switches have a unique AS number, the borders share one AS. Leaf or border switches with the same role cannot have different AS.
Leafs and borders can have the same AS, or different AS.
The fabric is identified by the spine switch AS number.
Enable IPv6 routed fabric: Check the Enable IPv6 routed fabric check box.
If not enabled, IPv4 underlay/routed fabric is used. To select this option, disable EVPN first.
Supports NX-OS software image version 9.3.6 and above.
Manual Underlay IP Address Allocation: Check the Manual Underlay IP Address Allocation check box to disable Dynamic Underlay IP Address Allocations.
-
Click EVPN. The Enable EVPN VXLAN Overlay option must be explicitly disabled. Note that this check box is enabled by default. This option should be enabled only for use-cases where customers want to build an eBGP-underlay/overlay based VXLAN EVPN fabric.
Routed Fabric: In a Routed Fabric, once the IP reachability between the spine-leaf network has been established, you can easily create and deploy networks on the leafs using either HSRP or VRRP as the First-Hop Routing Protocol (FHRP) of choice.
When you create an eBGP Routed fabric, the fabric uses eBGP as the control plane to build intra-fabric connectivity. Links between spine and leaf switches are autoconfigured with point-to-point (p2p) numbered IP addresses with eBGP peering built on top.
Note that Routed_Network_Universal Template is only applicable to a Routed Fabric.
First Hop Redundancy Protocol: Specifies the FHRP protocol. Choose either hsrp or vrrp. This field is only applicable to a Routed Fabric.
-
After a network has been created, you cannot change this fabric setting. You should delete all networks, and then change the FHRP setting.
-
The rest of the fields in the EVPN tab section are only applicable if you enable the EVPN VXLAN Overlay.
-
-
Click vPC. The fields in the tab are:
vPC Peer Link VLAN: VLAN used for the vPC peer link SVI.
Make vPC Peer Link VLAN as Native VLAN - Enables vPC peer link VLAN as Native VLAN.
vPC Peer Keep Alive option: Choose the management or loopback option. If you want to use IP addresses assigned to the management port and the management VRF, choose management. If you use IP addresses assigned to loopback interfaces (and a non-management VRF), choose loopback. If you use IPv6 addresses, you must use loopback IDs.
vPC Auto Recovery Time: Specifies the vPC auto recovery time-out period in seconds.
vPC Delay Restore Time: Specifies the vPC delay restore period in seconds.
vPC Peer Link Port Channel Number: Specifies the Port Channel ID for a vPC Peer Link. By default, the value in this field is 500.
vPC IPv6 ND Synchronize: Enables IPv6 Neighbor Discovery synchronization between vPC switches. The check box is enabled by default. uncheck the check box to disable the function.
vPC advertise-pip: Check the vPC advertise-pip check box to enable the advertise PIP feature.
You can enable the advertise PIP feature on a specific vPC as well.
Enable the same vPC Domain Id for all vPC Pairs: Check the Enable the same vPC Domain Id for all vPC Pairs check box. When you select this field, the vPC Domain Id field is editable
vPC Domain Id: Specifies the vPC domain ID to be used on all vPC pairs
vPC Domain Id Range: Specifies the vPC Domain Id range to use for new pairings.
Enable QoS for Fabric vPC-Peering: Enable QoS on spines for guaranteed delivery of vPC Fabric Peering communication.
QoS for vPC fabric peering and queuing policies options in fabric settings are mutually exclusive.
QoS Policy Name: Specifies QoS policy name that should be same on all fabric vPC peering spines.
The default name is spine_qos_for_fabric_vpc_peering.
-
Click Protocols. The fields in the tab are:
Routing Loopback Id - The loopback interface ID is populated as 0 by default. It is used as the BGP router ID.
BGP Maximum Paths - Specifies the BGP maximum paths.
Enable BGP Authentication: Check the Enable BGP Authentication check box to enable BGP authentication. uncheck the check box to disable it. If you enable this field, the BGP Authentication Key Encryption Type and BGP Authentication Key fields are enabled.
BGP Authentication Key Encryption Type: Choose the three for 3DES encryption type, or seven for Cisco encryption type.
BGP Authentication Key: Enter the encrypted key based on the encryption type.
Plain text passwords are not supported. Login to the switch, retrieve the encrypted key and enter it in the BGP Authentication Key field. Refer the Retrieving the Authentication Key section for details.
Enable BFD: Check the Enable BFD check box to enable feature bfd on all switches in the fabric. This feature is valid only on IPv4 underlay and the scope is within a fabric.
NDFC supports BFD within a fabric. The BFD feature is disabled by default in the Fabric Settings. If enabled, BFD is enabled for the underlay protocols with the default settings. Any custom required BFD configurations must be deployed through per switch freeform or per interface freeform policies.
The following config is pushed after you check the Enable BFD check box:
feature bfd
NDFC with BFD enabled, the following configurations are pushed on all P2P fabric interfaces: ` no ip redirects no ipv6 redirects`
For information about BFD feature compatibility, refer your respective platform documentation and for information about the supported software images, see Compatibility Matrix for Cisco NDFC.
Enable BFD for BGP: Check the Enable BFD for BGP check box to enable BFD for the BGP neighbor. This option is disabled by default.
Enable BFD Authentication: Check the Enable BFD Authentication check box to enable BFD authentication. If you enable this field, the BFD Authentication Key ID and BFD Authentication Key fields are editable.
BFD Authentication Key ID: Specifies the BFD authentication key ID for the interface authentication.
BFD Authentication Key: Specifies the BFD authentication key.
For information about how to retrieve the BFD authentication parameters, see Retrieving the Encrypted BFD Authentication Key, in Cisco NDFC Fabric Controller Configuration Guide.
-
Click Advanced. The fields in the tab are:
Intra Fabric Interface MTU: Specifies the MTU for the intra fabric interface. This value should be an even number.
Layer 2 Host Interface MTU: Specifies the MTU for the layer 2 host interface. This value should be an even number.
Power Supply Mode: Choose the appropriate power supply mode.
CoPP Profile: Choose the appropriate Control Plane Policing (CoPP) profile policy for the fabric. By default, the strict option is populated.
VRF Lite Subnet IP Range and VRF Lite Subnet Mask: These fields are populated with the DCI subnet details. Update the fields as needed.
Enable CDP for Bootstrapped Switch: Check the Enable CDP for Bootstrapped Switch check box to enable CDP for bootstrapped switch.
Enable NX-API: Specifies enabling of NX-API on HTTPS. This check box is checked by default.
Enable NX-API on HTTP: Specifies enabling of NX-API on HTTP. Check Enable NX-API on HTTP and Enable NX-API check boxes to use HTTP. This check box is checked by default. If you uncheck this check box, the applications that use NX-API and supported by Cisco NDFC, such as Endpoint Locator (EPL), Layer 4-Layer 7 services (L4-L7 services), VXLAN OAM, and so on, start using the HTTPS instead of HTTP.
If you check Enable NX-API and Enable NX-API on HTTP check boxes, applications use HTTP.
Enable Strict Config Compliance: Check the Enable Strict Config Compliance check box to enable this feature.
For Strict Configuration Compliance, see Enhanced Monitoring and Monitoring Fabrics Guide.
If Strict Configuration Compliance is enabled in a fabric, you cannot deploy Network Insights for Resources on Cisco NDFC.
Enable AAA IP Authorization: Enables AAA IP authorization, when IP Authorization is enabled in the AAA Server.
Enable DCNM as Trap Host: Check the Enable DCNM as Trap Host check box to enable NDFC as a trap host.
Enable TCAM Allocation: TCAM commands are automatically generated for VXLAN and vPC Fabric Peering when enabled.
Greenfield Cleanup Option: Enable the switch cleanup option for greenfield switches without a switch reload. This option is typically recommended only for the data center environments with the Cisco Nexus 9000v Switches.
Enable Default Queuing Policies: Check Enable Default Queuing Policies check box to apply QoS policies on all the switches in this fabric. To remove the QoS policies that you applied on all the switches, uncheck this check box, update all the configurations to remove the references to the policies, and save and deploy. Pre-defined QoS configurations are included that can be used for various Cisco Nexus 9000 Series Switches. When you check this check box, the appropriate QoS configurations are pushed to the switches in the fabric. The system queuing is updated when configurations are deployed to the switches. You can perform the interface marking with defined queuing policies, if required, by adding the required configuration to the per interface freeform block.
Review the actual queuing policies by opening the policy file in the template editor. From Cisco NDFC Web UI, choose Operations > Template. Search for the queuing policies by the policy file name, for example, queuing_policy_default_8q_cloudscale. Choose the file and click the Modify/View template icon to edit the policy.
See the Cisco Nexus 9000 Series NX-OS Quality of Service Configuration Guide for platform specific details.
N9K Cloud Scale Platform Queuing Policy: Choose the queuing policy from the drop-down list to be applied to all Cisco Nexus 9200 Series Switches and the Cisco Nexus 9000 Series Switches that ends with EX, FX, and FX2 in the fabric. The valid values are queuing_policy_default_4q_cloudscale and queuing_policy_default_8q_cloudscale. Use the queuing_policy_default_4q_cloudscale policy for FEXes. You can change from the queuing_policy_default_4q_cloudscale policy to the queuing_policy_default_8q_cloudscale policy only when FEXes are offline.
N9K R-Series Platform Queuing Policy: Choose the queuing policy from the drop-down list to be applied to all Cisco Nexus switches that ends with R in the fabric. The valid value is queuing_policy_default_r_series.
Other N9K Platform Queuing Policy: Choose the queuing policy from the drop-down list to be applied to all other switches in the fabric other than the switches mentioned in the above two options. The valid value is queuing_policy_default_other.
Enable MACsec: Enables MACsec for the fabric. For more information, see the section "MACsec Support in Data Center VXLAN EVPN and BGP Fabrics" in Enabling MACsec.
Leaf Freeform Config: Add CLIs that should be added to switches that have the Leaf, Border, and Border Gateway roles.
Spine Freeform Config: Add CLIs that should be added to switches with a Spine, Border Spine, and Border Gateway Spine roles.
Intra-fabric Links Additional Config: Add CLIs that should be added to the intra-fabric links.
-
Click Manageability. The fields in this tab are:
DNS Server IPs: Specifies the comma separated list of IP addresses (v4/v6) of the DNS servers.
DNS Server VRFs: Specifies one VRF for all DNS servers or a comma separated list of VRFs, one per DNS server.
NTP Server IPs: Specifies comma separated list of IP addresses (v4/v6) of the NTP server.
NTP Server VRFs: Specifies one VRF for all NTP servers or a comma separated list of VRFs, one per NTP server.
Syslog Server IPs: Specifies the comma separated list of IP addresses (v4/v6) IP address of the syslog servers, if used.
Syslog Server Severity: Specifies the comma separated list of syslog severity values, one per syslog server. The minimum value is 0 and the maximum value is 7. To specify a higher severity, enter a higher number.
Syslog Server VRFs: Specifies one VRF for all syslog servers or a comma separated list of VRFs, one per syslog server.
AAA Freeform Config: Specifies the AAA freeform configs.
If AAA configs are specified in the fabric settings, switch_freeform PTI with source as UNDERLAY_AAA and description as "AAA Configurations" will be created.
-
Click Bootstrap tab. The fields in this tab are:
Enable Bootstrap: Check the Enable Bootstrap check box to enable the bootstrap feature.
After you enable bootstrap, you can enable the DHCP server for automatic IP address assignment using one of the following methods:
-
External DHCP Server: Enter information about the external DHCP server in the Switch Mgmt Default Gateway and Switch Mgmt IP Subnet Prefix fields.
-
Local DHCP Server: Check the Local DHCP Server check box and enter details for the remaining mandatory fields.
Enable Local DHCP Server: Check the Enable Local DHCP Server check box to initiate enabling of automatic IP address assignment through the local DHCP server. When you check this check box, the DHCP Scope Start Address and DHCP Scope End Address fields become editable.
If you do not check this check box, NDFC uses the remote or external DHCP server for automatic IP address assignment.
DHCP Version - Select DHCPv4 or DHCPv6 from this drop-down list. When you select DHCPv4, the Switch Mgmt IPv6 Subnet Prefix field is disabled. If you select DHCPv6, the Switch Mgmt IP Subnet Prefix is disabled.
Cisco NDFC IPv6 POAP is not supported with Cisco Nexus 7000 Series Switches. Cisco Nexus 9000 and 3000 Series Switches support IPv6 POAP only when switches are either L2 adjacent (eth1 or out-of-band subnet must be a /64) or they are L3 adjacent residing in some IPv6 /64 subnet. Subnet prefixes other than /64 are not supported.
DHCP Scope Start Address and DHCP Scope End Address: Specifies the first and last IP addresses of the IP address range to be used for the switch out of band POAP.
Switch Mgmt Default Gateway: Specifies the default gateway for the management VRF on the switch.
Switch Mgmt IP Subnet Prefix: Specifies the prefix for the Mgmt0 interface on the switch. The prefix should be between 8 and 30.
DHCP scope and management default gateway IP address specification: If you specify the management default gateway IP address 10.0.1.1 and subnet mask 24, ensure that the DHCP scope is within the specified subnet, between 10.0.1.2 and 10.0.1.254.
Switch Mgmt IPv6 Subnet Prefix: Specifies the IPv6 prefix for the Mgmt0 interface on the switch. The prefix should be between 112 and 126. This field is editable if you enable IPv6 for DHCP.
Enable AAA Config: Check the Enable AAA Config check box to include AAA configs from the Manageability tab during device bootup.
Bootstrap Freeform Config: (Optional) Enter additional commands as needed. For example, if you are using AAA or remote authentication related configurations, you need to add these configurations in this field to save the intent. After the devices boot up, they contain the intent defined in the Bootstrap Freeform Config field.
Copy-paste the running-config to a freeform config field with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running config. For more information, see Resolving Freeform Config Errors in Switches in Enabling Freeform Configurations on Fabric Switches.
DHCPv4/DHCPv6 Multi Subnet Scope: Specifies the field to enter one subnet scope per line. This field is editable after you check the Enable Local DHCP Server check box.
The format of the scope should be defined as:
DHCP Scope Start Address, DHCP Scope End Address, Switch Management Default Gateway, Switch Management Subnet Prefix
For example: 10.6.0.2, 10.6.0.9, 10.6.0.1, 24
-
-
Click Configuration Backup. The fields on this tab are:
Hourly Fabric Backup: Check the Hourly Fabric Backup check box to enable an hourly backup of fabric configurations and the intent.
You can enable an hourly backup for fresh fabric configurations and the intent as well. If there is a configuration push in the previous hour, NDFC takes a backup.
Intent refers to configurations that are saved in NDFC but yet to be provisioned on the switches.
Scheduled Fabric Backup: Check the Scheduled Fabric Backup check box to enable a daily backup. This backup tracks changes in running configurations on the fabric devices that are not tracked by configuration compliance.
Scheduled Time: Specify the scheduled backup time in a 24-hour format. This field is enabled if you check the Scheduled Fabric Backup check box.
Select both the check boxes to enable both back up processes.
The backup process is initiated after you click Save.
Hourly and scheduled backup processes happen only during the next periodic configuration compliance activity, and there can be a delay of up to an hour. To trigger an immediate backup, do the following:
-
Choose LAN > Topology.
-
Click within the specific fabric box. The fabric topology screen comes up.
-
From the Actions pane at the left part of the screen, click Re-Sync Fabric.
You can also initiate the fabric backup in the fabric topology window. Click Backup Now in the Actions pane.
Click Save after filling and updating relevant information.
-
-
Click Flow Monitor. The fields on this tab are:
Enable Netflow - Check the Enable Netflow check box to enable Netflow on VTEPs for this Fabric. By default, Netflow is disabled. On Enable, NetFlow configuration will be applied to all VTEPS that support netflow.
When Netflow is enabled on the fabric, you can choose not to have netflow on a particular switch by having a dummy no_netflow PTI.
If netflow is not enabled at the fabric level, an error message is generated when you enable netflow at the interface, network, or vrf level. For information about Netflow support for Cisco NDFC, refer to Netflow Support.
In the Netflow Exporter area, click Actions > Add to add one or more Netflow exporters. This exporter is the receiver of the netflow data. The fields on this tab are:
-
Exporter Name: Specifies the name of the exporter.
-
IP: Specifies the IP address of the exporter.
-
VRF: Specifies the VRF over which the exporter is routed.
-
Source Interface: Enter the source interface name.
-
UDP Port: Specifies the UDP port over which the netflow data is exported.
Click Save to configure the exporter. Click Cancel to discard. You can also choose an existing exporter and select Actions > Edit or Actions > Delete to perform relevant actions.
In the Netflow Record area, click Actions > Add to add one or more Netflow records. The fields on this screen are:
-
Record Name: Specifies the name of the record.
-
Record Template: Specifies the template for the record. Enter one of the record templates names. In Release 12.0.2, the following two record templates are available for use. You can create custom netflow record templates. Custom record templates saved in the template library are available for use here.
-
netflow_ipv4_record: to use the IPv4 record template.
-
netflow_l2_record: to use the Layer 2 record template.
-
-
Is Layer2 Record: Check the Is Layer2 Record check box if the record is for Layer2 netflow.
Click Save to configure the report. Click Cancel to discard. You can also choose an existing record and select Actions > Edit or Actions > Delete to perform relevant actions.
In the Netflow Monitor area, click Actions > Add to add one or more Netflow monitors. The fields on this screen are:
-
Monitor Name: Specifies the name of the monitor.
-
Record Name: Specifies the name of the record for the monitor.
-
Exporter1 Name: Specifies the name of the exporter for the netflow monitor.
-
Exporter2 Name: (optional) Specifies the name of the secondary exporter for the netflow monitor.
The record name and exporters referred to in each netflow monitor must be defined in "Netflow Record" and "Netflow Exporter".
Click Save to configure the monitor. Click Cancel to discard. You can also choose an existing monitor and select Actions > Edit or Actions > Delete to perform relevant actions.
-
-
Click on the Fabric to view summary in the slide-in pane. Click on the Launch icon to view the Fabric Overview.
Salient Points
-
Brownfield migration is not supported for eBGP fabrics.
-
You cannot change the leaf switch AS number after it is created and Recalculate & Deploy operation is executed. You need to delete the leaf_bgp_asn policy and execute Recalculate & Deploy operation to remove BGP configuration related to this AS first. Then, you can add the leaf_bgp_asn policy with the new AS number.
-
If you want to switch between Multi-AS and Same-Tier-AS modes, remove all manually added BGP policies (including leaf_bgp_asn on the leaf switch and the ebgp overlay policies), and execute the Recalculate & Deploy operation before the mode change.
-
The supported roles are leaf, spine, super spine, border leaf, and border super spine.
-
On the border and super spine border device, VRF-Lite is supported with manual mode
Adding Switches to a Fabric
Switches in each fabric are unique, and hence, each switch can only be added to one fabric. See Adding Switches to a Fabric.
Deploying Fabric Underlay eBGP Policies
In NDFC, a fabric with the BGP Fabric template is created. One spine switch and three leaf switches are imported to it.
The two different types of fabrics are:
-
Creating a Multi-AS mode fabric: In a Multi-AS mode fabric, spine switches have a common BGP AS number and each leaf switch has a unique BGP AS number. Use the same steps for Same-Tier-AS to Multi-AS mode fabric conversion.
-
Creating a Same-Tier-AS mode fabric: Alternate steps are mentioned for Same-Tier-AS mode fabric creation. Use the same steps for Multi-AS to a Same-Tier-AS mode fabric conversion.
In a Same-Tier-AS fabric, all spine switches have a common BGP AS number and all leaf switches have a common BGP AS number (differing from the spine switches' BGP AS number). You must deploy policies as explained in the next section.
To deploy fabric underlay eBGP policy, you must manually add the leaf_bgp_asn policy on each leaf switch to specify the BGP AS number used on the switch. Implementing the Recalculate & Deploy operation afterward will generate eBGP peering over the physical interface between the leaf and spine switches to exchange underlay reachability information.
To add a policy to the required switch, see the section "Adding a Policy" in About Fabric Overview for LAN Operational Mode Setups.
Deploying Networks in eBGP-based Fabrics
Overview of Networks in a Routed Fabric
You can create a top-down network configuration for a routed fabric using NDFC. A routed fabric is run in one VRF, which is the default VRF. Note that creating VRFs manually is disabled for a routed fabric. Since the fabric is an IPv4 fabric, IPv6 address within the network is not supported. In a routed fabric, a network can only be attached to one device or a pair of vPC devices, unless it is a Layer-2 only network.
A routed fabric network configuration will not be put under a config-profile. When the eBGP fabric is configured as Routed Fabric (EVPN is disabled), at the fabric level, you can select the first hop redundancy protocol (FHRP) for host traffic to be either HSRP or VRRP. HSRP is the default value.
For a vPC pair, NDFC generates network level HSRP or VRRP configuration based on the fabric setting. If HSRP is chosen, each network is configured with one HSRP group, and the HSRP VIP address. By default, all the networks will share the same HSRP group number allocated by NDFC, while you can overwrite it per network. VRRP support is similar to HSRP.
Guidelines
-
HSRP authentication or VRRP authentication is not supported. If you want to use authentication, you can enter the applicable commands in the network freeform config.
-
vPC peer gateway can be used to minimize peer link usage in the case that some third-party devices ignore the HSRP virtual-MAC and use the ARP packet source MAC for ARP learning. In Routed fabric mode, NDFC generates vPC peer gateway command for VPC devices.
-
For an eBGP fabric, changing between routed fabric type and EVPN fabric type, or HSRP and VRRP, is not allowed with the presence of networks and VRFs. You need to undeploy and delete these networks and VRFs before changing the fabric type or FHRP. For more information, see Undeploying Networks for the Standalone Fabric and Undeploying VRFs for the Standalone Fabric.
-
If the fabric was running in Routed Fabric mode previously, the default fabric values such as FHRP protocol and network VLAN range are internally set for a Routed Fabric. You need to edit the fabric settings if you want to configure different values. Before deploying a network configuration, you need to update the FHRP protocol fabric setting and click Recalculate & Deploy.
Creating and Deploying a Network in a Routed Fabric
Create a routed fabric and deploy the necessary leaf and spine policies.
This procedure shows how to create and deploy a network in a routed fabric.
-
Choose any one of the following navigation paths:
-
Choose LAN > Fabrics. Click on a fabric to open the Fabric slide-in pane. Click the Launch icon. Choose Fabric Overview > Networks.
-
Choose LAN > Fabrics. Double-click on a fabric to open Fabric Overview > Networks.
-
-
From the Actions drop-down list, choose Create.
The Create Networks window appears. The fields in this window are:
Network Name: Specifies the name of the network. The network name should not contain any white spaces or special characters except underscore (_) and hyphen (-).
Layer 2 Only: (Optional) Specifies whether the network is a Layer 2 only network. FHRP configuration is not generated in a Layer 2 only network.
When an L3 Network template is attached to a standalone device, no FHRP configuration is generated.
Network Template: Select the Routed_Network_Universal template.
VLAN ID: Optional. Specifies the corresponding tenant VLAN ID for the network.
Network Profile section contains the General Parameters and Advanced tabs.
In the *General Parameters*tab, specify the required details.
Intf IPv4 addr on active: Specifies the IPv4 interface address on an active device in a vPC pair. This field is applicable only when you are creating and deploying a network for a vPC pair of devices.
Intf IPv4 addr on standby: Specifies the IPv4 interface address on a standby/backup device in a vPC pair. This field is applicable only when you are creating and deploying a network for a vPC pair of devices.
IPv4 Gateway/NetMask: Specifies the IPv4 gateway address with subnet.
Interface IPv6 addr on active: Specifies the IPv6 interface address on an active device in a vPC pair. This field is applicable only when you are creating and deploying a network for a vPC pair of devices.
Interface IPv6 addr on standby: Specifies the IPv6 interface address on a standby/backup device in a vPC pair. This field is applicable only when you are creating and deploying a network for a vPC pair of devices.
IPv6 Link Local address: Specifies the IPv6 link local address. This field is applicable only when you are creating and deploying a network for a vPC pair of devices and VRRP is chosen as the FHRP protocol.
The IPv4 gateway address and interface addresses should be in the same subnet.
The following fields under the General Parameters tab are optional:
Vlan Name: Specifies the VLAN name.
Interface Description: Specifies the description for the interface.
Standby Intf Description: Specifies the description for the standby interface in a vPC pair.
MTU for the L3 interface: Enter the MTU for Layer 3 interfaces.
Routing Tag: Specifies the routing tag that is associated with each gateway IP address prefix.
Advanced tab: This tab is applicable only when you are creating and deploying a network for a vPC pair of devices.
First Hop Redundancy Protocol: A read-only field that specifies FHRP selected in the fabric settings.
Active/master Switch Priority: Specifies the priority of the active or master device.
Standby/backup Switch Priority: Specifies the priority of the standby or backup device. The default value is 100. Note that this default value is not displayed when you preview the network configuration before deployment.
Enable Preempt: Specifies whether the standby/backup device can preempt an active device.
HSRP/VRRP Group: Specifies the HSRP or VRRP group number. By default, HSRP group number is 1.
Virtual MAC Address: Optional. Specifies the virtual MAC address. By default, VMAC is internally generated based on the HSRP group number (0000.0c9f.f000 + group number). The virtual MAC address is only applicable when hsrp is selected in the fabric settings.
HSRP Version: Specifies the HSRP version. The default value is 1. The *HSRP version*field is only applicable for HSRP.
-
Click Create Network. For more information, see the "Networks" section in About Fabric Overview for LAN Operational Mode Setups.
-
In the Network Attachment window, for a vPC pair, assign the active state for a device.
Check the isActive check box for an active device and uncheck the *isActive*check box for a standby device.
Click Save.
In a routed fabric, when you edit a deployed network and save without making any changes, the status of the network changes to Pending. Similarly, if a Network Attachment window is opened for a deployed network, and saved without any changes, the status of the network changes to Pending. In these cases, click the Preview icon to preview the configuration. This action changes the network status back to Deployed.
-
(Optional) Click the Preview icon to preview the configuration that deployed on devices.
The Preview Configuration window is displayed.
-
Click Deploy.
You can also deploy the network by navigating to the Fabric Overview window and clicking the Deploy button.
Creating Inter-Fabric Links Between a Routed Fabric and an External Fabric
You can use an inter-fabric link to connect a route fabric to an edge router. This link configures an IP address on the physical interface and establish eBGP peering with the edge router on default vrf. The BGP configuration includes advertising default route to leaf switches.
The Fabric Monitor Mode check box in the external fabric settings can be unchecked. Unchecking the Fabric Monitor Mode check box enables NDFC to deploy configurations to the external fabric. For more information, see "Creating an External Fabric" in External Connectivity Network.
-
Choose LAN > Fabrics. Double-click on a routed fabric.
The Fabric Overview window appears.
-
On the Links tab, click Actions > Create.
The Link Management - Create Link window appears.
Link Type: Choose Inter-Fabric to create an inter-fabric connection between two fabrics, via their border switches or edge routers.
Link Sub-Type: This field populates the IFC type. Choose ROUTED_FABRIC from the drop-down list.
Link Template: The link template is populated. The templates are auto populated with corresponding pre-packaged default templates that are based on your selection. For a routed fabric, the ext_routed_fabric template is populated.
Source Fabric: This field is pre-populated 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 or port channel interface that connects to the destination device. Only device with the border role can be chosen.
Destination Device and Destination Interface: Choose the destination device and Ethernet or port channel interface that connects to the source device.
Based on the selection of the source device and source interface, the destination information is auto populated based on Cisco Discovery Protocol information, if available. There is an extra validation performed to ensure that the destination external device is indeed part of the destination fabric.
The General Parameters tab contains the following fields.
Source BGP ASN: In this field, the AS number of the leaf is auto populated if you have created and applied the leaf_bgp_asn policy.
Source IPv4 Address/Mask: Fill up this field with the IP address of the source interface that connects to the destination device.
Destination IPv4: Fill up this field with the IPv4 address of destination interface
Destination BGP ASN: In this field, the AS number of the destination device is auto populated.
Source IPv6 Address/Mask: Fill up this field with the IP address of the source interface that connects to the destination device.
Destination IPv6: Fill up this field with the IPv6 address of destination interface.
BGP Maximum Paths: Specifies the maximum supported BGP paths.
Link MTU: Fill up this field with the interface MTU.
Disable Default Route Config: Check the Disable Default Route Config check box.
The Advanced tab contains the following optional fields:
Source Interface Description and Destination Interface Description - Describe the links for later use. After Save & Deploy, this description will reflect in the running configuration.
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, refer to Enabling Freeform Configurations on Fabric Switches.
-
Click Save.
-
Double-click the device which is connecting to the edge router in the external fabric, and click Actions > Recalculate & Deploy.
-
After the configuration deployment is completed in the Deploy Configuration window, click Close.
-
Navigate to the external fabric in the LAN Fabric window, and double-click on the fabric.
-
Click the Links tab to see all the links for the external fabric.
You can see the inter-fabric link that has been created.
The inter-fabric link is created if the External fabric is not in the monitor mode.
-
Navigate to the LAN Fabric window.
-
Double-click the external fabric connecting to the routed fabric and click Actions > Recalculate & Deploy.
-
After the configuration deployment is completed in the Deploy Configuration window, click Close.
Copyright
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
© 2017-2024 Cisco Systems, Inc. All rights reserved.