Changing VXLAN teaming policy and MTU settings in VCNS 5.5.x and NSX 6.x
search cancel

Changing VXLAN teaming policy and MTU settings in VCNS 5.5.x and NSX 6.x

book

Article ID: 345895

calendar_today

Updated On:

Products

VMware NSX Networking

Issue/Introduction

This article provides steps to change the VXLAN teaming policy and/or MTU settings in VMware NSX for vSphere 6.x (NSX-V) and vCloud Networking and Security (VCNS).

Environment

VMware NSX for vSphere 6.1.x
VMware NSX for vSphere 6.0.x
VMware NSX for vSphere 6.4.x
VMware NSX for vSphere 6.2.x
VMware NSX for vSphere 6.3.x
VMware vCloud Networking and Security 5.5.x

Resolution

To change the VXLAN teaming policy and MTU settings, unprepare the cluster for VXLAN and reprepare the cluster to apply the new settings from the client.

Note: This does not change MTU or teaming policy of pre-existing port groups. You still have to manually update the teaming policy and/or MTU of VXLAN port groups which have already been deployed (vmkernel and virtual wire/logical switch port groups).

To change the VXLAN teaming policy or MTU in vShield/NSX manager, use API calls to update the settings without redeploying the cluster:

Caution: This procedure modifies the database. Ensure to take a backup of the configuration files before proceeding.

  1. Take a snapshot of NSX/VCNS manager virtual machine.
  2. In the browser:
    1. Connect to the vShield manager or NSX web interface.
    2. In a new tab open the REST Client Plugin.
    3. Configure your authentication settings (basic settings).
    4. Configure the application/xml Content-Type header.
       
  3. Perform a query against all vxlan prepared switches using API call:

    Method: GET
    URL: https://NSX/vShieldIP/api/2.0/vdn/switches

    In the output, locate the switch you would like to modify and make a note of it. For example, dvs-35.
  4. Perform another GET against the specific switch:

    Method: GET
    URL: https://NSX/vShieldIP/api/2.0/vdn/switches/dvs-35

    For example:

    You see output similar to:

    <vdsContext>
    <switch>
    <objectId>dvs-35</objectId>
    <objectTypeName>VmwareDistributedVirtualSwitch</objectTypeName>
    <vsmUuid>423A993F-BEE6-1285-58F1-54E48D508D90</vsmUuid>
    <nodeId>916287b3-761d-430b-8ab2-83878dfe3e7f</nodeId>
    <revision>6</revision>
    <type>
    <typeName>VmwareDistributedVirtualSwitch</typeName>
    </type>
    <
    name>vds-site-a</name>
    <scope>
    <id>datacenter-21</id>
    <objectTypeName>Datacenter</objectTypeName>
    <
    name>Datacenter Site A</name>
    </scope>
    <clientHandle/>
    <extendedAttributes/>
    <isUniversal>false</isUniversal>
    <universalRevision>0</universalRevision>
    </switch>
    <mtu>1600</mtu>
    <teaming>FAILOVER_ORDER</teaming>
    <uplinkPortName>Uplink 4</uplinkPortName>
    <promiscuousMode>false</promiscuousMode<br></vdsContext>

     
  5. To change the teaming policy on a vDS. In this example, you are changing the teaming policy of dvs-35 to LOADBALANCE_SRCMAC, use this API call:

    For the Body, Copy the output of step 4’s API call and use that as the body of your next call.

    Modify the parameters that are to be changed such as teaming policy and/or MTU

    For example:

    To change to 9000 MTU and a Load Balancing Source MAC teaming policy:

    <vdsContext>
    <switch>
    <objectId>dvs-35</objectId>
    <objectTypeName>VmwareDistributedVirtualSwitch</objectTypeName>
    <vsmUuid>423A993F-BEE6-1285-58F1-54E48D508D90</vsmUuid>
    <nodeId>916287b3-761d-430b-8ab2-83878dfe3e7f</nodeId>
    <revision>6</revision>
    <type>
    <typeName>VmwareDistributedVirtualSwitch</typeName>
    </type>
    <name>vds-site-a</name>
    <scope>
    <id>datacenter-21</id>
    <objectTypeName>Datacenter</objectTypeName>
    <name>Datacenter Site A</name>
    </scope>
    <clientHandle/>
    <extendedAttributes/>
    <isUniversal>false</isUniversal>
    <universalRevision>0</universalRevision>
    </switch>
    <mtu>9000</mtu>
    <teaming>LOADBALANCE_SRCMAC</teaming>
    <uplinkPortName>Uplink 4</uplinkPortName>
    <promiscuousMode>false</promiscuousMode>
    </vdsContext>


    Following is a list of valid teaming policy entries in the <teaming>Teaming_policy</teaming>line:

    • Method: PUT
    • For VCNS: URL: https://<vShieldIP>/api/2.0/vdn/switches/<dvs-35>
    • For NSX: URL: https://<NSXManagerIP>/api/2.0/vdn/switches
    • FAILOVER_ORDER
    • ETHER_CHANNEL
    • LACP_ACTIVE
    • LACP_PASSIVE
    • LOADBALANCE_LOADBASED
    • LOADBALANCE_SRCID
    • LOADBALANCE_SRCMAC
    • LACP_V2
       
  6. To verify the syntax used is correct and the change is active you can query the switch configuration again with the GET command pointed at the vDS you are working with. For example:
     
    • Method:GET
    • URL: https://<NSX/vShieldIP>/api/2.0/vdn/switches/<dvs-35>
       
  7. Open the NSX/vShielduser interface to confirm the configuration changes are reflected.
  8. Change the settings on port groups that are already provisioned. The changes performed above only update the database and only take affect for future VXLAN vmkernel (vmknic) port groups deployments (new host preparations) and virtual wires (vxw- port groups). Port groups which are already provisioned by NSX/vShield on the vDS need to be updated manually using the vSphere client.
  9. Do a Force sync for the "Routing" and "VXLAN" services from "Installation and Upgrade > Host Prep > Cluster > Actions > Force Sync Services". This ensures that DLR related changes are reflected correctly on the hosts.



Additional Information

For more information on querying NSX/vShield vDS configurations using vSphere APIs, see: Best practices for using snapshots in the vSphere environment

Impact/Risks:
Incorrect modification of switch related database entries using PUT API calls can lead to an outage. It is recommended to take a snapshot of NSX/VCNS manager before making any changes.