Shulou(Shulou.com)06/03 Report--

When you use the Ethernet channel to bind the network card, the virtual machine network connection in the ESXi host will sometimes appear on and off. This problem occurs because the Nic binding properties are not propagated to the administrative network port group in ESXi.

From the load balancing policy drop-down menu of the port group, we can specify how the virtual switch loads the outbound traffic between the physical network cards within the group. It generally has the following ways:

1. Routing based on the source virtual port:

Select the uplink based on the virtual port ID on the switch. When a virtual switch selects an uplink for a virtual machine or VMkernel adapter, it always forwards traffic through the same uplink for that virtual machine or VMkernel adapter.

Note:

If the EtherChannel of the switch is not tied, it is based on the source port by default.

2. Routing based on IP hash:

Uplinks are selected based on the source and destination IP address hashes of each packet. For non-IP packets, the switch uses this data in the appropriate fields to calculate the hash value. IP-based grouping requires that the physical switch be configured with an Ethernet channel.

Note:

When the switch is bound with EtherChannel, the load balancing policy is set to be based on ip hash, so the virtual switch also needs to match it, so it should also be set to IP hash. The number of EtherChannel of the switch is limited. For example, some switches have 512. After adjusting the upper limit, it will be changed to 1024, but the number of internal ports will be reduced from 32 to 16.

3. Routing based on source MAC hash:

The uplink is selected based on the hash of the source Ethernet.

4. Routing based on physical Nic load:

Can be used for distributed port groups or distributed ports. Select the uplink based on the current load of the physical network adapter connected to the port group or port. If the uplink remains busy for 75% or more for 30 seconds, the host agent switch moves part of the virtual machine traffic to a physical adapter with available capacity.

Let's take a look at an example diagram of the Ether Channel network configuration:

Run this command to verify EtherChannel load balancing mode configuration:

Switch# show etherchannel load-balance

EtherChannel Load-Balancing Configuration:

Src-dst-ip

Mpls label-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:

Non-IP: Source XOR Destination MAC address

IPv4: Source XOR Destination IP address

IPv6: Source XOR Destination IP address

MPLS: Label or IP

Switch# show etherchannel summary

Flags: d-down P-bundled in port-channel

I-stand-alone s-suspended

H-Hot-standby (LACP only)

R-Layer3 S-Layer2

U-in use f-failed to allocate aggregator

M-not in use, minimum links not met

U-unsuitable for bundling

W-waiting to be aggregated

Number of channel-groups in use: 2

Number of aggregators: 2

Group Port-channel Protocol Ports

-+-

1 Po1 (SU)-Gi1/15 (P) Gi1/16 (P)

2 Po2 (SU)-Gi1/1 (P) Gi1/2 (P)

Switch# show etherchannel protocol

Channel-group listing:

Group: 1

-

Protocol:-(Mode ON)

Group: 2

-

Protocol:-(Mode ON)

Review the concept of link aggregation:

Ethernet channel: this is a link aggregation (port relay) method used to create a logical Ethernet link with a failover link by grouping two to eight physical Ethernet links, providing fault-tolerant and high-speed links between the switch, router and server. For additional information about Cisco EtherChannel, see Cisco's introduction to EtherChannel.

LACP or IEEE 802.3ad: link aggregation Control Protocol (LACP) is included in the IEEE specification as a way to control multiple physical ports bundled together to form a single logical channel. LACP allows network devices to negotiate auto-bundling links by sending LACP packets to peers (also directly connected devices that implement LACP). For more information about LACP, see Cisco's Link aggregation Control Protocol White Paper.

Note: LACP is only supported in vSphere 5.1 VDS 5.5 and 6.0 that use vSphere Distributed Switches (VDS) or Cisco Nexus 1000V. Some Huawei CE switches also support it.

EtherChannel is very similar to the 802.3ad:EtherChannel and IEEE 802.3ad standards and achieves the same goal. There are some differences between the two, except for EtherChannel, Cisco proprietary and 802.3ad are an open standard.

For more information about EtherChannel implementation, see the article series "understanding EtherChannel load balancing and Catalyst switch redundancy".

Scenarios supported by EtherChannel:

One IP to many IP connections. (host A has two connection sessions with hosts B and C)

Many IP to many IP connections. (multi-connection sessions between hosts An and B and hosts Cpene D, etc.)

Note: one IP to one IP connection through multiple NIC is not supported. (only one NIC is used for one connection session between host An and host B.)

Compatible with all ESXi / ESX VLAN configuration modes: VST,EST and VGT. For more information about these modes, see VLAN configuration on virtual switches, physical switches, and virtual machines (1003806).

Supported Cisco configurations: EtherChannel mode ON-(EtherChannel only enabled)

Supported HP configuration: trunk mode

Supported switch aggregation algorithm: IP-SRC-DST (short for IP-Source-Destination)

Supported virtual switch network card combination mode: IP HASH.

Note, however, that LACP support in vSphere Distributed Switch 5.1 only supports IP hash load balancing. In vSphere Distributed Switch 5.5 and later, all LACP load balancing algorithms are supported:

Do not use IP HASH load-balanced beacon probes.

Do not configure standby or unused uplinks with IP HASH load balancing.

VSphere Distributed Switch 5.1 supports only one EtherChannel per vNetwork distributed switch (vDS). However, vSphere Distributed Switch 5.5 and later supports multiple LAG.

Nic binding causes intermittent processing of virtual network connections in ESXi:

Please check the load balancing policy of the portgroup where the virtual machine is located. If the switch does EtherChannel, you need to choose the load balancing based on IP hash. If not, the route based on the source virtual port is selected by default. Accordingly, if the policy change does not take effect and still occurs intermittently, you can rebuild the port group and select the correct load balancing policy.

If the host is no longer connected to the vCenter Server after the virtual switch load balancing policy changes, use the following command:

# vim-cmd hostsvc/net/vswitch_setpolicy-nicteaming-policy=loadbalance_ip vSwitch0

# vim-cmd hostsvc/net/portgroup_set-nicteaming-policy=loadbalance_ip vSwitch0 "Management Network"

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.