Technical data

Brocade ServerIron ADX Advanced Server Load Balancing Guide 55
53-1003441-01
Other transparent cache switching options
2
Why ICMP redirects do not solve the problem
The ServerIron ADX redirects HTTP traffic destined for the Internet to the cache server. When the
cache server responds to the client, it does so by sending its packets to its default gateway
because the users are not in the same subnet as the cache server. However, at Layer 3, the packet
is addressed to a client that is actually accessible through the remote access server (RAS).
The border access router (BAR) knows the proper next hop router is the RAS, through a routing
protocol, and retransmits the packet to the RAS, at Layer 2. The RAS forwards the packet to the
client. Thus every packet to every client must go to the BAR and then be retransmitted. The BAR
port is already carrying all the fetch and refresh traffic from that cache and this additional traffic
can overload it.
• The BAR does not send an ICMP redirect in this case, as you might expect. A router sends ICMP
redirects only if the following conditions are met:
• The interface on which the packet comes into the router is the same as the interface on which
the packet gets routed out.
• 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 previously. When the cache server responds to a client, the first packet is forwarded to
the border access router (BAR) as discussed previously. 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