Editing Fabric Settings for Fabric Groups

Considerations

A few fabric-specific terms:

When a standalone fabric is added to the fabric group, the following actions take place:

Fabric and switch instance variables

While the fabric group provisions a global range of network and VRF values, some parameters are fabric-specific and some parameters are switch-specific. The parameters are called fabric instance and switch instance variables.

Fabric instance values can only be edited or updated using the VRFs and Networks configuration page for the fabric. Double-click the appropriate fabric to view Fabric Overview and go to Networks or VRFs tab. Some of the examples of fabric instance variables are BGP ASN, Multicast group per network or VRF, etc. For information about editing multicast group address, see Creating and deploying networks and VRFs in a fabric group.

You can edit the switch instance values after deploying the network on the switch. For example, VLAN ID.

General Parameters

All mandatory fields in the General Parameters tab are prefilled. Update the relevant fields as needed.

What’s next: Complete the configurations in another tabs, if required, or click Save when you have completed the necessary configurations for this fabric.

DCI

Click the Security tab.

Security

Field	Description
Enable Security Groups	Check this check box to enable a security group with an IPv4-only underlay and using the CLI Overlay Mode. For more information on security groups, see Working with Segmentation and Security for Your Nexus Dashboard VXLAN Fabric.
Security Group Name Prefix	Specify the prefix to use when creating a new security group.
Security Group Tag (SGT) ID Range (Optional)	Specify a tag ID for the security group if necessary.
Security Groups Pre-Provision	Check this check box to generate a security groups configuration for non-enforced VRFs.
Multi-Site CloudSec	Enables CloudSec configurations on border gateways. If you enable this field, the remaining three fields for CloudSec are editable. For more information, see Support for CloudSec in fabric group deployment.
CloudSec Key String	Specifies the Cisco Type 7 encrypted octet key string.
CloudSec Cryptographic Algorithm	Choose AES_128_CMAC or AES_256_CMAC for the encryption type.
CloudSec Enforcement	Specifies whether the CloudSec enforcement should be strict or loose. strict - Deploys the CloudSec configuration to all the border gateways in fabrics in VXLAN Multi-Site. If there are any border gateways that don’t support CloudSec, then an error message is generated, and the configuration isn’t pushed to any switch. If you select strict, the tunnel-encryption must-secure CLI is pushed to the CloudSec enabled gateways within VXLAN Multi-Site. loose - Deploys the CloudSec configuration to all the border gateways in fabrics in VXLAN Multi-Site. If there are any border gateways that do not support CloudSec, then a warning message is generated. In this case, the CloudSec configuration is only deployed to the switches that support CloudSec. If you select loose, the tunnel-encryption must-secure CLI is removed, if available. There should be at least two fabrics in a VXLAN fabric group with border gateways that support CloudSec. If there is only one fabric with a CloudSec capable device, then the following error message is generated: CloudSec needs to have at least 2 sites that can support CloudSec. To remove the error, make sure you have at least two fabrics that can support CloudSec or disable CloudSec.
CloudSec Status Report Timer	Specifies the CloudSec Operational Status periodic report timer in minutes. This value specifies how often the Nexus Dashboard polls the CloudSec status data from the switch. The default value is 5 minutes and the range is from 5 to 60 minutes.

Click the Resources tab.

Resources

Configuration Backup

Creating and moving a new fabric under the fabric group as a member

Create a new fabric as a standalone fabric and move it under the fabric group as a member. As a best practice, when you create a new fabric that is a potential member fabric of the fabric group, do not add networks and VRFs to the fabric. Move the fabric under the fabric group and then add networks and VRFs for the fabric group. This eliminates the need for validation or conflict resolution between the member and fabric group network and VRF parameters.

The following are some points to consider while creating a standalone member fabric:

The parameter values in the Resources tab are automatically generated. The VXLAN VNI ID ranges in the L2 Segment ID Range and L3 Partition ID Range fields allocated for new network and VRF creation are values from the fabric group segment ID range. If you want to update the VXLAN VNI ranges or the VRF and Network VLAN ranges, consider the following:

Other pointers to consider:

Moving the Member1 fabric under fabric group-parent-fabric

Go to the fabric group Overview to associate a member fabric under it.

Fabric group topology view pointers

The Topology tab displays the configured fabric groups and their child fabrics.

Adding and editing links

To add a link, choose Actions > More > Add Link. To edit a link, choose Actions > More > Edit Link.

To know how to add links between border switches of different fabrics (inter-fabric links) or between switches in the same fabric (intra-fabric links), refer to the Fabric Links topic.

Creating and deploying networks and VRFs in a fabric group

In standalone fabrics, networks and VRFs are created for each fabric. In a fabric group, networks and VRFs should be created at the fabric group level. The networks and VRFs are inherited by all the member networks. You cannot create or delete networks and VRFs for member fabrics. However, you can edit them.

For example, consider a fabric group with two member fabrics. If you create three networks in the fabric group, then all three networks will automatically be available for deployment in both the member fabrics.

Though member fabrics inherit the fabric group’s networks and VRFs, you have to deploy the networks and VRFs distinctly, for each fabric.

A deployment view is introduced for the fabric group, in addition to the per-fabric deployment view. In this view, you can view and provision overlay networks for all member fabrics within the fabric group, at once. However, you still have to apply and save network and VRF configurations distinctly, for each fabric.

Networks and VRFs are the common identifiers (represented across member fabrics) that servers (or end hosts) are grouped under so that traffic can be sent between the end hosts based on the network and VRF IDs, whether they reside in the same or different fabrics. Since they have common representation across member fabrics, networks and VRFs can be provisioned at one go. As the switches in different fabrics are physically and logically distinct, you have to deploy the same networks and VRFs separately for each fabric.

For example, if you create networks 30000 and 30001 for a fabric group that contains two member fabrics, the networks are automatically created for the member fabrics and are available for deployment.

You can deploy 30000 and 30001 on the border devices of all member fabrics through a single (fabric group) deployment screen. Prior to this, you had to access the first member fabric deployment screen, deploy 30000 and 300001 on the fabric’s border devices, and then access the second member fabric deployment screen and deploy again.

Networks and VRFs are created in the fabric group and deployed in the member fabrics. The steps are explained below:

Moving a standalone fabric with existing networks and VRFs to a fabric group

If you move a standalone fabric with existing networks and VRFs to a fabric group as a member, ensure that common networks (L2 VNI and L3 VNI), anycast gateway MAC, and VRF and network templates are the same across the fabric and the fabric group. Nexus Dashboard validates the standalone fabric with the network and VRF information of the fabric group to avoid conflict entries. An example of conflict entries is two common network names with a different network ID. After validation, the standalone fabric is moved to the fabric group as a member fabric only if there are no conflicts.

The following are the different points to consider while moving a fabric under a fabric group:

Support for CloudSec in fabric group deployment

CloudSec feature allows secured data center interconnect in a fabric group deployment by supporting source-to-destination packet encryption between border gateway devices in different fabrics.

CloudSec feature is supported on Cisco Nexus 9000 Series FX2 platform with Cisco NX-OS Release 9.3(5) or later. The border gateways, border gateway spines, and border gateway super spines that are FX2 platforms, and run Cisco NX-OS Release 9.3(5) or later are referred as CloudSec capable switches.

You can enable CloudSec while creating a fabric group.

The CloudSec session is point to point over DCI between border gateways (BGWs) on two different sites. All communication between sites uses fabric group PIP instead of VIP. Enabling CloudSec requires a switch to move from VIP to PIP, which could cause traffic disruption for data flowing between sites. Therefore, it is recommended to enable or disable CloudSec during a maintenance window.

Refer to the "Guidelines and Limitations for Secure VXLAN EVPN Multi-Site Using CloudSec" section in the latest Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide for the guidelines and limitations for Secure VXLAN EVPN fabric group using CloudSec.

feature tunnel-encryption
evpn multisite border-gateway 600
  dci-advertise-pip
tunnel-encryption must-secure-policy
tunnel-encryption policy CloudSec_Policy1
tunnel-encryption source-interface loopback20
key chain CloudSec_Key_Chain1 tunnel-encryption
  key 1000
    key-octet-string 7 075e731f1a5c4f524f43595f507f7d73706267714752405459070b0b0701585440
    cryptographic-algorithm AES_128_CMA
tunnel-encryption peer-ip 192.168.0.6
  keychain CloudSec_Key_Chain1 policy CloudSec_Policy1

interface ethernet1/13
  no switchport
  ip address 192.168.1.14/24 tag 54321
  evpn multisite dci-tracking
  tunnel-encryption
  mtu 9216
  no shutdown