In this section, you learn concepts and configuration of QoS in L2TPv3 networks. Although there are some L2TPv3 specific edge QoS services, L2TPv3 runs over an IP PSN; therefore, all IP QoS models apply. Specifically, you explore the IP differentiated services (DiffServ) model, whose architecture is defined in RFC 2475, "An Architecture for Differentiated Services."
DiffServ separates edge behaviorssuch as classification, marking, policing, metering, and complex per-user and per-application tasksfrom core functions or per-hop behaviors (PHB)including queuing, shaping, dropping, and simple tasks. DiffServ partitions IP traffic into a small number of classes (eight classes per RFC are recommended) and allocates resources on a per-class basis. At the edge, the classification information is summarized in the DiffServ code point (DSCP), which gives a new interpretation to the type of service (ToS) IPv4 header octet and IPv6 traffic class octet as defined in RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers."
The configuration of IP QoS in Cisco IOS follows the Modular QoS CLI (MQC) model. You can break down the MQC configuration into three distinctive steps:
Step 1.
| ClassificationTraffic is classified with a class-map.
|
Step 2.
| Policy creationPolicies are applied to the traffic classes that were defined previously in a policy-map.
|
Step 3.
| Policy applicationThe policies that were defined previously are applied in a direction to a specific interface, subinterface, or ATM and Frame Relay VCs using a service policy.
|
The following case studies explain examples of different QoS modules, including traffic marking, traffic policing, queuing and shaping, and Layer 2-specific matching and setting.
One of the constitutive pieces of the DiffServ model is traffic marking. Before exploring specific traffic marking methods, this section presents a historical perspective on the IPv4 header TOS octet that was defined originally in RFC 791. The ToS byte is the second byte in the IPv4 header and can be interpreted in multiple ways. Figure 13-8 shows the evolution of the ToS octet in different RFCs. You can see that the three most significant bits are called the precedence bits, and they correspond to the class selector in the DSCP.
Note
Traffic marking alone does nothing for QoS. PHBs need to exist in the core network to apply different policies to the traffic that is marked in different classes.
In the next sections, you learn different ways to perform traffic marking. The first two methods are L2TPv3 specific, whereas the third one is a generic marking.
The first method for marking traffic consists of setting the ToS value under a pseudowire class for all L2TPv3 IP packets. You carry out this configuration with the command ip tos value {value} as shown in Example 13-46.
! hostname SanFran ! pseudowire-class wan-l2tpv3-pw-pmtu-df encapsulation l2tpv3 sequencing both protocol l2tpv3 l2tpv3-wan ip local interface Loopback0 ip pmtu ip dfbit set ip tos value 96 !
Example 13-46 shows the ToS set to a value of 96 (0x60 in hexadecimal). This is the value for the complete ToS byte. The number 96 that is represented in binary equals 01100000, from which you can infer that the IP precedence is 011b or 3 (flash). To verify this configuration, configure inbound (that is, packets received) IP accounting by IP precedence in the NewYork PE in the interface that connects to the Denver P (see Example 13-47).
! hostname NewYork ! interface Serial10/0 ip unnumbered Loopback0 ip accounting precedence input !
Now send 1000 ping packets from the Oakland to the Albany CEs, which use the default precedence of 0. Check the IP accounting information that has been collected (see Example 13-48).
NewYork#show interfaces precedence
Serial10/0
Input
Precedence 3: 1000 packets, 140000 bytes
Precedence 6: 2 packets, 88 bytes
NewYork#
You can see that, as expected, 1000 packets were received with an IP precedence of 3. You also see a couple of IP precedence 6 packets that correspond to routing updates.
Note
Although IP accounting can be useful and is a quick way to gather per-precedence accounting information, it suffers from performance limitations. For example, IP accounting is not supported in distributed CEF (dCEF). It forces packets to be process switched in distributed platforms, such as the Cisco 7500 and 12000 series routers. Whenever possible, use NetFlow to collect statistics in a more scalable way. IP accounting is a great proof of concept tool, but you should not use it in distributed platforms.
Another traffic-marking feature that is specific to L2TPv3 is called ToS reflection. In ToS reflection marking, the ToS octet is copied over or reflected from the inner CE IP packet header into the outer IP tunnel packet header. This behavior cannot be mimicked with MQC.
To configure TOS reflection, you can use the pseudowire-class command ip tos reflect. The command ip tos {reflect | value} appears only in pseudowire-class configuration when the encapsulation is set to L2TPv3 (see Example 13-49).
! hostname SanFran ! pseudowire-class wan-l2tpv3-pw-pmtu-df encapsulation l2tpv3 sequencing both protocol l2tpv3 l2tpv3-wan ip local interface Loopback0 ip pmtu ip dfbit set ip tos reflect !
To verify the ToS reflection functioning, generate 1000 packets with IP precedence 5 (critical) from the Oakland CE to the Albany CE. Use an extended ping command, in which you must specify the ToS octet value. You can express an IP precedence of 5 in binary as 101. Therefore, the binary representation of the ToS is 10100000, which is 0xA0 or 160 (see Example 13-50).
Oakland#ping ip Target IP address: 192.168.105.2 Repeat count [5]: 1000 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: 0xa0 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 192.168.105.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !Output omitted for brevity !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (1000/1000), round-trip min/avg/max = 16/21/52 ms Oakland#
Using the same IP accounting method, verify the precedence in the packets sent over the IP PSN and received by the NewYork PE (see Example 13-51).
NewYork#show interfaces precedence
Serial10/0
Input
Precedence 3: 1000 packets, 140000 bytes
Precedence 5: 1000 packets, 140000 bytes
Precedence 6: 40 packets, 2352 bytes
NewYork#
You can see 1000 new packets received with precedence 5. The precedence 5 was copied over from the TS byte in the CE IP packet.
You can also configure both ip tos actions of value and reflect into a single pseudowire class. In that case, the ToS value in the outer IP header defaults to the fixed set value but is overwritten with the reflected value when the Layer 2 tunneled frame contains an IP packet.
The third traffic-marking mechanism uses MQC. The MQC set ip precedence and set ip dscp policy commands have been extended to include the tunnel keyword to indicate that the policy applies to the outer L2TPv3 tunnel IPv4 delivery header.
When you are using MQC to perform marking with L2TPv3, only the inbound direction (that is, coming from the CE device) is meaningful for classification; therefore, the classification criterion needs to be Layer 2 fields at the attachment circuit. A PE device normally marks classified traffic with a tunnel as IP DSCP. The primary goal for tunnel marking is to control QoS for a particular tunneled customer within the provider core network. Customer-specific PHB should be pushed out to the CE devices. For simplicity, Example 13-52 shows the configuration required to perform tunnel marking with a precedence of 2 (immediate) using MQC to classify all traffic incoming into the attachment circuit. Apply the service policy in a Layer 2 transport ATM PVC.
! hostname SanFran ! class-map match-all all_traffic match any ! policy-map prec-2 class all_traffic set ip precedence tunnel 2 ! interface ATM5/0 pvc 0/100 l2transport oam-ac emulation-enable 2 encapsulation aal5 xconnect 10.0.0.203 27 pw-class pw-l2tpv3-atm service-policy in prec-2 ! !
Now generate 500 packets by using an extended ping command from the Oakland CE to the Albany CE, and check the MQC policy-map counters (see Example 13-53).
SanFran#show policy-map interface
ATM5/0: VC 0/100 -
Service-policy input: prec-2 (1330)
Class-map: all_traffic (match-all) (1331/3)
500 packets, 56000 bytes
5 minute offered rate 4000 bps, drop rate 0 bps
Match: any (1332)
QoS Set
ip precedence tunnel 2
Packets marked 500
Class-map: class-default (match-any) (1334/0)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any (1335)
0 packets, 0 bytes
5 minute rate 0 bps
SanFran#
You can see that 500 packets were classified and marked with tunnel precedence 2. You can also check the PE-P interface in the NewYork PE for IP accounting statistics after you clear the counters (see Example 13-54).
NewYork#show interfaces precedence
Serial4/0
Input
Precedence 2: 500 packets, 70000 bytes
NewYork#
You can configure the three marking methods simultaneously. In that case, the relative priority from highest to lowest is as follows:
MQC set ip {precedence | dscp} tunnel
ToS reflection
ToS setting
For this reason, it is recommended that you use the MQC configuration in favor of the legacy ToS setting or marking. The policy for setting the IP precedence or DSCP in an L2TPv3 tunnel can be selected as a policing action by using the keywords set-prec-tunnel-transmit or setd-scp-tunnel-transmit.
Using the MQC model, you can configure traffic policing using single- or dual-rate policers that have multiple conform, exceed, and violate actions. Example 13-55 shows the possible actions for conforming traffic, including the highlighted tunnel marking. The same actions are available for exceeding and violating traffic.
SanFran(config-pmap-c-police)#conform-action ? drop drop packet set-clp-transmit set atm clp and send it set-cos-transmit set cos and send it set-discard-class-transmit set discard-class and send it set-dscp-transmit set dscp and send it set-dscp-tunnel-transmit rewrite tunnel packet dscp and send it set-frde-transmit set FR DE and send it set-mpls-exp-imposition-transmit set exp at tag imposition and send it set-prec-transmit rewrite packet precedence and send it set-prec-tunnel-transmit rewrite tunnel packet precedence and send it set-qos-transmit set qos-group and send it transmit transmit packet SanFran(config-pmap-c-police)#conform-action
Example 13-56 shows the configuration of a policer with marking actions.
!
hostname SanFran
!
class-map match-all all_traffic
match any
!
policy-map my_policer
class all_traffic
police cir 64000 pir 128000
conform-action set-prec-tunnel-transmit 5
exceed-action set-prec-tunnel-transmit 1
violate-action drop
interface ATM5/0
pvc 0/100 l2transport
oam-ac emulation-enable 2
encapsulation aal5
xconnect 10.0.0.203 27 pw-class pw-l2tpv3-atm
service-policy in my_policer
!
!
MQC is versatile enough through the use of nested or hierarchical policies to allow the configuration of ATM Forum Traffic Management 4.0 (TM 4.0) policers using the policy police rate. With this capability, a PE device can behave like a traditional ATM switch. In particular, you can configure the following policing policies:
CBR Policing Using a single class and police statement.
VBR.1 Policing Using hierarchical policies:
A parent policy includes a police statement to policy at peak cell rate (PCR) for all cells.
A child policy includes a police statement to policy at sustained cell rate (SCR) for all cells.
VBR.2 Policing Using hierarchical policies:
A parent policy includes a police statement to policy at PCR for all cells.
A child policy includes a police statement to policy at SCR for all cell loss priority of zero (CLP0) cells classified under a new class-map.
VBR.3 Policing Using hierarchical policies:
A parent policy includes a police statement to policy at PCR for all cells.
A child policy includes a police statement to policy at SCR for all CLP0 cells that are classified under a new class-map, and mark as exceeded any cells with CLP1.
UBR.1 Policing Using a single class and police statement.
Example 13-57 shows the ATMF TM 4.0 policer configuration, including tunnel IP precedence marking using the policy set ip precedence tunnel. The highlighted policy-maps are to be applied as input service policies under the ATM PVC.
! class-map match-all CLP0 match not atm clp ! ! policy-map CBR.1 class class-default police rate 10000 cps delay-tolerance 500 conform-action transmit exceed-action drop set ip precedence tunnel 5 policy-map VBR.1_child class class-default police rate 5000 cps atm-mbs 1000 conform-action transmit exceed-action drop policy-map VBR.1 class class-default police rate 10000 cps delay-tolerance 200 conform-action transmit exceed-action drop set ip precedence tunnel 4 service-policy VBR.1_child policy-map VBR.2_child class CLP0 police rate 5000 cps atm-mbs 1000 conform-action transmit exceed-action drop policy-map VBR.2 class class-default police rate 10000 cps delay-tolerance 200 conform-action transmit exceed-action drop set ip precedence tunnel 3 service-policy VBR.2_child policy-map VBR.3_child class CLP0 police rate 5000 cps atm-mbs 750 conform-action transmit exceed-action set-clp-transmit policy-map VBR.3 class class-default police rate 10000 cps delay-tolerance 400 conform-action transmit exceed-action drop set ip precedence tunnel 2 service-policy VBR.3_child policy-map UBR.plus class class-default police rate 10000 cps delay-tolerance 2000 conform-action transmit exceed-action drop set ip precedence tunnel 1 !
The ATMF TM4.0 specification uses the PCR as the rate in the first bucket and cell delay variation tolerance (CDVT) as the height of the first bucket. It also defines the use of the SCR as the rate in the second bucket and a function of maximum burst size (MBS) as the height of the second bucket.
You can see that, as specified in ATMF TM4.0, Example 13-57 uses the PCR and CDVT combination in the first bucket specified by the parent policy and uses the SCR and MBS combination in the second bucket specified by the child policy for VBR service types.
Note
Some platforms do not support the atm-mbs keyword. In those cases, you should define the SCR only in the child policies.
On some platforms, Layer 2 marking is supported only in the outbound direction. In these platforms, you cannot implement VBR.3 because it cannot use set atm-clp in an input policy. However, you can usually configure around this by marking with a new tunnel IP precedence instead of ATM CLP at ingress. You can map the tunnel IP precedence back to ATM CLP at egress with an intermediate qos-group:
Ingress PE In the ingress PE, perform VBR.2 policing as an inbound policy but set a different tunnel IP precedence or DSCP for the exceed-action in the VBR.3_child policymap instead of performing a drop action. This effectively performs an IP marking. You can refer to this IP precedence as CLP precedence.
Egress PE In the egress PE, at ingress from the P router, match the CLP precedence tunnel IP precedence with an inbound policy and set the qos-group. This classifies traffic that will later be marked with CLP. At egress in the attachment circuit that is outbound toward the CE, match the qos-group and set atm-clp.
Two local markings exist: qos-group and discard-class. They preserve the marking tunnel IP precedence or DSCP information (or MPLS Experimental bits in AToM) before tunnel or label disposition. Used as an input feature, the qos-group ID identifies or selects a class, and the discard-class identifies a drop precedence. These two local markings are important when input Layer 2 marking is not supported. They allow you to match on PSN information, such as IP DSCP or MPLS EXP, while acting on them at egress on an attachment circuit when that PSN class information is lost because of disposition.
The intermediate step is the qos-group ID, which conveys the received class to the output interface. A qos-group and discard-class are required when you use the input PHB marking to classify packets on the output interface. Example 13-58 shows a sample configuration setting the ATM CLP at attachment circuit egress based on the tunnel IP precedence at ingress from the P router.
! hostname NewYork ! class-map match-all pre1 match ip precedence 1 class-map match-all qosg match qos-group 1 ! ! policy-map clp class qosg set atm-clp policy-map qosg class pre1 set qos-group 1 ! interface Serial4/0 ip unnumbered Loopback0 service-policy input qosg ! interface ATM5/0 no ip address pvc 0/101 l2transport oam-ac emulation-enable 2 encapsulation aal5 xconnect 10.0.0.201 27 pw-class pw-l2tpv3-atm service-policy out clp ! !
You can see that the Serial4/0 interface coming into the NewYork PE from the Denver P has the inbound service policy qosg. The qosg policy-map classifies traffic with IP precedence of 1 in the class-map pre1 and sets the qos-group to 1 for the classified packets.
At egress and toward the attachment circuit, the PVC 0/101 in interface ATM5/0 has the outbound service policy clp. The policy-map clp sets the ATM CLP bit for traffic that is classified with the qosg class-map that matches qos-group 1. In effect, you are applying an outbound policy in the outgoing interface from an inbound classification in the incoming interface. The qos-group marking and matching acts like the middle man. Example 13-59 shows the verification for this pair of service policies.
NewYork#show policy-map interface
Serial4/0
Service-policy input: qosg (1581)
Class-map: pre1 (match-all) (1582/9)
5 packets, 700 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 1 (1583)
QoS Set
qos-group 1
Packets marked 5
Class-map: class-default (match-any) (1585/0)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any (1586)
0 packets, 0 bytes
5 minute rate 0 bps
ATM5/0: VC 0/101 -
Service-policy output: clp (1561)
Class-map: qosg (match-all) (1562/8)
5 packets, 560 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: qos-group 1 (1570)
QoS Set
atm-clp
Packets marked 5
Class-map: class-default (match-any) (1565/0)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any (1566)
0 packets, 0 bytes
5 minute rate 0 bps
NewYork#
The input service policy qosg in Serial4/0 matches 5 packets and sets the qos-group to 1. In turn, the output service policy clp in ATM5/0 VC 0/101 matches these 5 packets by qos-group and sets the atm-clp.
MQC supports multiple queuing and shaping of outbound features in L2TPv3 environments. Some of these features are as follows:
Low-latency queuing (LLQ) The LLQ is a strict priority first-in, first out (FIFO) queue. Strict priority queuing allows delay-sensitive data to receive a preferential queuing treatment by being dequeued and serviced before other queues.
Class-based weighted fair queuing (CBWFQ) CBWFQ provides a fair queuing based on defined classes with no strict priority. The weight for a packet that belongs to a specific class is given from the bandwidth that you assigned to the class when you configured it.
Weighted Random Early Detection (WRED) WRED drops packets selectively based on IP precedence. The higher the IP precedence, the less likely the packets are to be dropped.
Example 13-60 shows an example of egress queuing policies to provide committed information rate (CIR) guarantees.
! hostname SanFran ! class-map match-all cust1 match fr-dlci 100 class-map match-all cust2 match fr-dlci 101 ! policy-map cir_guarantee class cust1 bandwidth 128 class cust2 bandwidth 256 ! interface Serial3/1 no ip address service-policy output cir_guarantee encapsulation frame-relay frame-relay intf-type dce !
Example 13-60 matches Frame Relay DLCIs in two different class-maps and applies the bandwidth policy to each class. Example 13-60 does not show the two pseudowires in Serial 3/1 configured with the global connect command with attachment circuits of DLCI 100 and 101, respectively.
You can accomplish per-class traffic shaping for ATM PVC and permanent virtual path (PVP) attachment circuits with the pvc and atm pvp mode ATM service type configuration using the following commands:
CBR {PCR}
UBR {PCR}
VBR-RT {PCR} {SCR} [MBS]
VBR-NRT {PCR} {SCR} [MBS]
L2TPv3 transports and tunnels multiple and diverse Layer 2 technologies. It is reasonable that MQC supports different matching and setting criteria for different Layer 2 protocols. Table 13-1 summarizes some of these Layer 2 technology-specific criteria.
Ethernet
| match cos match vlan (including VLAN ranges)
| set cos
|
Frame Relay
| match fr-de match fr-dlci
| set fr-de set fr-fecn-becn
|
ATM
| match atm clp
| set atm-clp
|
With these combinations, you can configure the following:
Input service policies Matching on the Frame Relay DE bit, the ATM CLP bit, or Ethernet 802.1P CoS bits coming from the attachment circuit, and setting the IP tunnel precedence or DSCP into the L2TPv3 tunnel accordingly.
Output service policies Matching on a qos-group or discard-class conveying the input IP tunnel precedence or DSCP that is incoming from the IP PSN, and setting the Frame Relay DE or forward explicit congestion notification/backward explicit congestion notification (FECN/BECN) bits, ATM CLP bit, or 802.1P CoS bits as desired toward the attachment circuit.
For FECN/BECN marking, both FECN and BECN bits are set when they are above the marking threshold.
Example 13-61 shows an inbound service policy applied to an ATM PVC attachment circuit that sets the tunnel IP precedence to 2 (immediate) for ATM packets that do not have the CLP bit set.
! hostname SanFran ! class-map match-all not-clp match not atm clp policy-map prec-2 class not-clp set ip precedence tunnel 2 ! interface ATM5/0 pvc 0/100 l2transport oam-ac emulation-enable 2 encapsulation aal5 xconnect 10.0.0.203 27 pw-class pw-l2tpv3-atm service-policy in prec-2 ! !
Example 13-62 shows how to set the ATM CLP bit for all traffic.
! hostname NewYork ! class-map match-all everything match any policy-map atm-clp class everything set atm-clp interface ATM5/0 pvc 0/101 l2transport oam-ac emulation-enable 2 encapsulation aal5 xconnect 10.0.0.201 27 pw-class pw-l2tpv3-atm service-policy out atm-clp ! !
Example 13-63 Shows the verification results in the NewYork PE when sending 200 pings from the Oakland CE to the Albany CE.
NewYork#show policy-map interface
ATM5/0: VC 0/101 -
Service-policy output: atm-clp (1132)
Class-map: everything (match-all) (1133/1)
200 packets, 22400 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any (1134)
QoS Set
atm-clp
Packets marked 200
Class-map: class-default (match-any) (1136/0)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any (1137)
0 packets, 0 bytes
5 minute rate 0 bps
NewYork#
NewYork#show atm pvc 0/101
ATM5/0: VCD: 3, VPI: 0, VCI: 101
UBR, PeakRate: 149760
AAL5 L2transport, etype:0xF, Flags: 0x32000C2E, VCmode: 0x0
OAM Cell Emulation: enabled, F5 End2end AIS Xmit frequency: 2 second(s)
Interworking Method: like to like
Remote Circuit Status = No Alarm, Alarm Type = None
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC state: Not Managed
ILMI VC state: Not Managed
InPkts: 200, OutPkts: 200, InBytes: 21600, OutBytes: 21600
InPRoc: 0, OutPRoc: 0
InFast: 200, OutFast: 200, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 200
OAM cells received: 0
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
OAM cells sent: 0
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutAIS: 0, F5 OutRDI: 0
OAM cell drops: 0
Status: UP
NewYork#
You can see from both the policy-map and ATM PVC counters that 200 packets were marked with CLP1.