The data component follows these steps to process a packet with load balancing.
The bulk of the code that performs these steps is in the
equilibrium_process_packet() function, in the file
equilibrium-data_packet.c (other functions are called out where applicable).
Receive the packet.
The code that creates the data loops to receive packets is in the function
init_packet_loops(), and the code that receives packets is in the function
equilibrium_process_packet(); both are in the file
If it is not TCP, forward it back out immediately; otherwise continue.
Processing proceeds on the fast path and follows these steps:
At this point, the traffic is known to be egress traffic (it is going in the direction of the cluster), and no session exists for it. The application must perform additional processing on the packet to see if the traffic matches some application's parameters, for all the applications in the applicable service set (recall that a service set ID is transmitted with each packet). The application follows these steps:
Look up the session matching the addresses in the lookup table (for more information about the lookup table, see Sending and Receiving Status Updates).
When an address match is found, examine the ports. If the traffic is ingress traffic, the source port must match. If it is egress traffic, the destination port must match. If there is no match, resume the lookup until a match is found. (This only involves searching the list at a given table entry.)
If there is a match and the flow is for an application, interchange the address using the session information stored in the matching entry.
For egress traffic, load balance to the server stored in the session information (to preserve the session) and change the destination address to that of the server.
For ingress traffic, change the source address to the façade's address, since the client is expecting the reply from that address.
If there was a match, but the entry indicates that it is not application traffic, do nothing.
When matching is complete, forward the packet back out immediately; otherwise, continue.
If no match was found and the traffic is ingress traffic (it is coming from the direction of the cluster), forward the packet back out immediately; otherwise, proceed to Slow Path.
This design makes the following assumptions:
Check to see if the packet's destination address and destination port match those of an application in the matching service set.
If there is a match, find the server with the least load (the list is kept sorted to expedite this) and use it as the server for this new session. Session entries in the table are created with the needed information for the flow in both directions.
Otherwise there is no match, so this traffic does not belong to an application; but the application still creates a flow entry in the table for it (for faster lookups in the future); however, the age timeout of this flow is set to 5 minutes. This timeout value is not configurable. The packet is forwarded out immediately.
For all egress packets, apply URL filtering: search for the façade's address in any HTTP request's "Server" field. If found, replace the address with the real address of the server serving the session. (A domain name is normally used in the HTTP request, in which case no change is made; however, since this is not guaranteed, the application must also search for IP addresses.) The code to do this is in the function
http_request_filter() in the file
Because all egress packets are being searched for an HTTP request header, the application also logs each request with the server to which the request was directed. This is done through syslog, but the messages are pushed up to the control plane syslog file.
- The application always reads the initial IP fragment first; it forwards packets out until it encounters the initial fragment. This is necessary because no port information is present in trailing fragments, so the application cannot determine if the traffic matches that of an application. Additionally, the application must store the fragment ID from the initial fragment and match on this in trailing fragments as an alternative to examining the ports.
Sending and Receiving Status Updates
- Because HTTP requests could become fragmented (at various levels), the application is required to observe the start of the HTTP request header and the Server field in one packet.
© 2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5