Download 3.8 MB - Juniper Networks

DX Application Acceleration Platform
Connection Binding and Layer 7 Health Checking
When L7 health checking is enabled and the target servers are NTLM-enabled, the
expected HTTP return code of the health check should be set to 401 instead of the
default of 200. Because the health check connections from the DX appliance to the
target servers are not NTLM authenticated connections, health check requests
return 401 “Unauthorized” instead of 200 “OK”. The DX appliance can make sure
that the web server is up and running, but access to content is denied due to the
non-authenticated connection.
To set the expected return code to 401, enter the command:
dx%
set cluster <name> health returncode 401
Reverse Route Return
With “Reverse Route Return”, the DX appliance automatically adds routes when
packets come back from a node that does not already appear in the DX appliance’s
routing table. The problem reverse route return solves is that it is possible to lose
packets when there is more than one gateway and the default gateway is not where
the packet originated. Reverse route return allows response packets to be sent to
the router that originally sent the request packets. This is done automatically,
without the user having to manually configure static routes (a very time-consuming,
error prone procedure).
For example, assume that there are two routers in the network (R 1 and R 2) and
R 1 is the default gateway. If the DX appliance receives a packet from R 2 and there
are no routes configured for the particular destination, the response will be routed
towards R 1.The information that the request (or original packet) came from R 2
instead of R 1 is not included. Reverse route return remembers the path where the
request was originated and enables the DX appliance to send the packet back to the
router from which it was received.
Behavior
Normally, when a packet arrives on aDX Application Acceleration Platform from a
node, it is not guaranteed that the response to the packet will go back to the same
node. This is because of the way routing works in the operating system. Routing
does not “remember” the node from which it received the packet. Instead the
routing module decides where the packet should go by using current entries its
routing table. In cases where there is no explicit routing entry for the destination,
the packet is sent to the default gateway.
If the original packet did not arrive from the default gateway, but instead arrived
from a different route, the response may not reach the actual destination. One way
to counter this problem is to have the user configure static routes to the destination
manually, but this method is not only time-consuming, but also error prone. Also at
times it may not be possible to predict the path that a packet will take before
arriving at the DX appliance. The solution to this problem is whenever a packet is
received in the system, it is checked for following cases:
90
„
„
Did the packet originate from another network?
„
The incoming packet is from the DX appliance’s default gateway.
Connection Binding and Layer 7 Health Checking