Frame Relay Notes

• Packeteer's Frame Relay feature is not available on the PacketShaper 1200 and 1400 Lite models.
  
  
• PacketWise cannot properly construct the frame routing table if the router is not using subinterfaces in its Frame Relay configuration. (For example, if the serial WAN interface is Serial0, all the PVCs are mapped to Serial0 instead of being mapped to the virtual subinterfaces created on Serial0 — Serial0.1, Serial0.2, Serial0.3 etc.) To make PVC classify properly, try one of the following:
  
  Reconfigure your router to use subinterfaces, or
  
  Edit the matching rules of the PVC classes to include the appropriate subnet and addressing information.
  
  
• If the CIR that PacketWise picks up from the router for the initial configuration of a given PVC is greater than the link size, PacketWise will create the PVC partition with a minimum size equal to the link size. Keep in mind that if you have more than one PVC that falls into this situation, after this initial configuration, PacketWise will proceed to adjust each of the partition minimums to deal with this oversubscription of the link.
  
  As an example, suppose you have a 128k link and two PVCs. One PVC has been configured with a CIR of 256k on the FRAD; the other with a CIR of 512k. When the initial configuration is set up with the frame add command, the Frame Relay feature will detect that each CIR is greater than the link size. For each PVC, PacketWise will create a partition that has a new CIR (minimum size) of the link size (128k). Then, because both partition minimums add up to a value greater than the link size, PacketWise will handle this oversubscription scenario by setting each of the two 128k minimums to 64k, or half of the link size. The end result is that each PVC partition will each have a new CIR of 64k.
  
  
• For Frame Relay PVC classes, be sure to leave the server location set to any. If the location is set to inside or outside, any traffic on the PVC to or from a server that does not match the server location, will not be classified under the PVC class. This traffic will be tracked in a separate sibling class.
  
  
• The partition identifiers listed in the Frame Statistics output will not change if the PVC class names are changed. They will remain so long as the corresponding DLCI’s configured in the router remain the same. This allows consistent SNMP management.
  
  
• If Frame Relay is configured, the traffic tree will have PVC classes at the top of the Inbound and Outbound branches. If Traffic Discovery is enabled for these classes and the PacketShaper has been accessed from the outside via a browser, HTTP classes will begin appearing as children of the PVC classes. Any traffic that previously would have been classified by the Localhost (PacketShaper) class will now be classified by these new HTTP classes. (This is necessary to properly account for the bandwidth in the PVC partition.) To distinguish PacketShaper traffic from other web traffic, create a child Localhost class under each of the HTTP classes.
  
  
• If any network abnormalities hinder the unit from completing its routing table, you must reset the PacketShaper to reactivate the Frame Relay feature.
  
  
• Do not manually delete Frame Relay classes or partitions with the class delete or partition remove commands. The feature automatically removes Frame Relay classes based on the Frame Relay configuration of the local FRAD. Any PVCs considered inactive or invalid, but still configured on the router, are kept in the PacketShaper configuration.

PacketGuide™ for PacketWise® 7.4