Configuring CBWFQ for Frame Relay
This section discusses the configuration tasks for enabling CBWFQ on Frame Relay PVCs. CBWFQ is configured via the MQC configuration interface; MQC was explained at the beginning of this chapter. Table 18-1 lists the configuration options available for setting up the traffic classes. Table 18-2 displays the class policy configurations available.
NOTE
CBWFQ is introduced in Cisco IOS Release 12.0(5)T. CBWFQ for Frame Relay is supported on c2600, c3600, and c7200 series routers in Cisco IOS Release 12.1(2)T or later. On the c7500 series with VIP, distributed CBWFQ mode is supported in Cisco IOS Release 12.1(5)T or later.
To set up CBWFQ for Frame Relay on a Cisco router, the user first needs to configure the CBWFQ policy using the MQC. In addition, if your router platform supports Frame Relay Traffic Shaping, FRTS should be enabled for the Frame Relay interface that uses CBWFQ. After these steps are accomplished, the CBWFQ policy needs to be attached to the Frame Relay interface. There are several options available with regard to where the service policy can be applied.
First of all, the policy-map created for CBWFQ can be applied to a Frame Relay map class if CBWFQ needs to be applied to a Frame Relay subinterface or directly to a Frame Relay PVC. Frame Relay Traffic Shaping has to be enabled at the main interface on platforms that support Frame Relay Traffic Shaping. On c7500 series routers, Distributed Traffic Shaping (DTS) is supported, and the shape command has to be used in the policy-map to implement shaping. DTS combines Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping.
NOTE
As of Cisco IOS Release 12.1(5)T, QoS policies must run in distributed mode on the VIP because RSP-based QoS is no longer supported.
If the configured policy-map is applied directly at the main interface level, the CBWFQ mechanism applies to a single interface queue rather than at the per-PVC level queues.
Figure 18-3 shows the topology of the network used to demonstrate CBWFQ. The scenario presented in this example shows how CBWFQ can be used to allocate bandwidth to different classes of traffic on a heterogeneous network. It should be noted here that this scenario only serves as an example. The accompanying configuration examples are not cast in stone because of the varying characteristics and requirements of every network.
Figure 18-3. Network Diagram for Verifying CBWFQ for Frame Relay
As shown in Figure 18-3, routers R1 and R2 are connected to a Frame Relay network. Router R1 represents a spoke office location connected to the central office via a Frame Relay network, at a relatively slow access rate of 64 kbps. The Frame Relay network allows the sites to burst above their respective CIR rates when the traffic is light. R1 serves several remote users at its location, who need to frequently access the main Web server at the central office. The finance administrator at the spoke location with the static address 10.0.0.2/24 needs to upload daily revenue information via a TCP application. At the same time, the company is considering a voice over IP (VoIP) implementation on its network and has installed trial phones on its routers.
The configuration examples for the routers in Figure 18-3 are shown in Example 18-3.
Example 18-3. Configuration Examples of Routers in Figure 18-3
! Router R1:
class-map match-any deluxe
match ip precedence 5
match access-group name UDP
class-map match-all premium
match access-group 101
!
policy-map CBWFQ
class premium
bandwidth 32
class deluxe
bandwidth 16
queue-limit 80
class class-default
fair-queue
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
!
interface Serial4/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial4/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
frame-relay interface-dlci 102
class CBWFQ_class
!
router eigrp 1
network 172.16.1.0 0.0.0.3
network 10.0.0.0 0.0.0.255
!
ip access-list extended UDP
permit udp any any gt 10000
!
!
map-class frame-relay CBWFQ_class
frame-relay cir 96000
frame-relay mincir 64000
frame-relay adaptive-shaping becn
service-policy output CBWFQ
!
access-list 101 permit ip host 10.0.0.2 any
!
dial-peer voice 1 pots
destination-pattern 4001
!
dial-peer voice 2 voip
destination-pattern 4002
ip precedence 5
session target ipv4:172.16.1.2
________________________________________________________________
! Router R2:
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
no ip mroute-cache
duplex auto
speed auto
no cdp enable
!
interface Serial2/1
no ip address
encapsulation frame-relay
no ip mroute-cache
no fair-queue
clockrate 128000
frame-relay class FRTS
frame-relay traffic-shaping
!
interface Serial2/1.201 point-to-point
ip address 172.16.1.2 255.255.255.252
frame-relay interface-dlci 201
!
router eigrp 1
network 172.16.1.0 0.0.0.3
network 192.168.1.0 0.0.0.255
!
map-class frame-relay FRTS
frame-relay cir 512000
frame-relay mincir 256000
frame-relay adaptive-shaping becn
!
dial-peer voice 1 pots
destination-pattern 4002
!
dial-peer voice 2 voip
destination-pattern 4001
ip precedence 5
session target ipv4:172.16.1.1
As shown in Example 18-3, CBWFQ is configured on Frame Relay DLCI 102 at router R1. R1 has a guaranteed access rate of 64 kbps. Because of the different classes of traffic that run on the network, CBWFQ is selected as the queuing mechanism to allocate bandwidth among the different types of traffic. Half of the available bandwidth is allocated to the premium traffic class with the bandwidth command in the class-map premium configurations. The premium class matches traffic based on access list 101, which is in turn matched to all IP traffic from host 10.0.0.2.
Next, 16 kbps is assigned to traffic that matches either named access-list UDP or any traffic with IP precedence set to critical (5). The VoIP traffic between the sites is assigned the precedence of 5.
Traffic not matching any of the criteria set up in the user-defined class-maps goes into the default class. The WFQ scheme is applied to traffic in this default class. The completed policy-map is attached to the CBWFQ_class map-class configuration for Frame Relay. This is assigned to DLCI 102.
Finally, Frame Relay Traffic Shaping is configured at the main serial interface 4/0. The CIR rate is set to 96 kbps, and the minimum CIR rate is fixed at the guaranteed 64 kbps in the Frame Relay map class. This Frame Relay Traffic Shaping configuration allows traffic on DLCI 102 to burst up to 96 kbps during no congestion. Some carriers allow their customers to burst up to the port speed when there is no congestion. When congestion occurs in the Frame Relay network, the output rate can step back to the guaranteed rate of 64 kbps. The CBWFQ mechanism ensures traffic belonging to the defined classes of traffic receive the allocated share of bandwidth.
It is important to mention that the user should ensure that the amount of bandwidth configured is large enough to accommodate all overhead, such as the Layer 2 overhead.
The next section looks at the commands for monitoring CBWFQ for the examples in Figure 18-3.
Table 18-1. Available Options for Setting Up the Traffic Class (class-map) |
|
|
Command (config-cmap) |
Purpose |
|
match access-group {access-group | name access-group-name} |
The content of the packets is checked against the access list or named access list to determine if they belong to the class. |
|
match input-interface interface-name |
This checks the input interface of the packets to determine if they belong to the class. |
|
match protocol protocol |
This checks the packets to determine if they belong to a given protocol and hence, to the class. |
|
match mpls experimental number |
This checks the EXP field in the packets to determine if they belong to the class. |
Table 18-2. Available Options for Setting Up the Class Policy (policy-map) |
|
|
Command (config-pmap-c) |
Purpose |
|
bandwidth [percent percent] or bandwidth kbps |
This specifies the amount of bandwidth in kbps to be assigned to the class. The user should consider the Layer 2 overhead in the configured bandwidth. Note that beginning with Cisco IOS Release 12.1(1), the percent keyword is supported, and bandwidth can be assigned as a percentage. |
|
queue-limit |
This specifies the maximum number of packets that can be enqueued for the class. This uses the Tail Drop method. |
|
random-detect |
This enables WRED. The class policy drops packets using WRED instead of Tail Drop. "Weighted Random Early Detection (WRED) for Frame Relay." |
|
fair-queue (applicable to class-default only) |
This specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. |
|
priority kbps |
This creates a strict priority class and specifies the amount of bandwidth in kbps to be assigned to the class. |
NOTE
CBWFQ is introduced in Cisco IOS Release 12.0(5)T. CBWFQ for Frame Relay is supported on c2600, c3600, and c7200 series routers in Cisco IOS Release 12.1(2)T or later. On the c7500 series with VIP, distributed CBWFQ mode is supported in Cisco IOS Release 12.1(5)T or later.
To set up CBWFQ for Frame Relay on a Cisco router, the user first needs to configure the CBWFQ policy using the MQC. In addition, if your router platform supports Frame Relay Traffic Shaping, FRTS should be enabled for the Frame Relay interface that uses CBWFQ. After these steps are accomplished, the CBWFQ policy needs to be attached to the Frame Relay interface. There are several options available with regard to where the service policy can be applied.
First of all, the policy-map created for CBWFQ can be applied to a Frame Relay map class if CBWFQ needs to be applied to a Frame Relay subinterface or directly to a Frame Relay PVC. Frame Relay Traffic Shaping has to be enabled at the main interface on platforms that support Frame Relay Traffic Shaping. On c7500 series routers, Distributed Traffic Shaping (DTS) is supported, and the shape command has to be used in the policy-map to implement shaping. DTS combines Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping.
NOTE
As of Cisco IOS Release 12.1(5)T, QoS policies must run in distributed mode on the VIP because RSP-based QoS is no longer supported.
If the configured policy-map is applied directly at the main interface level, the CBWFQ mechanism applies to a single interface queue rather than at the per-PVC level queues.
Figure 18-3 shows the topology of the network used to demonstrate CBWFQ. The scenario presented in this example shows how CBWFQ can be used to allocate bandwidth to different classes of traffic on a heterogeneous network. It should be noted here that this scenario only serves as an example. The accompanying configuration examples are not cast in stone because of the varying characteristics and requirements of every network.
Figure 18-3. Network Diagram for Verifying CBWFQ for Frame Relay
As shown in Figure 18-3, routers R1 and R2 are connected to a Frame Relay network. Router R1 represents a spoke office location connected to the central office via a Frame Relay network, at a relatively slow access rate of 64 kbps. The Frame Relay network allows the sites to burst above their respective CIR rates when the traffic is light. R1 serves several remote users at its location, who need to frequently access the main Web server at the central office. The finance administrator at the spoke location with the static address 10.0.0.2/24 needs to upload daily revenue information via a TCP application. At the same time, the company is considering a voice over IP (VoIP) implementation on its network and has installed trial phones on its routers.
The configuration examples for the routers in Figure 18-3 are shown in Example 18-3.
Example 18-3. Configuration Examples of Routers in Figure 18-3
! Router R1:
class-map match-any deluxe
match ip precedence 5
match access-group name UDP
class-map match-all premium
match access-group 101
!
policy-map CBWFQ
class premium
bandwidth 32
class deluxe
bandwidth 16
queue-limit 80
class class-default
fair-queue
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
!
interface Serial4/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial4/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
frame-relay interface-dlci 102
class CBWFQ_class
!
router eigrp 1
network 172.16.1.0 0.0.0.3
network 10.0.0.0 0.0.0.255
!
ip access-list extended UDP
permit udp any any gt 10000
!
!
map-class frame-relay CBWFQ_class
frame-relay cir 96000
frame-relay mincir 64000
frame-relay adaptive-shaping becn
service-policy output CBWFQ
!
access-list 101 permit ip host 10.0.0.2 any
!
dial-peer voice 1 pots
destination-pattern 4001
!
dial-peer voice 2 voip
destination-pattern 4002
ip precedence 5
session target ipv4:172.16.1.2
________________________________________________________________
! Router R2:
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
no ip mroute-cache
duplex auto
speed auto
no cdp enable
!
interface Serial2/1
no ip address
encapsulation frame-relay
no ip mroute-cache
no fair-queue
clockrate 128000
frame-relay class FRTS
frame-relay traffic-shaping
!
interface Serial2/1.201 point-to-point
ip address 172.16.1.2 255.255.255.252
frame-relay interface-dlci 201
!
router eigrp 1
network 172.16.1.0 0.0.0.3
network 192.168.1.0 0.0.0.255
!
map-class frame-relay FRTS
frame-relay cir 512000
frame-relay mincir 256000
frame-relay adaptive-shaping becn
!
dial-peer voice 1 pots
destination-pattern 4002
!
dial-peer voice 2 voip
destination-pattern 4001
ip precedence 5
session target ipv4:172.16.1.1
As shown in Example 18-3, CBWFQ is configured on Frame Relay DLCI 102 at router R1. R1 has a guaranteed access rate of 64 kbps. Because of the different classes of traffic that run on the network, CBWFQ is selected as the queuing mechanism to allocate bandwidth among the different types of traffic. Half of the available bandwidth is allocated to the premium traffic class with the bandwidth command in the class-map premium configurations. The premium class matches traffic based on access list 101, which is in turn matched to all IP traffic from host 10.0.0.2.
Next, 16 kbps is assigned to traffic that matches either named access-list UDP or any traffic with IP precedence set to critical (5). The VoIP traffic between the sites is assigned the precedence of 5.
Traffic not matching any of the criteria set up in the user-defined class-maps goes into the default class. The WFQ scheme is applied to traffic in this default class. The completed policy-map is attached to the CBWFQ_class map-class configuration for Frame Relay. This is assigned to DLCI 102.
Finally, Frame Relay Traffic Shaping is configured at the main serial interface 4/0. The CIR rate is set to 96 kbps, and the minimum CIR rate is fixed at the guaranteed 64 kbps in the Frame Relay map class. This Frame Relay Traffic Shaping configuration allows traffic on DLCI 102 to burst up to 96 kbps during no congestion. Some carriers allow their customers to burst up to the port speed when there is no congestion. When congestion occurs in the Frame Relay network, the output rate can step back to the guaranteed rate of 64 kbps. The CBWFQ mechanism ensures traffic belonging to the defined classes of traffic receive the allocated share of bandwidth.
It is important to mention that the user should ensure that the amount of bandwidth configured is large enough to accommodate all overhead, such as the Layer 2 overhead.
The next section looks at the commands for monitoring CBWFQ for the examples in Figure 18-3.
