QoS Offload on Satellite
The Satellite System enables you to configure a topology in which one or more satellite switches complement one or more CRS Router, to collectively deploy a single virtual switching system. In this system, the satellite switches act under the management control of the routers. The connections between the CRS Router and the satellite switches are called the Inter-chassis link (ICL), which is established using standard Ethernet interfaces.
The ICL link between the and the satellite gets oversubscribed by the access interfaces on the satellite box. This is because the QoS policies applied on the satellite interfaces are programmed on the CRS Router Line card locally. Therefore, the flow of traffic on the ICL from the satellite switch is not controlled. This leads a loss of high-priority traffic due to congestion on the ICL.
This figure shows the ports where the QoS policies may be applied.
Benefits of QoS Offload
The QoS offload feature protects the control packets when Satellite fabric links (SFL) is congested. The offloading of QoS policies helps to drop excess traffic at the ingress direction (or access ports) and prioritize the protocol control traffic at the egress direction (or SFL).
QoS Offload on Different Topologies
The QoS Offload feature is supported on these satellite topologies:
L2 Fabric Architecture
In the L2 Fabric architecture, a satellite is connected to one or more hosts through one or more ethernet virtual circuit (EVC) in the Layer 2 Fabric network. An EVC is identified by two transport VLAN IDs, TPVID- S and TP-VID-H. TP-VID-S is the satellite side transport VLAN ID and TP-VID-H is the host side transport VLAN ID.
In this configuration, the ICL link is created on the VLAN and EVC is provisioned as an interface in the host-side. The nV satellite fabric interface is created under this interface. The service-policy is configured in the nv mode and the QoS policy is offloaded on the ICL link where the VLAN is connected to the Host.
Restrictions
- Policy on sub-interfaces is not supported.
-
Classification based on access group is not supported.
QoS Offload Scenarios
This section describes the various QoS offload scenarios on different interfaces on different satellite topologies.
Service-policy on Access Port over Physical Interface
In this scenario, the QoS policy is configured on the access port or in the ingress direction over the physical interface of the satellite.
In this example, the policy_A service-policy is directly applied on the Ethernet interface on the satellite. Thus, policy_A stays on the CRS Router and there is no offloading in this example.
interface gigabitEthernet 100/0/0/0
service-policy input/output policy_A
!
!
In this example, the policy_B service-policy is configured under the nv mode, and the QoS policy is completely offloaded to the Satellite.
interface gigabitEthernet100/0/0/0
nv
service-policy input policy_B
Service-policy on Access Port over Bundle Interface
In this scenario, the QoS policy is configured on the bundle access port or in the ingress direction over the bundle interface of the satellite.
In this example, similar to one for the physical interface, the QoS service-policy is configured under the nv mode and the policy-map is offloaded on the satellite bundle-ether interface.
interface GigabitEthernet 100/0/0/1
bundle-id 1
!
interface GigabitEthernet 100/0/0/1
bundle-id 1
!
interface bundle-ether 1
nv
service-policy input<Policy-map name>
!
!
Service-policy on SFLs over Physical Interface (L2 Fabric)
In this scenario, the QoS policy is configured on the VLAN interface or in the egress direction over the physical interface of the satellite.
interface TenGigabitEthernet 0/1/0/0
nv satellite-fabric-link satellite 100
remote-ports GigabitEthernet 0/0/0-5
service-policy output <Policy-map-name>
!
interface TenGigabitEthernet 0/1/0/0
nv satellite-fabric-link satellite 100
remote-ports GigabitEthernet 0/0/0-5
service-policy output <Policy-map-name>
!
Supported Platform-Specific Information for QoS Offload
This section describes the supported capability matrix, various supported classification combinations, and the supported scalability matrix for 9000v and ASR 901 satellites.
Supported Capability Matrix
interface GigabitEthernet200/0/0/10
nv
service-policy input access
!
!
interface Bundle-Ether200
ipv4 point-to-point
ipv4 unnumbered Loopback3000
nv
satellite-fabric-link satellite 200
service-policy output icl
redundancy
iccp-group 10
!
remote-ports GigabitEthernet 0/0/0-43
!
!
!
policy-map icl
class icl1
bandwidth remaining percent 5
!
class icl2
bandwidth remaining percent 4
!
class icl3
priority level 1
!
class icl4
bandwidth remaining percent 1
!
class class-default
bandwidth remaining percent 1
!
end-policy-map
!
RP/0/RSP1/CPU0:vkg3(config)#show running-config policy-map access
policy-map access
class access1
set qos-group 1
!
class access2
set qos-group 2
!
class access3
set qos-group 3
!
class access4
set qos-group 4
!
class class-default
!
end-policy-map
!
class-map match-any access1
match cos 1
match precedence 1
end-class-map
!
class-map match-any access2
match cos 2
match precedence 2
end-class-map
!
class-map match-any access3
match cos 3
match precedence 3
end-class-map
!
class-map match-any access4
match cos 4
match precedence 4
end-class-map
!
class-map match-any icl1
match qos-group 1
end-class-map
!
class-map match-any icl2
match qos-group 2
end-class-map
!
class-map match-any icl3
match qos-group 3
end-class-map
!
class-map match-any icl4
match qos-group 4
end-class-map
!
RP/0/RSP1/CPU0:vkg3(config)#do show qos status interface bundle-ether 200 nv
Bundle-Ether200 direction input: Service Policy not installed
Bundle-Ether200 Satellite: 200 output: icl
Last Operation Attempted : IN-PLACE MODIFY
Status : ACTIVE
RP/0/RSP1/CPU0:vkg3(config)#do show qos status interface gigabitEthernet 200/0/0/10 nv
GigabitEthernet200/0/0/10 Satellite: 200 input: access
Last Operation Attempted : IN-PLACE MODIFY
Status : ACTIVE
GigabitEthernet200/0/0/10 direction output: Service Policy not installed
Feature |
Support on 9000v Platform |
Range |
Restrictions |
||
---|---|---|---|---|---|
Classification |
|||||
Ingress |
|||||
COS |
Yes |
0-7 |
The cos classification is done on the outer vlan tag.
|
||
IP DSCP |
Yes |
0-63 |
IP DSCP is supported for untagged, single-tagged, double-tagged, and mac-in-mac packets on the ingress direction, from the access-side. IP DSCP is supported for IPv4 and IPv6. |
||
IP PREC |
Yes |
0-7 |
IP PREC is supported for untagged, single-tagged, double-tagged, and mac-in-mac packets on the ingress direction, from the access-side. IP PR is supported only for IPv4. |
||
MPLS EXPERIMENTAL TOPMOST |
Yes |
0-7 |
The mpls experimental topmost feature is supported only for the untagged packets on the ingress direction, from the access-side. |
||
VLAN |
Yes |
1-4096 |
The vlan classification is done on the outer vlan tag based on the policies and the cos value applied on the outer vlan tag.
|
||
Egress |
|||||
QOS-GROUP |
Yes |
1-5 |
A class-map with multiple "match qos-group" statements is not supported.
|
||
COS |
Yes |
0-7 |
The cos classification is done on the outer vlan tag.
|
||
IP DSCP |
Yes |
0-63 |
IP DSCP is supported for untagged, single-tagged, double-tagged, and mac-in-mac packets on the ingress direction, from the access-side. IP DSCP is supported only for IPv4. |
||
IP PREC |
Yes |
0-7 |
IP PREC is supported for untagged, single-tagged, double-tagged, and mac-in-mac packets on the ingress direction, from the access-side. IP PR is supported only for IPv4. |
||
MPLS EXPERIMENTAL TOPMOST |
Yes |
0-7 |
The mpls experimental topmost feature is supported only for the untagged packets on the ingress direction, from the access-side. |
||
VLAN |
Yes |
1-4096 |
The vlan classification is done on the outer vlan tag based on the policies and the cos value applied on the outer vlan tag.
|
||
Marking |
|||||
Ingress |
|||||
COS |
Yes |
0-7 |
The cos marking is done on the vlan tag that is added by the satellite on the direction towards host. |
||
IP DSCP |
Yes |
0-63 |
IP DSCP is supported for untagged, single-tagged, double-tagged, and mac-in-mac packets on the ingress direction, from the access-side. |
||
MPLS EXPERIMENTAL IMPOSITION |
No |
0-7 |
— |
||
IP PREC |
Yes |
0-7 |
IP PREC is supported for untagged, single-tagged, double-tagged, and mac-in-mac packets on the ingress direction, from the access-side. |
||
QOS-GROUP |
Yes |
0-5 |
The qos-group marking feature is only used to redirect packets to a particular queue. The set qos-group 0 on ingress policy is necessary to send the packets to queue 0 on ICL.
|
||
Queuing |
|||||
Egress |
|||||
Bandwidth Percent |
Yes |
— |
For a 9000v satellite, bandwidth value cannot be configured under qos-group 3. A combination of bandwidth types cannot be configured. For example, the bandwidth command can be configured either with kbps, or remaining percent, or remaining ratio, but not with a combination of all. |
||
Bandwidth Remaining Percent |
Yes |
— |
|||
Bandwidth Remaining Ratio |
Yes |
— |
|||
Priority |
Yes |
— |
When a priority level is configured at the host, it by default gets configured to priority percent 95 85 on the satellite. The priority action cannot be combined with other queuing actions. Only one class-map with a priority action can be configured. On 9000v satellites, the priority action is only supported under qos-group 3. |
||
Priority Percent |
Yes |
— |
|||
Random Detect Discard-class-based |
No |
Discard-class: 0-2 Thresholds: 1-8192000 |
— |
||
Shape Average |
Yes |
8000- 10000000000 |
On 9000v satellites, the shape average command cannot be configured under qos-group 3. |
||
HQOS |
No |
— |
— |
||
Rate Limiting (Only Ingress) |
|||||
1R2C |
Yes |
CIR/PIR: 8000-10000000000 Burst bytes: 1000- 256000000 Burst ms:1-2000 |
The bytes can be configured in milliseconds (ms) only if CIR is in percent.
|
||
2R3C |
Yes |
If the exceed-action command is configured, then violate-action is copied from exceed-action, by default. If the exceed-action is not configured, then violate-action and exceed-action are dropped.
|
Supported Classification Combination
These are the allowed classification combination in CRS Router:
-
COS + IP DSCP
-
IP DSCP +VLAN
-
COS + VLAN
-
IP DSCP + IP PREC
Note |
The IP DSCP + IP PREC combination is not supported for 9000v. |
The table lists the allowed classification combinations in 9000v:
Match-all class map |
DSCP + PREC + COS |
PREC + DSCP + VLAN |
|
Match-any class map |
VLAN + COS + PREC + DSCP |
DSCP + VLAN + COS |
|
DSCP + PREC + COS |
|
VLAN + COS + PREC |
Note |
For NCS 5000 Series Satellite, COS+DSCP match is the only supported classification combination on ingress. For Egress, policies can only match on qos-group (1 per class-map). For Egress offload policies on NCS 5000 Series Satellite, it is mandatory to configure eight class-maps including class-default for eight queues, even if all the class maps are not in use. |
Supported Scalability Matrix for 9000v
Class-map with options |
Number of Field Programmable (FP) entries needed per policy-map(max 8 classes) |
Max policy-maps supported |
---|---|---|
cos (0-7) |
7 + 1 ( class default) |
2304/8 = 288 |
ip dscp (0-63) |
7 + 1 |
2304/8 = 288 |
ip precedence (0-7) |
7 + 1 |
2304/8 = 288 |
vlan (1-4094) |
7 + 1 |
2304/8 = 288 |
match-any or match-all with single argument |
||
cos + dscp cos+ prec cos + vlan dscp + vlan prec + vlan |
2 *7 + 1 (class-default) = 15 |
2304/15 = 153.6 |
match-any with maximum arguments to the match parameters |
||
cos (max 4)+ ip precedence (max 4) |
8 * 7 + 1 (class-default) = 57 |
2304/57 = 40.4 |
cos (4) + ip dscp (8) |
12 * 7 + 1 (class-default)= 85 |
2304/85 = 27.1 |
cos (4) + vlan (30) |
34 * 7 + 1 = 239 |
2304/239 = 9.6 |
vlan (30) + ip prec (4) |
34 *7 + 1 = 239 |
2304/239 = 9.6 |
vlan (30)+ip dscp (8) |
38*7 + 1 =267 |
2304/267 = 8.6 |
match-all with maximum arguments |
||
cos (4) + ip dscp (8) |
32 *7 + 1=225 |
2304/225 = 10.2 |
cos (4) + vlan (30) |
120 *7+ 1=841 |
2304/841 = 2.7 |
vlan (30) + ip prec (4) |
120*7+1=841 |
2304/841 = 2.7 |
cos (4) + ip prec (4) |
16 *7 +1= 113 |
2304/113 = 20.3 |
vlan (30) + ip dscp (8) |
240 *7 + 1 = 1681 |
2304/1681 =1.3 |