Table of Contents
Advertisement
Overview
FCs that use meters/policers and BUM traffic-type policers (if in use) will use the aggregate meter
configured for hierarchical ingress policing.
When 'no queue' command is executed, then the FC is updated to use the default meter. User can
change the meter association, if need be.
Under a FC, only a single queue for use with unicast traffic is allowed. All other traffic types (i.e.
BUM) share a single set of 8 ingress queues in the system.
A FC that is using a queue uses a classification entry to match the appropriate fields in the received
unicast traffic and assign it the configured queue and profile. The classification entries specified
through num-qos-resources are shared among all the FCs in use (FCs could be using meters or
queues).
An aggregate shaper per SAP is available to limit the ingress rate per SAP. It applies only to
unicast traffic that uses SAP ingress queues. Per SAP aggregate meter can be used to rate-limit
traffic (unicast and BUM) that use meters.
User is provided with an option to assign a profile to SAP ingress queued traffic. In the SAP
ingress policy, classification entries allows for profile configuration in- addition to a FC
configuration. Profile can be specified as 'in' (in-profile) or 'out' (out-of-profile). Profile
parameter is applicable only for FC that uses a queue. For a FC that uses meter, the system will
ignore the configured profile and uses the profile as determined by the meter/policer. The profile
(either assigned by the user or determined by the policer) is used subsequently to determine the
slope to use at the ingress and egress queuing points and is used for egress marking (if enabled).
SAP-based scheduling (as available for egress SAPs) will used for scheduling the unicast SAP
ingress queues. In other words, the available ingress bandwidth is distributed equally among all
the SAPs, up to the SAP aggregate shaper rate. In turn the SAP scheduler, that enforces the SAP
aggregate rate, distributes the available bandwidth to each of the FCs configured for the SAP,
based on the queue priority and queue weights configured by the user.
Ingress queuing needs two passes through the traffic manager. The first pass does the ingress
queuing and shaping and the second pass does egress queuing and shaping. 7210 SAS-X has two
internal loopback schedulers and fixed bandwidth is allotted to them at system boot up. In current
release, the system uses one of the loopback scheduler/path to loop the BUM traffic, received
either on SAPs or network ports, after replication to the second pass for egress queuing. The other
internal loopback scheduler will be allotted for ingress queued unicast traffic with appropriate
bandwidth allotted to it when user enables ingress queuing. User can enable ingress queuing for
unicast traffic, using the CLI command config> system> resource-profile> qos> ingress-queues
highUcastLowMcast. It allocates 20G of bandwidth to ingress queued unicast traffic and allocates
11G to BUM traffic. The unicast internal loopback scheduler distributes the available bandwidth
among all the ingress unicast queues based on the user configured queue rate and queue priority.
This CLI command is a boot-time parameter and a change to this will require a reboot of the node.
Existing deployments that use only ingress policed unicast traffic and ingress policed BUM traffic
with egress queuing (SAP and network port) can continue to use up to 44G of bandwidth as before
Page 200
7210 SAS-X and 7210 SAS-R6 OS Quality of Service Guide
Advertisement
Table of Contents
