If I choose VMKnic policy as "Load balance SrcID", can I later on change my individual virtual wire VM port group to use Failover policy?
I'd like to have VNI 5000 port-group always use Uplink1, VNI 5001 port-group always use Uplink2 while VTEP Vmknic are based on "Load Balance SrcID"?
From Web GUI, I can make such a change but my existing or new VMs for a specific VNI group are not consistently mapped to what I specified as the active uplink.
No, it is not supported to modify the teaming policy on any portgroups for VXLAN logical switches directly through VC. If you want both uplinks to be used, stick with the Load Balance - SRC ID teaming policy.
I will try to answer but i am not sure if it is correct.
When a VM communicates with another VM on same logical switch but on different host and in same cluster it then uses Logical switch port group teaming policy.
When a VM Communicates with another VM on same logical switch but on different host and different cluster it then uses VMKNIC Teaming Policy.
hello, what i believe is totally different guys, any vm member of a logical switch always use the VTEP interface or interfaces of the host it resides on based on the teaming policy defined when u configure the VXLAN for the cluster that host is member of, so it uses the VTEP interface or interfaces for any external communication, but if it tries to communicate with another vm on the same host even if it is in a different logical switch then the traffic doesnt even hit the physical network that is the case if the distributed logical router is in use for L3 traffic.
Copy&Past from NSX Design Guide Page 74:
• VDS offers great flexibility for what concerns uplinks connectivity. Every port-group defined as part of a VDS could,
in principle, make use of a different teaming option, depending on the requirements of the traffic associated to that
specific port-group.
• The teaming option associated to a given port-group must be the same for all the ESXi hosts connected to that
specific VDS (even if belonging to separate clusters). Still referring to the case of the VXLAN transport port-group,
if the LACP teaming option is chosen for the ESXi hosts part of compute cluster 1, this same option must be
applied to all the other compute clusters connected to the same VDS. Trying to choose a different teaming option
for a different cluster would not be accepted and will trigger an error message at the time of VXLAN provisioning.
• If LACP or Static EtherChannel is selected as the teaming option for VXLAN traffic for clusters belonging to a given
VDS, then the same option should be used for all the other port-groups (traffic types) defined on the VDS. The
reason is that the ether-channel teaming choice implies a requirement of configuring a port-channel also on the
physical network side. Once the physical ESXi uplinks are bundled in a port-channel on the physical switch (or
switches), using a different teaming method on the host side may result in unpredictable results (and often in loss
of communication).
Teaming Policy for Virtual Distributed Switches:
You should choose a teaming policy for VXLAN transport based on the topology of your physical switches. It is recommended that you do not mix teaming policies for different portgroups on a vSphere Distributed Switch. If uplinks are shared in these different teaming policies, then traffic will be interrupted. For a Logical Distributed Router, mixed teaming policies may result in routing problems. As a best practice - if you want to use IP hash based teaming (Ether channel, LACPv1, or LACPv2), use all uplinks on the vSphere Distributed Switch for the team and do not have portgroups on that vSphere Distributed Switch with different teaming policies.
VM to VM Traffic goes through Logical switch Port Group or VMknic VTEP Port Group.
No, it is not supported to modify the teaming policy on any portgroups for VXLAN logical switches directly through VC. If you want both uplinks to be used, stick with the Load Balance - SRC ID teaming policy.
Thanks Ray. That cleared up my confusion.
Thank you Roie(love your blog), hs77 and dywanah.