Within ESXi 5.0, there are 4 methods of Load Balancing. As stated in the help
Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
This test is to review what "Route based on source MAC hash" does and how it perform the required traffic load balancing.
This Blog is for my personal use only.... it doesn't serve to be too informatives for any other persons in my perspective... unless you share the same hobby as mine...
Tuesday 18 October 2011
Wednesday 12 October 2011
ESXi 5.0 Load Balancing Test: Route based on IP hash
Within ESXi 5.0, there are 4 methods of Load Balancing. As stated in the help
Route based on the originating port ID Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash Select an uplink based on a hash of the source Ethernet.
Use explicit failover order Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
The test below is to test and study what "Route based on IP hash" does and how it perform traffic load balancing.
Route based on the originating port ID Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash Select an uplink based on a hash of the source Ethernet.
Use explicit failover order Always use the highest order uplink from the list of Active adapters that passes failover detection criteria.
The test below is to test and study what "Route based on IP hash" does and how it perform traffic load balancing.
ESXi 5.0 Load Balancing Test: Route based on the originating virtual port ID
Within ESXi 5.0, there are 4 methods of Load Balancing. As stated in the help
Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria. This test is to review what "Route based on the originating port ID" does and how it perform the required traffic load balancing.
Route based on the originating port ID
Select an uplink based on the virtual port where the traffic entered the standard switch.
Route based on ip hash
Select an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
Route based on source MAC hash
Select an uplink based on a hash of the source Ethernet.
Use explicit failover order
Always use the highest order uplink from the list of Active adapters that passes failover detection criteria. This test is to review what "Route based on the originating port ID" does and how it perform the required traffic load balancing.
Tuesday 11 October 2011
vSwitch Network Failover Detection Testing: Beacon Probing and Link Status
In ESXi 5.0, under vSwitch Network NIC Teaming, there is a Network Failover Detection field. It has two setting, Beacon Probing and Link Status Only.
Under the help Section, it state the following,
Link Status only
Relies solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or mis-configured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing
Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This option detects many of the failures mentioned above that are not detected by link status alone.
Note: Do not use beacon probing with IP-hash load balancing.
After three days of testing over weekends, I found Beacon Probing is very confusing, but it works.
Link Status is what stated above, nothing much to test. But Beacon Probing is Beacon + Link State.
Under the help Section, it state the following,
Link Status only
Relies solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or mis-configured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing
Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This option detects many of the failures mentioned above that are not detected by link status alone.
Note: Do not use beacon probing with IP-hash load balancing.
After three days of testing over weekends, I found Beacon Probing is very confusing, but it works.
Link Status is what stated above, nothing much to test. But Beacon Probing is Beacon + Link State.
Wednesday 5 October 2011
vSwitch Networking Security Testing - Part 2 MAC Address Changes
In ESXi 5.0 Networking Security, each vSwitch has the following Security Policy Tab.
A Windows 2008 R2 Server VM is installed in the ESXi 5.0 Server and a Port Group is created for this VM.
Under the help menu of "Edit Security Policy for a vSphere Standard Switch". It state the difference between these two setting
The confusion is, reference to where? or from which perspective? While doing networking for so many years, I came to understand that when we come to "Inbound" traffic and "Outbound" traffic, we must think like a Router or Switch. If I am a Router, any traffic that is coming into me is an "Inbound" traffic, the traffic can be from any interfaces. That goes the same to any traffic that is going out of me, which is an "Outbound" traffic, it can also be going out of any Interfaces. That goes the same if your are a Server.
But in the case of a Server it's "Inbound" traffic is the Physical Switch "Outbound" traffic, and the Server "Outbound" traffic is the Physical Switch "Inbound" traffic. When we read the traffic, we have to know where we stand. Inside the Server? or Inside the Switch. That is what I called perspective of things.
The problem with the above statement is that it does not state the "Inbound" and "Outbound" is from which perspective. From the virtual machine or from the virtual switch.
In any case, I am doing some test to find out.
- Promiscuous Mode: Accept or Reject
- MAC Address Changes: Accept or Reject
- Forged Transmits: Accept or Reject
A Windows 2008 R2 Server VM is installed in the ESXi 5.0 Server and a Port Group is created for this VM.
Under the help menu of "Edit Security Policy for a vSphere Standard Switch". It state the difference between these two setting
- MAC Address Changes
- Reject - If you set the MAC Address Changes to Reject and the guest operating system changes the MAC address of the adapter to anything other than what is in the .vmx configuration file, all inbound frames are dropped. If the Guest OS changes the MAC address back to match the MAC address in the .vmx configuration file, inbound frames are passed again.
- Accept - Changing the MAC address from the Guest OS has the intended effect: frames to the new MAC address are received.
- Forged Transmits
- Reject - Any outbound frame with a source MAC address that is different from the one currently set on the adapter are dropped.
- Accept - No filtering is performed and all outbound frames are passed.
The confusion is, reference to where? or from which perspective? While doing networking for so many years, I came to understand that when we come to "Inbound" traffic and "Outbound" traffic, we must think like a Router or Switch. If I am a Router, any traffic that is coming into me is an "Inbound" traffic, the traffic can be from any interfaces. That goes the same to any traffic that is going out of me, which is an "Outbound" traffic, it can also be going out of any Interfaces. That goes the same if your are a Server.
But in the case of a Server it's "Inbound" traffic is the Physical Switch "Outbound" traffic, and the Server "Outbound" traffic is the Physical Switch "Inbound" traffic. When we read the traffic, we have to know where we stand. Inside the Server? or Inside the Switch. That is what I called perspective of things.
The problem with the above statement is that it does not state the "Inbound" and "Outbound" is from which perspective. From the virtual machine or from the virtual switch.
In any case, I am doing some test to find out.
Subscribe to:
Posts (Atom)