Traffic shapers and policers use packet traffic descriptors to ensure adherence to the service level agreement in QoS. However,
when traffic flows from one hop to another in a network, headers added or removed at interim hops affect the packet bytes
being accounted for by QoS at each hop. When your end-user network measures the packet bytes to ensure they receive the payload
as agreed, these additional header bytes cause a discrepancy.
QoS overhead accounting provides the flexibility to operators to decide which header bytes can be excluded by the traffic
shaper and policer and which can be included, depending on the end user’s requirements and device capabilities, to meet the
committed payload in units of bytes.
For example, if the QoS commitment includes the additional header bytes, the overhead accounting feature allows your router
to account for this overhead and reduces the traffic policing and shaping rates accordingly. This is also called a positive accounting overhead.
If however, the committed rate doesn’t include the additional bytes, overhead accounting allows your router to adjust the
core stream traffic such that the traffic policing and shaping rates are increased. This is also called a negative accounting overhead.
To summarize, QoS overhead accounting enables the router to account for packet overhead when shaping and policing traffic
to a specific rate. This accounting ensures that the router runs QoS features on the actual bandwidth that the subscriber
traffic consumes.
Any interface that supports QoS policies supports overhead accounting.
Note
|
You can enable user overhead accounting using the optional configuration of accounting user-defined
<overhead size in bytes> while attaching the service policy on the egress interface.
|
Guidelines and Restrictions
-
Overhead accounting for ingress shaping is not supported.
-
You can't program more than one compensation value per NPU or router, even if they're on different egress ports.
-
You can configure the same egress compensation for different egress ports.
The following restrictions apply for routers that have Cisco NC57 line cards installed and operate in native and compatibility
modes.
-
More than one compensation value can be programmed, provided you configure egress policy maps on different egress ports.
-
You must configure a unique compensation value for a main interface and all sub-interfaces belonging to that main interface.
You can't program different compensation values on different sub-interfaces sharing a common main interface.
-
You can configure different compensation values on different sub-interfaces if they belong to other main interfaces.
-
Compensation value programmed on egress queues (but not on VoQs) will remain active until the last egress policy map (with
header compensation) is removed from main or sub-interfaces. This may impact traffic flow on main and sub-interfaces even
though no compensation is set for them.
The following restrictions apply for routers that have line cards other than Cisco NC57 line cards.
-
You can't program more than one compensation value per NPU or router, even if they're on different egress ports.
-
You can configure the same egress compensation for different egress ports.
-
NPUs can have different compensation values configured on different line cards in a modular system.
-
Compensation value programmed on egress queues (but not on VoQs) will remain active until the last egress policy map (with
header compensation) is removed from main or sub-interfaces. This may impact traffic flow on main and sub-interfaces even
though no compensation is set for them.
Configuring for Overhead Accounting
To configure overhead accounting, you must:
-
Create a policy map and configure QoS actions for that map.
-
Configure overhead accounting and attach the map to an interface.
/* create QoS policy */
Router#configure terminal
Router(config)#policy-map policer
Router(config-pmap)#class class-default
Router(config-pmap-c)#police rate percent 10
Router(config-pmap-c-police)#commit
/* configure account overhead value while attaching the QoS policy to interface */
Router(config)#int hundredGigE 0/0/0/2
Router(config-if)#service-policy input policer account user-defined 12
Router(config-if)#commit
Router(config-if)#root
Router(config)#end
Running ConfigurationRouter#sh run int hundredGigE 0/0/0/2
interface HundredGigE0/0/0/2
service-policy input policer account user-defined 12
!
The following example shows how to configure a negative overhead accounting value:
Router#conf
Router(config)#int hundredGigE 0/0/0/2
Router(config-if)#service-policy input policer account user-defined -12
Router(config-if)#commit
To modify an overhead accounting value, you must:
-
Remove the existing QoS policy and re-add it.
-
Configure the new overhead accounting value.
Router#conf
Router(config)#int hundredGigE 0/0/0/2
Router(config-if)#no service-policy input policer
Router(config-if)#service-policy input policer account user-defined -20
Router(config-if)#commit
Router#sh run int hundredGigE 0/0/0/2
interface HundredGigE0/0/0/2
service-policy input policer account user-defined -20
!
Positive Accounting Use Case
If QoS commitment includes Preamble, Frame Delimiter & Interframe Gap and has the following configuration:service-policy input <foo> account user-defined +20
For QoS purposes, your router treats this packet as a packet of size = Actual Packet size + 20. Hence, the effective policing
and shaping is reduced to match the downstream interface.
Negative Accounting Use Case
If QoS commitment to your router does not include VLAN header information, and has the following configuration:
service-policy input <foo> account user-defined -4
For QoS purposes, your router treats this packet as a packet of size = Actual Packet size – 4. Hence, the effective policing
and shaping is increased to match the downstream interface.
Associated Commands
service-policy (overhead accounting)