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

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

book

Article ID: 345895

calendar_today

Updated On:

Products

VMware NSX

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)

Environment

VMware NSX for vSphere 6.0.x
VMware NSX for vSphere 6.1.x
VMware NSX for vSphere 6.2.x
VMware NSX for vSphere 6.3.x
VMware NSX for vSphere 6.4.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 manager virtual machine.
  2. In the browser:
    1. Connect to the 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/<NSXManagerIP>/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/<NSXManagerIP>/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-####-####-####-54E48D508D90</vsmUuid>
    <nodeId>916287b3-####-####-####-83878dfe3e7f</nodeId>
    <revision>6</revision>
    <type>
    <typeName>VmwareDistributedVirtualSwitch</typeName>
    </type>
    <    name>vds-####-a</name>
    <scope>
    <id>datacenter-21</id>
    <objectTypeName>Datacenter</objectTypeName>
    <     name>Datacenter #### 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-####-####-####-54E48D508D90</vsmUuid>
    <nodeId>916287b3-####-####-####-83878dfe3e7f</nodeId>
    <revision>6</revision>
    <type>
    <typeName>VmwareDistributedVirtualSwitch</typeName>
    </type>
    <name>vds-####-a</name>
    <scope>
    <id>datacenter-21</id>
    <objectTypeName>Datacenter</objectTypeName>
    <name>Datacenter #### 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
    • 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://<NSXManagerIP>/api/2.0/vdn/switches/<dvs-##>
       
  7. Open the NSX 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 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 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.

Powered by Wolken Software