1. Make sure the PacketShaper sees the proper traffic and in both directions.
- Incorrect Site Router setting: if you want to monitor all the traffic going through the PacketShaper, the Site Router setting should be none. Set a site router if you want to monitor traffic going only through that one router.
- Make sure that the traffic doesn’t flow through the PacketShaper more than once. If traffic flows through the appliance multiple times, it could have negative impact on classification, reporting, and performance.
- In watch mode, make sure all necessary IP/MAC addresses are added.
2. The Inbound and Outbound WAN link needs to end in K, M, or G.
- Customers sometimes forget to specify the unit (for example, entering 100 for link size, instead of 100M).
3. Reports are based on class tree structure. Consider report requirements before setting up the class tree.
- For example, if you want reports based on site subnets, you need to create a site-based class tree. See Traffic Tree Overview.
4. Back up configuration frequently.
- During initial deployment, you may want to experiment with different configuration settings. Symantec recommends making backups before each configuration strategy, so that you have something to return to if you decide to go back to the older configurations. This is also important for the production box.
- See Back Up a Configuration.
5. Don’t complicate things by applying policies and partitions to every class.
- By default, all classes have a policy of priority 3 and use the default Inbound or Outbound partition. If you have certain applications/classes that you want to restrict or prioritize, then apply policies and partitions to only those classes.
- Rate policies are recommended only if you want to guarantee/limit bandwidth per flow. Using excessive rate policies could complicate things.
- Rate policy is per flow, not per class. For example, if you have a rate policy of 50K-500K on a class, each flow can get up to 500K, so the total usage for the class can go much higher. If you want to limit the usage for all flows in that class to 500K, use a partition and set a limit.
6. Do not change default partitions and policies for Inbound class, Outbound class, Localhost class, and Default buckets.
- The default partition for Inbound and Outbound is Uncommitted-None, which allocates bandwidth that is not already committed to other classes. Changing this setting may have negative consequences. The default policy is Priority 3, and is an inheritable policy (meaning all flows that don’t have a policy will inherit this policy). Changing this to a low value may starve some flows.
7. Traffic is not being classified into the intended class and you don’t know which class it is classifying into.
- Check the matching rules of the intended class and make sure they are correct.
- Make sure all the necessary plug-ins are loaded. Go to the PacketShaper Download page and click Plug Ins for the PacketWise version you are using.
- Issue the following CLI command to see where the flow is hitting: traffic flow –tupxICA <ipaddress>. Check the matching rule for that class and see if there is any conflict.
8. What is the SameSide class?
9. Verify your settings.
- The setup show CLI command displays all basic settings; look over the settings, making sure that you did not configure anything incorrectly.
- Run net nic a couple times and make sure that the errors are not incrementing. If they are incrementing, try changing the Speed/Duplex setttings, cables, and makes sure the box is not overloaded.
- It is a good idea to configure failover bypass so that traffic is not blocked if the PacketShaper loses power. Configure the NIC settings on the devices connected to the PacketShaper such that they communicate with each other properly when PacketShaper goes into bypass mode.
- Use the ipfilter passthrough command to bypass traffic that is going through the PacketShaper but you don’t want to monitor/manage. This is sometimes necessary to bypass LAN to DMZ or LAN to Internal servers.
- Configure proper security settings on the inside/outside interfaces to allow necessary IP addresses. For example, when using the URL category feature, if you want to secure access to the outside interface, do not use the secure option because the URL category feature requires access to a number of outside web servers. Instead, use the list security option and add the IP addresses of the necessary servers to the exception list. Also, make sure the list contains the IP addresses of DNS servers, management hosts, heartbeat servers, etc.