How does one configure a PacketShaper to compress/accelerate Internet traffic?
Article ID: 165935
Updated On:
Products
Issue/Introduction
Xpress offers a way to specify that the entire Internet is "remote" to a tunnel. Assume a topology where there may be one or more edge sites which connect to a common core PacketShaper. From the perspective of the edge sites, the Internet is always reached via the core.
Internet-----LAN----CorePS---R----WAN----R----EdgePS-----LAN
10.0.1.0/24 10.0.2.0/24
Core PacketShaper Xpress-IP address: 10.0.1.10
Edge PacketShaper Xpress-IP address: 10.0.2.10
There is a unique configuration that needs to be applied to support this topology. The default tunnel discovery mechanism attempts to learn every host on the Internet for which flows are established. This would result in far more tunnel hosts being learned than the PacketShapers could support. The configuration steps outlined in this article provide a configuration for this topology.
Resolution
Note: This configuration can only be used in a hub-and-spoke topology. The edge PacketShapers cannot have tunnels established to other edge sites. (meshed topology)
1. Starting from a default configuration, first configure Xpress-IP addresses via the command line or browser interface.
2. Configure tunnel passwords on both PacketShapers. In this example, we'll use a tunnel password of "bluecoat:"
tunnel password bluecoat
3. On the edge PacketShaper, disable remote host discovery via RSVP. This step is needed to prevent the edge PacketShaper from attempting to learn Internet hosts via remote discovery.
setup variable tnlRemoteRsvpDiscovery 0
4. On the edge PacketShaper, create a static tunnel to the core Packetshaper. We'll name the tunnel "core" in this example, and use 10.0.1.10 as the Xpress-IP address of the core PacketShaper.
tunnel new main 10.0.1.10 core
5. Configure the address range 0.0.0.0-255.255.255.255 as remote on the tunnel you created in step 4.
tunnel remote add core 0.0.0.0-255.255.255.255
6. On the core PacketShaper, disable local tunnel learning. This step is needed to prevent the core PacketShaper from attempting to learn Internet hosts via local discovery.
setup variable tnlLocalArpDiscovery 0
setup variable tnlLocalIpDiscovery 0
7. Check for any unwanted local tunnel entries on the edge PacketShaper. These entries may have been learned prior to changing the tunnel discovery variables.
On the edge PacketShaper:
tunnel local show
The list should only include hosts/subnets on the inside of the edge PacketShaper. We have left local tunnel learning enabled on the edge PacketShaper. If hosts are being learned which are not on the inside of the edge PacketShaper, you will need to configure local static tunnel entries and disable tunnel discovery.
a. tunnel discovery off
b. tunnel local add main 10.0.2.0/24
c. flush incorrect dynamic tunnel local entries: tunnel local flush all
8. Flush all dynamic tunnel remote entries that may have been learned for the tunnel named "core" on the edge PacketShaper. There is no need for any dynamic tunnel remote entries because the address range configured in step 5 covers all hosts.
tunnel remote flush core
9. On the core PacketShaper, flush all dynamic tunnel local entries that may have been learned.
tunnel local flush all
10. Check the remote tunnel list on the core PacketShaper for the tunnel to the edge PacketShaper. Since we have not configured a static tunnel to the edge PacketShaper, a dynamic tunnel will form from the core to the edge PacketShaper. The list of hosts should match the local list of tunnel hosts on the edge PacketShaper
tunnel remote show 10.2.0.10:main
This configuration allows compression of flows from hosts behind the edge PacketShaper to the Internet or hosts located on the Inside of the core PacketShaper.
Feedback
