When mapping your circuit to multiple bridges there are two scenarios to consider: backhauling traffic through your Exinda appliance and link aggregation through your Exinda appliance. The dual bridge bypass feature ensures that traffic is processed properly in these scenarios. Note that "dual" really means "multi" as traffic can pass through two or more bridges. There are separate dual bridge bypass settings for acceleration and for monitoring. Note that by default both acceleration and monitor for dual bridge bypass are enabled.
Backhauled traffic flows between distributed sites and the Internet via a centralized backbone, which is typically at headquarters. This means that traffic may go through your Exinda appliance at headquarters twice: from the source through the Exinda appliance, turning around at a router, back through the Exinda appliance, and on to the destination. This is problematic for accelerated traffic because you do not want to re-accelerate the traffic. The dual bridge bypass feature allows each bridge to treat traffic differently, so that the traffic is accelerated on one bridge on the way in and bypasses the acceleration handling from the second bridge on the way out.
Link aggregation maps multiple bridges to act as a single link. You may have a single router that is passing data through multiple bridges, where some packets may go over one bridge and some over the other. Or you may have multiple upstream service providers with asymmetric routes, where traffic may go out one bridge and return via another bridge. In this case, dual bridge bypass needs to be disabled so that traffic is handled the same regardless of which bridge it arrives on.
For acceleration, dual bridge bypass controls where packets are intercepted and passed to acceleration and edge cache.
This is desirable for backhaul settings but will cause traffic problems if there is asymmetric routing or link aggregation in use. Consider traffic passing through the appliance from the WAN to the Internet as:
WAN <-> br10 <-> router <-> br20 <-> internet
This is desirable for asymmetric routing or link aggregation, where you want traffic to switch bridges. However, in an accelerated backhauled scenario, the accelerated traffic cannot switch bridges and still function properly. The SYN from the client must be processed on the same bridge as the SYN/ACK from the server.
For monitoring, dual bridge bypass controls how flows are tracked and how flows appear in the real-time monitor.
This may be desirable when you have dual bridge bypass for acceleration enabled so that you can see all the policies applied to the flows. If traffic is both accelerated and edge cached you see the two separate flows in real-time, but they will not be coloured yellow and blue to indicate acceleration and edge cache. They will both be coloured the one of the two colours.
If you see the (A) symbol in the real-time monitor and you get asymmetric route warnings, either the appliance is not seeing half of the flow or the other half of the flow is on another bridge, where the flow is bypassing acceleration processing on the second bridge and therefore you need to disable dual bridge bypass for acceleration for it to work properly.
If you have two circuits configured on the Exinda such that traffic between the headquarters appliance and the branch appliance goes through one circuit and the traffic between the headquarters appliance and the internet goes through a second circuit, then the traffic for a single flow will be counted in the appropriate virtual circuit for each circuit.
When doing load balancing, failover, link bonding, or seeing asymmetric routes (either locally or in a HA cluster), you will want to turn off the monitor dual bridge bypass function to get back to a merged view of all flows.
|
|