Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Quality of Service

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:

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.

Case Study 13-4: Traffic Marking

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.

ToS Setting

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.

Example 13-46. ToS Setting Configuration

!
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).

Example 13-47. IP Accounting Configuration in the NewYork PE

!
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).

Example 13-48. ToS Setting Verification in the NewYork PE

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.

ToS Reflection

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).

Example 13-49. ToS Reflection Configuration

!
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).

Example 13-50. Generating Precedence 5 Traffic Between CEs

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).

Example 13-51. ToS Reflection Verification in the NewYork PE

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.

MQC IP Precedence or DSCP Setting

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.

Example 13-52. Tunnel Marking with MQC Configuration

!
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).

Example 13-53. Tunnel Marking with MQC Verification in the SanFran PE

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).

Example 13-54. Tunnel Marking with MQC Verification in the NewYork PE

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.

Case Study 13-5: Traffic Policing

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.

Example 13-55. Traffic-Policing Actions

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.

Example 13-56. Traffic-Policing Configuration

!
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.

Example 13-57. ATM TM 4.0 Policers

!
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.

Example 13-58. Conveying Class Classification from Egress to Egress

!
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.

Example 13-59. Verifying the QoS Group Configuration

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.

Case Study 13-6: Queuing and Shaping

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.

Example 13-60. Queuing Configuration for Frame Relay Pseudowires

!
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]

Case Study 13-7: Layer 2-Specific Matching and Setting

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.

Layer 2

Matching

Setting

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.

Example 13-61. Matching on ATM CLP

!
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.

Example 13-62. Setting on ATM CLP-Configuration

!
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.

Example 13-63. Setting on ATM CLPVerification

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.