Technical data

50 ServerIron ADX Advanced Server Load Balancing Guide
53-1002435-03
Other transparent cache switching options
2
• The route being used for the outgoing packet must not have been created or modified by an
ICMP redirect, and must not be the router's default route.
• The sub-net of the source IP address is the same as the sub-net of the next-hop IP address of
the routed packet.
• The packet must not be source routed.
• The router must be configured to send redirects.
The third rule is violated here because caches put the web server’s address in the source address
field rather than the cache’s address. Thus in this scenario, the packet is retransmitted to the best
next hop router (the RAS) but no ICMP redirect is sent.
The ServerIron ADX solution
Cache route optimization of the ServerIron ADX is a Layer 2 mechanism that solves the problem
described above. When the cache server responds to a client, the first packet is forwarded to the
border access router (BAR) as discussed above. The BAR then retransmits the packet with the
remote access server (RAS) as the destination MAC address and the BAR as the source MAC. The
ServerIron ADX examines the packet at Layer 4. The ServerIron ADX finds a session table entry for
this packet and knows it came from the cache server. The ServerIron ADX knows the packet has
been re-transmitted because the packet’s source MAC address isn’t the cache server’s MAC
address and the input port isn’t the cache server’s port. The ServerIron ADX also recognizes that
for this particular TCP session, it has seen the same packet with two different destination MAC
addresses and knows that the second MAC address is the more appropriate one to use.
The ServerIron ADX contains a state table that includes a field for a MAC address. Initially this field
is blank. If the ServerIron ADX sees that a packet has been re-transmitted, the ServerIron ADX
places the new destination MAC address (the RAS MAC address) in the state table. When
subsequent packets are sent from the cache server, the ServerIron ADX sees that there is a MAC
address in the state table and replaces the destination MAC address with this address and
forwards the packet.
How cache route optimization works
Each TCP connection between the cache and a client is tracked by the ServerIron ADX in a state
table. The state table uses a key made up of the Layer 4 header: source IP address, source TCP
port, destination IP address, and destination TCP port. The state table also has a field for a MAC
address. This field is initially set to null (empty). When the cache server sends a packet a client, the
ServerIron ADX examines its Layer 4 header and checks to see whether it matches an entry in the
state table. The ServerIron ADX also examines the source MAC address to verify that the cache sent
the packet. If the MAC address field in the state table is null, and it will be for the first packet, the
ServerIron ADX simply forwards the packet at Layer 2 to the cache’s default gateway, the BAR.
When the packet is re-transmitted by the BAR, the ServerIron ADX examines the Layer 4 header
again, and sees that it matches an existing connection. The ServerIron ADX also examines the
source MAC address to be sure the cache server sent the packet. In this case, the source MAC
address is the BAR’s MAC, not the cache server’s. The ServerIron ADX concludes that this packet
has been retransmitted and places the destination MAC address of the packet, the RAS’s MAC, into
the state table’s MAC address field for this connection. Then the packet is forwarded to the RAS at
Layer 2.
When the cache server transmits the next packet, the ServerIron ADX compares its Layer 4 header
to the state table and gets a match and now the entry has a MAC address in the MAC address field.
The ServerIron ADX replaces the destination address with the stored MAC address and transmits
the packet at Layer 2 using the new “optimum” MAC address. Thus all packets except the first
packet are sent directly to the optimum router.