Backhauled Internet Traffic

A backhauled topology transports traffic between a remote site and the Internet via a centralized backbone, such as the headquarters of an organization . Because of the layout, the traffic may go through an Exinda appliance at the headquarters twice. The traffic flows from the client through the appliance, turns around at a router, and goes back through the appliance to the destination. Backhauling traffic introduces various issues that need to be considered when configuring your Exinda appliance.

Multi-Bridge Circuits

Backhauling is problematic for accelerated traffic because you do not want to re-accelerate the traffic. The dual bridge bypass mode prevents traffic from being re-accelerated. By default, this mode is enabled.

In a backhauled topology, the traffic is transported over multiple bridges and you want each bridge to treat traffic differently so that the traffic is accelerated on the way in from the branch site and bypasses acceleration on the way out to the Internet. The dual bridge bypass mode ensures that only one bridge handles acceleration. The traffic is passed though the second bridge with no additional acceleration handling, that is, the traffic bypasses acceleration handling on the second bridge.

Consider traffic passing through the appliance from the WAN to the Internet as

WAN <-> br10 <-> router <-> br20 <-> internet

• For an incoming accelerated connection, the acceleration processing happens on the first WAN interface to see the SYN. In this case, where the connection is going to the Internet, the accelerated connection is processed on br10. That same traffic when seen on br20 is then passed though untouched (the traffic bypasses br20).
• For an outgoing accelerated connection, the acceleration processing will happen on the first bridge with a matching acceleration policy. In this case, where the connection is from the Internet, if there is an acceleration policy on br20, the acceleration policy is enacted on br20 and the traffic is left untouched on br10. Or if the acceleration policy was on br10, then the traffic is passed through br20 untouched and accelerated on br10.

Note that there are separate dual bridge bypass settings for acceleration and for monitoring. To learn more about dual bridge bypass, see Dual Bridge Bypass.

Sending Exinda-Specific Option Codes to the Internet

Consider backhauled traffic passing from the client to the Internet through two accelerated Exinda appliances - one at the client's branch site and one at headquarters:

Client -> Branch Exinda -> WAN -> Headquarters Exinda -> Internet

The Exinda appliances use the TCP option 30 on the SYN packets to detect which appliances will participate in accelerating the TCP connection. Normally, the Exinda appliance at the headquarters would send a SYN with an attached TCP option 30 to the server on the Internet just in case there is another Exinda appliance closer to the server. The End Acceleration feature enabled on the Exinda appliance at headquarters identifies that appliance as the end of the acceleration chain and will prevent the appliance from sending the TCP option 30 on the SYN packet to the Internet.

If, however, you have a hub-and-spoke topology, where the Exinda appliance at headquarters could either be the end of the acceleration chain when backhauling Internet traffic or it could be an Exinda in the middle for traffic transported between distributed branches via the headquarters, you will not want to enable this feature.

To learn more about this feature, see Configure TCP Acceleration.