Application Scenarios for Traffic Policing

Traffic policing mainly applies to DS ingress node. Packets that exceed the SLA are dropped, or re-marked to ensure that packets conforming to the SLA are provided with guaranteed services. Figure 1 shows typical networking.

Figure 1 Application 1

As shown in Figure 2, a NetEngine 8000 F connects a wide area network (WAN) and a local area network (LAN). The LAN bandwidth (100 Mbit/s) is higher than the WAN bandwidth (2 Mbit/s). When a LAN user attempts to send a large amount of data to a WAN, the NetEngine 8000 F at the network edge is prone to traffic congestion. Traffic policing can be configured on the NetEngine 8000 F at the network edge to restrict the traffic rate, preventing traffic congestion.

Figure 2 Application 2

Interface-based Traffic Policing

Interface-based traffic policing controls all traffic that enters an interface and does not identify the packet types. As shown in Figure 3, a NetEngine 8000 F at an ISP network edge connects to three user networks. The SLA defines that each user can send traffic at a maximum rate of 256 kbit/s. However, burst traffic is sometimes transmitted. Traffic policing can be configured on the ingress NetEngine 8000 F at the ISP network edge to restrict the traffic rate to a maximum of 256 kbit/s. All excess traffic over 256 kbit/s will be dropped.

Figure 3 Interface-based traffic policing

Class-based Traffic Policing

The class-based traffic policy controls the rate of one or more types of packets that enter an interface but not all types of packets.

As shown in Figure 4, traffic from the three users at 1.1.1.1, 1.1.1.2, and 1.1.1.3 is converged to a NetEngine 8000 F. The SLA defines that each user can send traffic at a maximum rate of 256 kbit/s. However, burst traffic is sometimes transmitted. When a user sends a large amount of data, services of other users may be affected even if they send traffic at a rate lower than 256 kbit/s. To resolve this problem, configure traffic classification and traffic policing based on source IP addresses on the inbound interface of the device to control the rate of traffic sent from different users. The device drops excess traffic when the traffic rate of a certain user exceeds 256 kbit/s.

Figure 4 Class-based traffic policing

Multiple traffic policies must be configured on the inbound interface to implement different rate limits for data flows sent from different source hosts. The traffic policies take effect in the configuration order. The first traffic policy configured is the first to effect first after data traffic reaches the interface.

Combination of Traffic Policing and Other QoS Policies

Traffic policing and other QoS components can be implemented together to guarantee QoS network-wide.

Figure 5 shows how traffic policing works with congestion avoidance to control traffic. In this networking, four user networks connect to a NetEngine 8000 F at the ISP network edge. The SLA defines that each user can send FTP traffic at a maximum rate of 256 kbit/s. However, burst traffic is sometimes transmitted at a rate even higher than 1 Mbit/s. When a user sends a large amount of FTP data, FTP services of other users may be affected even if they send traffic at a rate lower than 256 kbit/s. To resolve this problem, configure class-based traffic policing on each inbound interface of the NetEngine 8000 F to monitor the FTP traffic and re-mark the DSCP values of packets. The traffic at a rate lower than or equal to 256 kbit/s is re-marked AF11. The traffic at a rate ranging from 256 kbit/s to 1 Mbit/s is re-marked AF12. The traffic at a rate higher than 1 Mbit/s is re-marked AF13. Weighted Random Early Detection (WRED) is configured as a drop policy for these types of traffic on outbound interfaces to prevent traffic congestion. WRED drops packets based on the DSCP values. Packets in AF13 are first dropped, and then AF12 and AF11 in sequence.

Figure 5 Combination of traffic policing and congestion avoidance

Statistics Collection of Traffic Policing

Traffic that enters a network must be controlled, and traffic statistics must be collected. Traditional statistics collection has the following defects:

For upstream traffic, only statistics about packets after a CAR operation is implemented can be collected. Statistics about the actual traffic in need and the packet loss during CAR are not provided.
For downstream traffic, only statistics about packets after a CAR operation is implemented can be collected. Statistics about the forwarded and dropped packets are not provided.

Carriers require statistics about traffic that has been implemented with CAR to analyze user traffic beyond the specifications, which provides a basis for persuasion of purchasing a higher bandwidth. Using the interface-based CAR statistics collection function, NetEngine 8000 Fs can collect and record statistics about the upstream traffic after a CAR operation (the actual access traffic of a user), as well as statistics about the forwarded and dropped downstream packets after a CAR operation.