Layer-2 WAN Deployments
The types of Layer-2 WANs as follows:
Layer-2 WANsBroadcast Layer-2 WANsLayer-2 WANs
On a Layer-2 WAN, Riverbed recommends setting the LAN router closest to the SteelHead as its in-path default gateway. For example, in
Figure 9‑21, SteelHead A must use 192.168.255.1 as its in-path default gateway and SteelHead B must use 192.168.255.2 as its in-path default gateway.
Figure 9‑21. SteelHeads Deployed in a Layer-2 WAN
If the links to the WAN carry 802.1Q tagged packets, and if the WAN service provider routes packets based on 802.1Q tags, it is necessary to configure the SteelHeads for 802.1Q deployment, and to use the full address transparency mode.
For information about full address transparency mode, see
Full Address Transparency.
Broadcast Layer-2 WANs
A Layer-2 broadcast network over the WAN is very similar to a Layer-2 WAN. However, a Layer-2 broadcast WAN behaves like a hub, whereby packets from each site are replicated over the WAN to all the other sites. For example, in
Figure 9‑22, Router 2 can detect traffic between 172.30.2.1 and 10.10.2.1.
Figure 9‑22. A Layer-2 Broadcast WAN Deployment
When deploying SteelHeads in a Layer-2 broadcast WAN, you must ensure that the correct SteelHead is handling the traffic. Furthermore, a Layer-2 Broadcast WAN is not compatible with simplified routing and therefore you must use static routes to avoid packet ricochet.
In
Figure 9‑22, when 172.30.2.1 sends a SYN packet toward 10.10.2.1, SteelHead A adds its probe option to the SYN packet (SYN+). The correct SteelHead that responds to this packet is SteelHead B, because it is closest to the 10.10.2.1 server. However, because of the Layer-2 Broadcast WAN, SteelHead C would also detect the SYN+ packet and respond to SteelHead A. This behavior creates two probe responses (SYN/ACK+) from two separate SteelHeads.
If the latency between SteelHead A and SteelHead C is lower than that of SteelHead A and SteelHead B, then SteelHead A receives the probe response from SteelHead C first. When the probe response SteelHead B arrives at SteelHead A, SteelHead A ignores the probe response, because it has already received a probe response from SteelHead C.
This is clearly an undesirable situation, because SteelHead A must be peering with SteelHead B and not SteelHead C when trying to reach the 10.10.2.1 server. To avoid this situation, enter the following CLI command:
in-path broadcast support enable
When broadcast support is enabled, the SteelHead checks its routing table to see whether it uses its LAN or WAN interface to reach the destination IP. If the destination IP is reachable through the LAN, the appliance sends a probe response to the sender. Otherwise, it simply ignores the probe request.
Alternatively, you can use a fixed-target rule to define the SteelHead peers. However, fixed-target rules might not be scalable for larger deployments.