Fujitsu BX600 User Manual page 23

Smart Load Balancing enables both transmit and receive load balancing based on the Layer 3/Layer 4
IP address and TCP/UDP port number. In other words, the load balancing is not done at a byte or
frame level but on a TCP/UDP session basis. This methodology is required to maintain in-order
delivery of frames that belong to the same socket conversation. Load balancing is supported on 2-8
ports. These ports can include any combination of add-in adapters and LAN on Motherboard (LOM)
devices. Transmit load balancing is achieved by creating a hashing table using the source and
destination IP addresses and TCP/UDP port numbers.The same combination of source and
destination IP addresses and TCP/UDP port numbers will generally yield the same hash index and
therefore point to the same port in the team. When a port is selected to carry all the frames of a given
socket, the unique MAC address of the physical adapter is included in the frame, and not the team
MAC address. This is required to comply with the IEEE 802.3 standard. If two adapters transmit
using the same MAC address, then a duplicate MAC address situation would occur that the switch
could not handle.
Receive load balancing is achieved through an intermediate driver by sending gratuitous ARPs on a
client by client basis using the unicast address of each client as the destination address of the ARP
request (also known as a directed ARP). This is considered client load balancing and not traffic load
balancing. When the intermediate driver detects a significant load imbalance between the physical
adapters in an SLB team, it will generate G-ARPs in an effort to redistribute incoming frames. The
intermediate driver (BASP) does not answer ARP requests; only the software protocol stack provides
the required ARP Reply. The receive load balancing is a function of the number of clients that are
connecting to the system through the team interface.
SLB receive load balancing attempts to load balance incoming traffic for client machines across
physical ports in the team. It uses a modified gratuitous ARP to advertise a different MAC address for
the team IP Address in the sender physical and protocol address. This G-ARP is unicast with the
MAC and IP Address of a client machine in the target physical and protocol address respectively.
This causes the target client to update its ARP cache with a new MAC address map to the team IP
address. G-ARPs are not broadcast because this would cause all clients to send their traffic to the
same port. As a result, the benefits achieved through client load balancing would be eliminated, and
could cause out of order frame delivery. This receive load balancing scheme works as long as all
clients and the teamed system are on the same subnet or broadcast domain.
When the clients and the system are on different subnets, and incoming traffic has to traverse a router,
the received traffic destined for the system is not load balanced. The physical adapter that the
intermediate driver has selected to carry the IP flow carries all of the traffic. When the router sends a
frame to the team IP address, it broadcasts an ARP request (if not in the ARP cache). The server
software stack generates an ARP reply with the team MAC address, but the intermediate driver
modifies the ARP reply and send it over a particular physical adapter, establishing the flow for that
session.
The reason is that ARP is not a routable protocol. It does not have an IP header and therefore is not
sent to the router or default gateway. ARP is only a local subnet protocol. In addition, since the G-
ARP is not a broadcast packet, the router will not process it and will not update its own ARP cache.
The only way that the router would process an ARP that is intended for another network device is if it
E
has Proxy ARP enabled and the host has no default gateway. This is very rare and not recommended
for most applications.
123
4 Broadcom Gigabit Ethernet Teaming Services