For a general overview of WAN Virtualization, please read the Overview article in the WAN Virtualization Product Documentation section.
General Cases
- Aggregation Case
- Aggregation is when multiple tunnels are in use concurrently.
- Enable ppp-use-delta to compensate for latency difference between tunnels.
- ppp-timeout set to default
- Non-Aggregation Case
- Traffic is routed over a single tunnel, or sessions are kept on a single tunnel at a time.
- Disable Dynamic Re-weighting
- The ppp-timeout default is 16ms
- If the “Total Packet Loss” is high, then increase the ppp-timeout to 32ms or 64ms.
Failover Use Case
This is a Non-Aggregation case. Use when:
- There are two or more active tunnels. This will require at least two WANs at one of the sites.
- Add a WAN Virtualization Static Route and only pick the primary tunnel.
- Set the maximum RTT/Loss to values that are the upper bound of what is acceptable for your traffic.
- Only one tunnel will be in use, until it hits the configured Loss/Latency threshold which triggers the tunnel failover.
The Voice and Data Use Case
This will build on the Failover Use Case. The major addition is that there will be two traffic types. One type of traffic is real-time voice and the other type is all other internet/data traffic. This requires more definition to the WAN Virtualization Static Route(s):
- One route will be for voice - it can be either: listed first; classified by a subnet(s); or classified by the UDP protocol with the appropriate port range.
- One route will be for data/Internet - this can be for all other traffic traffic (a default route) or classified by a subnet(s).
Network Cases
- The Routing Case
- All traffic is routed through the Ecessa - whether going through WAN Virtualization or not.
- The Bridging Case (Layer 2)
- The Ecessa is a pass-through device that bridges all traffic except for what the Ecessa routes over WAN Virtualization, a VPN, or out a WAN.
Configuration Notes
Static Routes
It is no longer recommended to use LAN Traffic Identification to classify what traffic should be put into the WAN Virtualization tunnels. In general, it is recommended to use Static Routes where the remote WAN Virtualization site that the traffic should be sent to is configured as the "Route."
This configuration offers the ability to:
- Fail into and out of an MPLS (with WAN Virtualization having more or less priority)
- Fail into and out of a Bridge.
QoS
Use priority QoS on the WAN link(s) unless using a bridge. Give WAN Virtualization (GRE and/or ESP) traffic high priority, usually in this order:
- ICMP (for WAN line testing)
- WAN Virtualization (GRE and/or ESP)
- All other traffic.
For general QoS configuration information, please see the articles located here.
VPN
If sending traffic over WAN Virtualization on a public WAN (usually common broadband like Cable or DSL) then it is recommended to encrypt the public tunnels to safeguard data.
For more information on this type of configuration, please refer to the Site Encryption article.
Statistics Interval
This value is used to define the time frame to calculate the Max RTT/Loss and is configured via the CLI by using the command wanvirt set stats-interval INTERVAL where INTERVAL is a unit of time in either seconds, minutes, hours, or days.
WAN Virtualization Static Routes
As described earlier in this article, WAN Virtualization static routes can play a key role in handling network traffic over multiple tunnels. For more information on configuration options, please see the Advanced Configuration article under the WAN Virtualization section.
WAN Virtualization MTU (10.5.3+ & 10.6.3+)
The MTU for the WAN Virtualization tunnels can be configured via the CLI by using the command wanvirt site modify alias SITE_NAME mtu MTU where SITE_NAME is the name of the remote WAN Virtualization site and the MTU is is the desired MTU value. This change should be made on both sides of the WAN Virtualization bond. The default MTU is set at 1500 but can be changed to 1454 for un-encrypted WAN Virtualization or 1400 for encrypted WAN Virtualization to achieve higher throughput.
0 Comments