Enabling Freeform Configurations on Fabric Switches, Release 12.2.2

Tech Article
 
Last updated: April 8, 2024
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

There were no major changes from the previous release.

Enabling Freeform Configurations on Fabric Switches

In Nexus Dashboard Fabric Controller, you can add custom configurations through freeform policies in the following ways:

  1. Fabric-wide:

    • On all leaf, border leaf, and border gateway leaf switches in the fabric, at once.

    • On all spine, super spine, border spine, border super spine, border gateway spine and border switches, at once.

  2. On a specific switch at the global level.

  3. On a specific switch on a per network or a per VRF level.

  4. On a specific interface on a switch.

Leaf switches are identified by the roles Leaf, Border, and Border Gateway. The spine switches are identified by the roles Spine, Border Spine, Border Gateway Spine, Super Spine, Border Super Spine, and Border Gateway Super Spine.

note.svg

You can deploy freeform CLIs when you create a fabric or when a fabric is already created. The following examples are for an existing fabric. However, you can use this as a reference for a new fabric.

Deploying Fabric-Wide Freeform CLIs on Leaf and Spine Switches

  1. Choose Manage > Fabrics.

  2. Select the fabric, and select Edit Fabric from the Actions drop-down list.

    (If you are creating a fabric for the first time, click Create Fabric).

  3. Click the Advanced tab and update the following fields:

    Leaf Freeform Config - In this field, add configurations for all leaf, border leaf, and border gateway leaf switches in the fabric.

    Spine Freeform Config - In this field, add configurations for all Spine, Border Spine, Border Gateway Spine, Super Spine, Border Super Spine, and Border Gateway Super Spine switches in the fabric.

    note.svg

    Copy-paste the intended configuration with the correct indentation, as seen in the running configuration on the Nexus switches. For more information, see Resolving Freeform Config Errors in Switches.

  4. Click Save. The fabric topology screen comes up.

  5. Click Deploy Config from the Actions drop-down list to save and deploy the configurations.

    Configuration Compliance functionality ensures that the intended configuration as expressed by those CLIs are present on the switches and if they are removed or there is a mismatch, then NDFC flags it as a mismatch and indicates that the device is out-of-sync.

Incomplete Configuration Compliance - On some Cisco Nexus 9000 Series switches, in spite of configuring pending switch configurations using the Deploy Config option, there could be a mismatch between the intended and switch configuration. To resolve the issue, add a switch_freeform policy to the affected switch (as explained in the Deploying Freeform CLIs on a Specific Switch on a Per VRF/Network Basis). For example, consider the following persistent pending configurations:

line vty
logout-warning 0

After adding the above configurations in a policy and saving the updates, click Deploy Config in the topology screen to complete the deployment process.

To bring back the switch in-sync, you can add the above configuration in a switch_freeform policy saved and deployed onto the switch.

Deploying Freeform CLIs on a Specific Switch

  1. Choose Manage > Fabrics.

  2. Select the fabric, and select Edit Fabric from the Actions drop-down list.

  3. Click the Policies tab.

  4. From the Actions drop-down list, choose Add Policy.

    The Create Policy screen comes up.

    note.svg

    To provision freeform CLIs on a new fabric, you have to create a fabric, import switches into it, and then deploy freeform CLIs.

  5. In the Priority field, the priority is set to 500 by default. You can choose a higher priority (by specifying a lower number) for CLIs that need to appear higher up during deployment. For example, a command to enable a feature should appear earlier in the list of commands.

  6. In the Description field, provide a description for the policy.

  7. From the Template Name field, select freeform_policy.

  8. Add or update the CLIs in the Freeform Config CLI box.

    Copy-paste the intended configuration with the correct indentation, as seen in the running configuration on the Nexus switches. For more information, see Resolving Freeform Config Errors in Switches.

  9. Click Save.

    After the policy is saved, it gets added to the intended configurations for that switch.

  10. From the Fabric Overview page, click the Switches tab and choose the required switches.

  11. On the Switches tab, click the Actions drop-down list and choose Deploy.

Pointers for freeform_policy Policy Configuration:

  • You can create multiple instances of the policy.

  • For a vPC switch pair, create consistent freeform_policy policies on both the vPC switches.

  • When you edit a freeform_policy policy and deploy it onto the switch, you can see the changes being made (in the Side-by-side tab of the Preview option).

Freeform CLI Configuration Examples

Console Line Configurations

This example involves deploying some fabric-wide freeform configurations (for all leaf, and spine switches), and individual switch configurations.

Fabric-wide session timeout configuration:

line console
  exec-timeout 1

Console speed configuration on a specific switch:

line console
  speed 115200
note.svg

For Cisco Nexus 9804 and Cisco Nexus 9808 switches, you need to create a switch_freeform policy for the non-default console speed, as these switches only support a speed of 115200.

IP Prefix List/Route-map Configurations

IP prefix list and route-map configurations are typically configured on border devices. These configurations are global because they can be defined once on a switch and then applied to multiple VRFs as needed. The intent for this configuration can be captured and saved in a switch_freeform policy. As mentioned earlier, note that the configuration saved in the policy should match the show run output. This is especially relevant for prefix lists where the NX-OS switch may generate sequence numbers automatically when configured on the CLI. An example snippet is shown below:

ip prefix-list prefix-list-name1 seq 5 permit 20.2.0.1/32
ip prefix-list prefix-list-name1 seq 6 permit 20.2.0.2/32
ip prefix-list prefix-list-name2 seq 5 permit 192.168.100.0/24

ACL Configurations

Access control list (ACL) configurations are typically configured on specific switches and are not fabric-wide configurations. When you configure ACLs as freeform CLIs on a switch, you should include sequence numbers. Otherwise, there will be a mismatch between the intended and the running configurations.

Following is a configuration example with sequence numbers:

ip access-list ACL_VTY
  10 deny tcp 172.29.171.67/32 172.29.171.36/32
  20 permit ip any any
ip access-list vlan65-acl
  10 permit ip 69.1.1.201/32 65.1.1.11/32
  20 deny ip any any

interface Vlan65
  ip access-group vlan65-acl in
line vty
  access-class ACL_VTY in

If you have configured ACLs without sequence numbers in a freeform_policy policy, update the policy with the sequence numbers as shown in the running configuration of the switch.

After the policy is updated and saved, right-click the device and select the per switch Deploy Config option to deploy the configuration.

Prior to NDFC release 12.2.1, when you perform a Recalculate & Deploy on a fabric where switches are imported with the Preserve Config option enabled (a Brownfield deployment), the IP ACL configuration for a VXLAN fabric is captured in the switch_freeform policy, along with the non-matched switch configuration. For the same situation in an Enhanced Classic LAN fabric, where you have a Brownfield import with the Preserve Config option enabled, the same configuration information is captured into a smaller subset of individual ACL freeforms.

Beginning with NDFC release 12.2.1, for both VXLAN and Enhanced Classic LAN fabrics:

  • If the ACL configurations match with the ip_acl and ipv6_acl nvPairs, then those configurations will be captured in the ip_acl and ipv6_acl policies.

  • If the ACL configurations do not match with the ip_acl and ipv6_acl nvPairs, then those configurations will be captured in a smaller subset of per ACL freeforms, which means that MAC-based ACLs would continue to be captured into their individual switch freeforms.

Resolving Freeform Config Errors in Switches

Copy and paste the running-config to the freeform config with correct indentation, as seen in the running configuration on the NX-OS switches. The freeform config must match the running config. Otherwise, configuration compliance in Nexus Dashboard Fabric Controller marks the switches as out-of-sync.

Following is an example of the freeform config of a switch.

feature bash-shell
feature telemetry

clock timezone CET 1 0
# Daylight saving time is observed in
Metropolitan France from the last Sunday in March (02:00 CET) to the last Sunday in October (03:00 CEST) clock summer-time CEST 5 Sunday March 02:00 5 Sunday October 03:00 60
clock protocol ntp

telemetry
  destination-profile
    use-vrf management

The highlighted line about the daylight saving time is a comment that is not displayed in the show running config command output. Therefore, configuration compliance marks the switch as out-of-sync because the intent does not match the running configuration.

Next, check the running config in the switch for the clock protocol.

spine1# show run all | grep "clock protocol"
clock protocol ntp vdc 1

You can see that vdc 1 is missing from the freeform config.

In this example, let us copy-paste the running config to the freeform config.

Following is the updated freeform config:

feature bash-shell
feature telemetry

clock timezone CET 1 0
clock summer-time CEST 5 Sunday March 02:00 5 Sunday October 03:00 60 clock protocol ntp vdc 1

telemetry
  destination-profile
    use-vrf management

After you copy-paste the running config and deploy, the switch will be in-sync. When you click Recalculate Config, click the Pending Config column. You can view the Side-by-Side Comparison for information about the difference between the defined intent and the running config.

Deploying Freeform CLIs on a Specific Switch on a Per VRF/Network Basis

  1. Navigate to Manage > Fabrics.

  2. Select the fabric, then select Edit Fabric from the Actions drop-down list.

  3. Click the VRFs tab.

  4. From the Actions drop-down list, select Create.

    The Create VRF screen comes up.

  5. Select an individual switch.

    The VRF attachment form is displayed, listing the switch that is selected. In the case of a vPC pair, both switches belonging to the pair are displayed.

  6. Under the CLI Freeform column, select the button labeled Freeform config. This option allows a user to specify additional configurations that should be deployed to the switch along with the VRF profile configuration.

  7. Add or update the CLIs in the Free Form Config CLI box. Copy-paste the intended configuration with the correct indentation, as seen in the running configuration on the Nexus switches. For more information, see Resolving Freeform Config Errors in Switches.

  8. Click Deploy Config.

    note.svg

    The Freeform config button will be gray when there is no per VRF per switch config specified. The button will be blue when some config has been saved by the user.

    After the policy is saved, click Save on the VRF Attachment pop-up to save the intent to deploy the VRF to that switch. Ensure that the checkbox on the left next to the switch is checked.

  9. (Optional) Click Preview to look at the configuration that will be pushed to the switch.

  10. Click Deploy Config to push the configuration to the switch.

The same procedure can be used to define a per network per switch configuration.

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.

Need help?