Packets that are generated and transmitted by a router are called Locally Originated Packets (LOPs). These are different from
packets that pass through the router. Each device uses a default precedence value as determined by the device. The default
value, used by Locally Originated Control Protocols (LOCPs) such as BGP, OSPF, CCM(CSM), BFD, and RSVP, is a precedence of
6 or Differentiated Services Codepoint (DSCP) of 48. Locally Originated Management Protocols (LOMPs) such as Telnet and SSH
use a precedence value of 2 or DSCP of 16. SNMP uses a precedence value of 0. Some protocols such as BGP, RSVP, CFM, and LDP
and the management protocols are capable of setting a specific precedence or DSCP value.
The following applies to Traffic Class (TC) alignment:
-
Before Release 7.6.1:
-
Locally generated control plane packets, such as IS-IS and BGP, are generated using traffic-class 6.
-
Locally generated BFD over Bundle (IETF) packets, which are generated on the Network Processing Unit (NPU), are generated
using traffic-class 6.
-
From Release 7.6.1 onwards:
-
Locally generated control plane packets, such as IS-IS and BGP, are generated using traffic-class 7.
-
Locally generated BFD over Bundle (IETF) packets, which are generated on the Network Processing Unit (NPU), are generated
using traffic-class 7.
-
When the BFD packets are offloaded to the hardware and generated on the NPU, the egress QoS policies are applied. These packets
are classified along with the regular data plane traffic.
On the router, datapath packets and injected packets aren’t differentiated if both their traffic classes share the same Virtual
Output Queues (VOQs). Therefore, in the case of a congested VOQ, the LOCP packets are dropped. To avoid the LOCP packets drop,
Cisco recommends that you have a different traffic class for data path traffic. Alternatively, you can also specify a higher
bandwidth for traffic-class 7 (if ingress traffic rate is predictable).
Classifying traffic helps the router to recognize traffic as a certain type and mark that traffic. By marking traffic early
on its travel, you can prevent excessive reclassification later. You can mark traffic at the protocol level as shown in the
following examples:
Ethernet
The following configuration shows that the outbound Control Hub packets are marked with a precedence value of 2 and EXP of
2, instead of a precedence and EXP value of 6. The SSH packets have a precedence value of 3 instead of 2.
ethernet cfm
mep domain FOO service FOOBAR mep-id 1
cos 2
ssh server dscp 24
BGP
neighbor x.x.x.x dscp
MPLS LDP
mpls ldp signalling dscp
Telnet
telnet ipv4 dscp
SNMP
snmp-server ipv4 precedence/dscp
Syslog
logging ipv4 precedence/dscp
netflow
flow exporter-map TEST dscp
NTP
ntp ipv4 precedence/dscp
ssh client dscp 56
ssh server dscp 56
Note
|
By default, the router marks the Precision Time Protocol (PTP) traffic as high priority. Therefore, the need to prioritize
PTP traffic in the QoS configuration is not required.
|
All LOCPs originating on the RP or LC CPU have the discard priority set in the appended Buffer Header (BHDR). The discard
priority ensures that the LOCPs are not dropped internally (under normal circumstances). Such LOCPs include non-IP (IS-IS
and ARP) based control packets. The discard priority is not set for LOMPs. Therefore, such packets are treated as normal traffic,
both in terms of classification and re-marking, and may be dropped under congestion conditions. Therefore, you must ensure
that you do not inadvertently re-mark and drop such traffic.
Note
|
By default, all LOCPs are assigned to traffic-class 7. Considering that LOCPs and LOMPs are generated by the RP, an Ingress
QoS policy cannot be applied. Therefore, you must ensure that the egress QoS policy includes a class-map which matches traffic-class
7. By definition, the egress QoS policy matches all implicitly marked packets.
|
LOCPs are not subject to traffic policing, Weighted Random Early Detection (WRED), or Tail-drop queue-limit operation. The
LOCP packets are not subject to WRED, even if the max_th value is being met. The tail-drop queue-limit must be hit before the LOCP packets are dropped.
All LOCPs with the discard priority set are by default put into an implicitly allocated high priority queue of each physical
egress interface.
By default, all LOCPs that have the discard priority set are put into an implicitly allocated high priority queue of each
physical egress interface.
When configuring QoS policies, you may attach a policy to the physical interface, which then references the sub-interfaces.
Or, alternatively, you may attach QoS policies to the sub-interfaces directly. If you attach QoS policies to the sub-interfaces
directly, the operator is prevented from attaching a QoS policy to the physical interface. LOCPs, including those being transmitted
on a sub-interface, are always sent out on the default high-priority queue of the physical interface. The operator is therefore
prevented from assigning any bandwidth to the physical interface, which could be reserved for use by LOCPs. During over-subscription,
it may lead to a LOCPs drop and as a result, sessions may be terminated.
To prevent session termination, a minimum bandwidth of MIN (1% of interface BW, 10 mbps) is reserved for the default high-priority
queue associated with the physical interface that has no QoS policy applied. If a QoS policy is applied to the physical interface,
the minimum bandwidth for the default HP queue is controlled by the configured policy.
-
Any QoS classification does not affect the queue-selection for LOCP.
-
Irrespective of the QoS policy configured, non-IP LOP control packets are always sent to the high-priority queue. For example,
ISIS and ARP
LOCPs can be mapped to a corresponding QoS group. The following example illustrates how this can be achieved:
control-plane
! local control-packets
copy precedence qos-group
The precedence value of the control packet is mapped to the respective QoS group number.