Filter
Top Products
Page 37 | AlliedWare Plus™ OS: Overview of QoS
5: Policing combined traffic types on combined ports
In this scenario, two types of traffic are collectively policed on multiple ports collectively. The
policer counts all the packets that match either type’s class map on any of the ports.
This scenario uses an aggregate policer.
For example, consider a situation in which the switch has an uplink port connected to an ISP,
and the service contract with the ISP stipulates that they will undertake to deliver a total of
x Mbps of realtime traffic, y Mbps of interactive session traffic, and z Mbps of best-effort
traffic. The switch needs to police its aggregate traffic to these stipulated service levels. So,
the traffic arriving via all the inward-facing ports needs to be collectively policed to the levels
stipulated in the contract, and then delivered to the ISP via the uplink port.
However, there are probably multiple different types of traffic that come under the heading of
“realtime” traffic, and different marking (DSCP, CoS, queue) that needs to be applied to each
of those component traffic types. These different component traffic types need to be put into
different class maps, and the “realtime” policing needs to be applied collectively to all those
class maps.
Similarly, policing needs to be applied collectively to multiple class maps if there are multiple
separate types making up the “interactive session” traffic, and the different component types
need different marking.
The following figure shows this scenario.
policy-map
match
match
class-map 2
ACL
match
match
class-map 1
match <parameter>
match access-group
class <map-name>
class <map-name>
aggregate
policer
police aggregate <name>
port
port
port
service-policy input <policy-name>
policer-5.eps