Service ingress and egress QoS policies

To create a service ingress queue, define the following:

• a new queue ID value. The system does not dynamically assign a value

• queue parameters. Ingress queues support multipoint queues, explicit and auto-expedite hardware queue scheduling, and parent virtual scheduler definition.

The following displays an ingress queue configuration:

A:ALA-7>config>qos# info
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------ 
...
        sap-ingress 100 create
            description "Used on VPN sap"
            queue 1 create
            exit
            queue 2 multipoint create
            exit
            queue 10 create
                parent VPN_be
                rate 11000
            exit
            queue 12 create
                parent VPN_priority
                rate 11000
            exit
            queue 13 create
                parent VPN_reserved
                rate 1
            exit
            queue 15 create
                parent VPN_video
                rate 1500 cir 1500
            exit
            queue 16 create
                parent VPN_voice
                rate 2500 cir 2500
            exit
            queue 17 create
                parent VPN_nc
                rate 100 cir 36
            exit
            queue 20 multipoint create
                parent VPN_be
                rate 11000
            exit
            queue 22 multipoint create
                parent VPN_priority
                rate 11000
            exit
            queue 23 multipoint create
                parent VPN_reserved
                rate 1
            exit
            queue 25 multipoint create
                parent VPN_video
                rate 1500 cir 1500
            exit
            queue 26 multipoint create
                parent VPN_voice
                rate 2500 cir 2500
            exit
            queue 27 multipoint create
                parent VPN_nc
                rate 100 cir 36
            exit
...
#------------------------------------------
A:ALA-7>config>qos# 

The percent-rate command is supported in a SAP ingress QoS policy for pir and cir parameters for both queues and policers, with the fir parameter supported only for queues on FP4 or later hardware that is ignored when the related policy is applied to FP3-based hardware. For pir, the range is 0.01 to 100.00, and for cir and fir, the range is 0.00 to 100.00.

For queues, when the queue rate is percent-rate, either a local-limit or a port-limit can be applied.

When the local-limit is used, the percent-rate is relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used. When the port-limit is used, the percent-rate is relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.

For policers, the percent-rate rate is always relative to the immediate parent root policer/arbiter rate or the FP capacity.

The following shows a SAP ingress QoS policy configuration:

*A:PE>config>qos>sap-ingress# queue 1 percent-rate
  - no percent-rate
  - percent-rate <pir-percent> [cir <cir-percent>] [fir <fir-percent>] [port-limit | local-limit] [fir <fir-percent>]
  - percent-rate <pir-percent> police [port-limit | local-limit]

 <pir-percent>        : [0.01..100.00]
 <cir-percent>        : [0.00..100.00]
 <fir-percent>        : [0.00..100.00]
 <police>             : keyword
 <port-limit | local-*> : keyword


*A:PE>config>qos>sap-ingress# policer 1 percent-rate
  - no percent-rate
  - percent-rate <pir-percent> [cir <cir-percent>]

 <pir-percent>        : [0.01..100.00]
 <cir-percent>        : [0.00..100.00]


*A:PE>config>qos>sap-ingress#

The following displays a forwarding class and precedence configurations:

A:ALA-7>config>qos# info
#------------------------------------------
...
            fc af create
                queue 12
                broadcast-queue 22
                multicast-queue 22
                unknown-queue 22
            exit
            fc be create
                queue 10
                broadcast-queue 20
                multicast-queue 20
                unknown-queue 20
            exit
            fc ef create
                queue 13
                broadcast-queue 23
                multicast-queue 23
                unknown-queue 23
            exit
            fc h1 create
                queue 15
                broadcast-queue 25
                multicast-queue 25
                unknown-queue 25
            exit
            fc h2 create
                queue 16
                broadcast-queue 26
                multicast-queue 26
                unknown-queue 26
            exit
            fc nc create
                queue 17
                broadcast-queue 27
                multicast-queue 27
                unknown-queue 27
            exit
            prec 0 fc be
            prec 2 fc af
            prec 3 fc ef
            prec 5 fc h1
            prec 6 fc h2
            prec 7 fc nc
...
#------------------------------------------
A:ALA-7>config>qos# 

When specifying SAP ingress match criteria, only one match criteria type (IP/IPv6 or MAC) can be configured in the SAP ingress QoS policy.

The following displays an ingress IP criteria configuration:

A:ALA-7>config>qos# info
...
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
        sap-ingress 100 create
...
            ip-criteria
                entry 10 create
                    description "Entry 10-FC-AF"
                    match protocol 6
                        src-ip 10.10.10.103/24
                    exit
                    action fc af priority high
                exit
                entry 20 create
                    description "Entry 20-FC-BE"
                    match protocol 17
                        dst-port eq 255
                    exit
                    no action
                exit
            exit
        exit
..
#------------------------------------------
A:ALA-7>config>qos# 

When specifying SAP ingress match criteria, only one match criteria type (IP/IPv6 or MAC) can be configured in the SAP ingress QoS policy.

The following displays an ingress IPv6 criteria configuration:

A:ALA-48>config>qos>sap-ingress# info
----------------------------------------------
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            ip-criteria
            exit
            ipv6-criteria
                entry 10 create
                    description "IPv6 SAP-ingress policy"
                    match 
                        src-ip 2001:db8:1000::/64
                        dst-ip 2001:db8:2000::/64
                    exit
                    action fc be priority low
                exit
                entry 20 create
                    description "Entry 20-FC-AF"
                    match next-header tcp
                        src-port eq 500
                    exit
                    action fc af priority high
                exit
            exit
----------------------------------------------
A:ALA-48>config>qos>sap-ingress#

The SAP ingress QoS policy allows the assignment of a tag to each IPv4/IPv6 criteria statement entry. This is useful when a single SAP ingress QoS policy needs to be used for a different service context and it is still needed to apply service specific entries at individual SAP level.

In this concept, the SAP ingress policy can contain entries with different tag values as well as untagged entries. The user configures a tag entry override per-SAP to select which tagged entries are included for the related SAP (untagged entries are always included). Using this tagging concept and matching on destination-port are mutually exclusive.

In the following example, a base configuration IPv4 prefix list is created together with two other lists (list1 and list2) that are used for different VPRN IP interfaces. Also, a base configuration IPv6 prefix list is created together with two other lists (list1 and list2) that are to be used for different VPRN IP interfaces.

The following entries are used for both the IPv4 and IPv6 criteria statement:

• VPRN 1/int: 10, 20, 30

• VPRN 2/int: 10, 20, 30, 1000

• VPRN 3/int: 10, 20, 30, 2000

Example:

configure
    qos
        match-list
            ip-prefix-list "ipv4-base-config" create
                prefix 10.0.0.0/16
                prefix 10.1.0.0/16
            exit
            ip-prefix-list "list1" create
                prefix 172.16.1.0/24
                prefix 172.16.2.0/24
            exit
            ip-prefix-list "list2" create
                prefix 192.168.1.0/24
                prefix 192.168.2.0/24
            exit
            ipv6-prefix-list "ipv6-base-config" create
                prefix 2001:db8:1000::/64
                prefix 2001:db8:2000::/64
            exit
            ipv6-prefix-list "list1" create
                prefix 2001:db8:3000::/64
                prefix 2001:db8:4000::/64
            exit
            ipv6-prefix-list "list2" create
                prefix 2001:db8:5000::/64
                prefix 2001:db8:6000::/64
            exit
        exit
        sap-ingress 10 name "10" create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            policer 1 create
            exit
            policer 2 create
            exit
            ip-criteria
                type tagged-entries
                entry 10 create 
                    match
                        src-ip ip-prefix-list "ipv4-base-config"
                    exit
                    action fc "l2" policer 1
                exit
                entry 20 create
                    match
                        src-ip 10.2.0.0/16
                    exit
                    action fc "af" policer 2
                exit
                entry 30 create
                    match
                        src-ip 10.3.0.0/16
                    exit
                    action fc "af"
                exit
                entry 1000 create 
tag 1
                    match
                        src-ip ip-prefix-list "list1"
                    exit
                    action fc "l1"
                exit
                entry 2000 create 
tag 2
                    match
                        src-ip ip-prefix-list "list2"
                    exit
                    action fc "ef"
                exit
            exit
        exit
            ipv6-criteria
                type tagged-entries
                entry 10 create 
                    match
                        src-ip ipv6-prefix-list "ipv6-base-config"
                    exit
                    action fc "l2" policer 1
                exit
                entry 20 create
                    match
                        src-ip 10.2.0.0/16
                    exit
                    action fc "af" policer 2
                exit
                entry 30 create
                    match
                        src-ip 10.3.0.0/16
                    exit
                    action fc "af"
                exit
                entry 1000 create 
tag 1
                    match
                        src-ip ip-prefix-list "list1"
                    exit
                    action fc "l1"
                exit
                entry 2000 create 
tag 2
                    match
                        src-ip ip-prefix-list "list2"
                    exit
                    action fc "ef"
                exit
            exit
        exit
    exit
    service
        vprn 1 name "1" customer 1 create
            interface "int" create
                address 10.10.10.1/24
                sap 1/1/1:1 create
ingress
    sap-ingress "10"
                exit
            exit
        exit
        vprn 2 name "2" customer 1 create
            interface "int" create
                address 10.20.20.1/24
                sap 1/1/1:2 create
                    ingress
    sap-ingress "10"
                        criteria-overrides
                            ip-criteria
                                activate-entry-tag 1
                            ipv6-criteria
                                activate-entry-tag 1
                        exit
                    exit 
                exit
            exit
        exit
        vprn 3 name "3" customer 1 create
            interface "int" create
                address 10/30/30.1/24
                sap 1/1/1:3 create
                    ingress
    sap-ingress "10"
                        criteria-overrides
                            ip-criteria activate-entry-tag 2
                            ipv6-criteria activate-entry-tag 2
                        exit
                    exit 
                exit
            exit
        exit
    exit

It is possible to classify traffic directly to a policer, independent of the policer/queue assigned to the traffic’s forwarding class. This is supported at SAP ingress by configuring a policer in the action statement: ip-criteria, ipv6-criteria, or mac-criteria.

The standard mechanisms are still used to assign a forwarding class to the related traffic, and this forwarding class continues to be used for QoS processing at egress.

The use of explicitly configured broadcast, unknown, or multicast policers is not supported. QPPB processing takes precedence over this feature.

This could be used, for example, when it is required that ingress OAM traffic is not subject to the same QoS control as other customer traffic on a specific SAP. The OAM traffic could be classified based on its source MAC address (for example, with an OUI of 00-xx-yy as shown in Ingress criteria classification directly to policer) and directed to policer 1 while the remainder of the customer’s traffic is processed using ingress queue 1.

The configuration would be as follows:

        sap-ingress 10 create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            policer 1 create
            exit
            mac-criteria
                entry 10 create
                    match
                        src-mac 00-xx-yy-00-00-00 ff-ff-ff-00-00-00
                    exit
                    action policer 1
                exit
            exit
        exit

Virtual Network Identifier (VNI) classification is supported for VXLAN and VXLAN GPE traffic within a SAP ingress QoS policy. This classification is configured in the ip-criteria and ipv6-criteria contexts with type vxlan-vni (changed from the default type normal). The matching entry must be created with match protocol udp for IPv4 or match next-header udp for IPv6 and uses the vxlan-vni parameter within the match statement to match on a single VNI or a range of VNIs.

The type cannot be changed when ip-criteria or ipv6-criteria entries are configured. If there are no ip-criteria or ipv6-criteria entries configured, the type can be changed from vxlan-vni to normal. The type can only be changed from normal to vxlan-vni if there are no ip-criteria or ipv6-criteria entries configured and if the SAP ingress QoS policy has not been applied to any object.

The following is an example where traffic received with a VNI of 1 is sent to policer 1 and VNIs 2 to 10 are sent to policer 2:

        sap-ingress 10 create
            queue 1 create
            exit
            queue 11 multipoint create
            exit
            policer 1 create
            exit
            policer 2 create
            exit
            ip-criteria
                type vxlan-vni
                entry 10 create
                    match protocol udp
                        vxlan-vni eq 1
                    exit
                    action policer 1
                exit
                entry 20 create
                    match protocol udp
                        vxlan-vni range 2 10
                    exit
                    action policer 2
                exit
            exit
        exit

Ingress VNI classification is applicable to all Ethernet SAPs, except for PW-SAPs, B-VPLS SAPs, and CCAG SAPs, in any applicable service.

The following restrictions also apply:

• Source and destination port matching on a SAP, on which a SAP ingress QoS policy is applied that has ip-criteria or ipv6-criteria statements with type vxlan-vni, is not available for:

  • IPv4 QoS classification for VXLAN or VXLAN GPE traffic

  • IPv6 QoS and filter classification for VXLAN or VXLAN GPE traffic

  If the criteria type is set to vxlan-vni and if source or destination port matching entries are configured in an IPv4 or IPv6 SAP ingress QoS policy or in an IPv6 filter policy, any VXLAN or VXLAN GPE ingress traffic do not match these entries on the SAP on which the SAP ingress QoS policy is applied.

• The simultaneous configuration on a SAP of a QoS policy containing an ip-criteria entry with type vxlan-vni and of a MAC filter with type vid is not supported, and the other way around.

  This is only applicable to Epipe and VPLS services.

• If a SAP ingress QoS policy that has ip-criteria or ipv6-criteria statements with type vxlan-vni is applied to a SAP, any ip-criteria or ipv6-criteria entry match vxlan-vni statements do not match:

  • IPv4 packets containing options

  • IPv6 packets containing extension headers

  • ingress 802.1ah PBB frames

  • IPv6 over PPPoE traffic received with more than one VLAN tag

  • non-first fragments of an IPv4 or IPv6 fragmented packet

• The configuration of a SAP ingress QoS policy containing ip-criteria or ipv6-criteria entry match vxlan-vni statements is not supported within an SLA profile.

Use the lsp-exp command to set the sap-ingress qos policy on Ethernet L2 SAPs to perform FC mapping based on EXP bits.

The lsp-exp option causes the forwarding class and drop priority of incoming traffic to be determined by the mapping result of the EXP bits in the top label.

The following example displays FC mapping based on EXP bits:

*A:Dut-T>config>qos>sap-ingress# info 
----------------------------------------------
            queue 1 create
            exit
            queue 2 create
            exit
            queue 3 create
            exit
            queue 11 multipoint create
            exit
            fc "af" create
                queue 2
            exit
            fc "be" create
                queue 1
            exit
            fc "ef" create
                queue 3
            exit
            lsp-exp 0 fc "be" priority low
            lsp-exp 1 fc "af" priority high

Cards store QoS policy match-criteria entries in dedicated memory banks in hardware also referred to as CAM tables:

• IP/MAC ingress

• IP/MAC egress

• IPv6 ingress

• IPv6 egress

To create a service egress QoS queue, define the following:

• the forwarding class name or names associated with the egress queue. The egress queue for the service traffic is selected based on the forwarding classes that are associated with the queue.

• a new queue ID value. The system does not dynamically assign a value.

• queue parameters. Egress queues support explicit and auto-expedite hardware queue scheduling, and parent virtual scheduler definition.

The following displays an egress QoS policy configuration:

A:ALA-7>config>qos# info
--------------------------------------------------
...
        sap-egress 105 create
            description "SAP egress policy"
            queue 1 create
                parent "scheduler-tier1"
            exit
            queue 2 create
            exit
            queue 3 expedite create
                parent "test1"
            exit
            fc af create
                queue 1
            exit
            fc ef create
            exit
        exit
...
------------------------------------------------
A:ALA-7>config>qos# 

The percent-rate command is supported in a SAP egress QoS policy for pir and cir parameters for both queues and policers. For pir, the range is 0.01 to 100.00, and for cir, the range is 0.00 to 100.00.

For queues, when the queue rate is percent-rate, either a local-limit or a port-limit can be applied.

When the local-limit is used, the percent-rate is relative to the queue’s parent scheduler rate or the agg-rate at egress. If there is no parent scheduler rate or agg-rate, or those rates are max, the port-limit is used. When the port-limit is used, the percent-rate is relative to the rate of the port (including the egress-rate setting) to which the queue is attached. The port-limit is the default.

For policers, the percent-rate rate is always relative to the immediate parent root policer/arbiter rate or the FP capacity.

The following shows a SAP egress QoS policy configuration:

*B:PE>config>qos>sap-egress# queue 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>] [port-limit | local-limit]

<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]
<port-limit | local-*> : keyword

*B:PE>config>qos>sap-egress# policer 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>]

<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]


*B:PE>config>qos>sap-egress#

SR OS supports egress queue length configuration (CBS and MBS) as a function of the expected delay. The system automatically translates this configuration into kilobytes based on the administrative rate of the queue parent (for example, the scheduler or aggregate shaper) for queues that have a parent. The actual operational values of CBS and MBS are shown in kilobytes, and not as a function of the delay, in the corresponding show pools commands.

Nokia recommends using the same method of defining CBS, MBS, and burst limit for all queues within the same SAP egress policy. CBS and MBS as a function of delay is not supported on HSQ. Policies that contain a function of delay applied to an HSQ will have default egress queue CBS and MBS value.

Dynamic MBS is used to constrain the maximum delay experienced by the traffic forwarded through an egress queue group queue when the operational PIR of the queue is modified as part of the HQoS algorithm.

The approximate maximum delay of traffic through a queue because of the length of the queue, when the queue is not using HQoS, is relative to its administrative PIR and can be approximated as (MBS[kB] ✕ 8) / PIR[kb/s]) in seconds. A queue’s PIR is set to max, and its administrative PIR is set to the rate of the port to which the queue is attached.

When using HQoS, the PIR is modified by the HQoS algorithm to give an operational PIR that is equal to or lower than the administrative PIR. As the operational PIR changes, the delay through the queue can also change if the length of the queue is fixed. Reducing the operational PIR could increase the delay, while increasing the operational PIR could reduce the delay. Enabling dynamic MBS on a queue allows the system to change the administrative MBS of the queue in a ratio of operational PIR to administrative PIR, giving an operational MBS, which aims to maintain the maximum queue delay. A queue’s drop tails and WRED slope parameters are defined as percentages of the MBS and are, therefore, adjusted accordingly.

When any of the queue parameters are reduced, packets that are already in the queue are not affected and are forwarded. Reducing these parameters constrains the latency for newly arriving packets, but those packets already in the queue before the new parameter values were set are forwarded with the delay associated with the actual queue depth when the packet was enqueued (based on the previous parameter values).

The configured CBS is used as a minimum operational MBS. The maximum MBS is capped by the maximum administrative MBS (1 GB).

If the operational MBS changes such that its value is similar or equal to the configured CBS, the system increases the CBS to ensure that buffers can be requested from the correct portion of the buffer pool (shared or reserved). This operation is automatic, and the CBS reverts to its configured value if the MBS is increased sufficiently. The automatic increase in the CBS could, however, cause the resv-cbs red or amber alarms to be raised if the increase in the related queues’ CBS results in the total CBS assigned (but not necessarily used) matching or exceeding the resv-cbs red and amber thresholds.

If a LAG is used together with pool-per-queue, the related hardware queues exist in their own pool in the egress WRED megapool on a specific FP and the operational MBS is used to size the shared part of the pool with the sum of the CBS defining the reserved part of the pool.

Dynamic MBS is supported for both native FP and pool-per-queue queues within an egress queue group template, which can be applied to access or network Ethernet ports and used for egress network interface traffic, egress SAP traffic, and subscriber egress policed traffic.

The configuration of dynamic MBS and queue depth monitoring are mutually exclusive.

Dynamic MBS is configured as follows:

configure
    qos
       queue-group-templates
          egress
              queue-group queue-group-name create
                  queue queue-id

The operational MBS can be shown using the show pools and show qos scheduler-hierarchy commands.

The following example shows the use of dynamic MBS. A queue group template is applied to port 5/1/1 configured with multiple queues using HQoS, one of which has the following parameters:

queue-group "qg1" create
  queue 1 best-effort create
       parent "s1" 
       rate 50000
       mbs 1000 kilobytes
       dynamic-mbs
   exit

Without any traffic in the other queues constraining the operational PIR on this queue, the MBS used is the administrative MBS.

*B:PE# show pools access-egress 5/1/1 queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 50000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 1008 KB          Oper MBS         : 1008 KB
High-Plus Drop Tail  : 1008 KB          High Drop Tail   : 1008 KB
Low Drop Tail        : 888 KB           Exceed Drop Tail : 792 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

If traffic is sent to the other queues in the queue group such that the operational PIR of queue 1 is reduced to 25 Mb/s, the show output changes to:

*B:PE# show pools 5/1/1 access-egress queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 25000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 1008 KB          Oper MBS         : 504 KB
High-Plus Drop Tail  : 1008 KB          High Drop Tail   : 1008 KB
Low Drop Tail        : 948 KB           Exceed Drop Tail : 900 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

The output shows that the operational MBS is now 50% of the administrative MBS and that the queue’s drop tails have changed accordingly.

An access egress packet’s forwarding class can be changed to redirect the packet to an alternate queue than the ingress forwarding class determination would have used. An access egress packet’s profile can also be changed to modifying the congestion behavior within the egress queue. In both cases, egress marking decisions are based on the new forwarding class and profile as opposed to the egress forwarding class or profile. The exception is when ingress remarking is configured. An ingress remark decision is not affected by egress forwarding class or egress profile overrides.

The SAP egress QoS policy allows reclassification rules that are used to override the ingress forwarding class and profile of packets that egress a SAP where the QoS policy is applied.

Dot1p, IP precedence, DSCP, and IP quintuple entries can be defined, each with an explicit forwarding class or profile override parameters. The reclassification logic for each entry follows the same basic hierarchical behavior as the classification rules within the SAP ingress QoS policy. Dot1p, IP precedence, and DSCP have the lowest match priority while the IP criteria (quintuple) entries have the highest.

When an optional parameter (such as profile) for Dot1p, IP precedence, or DSCP entries is not specified, the value from the lower priority IP quintuple match for that parameter is preserved. If the IP precedence values overlap with DSCP values in that they match the same IP header TOS field, the DSCP entry parameters override or remove the IP precedence parameters. When none of the matched entries override a parameter, the ingress classification is preserved.

The following displays a SAP egress QoS policy IP criteria configuration:

*A:PE>config>qos# info
----------------------------------------------
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
        sap-egress 10 name "10" create
            queue 1 create
            exit
            ip-criteria
                entry 10 create
                    match
                        src-ip 192.168.0.0/16
                    exit
                    action fc "af"
                exit
                entry 20 create
                    match
                        dst-ip 10.0.0.0/8
                    exit
                    action fc "be"
                exit
            exit
        exit
----------------------------------------------
*A:PE>config>qos#

The following displays a SAP egress QoS policy IPv6 criteria configuration:

*A:PE>config>qos# info
----------------------------------------------
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
        sap-egress 10 name "10" create
            queue 1 create
            exit
            ipv6-criteria
                entry 10 create
                    match
                        dst-ip 2001:db8:1000::/64
                    exit
                exit
            exit
        exit
----------------------------------------------
*A:PE>config>qos#

Cards store QoS policy match-criteria entries in dedicated memory banks in hardware, also referred to as CAM tables:

• IP/MAC ingress

• IP/MAC egress

• IPv6 ingress

• IPv6 egress

Dot1p remarking can be performed on egress for all services and with respect to the profile of the packet and the VLAN tag.

The following commands can be used to remark the dot1p values at a SAP egress:

configure qos sap-egress policy-id create
    use-policer-result-marking-dot1p-inner 
    fc fc-name create
    dot1p {dot1p-value | in-profile dot1p-value out-
     profile dot1p-value [exceed-profile dot1p-value]}
    dot1p-inner {dot1p-value | in-profile dot1p-value
     out-profile dot1p-value | exceed-profile dot1p-value} 
    dot1p-outer {dot1p-value | in-profile dot1p-value
     out-profile dot1p-value [exceed-profile dot1p-
     value]}
    exit

All inplus-profile traffic is marked with the same value as in-profile traffic.

The precedence of these commands is summarized as follows, from highest to lowest precedence:

• dot1p-outer used for outer tag markings

• dot1p-inner used for inner tag markings

• existing dot1p used for marking both tags

• markings taken from packet received at ingress

• dot1p-inner marking is dependent on policer result if use-policer-result-marking-dot1p-inner is enabled

The configuration of QinQ-mark-top-only under the SAP egress takes precedence over the use of the dot1p-inner in the policy, that is, the inner VLAN tag is not remarked when QinQ-mark-top-only is configured. The marking used for the inner VLAN tag is based on the current default, which is governed by the marking of the packet received at the ingress to the system. If QinQ-mark-top-only is omitted, both the inner and outer VLAN tags are remarked.

The egress remarking occurs after any egress classification.

DSCP and IP precedence remarking can be performed on egress for layer 3 services only with respect to the profile of the packet.

Use the following CLI syntax to remark the DSCP and IP precedence values at a SAP egress:

configure qos sap-egress policy-id create
  fc fc-name create
    dscp {dscp dscp-name | in-profile dscp-name out-
      profile dscp-name [exceed-profile dscp-name]}
    prec {ip-prec-value | in-profile ip-prec-value out-
      profile ip-prec-value} [exceed-profile ip-prec-
      value]}
  exit
exit

All inplus-profile traffic is marked with the same value as in-profile traffic.

Remarking the DSCP and IP precedence based on the profile result of egress policing must be enabled under the related policer configuration, as follows:

sap-egress policy-id create
  policer policer-id create
    enable-dscp-prec-remarking
  exit
exit

Apply SAP ingress and egress policies to the following service SAPs:

• Epipe

• IES

• VPLS

• VPRN

See the "Subscriber Services Overview" section of the 7705 SAR Gen 2 Services Overview Guide for information about configuring service parameters on the 7705 SAR Gen 2.

QoS existing policies and entries can be edited. The changes are applied immediately to all services where this policy is applied. To prevent configuration errors, copy the policy to a work area, make the edits, then write over the original policy.

Every service SAP is associated, by default, with the appropriate egress or ingress policy (policy ID 1). The default policy can be replaced with a customer-configured policy but cannot entirely remove the policy from the SAP configuration. When a non-default service egress or ingress policy is removed, the association reverts to the default policy ID 1.

A QoS policy cannot be deleted until it is removed from all SAPs where it is applied.

A:ALA-7>config>qos# no sap-ingress 100
MINOR: CLI SAP ingress policy "100" cannot be removed because it is in use.
A:ALA-7>config>qos#

Use the following syntax to remove a policy from the QoS configuration:

config>qos# no sap-ingress policy-id

Example:

config>qos# no sap-ingress 100
config>qos# no sap-egress 1010