Filter
Top Products
Page 33 | AlliedWare Plus™ OS: Overview of QoS
3: Policing one traffic type on separate ports, and
another traffic type on the same ports combined
In this scenario, one type of traffic is collectively policed on several ports, while another type
of traffic is individually policed on those ports. For the first traffic type, the policer counts all
the packets that match that type’s class map on any of the ports. For the second traffic type,
the policer separately counts packets that match that type’s class map on each port.
This scenario uses an aggregate policer and an ordinary policer. The switch aggregates traffic
over all the ports if the traffic matches the class map with the aggregate policer.
Use this type of scenario when you need to police, for example, realtime traffic to an overall
collective limit, but want to provide different levels of web-browsing bandwidth to different
users connected to the switch.
For example, you could have a VoIP phone and a PC connected to each of the user ports on
the switch, and the uplink port connected to an ISP that has contracted to accept x Mbps of
VoIP traffic. Each user can make only one phone call at a time (having only one phone), so
there is no point in applying individual VoIP bandwidth limits on each port. But, the overall
VoIP traffic needs to be limited to the level of the service contract.
However, for web browsing, any given user could potentially take up a large amount of
bandwidth, so to provide a fair service, each user's bandwidth needs to be individually
policed. (Also, maybe the system could police different users’ bandwidth to different levels).
The following figure shows this kind of scenario.
policy-map
port
port
port
match
match
class-map 2
ACL
match
match
aggregate
policer
class-map 1
match <parameter>
match access-group
police single-rate or
class <map-name>
class <map-name>
service-policy input <policy-name>
police twin-rate
policer
police aggregate <name>
policer-3.eps