Problem

The MAC Forwarding method has some advantages over the Forwarding methods used by many Load Balancers. MAC Forwarding only forwards packets received from client to backend servers. The SourceIP=Clientip remains intact so the backend responds back to source and not the Edge LB as would be the case for NAT where SourceIP is replaced by a returnaddress on the Load Balancer. This means MAC Forwarding only handles half the traffic of NAT or can handle twice the traffic of NAT and so provides better performance and throughput. Since MAC Forwarding keeps SourceIP=Clientip it is easy to log clientip in the backend server access logs where as with NAT the clientip is lost and Edge is not a server type that has an equivalent to an access log. It is easy to get excited about setting up an Edge Load Balancer and configuring for MAC forwarding but the difficult work is in configuring the backend servers. The backend servers can be configured and tested for MAC forwarding without the Edge server once a clusterip address has been assigned. Pre-testing the clusterip address on each backend server will help ensure successful MAC Forwarding config of the Edge Load Balancer. To cluster a number of tcpip addresses under a single ClusterIP/VirtualIP most load balancers replace the destinationip=clusterip in the packet with a serverip of a backend server as defined in the load balancer cluster config. This prevents duplicate ip of the clusterip address since only the load balancer owns the clusterip on the network so clusterip stops at the load balancer. This usually means that SourceIP=Clientip has to change also to a returnaddress of the load balancer. This in effect makes the load balancer a proxy point remaining inbetween client and backend. In MAC Forwarding the Source and Destination IP address remain intact in the packet. Only the MAC Address for the Destination is changed to a MAC address of a backend server defined in the Load Balancer config. In MAC Forwarding the backend server receives a packet with sourceip=clientip and destinationip=clusterip therefore the backend server and client will be unware of the packet forwarder (Edge LB) but more importantly each backend server must also have the clusterip aliased. How can we alias this clusterip on multiple machines without creating a DUP IP situation on the network? We do this by aliasing the clusterip on a loopback adapter/interface on each backend server. Loopbacks do not announce or advertise their ip address on the network (except for Linux but arp suppression can be configured for the loopback to control the behavior). Backend server network adapters/interfaces can be configured to accept packets for ipaddresses aliased on the loopback. This may even be default behavior for the OS in use. This allows the backend server to own the clusterip within its own local scope of the machine but not on the network and so preventing dup ip. This also supports configuring the backend HTTP or LDAP server to listen and startup on the clusterip. MAC Forwarding usually requires the Edge, Backend Servers and Clusterip be part of the same TCPIP subnet. IP routing stops at the subnet router and is then routed as Local Area Network Ethernet using MAC address. Only the subnet router has the ARP table of MAC to ipaddresses for that subnet. Notice you do not configure the backend MAC addresses in the Edge config. You configure the backend ipaddress or hostname. Edge gets the MAC addresses of the backends from the subnet router. Edge MAC Forwarding is very dependant on ARP (Address Resolution Protocol), normal ethernet behavior and proper communication with the subnet router.