Cisco Multiservice Switching Networks

2017-07-07 02:10:07

As you know, MPLS QoS is different in frame-based MPLS networks and cell-based MPLS networks. The difference comes from how DiffServ information is conveyed to LSRs. In frame-based MPLS, where there is an MPLS shim header and the experimental bits are visible, the PHB Scheduling Class (PSC) and drop priority are inferred from the EXP (experimental) field, giving birth to E-LSP (EXP Inferred PSC Label Switch Paths). This contrasts with cell-based MPLS, where the class is inferred exclusively from the label (and the drop priority is inferred from the CLP bit for cell-mode MPLS) and thus is called L-LSP (Label-Only Inferred PSC Label Switch Paths).

Enabling and Configuring Multi-vc

The first part of the ATM MPLS QoS configuration consists of enabling Multi-vc. Multi-vc is an eLSR's ability to set up multiple parallel L-LSPs (with different QoS treatment in the MPLS network) to a destination. This capability is shown in Figure 7-2.

Figure 7-2. QoS in ATM MPLS Networks: Multi-vc

In ATM MPLS eLSRs (PE routers in MPLS VPN jargon), packets are mapped to different L-LSPs based on the precedence bits in the IP header. A maximum of four parallel LVCs to a specific destination are set up. Those LVCs have well-known names: available, standard, premium, and control. Four classes, one for each well-known LVC, are defined in ATM MPLS eLSRs, as shown in Table 7-1. These classes are fixed and cannot be changed.

Table 7-1. IP Precedence-to-Class Mappings in eLSRs
Class	IP Precedence
0	0/4
1	1/5
2	2/6
3	3/7

The default mapping from these classes to the LVCs (CoS-to-LSP mapping at the edge) is shown in Table 7-2. Different classes can be mapped to different LVCs by configuration.

Table 7-2. Class-to-L-LSP Default Mapping
Class	LVC
0	Available
1	Standard
2	Premium
3	Control

In our example, we will set up only three parallel LVCs: available, standard, and premium. The reason why we left control out will be more evident later in this chapter when we configure the ATM LSRs. The QoS design we will configure in our MPLS VPN network is shown in Figure 7-3.

Figure 7-3. Sample DiffServ-Aware ATM MPLS Network

The first step in our configuration is to establish the class-to-LVC mapping. We will set up the mapping shown in Table 7-3.

Table 7-3. Class-to-L-LSP Mapping in Our Example
Class	LVC
0 1	Available
2	Standard
3	Premium

To achieve the class-to-LVC mappings, we define a match-all access list and a cos-map and combine the two in a global mpls prefix-map (see Example 7-18).

Example 7-18. Using the mpls cos-map and mpls prefix-map Commands

PE_m8850_RPM_10#conf t Enter configuration commands, one per line. End with CNTL/Z. PE_m8850_RPM_10(config)#access-list 1 permit any PE_m8850_RPM_10(config)#mpls cos-map 1 PE_m8850(config-mpls-cos-map)#class 0 ? available Transmit on available Label-VC control Transmit on control Label-VC premium Transmit on premium Label-VC standard Transmit on standard Label-VC PE_m8850(config-mpls-cos-map)#class 0 available PE_m8850(config-mpls-cos-map)#class 1 available PE_m8850(config-mpls-cos-map)#class 2 standard PE_m8850(config-mpls-cos-map)#class 3 premium PE_m8850(config-mpls-cos-map)#exit PE_m8850_RPM_10(config)#mpls prefix-map 1 access-list 1 cos-map 1 PE_m8850_RPM_10(config)#

In the general case, we can have several CoS maps configuring from one to four parallel LVCs and can apply them to different destinations based on the ACL. With this we can selectively enable or disable multi-vc for different destinations.

At this point, as shown in Example 7-19, we have only one LVC to the remote PE destination.

Example 7-19. Checking ATM LDP Bindings Without Multi-vc

PE_m8850_RPM_10#show mpls atm-ldp bindings 172.27.1.129 32 Destination: 172.27.1.129/32 Headend Router Switch1.27 (3 hops) 0/36 Active, VCD=209 PE_m8850_RPM_10#

To finish the multi-vc configuration, we need to enable multi-vc in the MPLS subinterfaces. See Example 7-20.

Example 7-20. Enabling Multi-vc

PE_m8850_RPM_10#conf t Enter configuration commands, one per line. End with CNTL/Z. PE_m8850_RPM_10(config)#interface switch 1.27 PE_m8850_RPM_10(config-subif)#mpls atm multi-vc PE_m8850_RPM_10(config-subif)#^Z PE_m8850_RPM_10#

You can see in Example 7-21 that we have three LVCs to the remote PE destination.

Example 7-21. Checking ATM LDP Bindings with Multi-vc

PE_m8850_RPM_10#show mpls atm-ldp bindings 172.27.1.129 32 Destination: 172.27.1.129/32 Headend Router Switch1.27 (3 hops) 0/40 Active, VCD=238, CoS=available Headend Router Switch1.27 (3 hops) 0/42 Active, VCD=236, CoS=standard Headend Router Switch1.27 (3 hops) 0/44 Active, VCD=234, CoS=premium PE_m8850_RPM_10#

Configuring the Core Behaviors

In the VSI slaves, four CoS buffers (CoSBs) (QBins in BXM and UXM slaves) are reserved for MPLS. As you know from Chapter 3, "Implementations and Platforms," DiffServ queuing is achieved by VSI and the Service Class Templates (SCTs), providing bandwidth subpartitioned for different classes of service. Each COS (control, premium, standard, and available) is mapped to one of those CoSBs in the general parameters of the SCT. So different traffic classes are queued separately, and each queue (for each class) receives a bandwidth allocation. This mapping is shown in Table 7-4.

Table 7-4. Class-to-L-LSP Mapping in Our Example
Class	IP Precedence	AXSM CoSB Number	BXM and UXM CoSB Number
0	0/4	7	10
1	1/5	8	11
2	2/6	9	12
3	3/7	10	13

This can be seen with the command dspsct on the BPX-8650, IGX-8400, and MGX-8850 platforms. More details can be found in the "Service Class Templates and QoS" section in Chapter 3.

This is the MPLS-only SCT in BPX-8600 and IGX-8400 slaves, which is the default SCT used. See Example 7-22:

Example 7-22. Checking Service Class Templates in BPX and IGX Switches

b8620-7b TN Cisco BPX 8620 9.3.30 Dec. 9 2001 18:43 GMT Service Class Map for MPLS1 Template Service Class Qbin Service Class Qbin Service Class Qbin Default 13 Signaling 10 Tag0 10 Tag1 11 Tag2 12 Tag3 13 Tag4 10 Tag5 11 Tag6 12 Tag7 13 TagAbr 14 Last Command: dspsct 1 Next Command:

On MGX-8850 platforms, the default SCT which is SCT 0 does not have MPLS support. Example 7-23 shows SCT number 4 in an AXSM slave.

Example 7-23. SCT Number 4

To differentiate between the two IP Precedence values in the same CoSB or QBin, we use the Cell Loss Priority (CLP) bit in the ATM cell header as a drop priority.

From the LSC, we can see the service type of the different parallel LVCs (TagCOS0 to TagCOS7) and infer the CoSB used from the SCT. To do this we use the command show xtagatm cross-connect for a specific interface and VPI/VCI, as shown in Example 7-24.

Example 7-24. Using show xtagatm cross-connect for a Specific Interface

m8850_RPM_9#show xtagatm cross-connect interface xTagATM 101 0 40 Phys desc: 10.1 Interface: XTagATM101 Intf type: extended tag ATM VPI/VCI: 0/40 X-Phys desc: 1:1.4:40 X-Interface: XTagATM1144 X-Intf type: extended tag ATM X-VPI/VCI: 27/742 Conn-state: UP Conn-type: input Cast-type: point-to-point Rx service type: Tag COS 0 Rx cell rate: n/a Rx peak cell rate: 10000 Tx service type: n/a Tx cell rate: n/a Tx peak cell rate: n/a m8850_RPM_9#show xtagatm cross-connect interface xTagATM 101 0 42 Phys desc: 10.1 Interface: XTagATM101 Intf type: extended tag ATM VPI/VCI: 0/42 X-Phys desc: 1:1.4:40 X-Interface: XTagATM1144 X-Intf type: extended tag ATM X-VPI/VCI: 27/740 Conn-state: UP Conn-type: input Cast-type: point-to-point Rx service type: Tag COS 1 Rx cell rate: n/a Rx peak cell rate: 10000 Tx service type: n/a Tx cell rate: n/a Tx peak cell rate: n/a m8850_RPM_9#show xtagatm cross-connect interface xTagATM 101 0 44 Phys desc: 10.1 Interface: XTagATM101 Intf type: extended tag ATM VPI/VCI: 0/44 X-Phys desc: 1:1.4:40 X-Interface: XTagATM1144 X-Intf type: extended tag ATM X-VPI/VCI: 27/738 Conn-state: UP Conn-type: input Cast-type: point-to-point Rx service type: Tag COS 2 Rx cell rate: n/a Rx peak cell rate: 10000 Tx service type: n/a Tx cell rate: n/a Tx peak cell rate: n/a m8850_RPM_9# m8850_RPM_9#show xtagatm cross-connect interface xTagATM 101 0 32 Phys desc: 10.1 Interface: XTagATM101 Intf type: extended tag ATM VPI/VCI: 0/32 X-Phys desc: 9.1 X-Interface: n/a X-Intf type: switch control port X-VPI/VCI: 0/134 Conn-state: UP Conn-type: input/output Cast-type: point-to-point Rx service type: Tag COS 7 Rx cell rate: n/a Rx peak cell rate: 353208 Tx service type: Tag COS 7 Tx cell rate: n/a Tx peak cell rate: 353208 m8850_RPM_9#

It is very important to note that the control-vc for untagged traffic (VPI/VCI 0/32 by default) uses the service type Tag CoS 7. So it shares the CoSB with the control class LVCs.

We will now configure the per-hop behaviors (PHBs) and, specifically, the PSC by setting the weights to implement class-based weighted fair queuing (CBWFQ) among the CoS buffers. We do that by configuring the weight as a percentage for each class in each LC-ATM interface, as shown in Example 7-25. That is, the total weight for the four classes in an XTagATM interface is 100 and corresponds to the full interface bandwidth:

Example 7-25. Configuring the ATM CoS Weights

m8850_RPM_9#conf t Enter configuration commands, one per line. End with CNTL/Z. m8850_RPM_9(config)#interface xTagATM 101 m8850_RPM_9(config-if)#mpls atm cos control 1 m8850_RPM_9(config-if)#mpls atm cos available 29 m8850_RPM_9(config-if)#mpls atm cos standard 35 m8850_RPM_9(config-if)#mpls atm cos premium 35 m8850_RPM_9(config-if)#^Z m8850_RPM_9#

So for this XTagATM interface, the premium class and the standard class have the same relative weight, the available class has a weight of 29/35 relative to each of the previous two (that is, a 29/100 weight relative to the 100 percent of interface bandwidth), and the control class has a weight of 1/100 relative to the whole interface.

NOTE

Even though no LVC is using the class control, we configure a relative weight of 1 percent for the CBWFQ PSC. This is because the control-vc carrying LDP and IGP updates (untagged traffic) uses the control CoS buffer.

We now configure all XTagATM interfaces in all LSCs to use these weights.

Configuring the Edge Behaviors

From the DiffServ model, we still need to configure the edge behaviors. We start by configuring the PE router interfaces toward the P routers (facing the MPLS network) by enabling CBWFQ, low-latency queue (LLQ), and weighted random early discard (WRED). We use the Cisco IOS Modular QoS CLI (MQC) provisioning mechanism to accomplish this task.

NOTE

These MQC features require CEF to be enabled. MQC features work only for packets traversing the router on the Cisco IOS CEF switching path. A common mistake is to test this with packets originating in the tested router. This does not work, because those packets are process-switched.

We first define our classes under class-map statements (see Example 7-26).

Example 7-26. PE class-map Configuration

PE_m8850_RPM_10#conf t Enter configuration commands, one per line. End with CNTL/Z. PE_m8850_RPM_10(config)#class-map match-all voip PE_m8850_RPM_10(config-cmap)#match mpls experimental 3 PE_m8850_RPM_10(config-cmap)#class-map match-all dlsw PE_m8850_RPM_10(config-cmap)#match mpls experimental 2 PE_m8850_RPM_10(config-cmap)#class-map match-all avail1 PE_m8850_RPM_10(config-cmap)#match mpls experimental 4 5 PE_m8850_RPM_10(config-cmap)#class-map match-all avail2 PE_m8850_RPM_10(config-cmap)#match mpls experimental 0 1 PE_m8850_RPM_10(config-cmap)#exit

We define four classes (voip, dlsw, avail1, and avail2), and we match on the MPLS experimental bits copied from the IP Precedence bits.

It is important to note that we are matching on MPLS experimental bits. The following is an excerpt from RFC 3035:

...when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a shim header. [...] The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim.

Then we define the policy to apply to those classes in a policy-map, building the Policy block in the edge behavior (see Example 7-27).

Example 7-27. PE policy-map Configuration

PE_m8850_RPM_10(config)#policy-map To-Network PE_m8850_RPM_10(config-pmap)#class voip PE_m8850_RPM_10(config-pmap-c)#priority 128 PE_m8850_RPM_10(config-pmap-c)#class dlsw PE_m8850_RPM_10(config-pmap-c)#bandwidth 256 PE_m8850_RPM_10(config-pmap-c)#random-detect PE_m8850_RPM_10(config-pmap-c)#class avail1 PE_m8850_RPM_10(config-pmap-c)#bandwidth 192 PE_m8850_RPM_10(config-pmap-c)#random-detect PE_m8850_RPM_10(config-pmap-c)#class avail2 PE_m8850_RPM_10(config-pmap-c)#bandwidth 64 PE_m8850_RPM_10(config-pmap-c)#random-detect PE_m8850_RPM_10(config-pmap-c)#set atm-clp PE_m8850_RPM_10(config-pmap-c)#exit PE_m8850_RPM_10(config-pmap)#exit

In these policies we are specifying CBWFQ, a LLQ for the voip class, and WRED. We are differentiating between the avail1 and avail2 classes by a different weight for CBWFQ, but the two classes use the same LVC in the core (Available). To differentiate them in the core, we set the ATM cell header CLP bit in the class avail2.

NOTE

To differentiate the drop priority (CLP bit) in the core, the CoS buffers descriptor template in the SCT needs to be configured for CLP Hysteresis as the Discard Selection, not Frame Discard. Frame Discard is the default. You need to change it so that cells with the CLP bit set or clear are treated differently.

On IGX-8400 and BPX-8600 platforms, the discard selection method can be changed between EPD (a frame-discard method) and CLP hysteresis (a selective cell-discard method) using the command cnfqbin. With these platforms, changing the discard selection mechanism in one QBin does not change the default values in the template.

A different way of setting the CLP bit is with set-clp-transmit as a policing action also using MQC.

We apply the policies for those classes as an output service policy in the PE interface toward the LSR, as shown in Example 7-28.

Example 7-28. PE service-policy Configuration

PE_m8850_RPM_10(config)#interface switch 1.27 PE_m8850_RPM_10(config-subif)#service-policy output To-Network PE_m8850_RPM_10(config-subif)#^Z PE_m8850_RPM_10#

Finally, we need to classify the traffic. We can do so either in the CE router as an output policy toward the PE or in the PE router as an input policy from the CE. In most cases, the CE router is a managed device. Therefore, in our example we will classify traffic in egress on the CE router toward the PE. If the CE router is not owned, the classification can be done at ingress in the PE router following the same procedure and applying the policy as a service-policy input.

For the classification, as shown in Example 7-29, we will use an access list (ACL) to identify VoIP traffic, a protocol match in MQC to categorize DLSW traffic, and other protocol matches to recognize some specific protocols (Telnet, HTTP, POP3, and SMTP are considered low-priority for this exercise). We will group those packets in the avail2 class and use class-default as the avail1 class. The class-default includes all packets not matched by any of the other classes.

Example 7-29. CE class-map Configuration

CE_1#conf t Enter configuration commands, one per line. End with CNTL/Z. CE_1(config)#access-list 100 permit udp any any range 16384 32767 CE_1(config)#class-map match-any voip CE_1(config-cmap)#match access-group 100 CE_1(config-cmap)#class-map match-any dlsw CE_1(config-cmap)#match protocol dlsw CE_1(config-cmap)#class-map match-any avail2 CE_1(config-cmap)#match protocol telnet CE_1(config-cmap)#match protocol http CE_1(config-cmap)#match protocol pop3 CE_1(config-cmap)#match protocol smtp CE_1(config-cmap)#exit

After the classification is done, we mark those packets in those classes in a policy map, as shown in Example 7-30. We will mark IP Precedence that at the PE router will be used to identify these classes copied to the EXP bits.

Example 7-30. CE policy-map Configuration

CE_1(config)#policy-map To-PE CE_1(config-pmap)#class voip CE_1(config-pmap-c)#set ip precedence 3 CE_1(config-pmap-c)#class dlsw CE_1(config-pmap-c)#set ip precedence 2 CE_1(config-pmap-c)#class avail2 CE_1(config-pmap-c)#set ip precedence 1 CE_1(config-pmap-c)#class class-default CE_1(config-pmap-c)#set ip precedence 4 CE_1(config-pmap-c)#^Z CE_1#

Finally, we apply that policy to the FE interface in the output direction, as shown in Example 7-31.

Example 7-31. CE service-policy Configuration

CE_1(config)#interface fastEthernet 0/0 CE_1(config-if)#service-policy output To-PE

We perform a similar configuration in the other PE and CE routers, setting up the other direction.

MQC can also serve a different purpose than QoS support. To provide for counters and statistics on the different frames received by a PE with different EXP bits values, you can configure a policy-map that only sets the experimental bits to the same value as matched by the class-map, and then apply the service-policy in the input direction in the ATM interface facing the P router. This service-policy does not modify the packets, but enables per-COS counters to be displayed using the command show policy-map interface. So a service-policy in the output direction serves as congestion management towards the P router, and a service-policy in the input direction collects counters from the P router.

QoS Example Summary

As a summary of our QoS example, we can go backwards and draw a table with the network behavior. It would look similar to Table 7-5.

Table 7-5. QoS Summary in Our Example
Class	CE		PE		LVC
Class	Classif	Marking	Classif	Marking	LVC
VoIP	VoIP ACL	IP Prec 3	MPLS Exp 3	LLQ WRED	Premium (Class 3; Precedence 3/7)
DLSW	DLSW protocol	IP Prec 2	MPLS Exp 2	CBWFQ WRED	Standard (Class 2; Precedence 2/6)
Avail2	Telnet, HTTP, POP3, and SMTP protocols	IP Prec 1	MPLS Exp 0 1	CBWFQ WRED CLP => 1	Available (Classes 0/1; Precedence 0/1/4/5)
Avail1	The rest	IP Prec 4	MPLS Exp 4 5	CBWFQ WRED	Available (Classes 0/1; Precedence 0/1/4/5)

This table helps you understand the complete picture. It also helps you map an IP packet entering the CE router to the LVC it will use while traversing the ATM LSRs.

Enabling and Configuring Multi-vc

Figure 7-2. QoS in ATM MPLS Networks: Multi-vc

Table 7-1. IP Precedence-to-Class Mappings in eLSRs

Table 7-2. Class-to-L-LSP Default Mapping

Figure 7-3. Sample DiffServ-Aware ATM MPLS Network

Table 7-3. Class-to-L-LSP Mapping in Our Example

Example 7-18. Using the mpls cos-map and mpls prefix-map Commands

Example 7-19. Checking ATM LDP Bindings Without Multi-vc

Example 7-20. Enabling Multi-vc

Example 7-21. Checking ATM LDP Bindings with Multi-vc

Configuring the Core Behaviors

Table 7-4. Class-to-L-LSP Mapping in Our Example

Example 7-22. Checking Service Class Templates in BPX and IGX Switches

Example 7-23. SCT Number 4

Example 7-24. Using show xtagatm cross-connect for a Specific Interface

Example 7-25. Configuring the ATM CoS Weights

Configuring the Edge Behaviors

Example 7-26. PE class-map Configuration

Example 7-27. PE policy-map Configuration

Example 7-28. PE service-policy Configuration

Example 7-29. CE class-map Configuration

Example 7-30. CE policy-map Configuration

Example 7-31. CE service-policy Configuration

QoS Example Summary

Table 7-5. QoS Summary in Our Example

Категории