1 Cisco Router with 2 ISP

dual internet links NATing with PBR and IP SLA

VERSION 6 

Introduction
Network Address Translation is a very common feature used to address some issues and also to meet some networks' requirements such as, overlapped networks and Internet links.
In this small document we will discuss a business requirement example, and the main idea behind this example is to demonstrate how to implement and configure NATign with dual homed Internet edge Router  in conjunction with other Cisco IOS advanced features (Policy Based routing PBR and IPSLA ).
Also we will see how all of the above mentioned features work together and how IP SLA will work like a gear to this implementation in term of controlling the exit path of the traffic by controlling the default route in the routing table and PBR decision.

Requirements:
Company XYZ.com has bought a second Internet connection with 1 Mbps in addition to the existing one with 512 Kbps.
the requirement is to load share the traffic over those two links
web traffic and telnet traffic must use the the new ISP link ISP2  and all other traffic must go thorough the old ISP link ISP1
in the case of any of the above links gose down all the traffic should use the remaining link

Note:
this example has been configured in a lab environment and al the private ip addresses used in this document just for the purpose of this example

Proposed solution:
According to the above requirements we will use Policy Based routing feature to control LAN traffic going to the Internet and which path to use.
all traffic from the LAN subnet 10.1.1.0/24 destined to tcp 23, 80 and 443 must be routed to ISP 2  link with next hop 172.16.1.2
all other traffic will go though ISP 2 with next hop of 192.168.1.2

as we do not have any subnet or ip ranges to use it over the Internet we have to use NATing with overload option to use the Internet interface IP address
of each ISP link
for example traffic going through ISP 1 will be seen by ISP one and the Internet as it is from 192.168.1.1
if it is through ISP 2 will be seen as it is from 172.16.1.1

In the case of one of the links go down we need all the traffic to use the other remaining link
this will be archived here by using IP SLA with ICMP echo that will be sent to each of the ISP next hop IP addresses in our example 192.168.1.2 and 172.16.1.2
the ICMP echo will be sent every 1 second with time out of 500 msec

if the icmp reply not heard from any of those next hops within 1 second that link will be considered down and the default route in the Internet router pointing to that hop will be withdrawn from the routing table
and the PBR descion will be changed based on that as well

Configurations:

interface FastEthernet1/0
description LAN interface
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip policy route-map PBR    ---- this is for policy based routing

interface FastEthernet1/1
description To ISP 1
ip address 192.168.1.1 255.255.255.0
ip nat outside
!
interface FastEthernet2/0
description To ISP 2
ip address 172.16.1.1 255.255.255.0
ip nat outside
as we can see above the inside interface was configured as inside NAT interface also a policy based routing with a name of PBR applied to that interface, the configurations of this PBR will be described later
both of the Internet ISP links configured as outside NAT interfaces

IP SLA configurations:

ip sla 1
icmp-echo 192.168.1.2
timeout 500
frequency 1
ip sla schedule 1 life forever start-time now

ip sla 2
icmp-echo 172.16.1.2
timeout 500
frequency 1
ip sla schedule 2 life forever start-time now

as we can IP sla 1 will sends icp echo to ISP 1 ip address every 1 second and IP sla 2 will send it to ISP 2

track 10 rtr 1 reachability
delay down 1 up 1
!
track 20 rtr 2 reachability
delay down 1 up 1
!

if ip sla 1 did not get icmp replay within 1 second track 10 will be considered as down ( from ISP 1)
track 20 same for ISP 2

ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 10
ip route 0.0.0.0 0.0.0.0 172.16.1.2 track 20

we have two default routes each one point to one of the ISP's IP address, also each static default route is associated with the corresponding IP SLA track created above
in this case if ISP 1 link is down the first default route will disappear from  the routing table ( we will see this through some verifications command later in his document).

access-list 10 permit 10.1.1.0 0.0.0.255
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq telnet
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq www
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 443
access-list 101 permit ip any any

these ACLs will be used with PBR and NATing

route-map PBR permit 10
match ip address 100
set ip next-hop verify-availability 172.16.1.2 1 track 20
!
route-map PBR permit 30
match ip address 101
set ip next-hop verify-availability 192.168.1.2 2 track 10
!
we can see from the above route-map called PBR that we have several checks to our traffic coming from the LAN interface towards the Internet

first check is the ACL level
if the traffic soured from our LAN subnet 10.1.1.0/24 and going to any destination using tcp 23, 80 or 443 then this traffic will be match with ACL 100
if any thing else then will be match with ACL 101

In case of telnet traffic tcp 23, this will be match by ACL 100 and route-map sequence 10
but in this sequence we have another check before we send the traffic to the next hope 172.16.1.2, we need to make sure this next hope is up and reachable this is done by the IP SLA /track 20 created above if this track is up then the traffic will be route thorough ISP2 with a next hop 172.16.1.2
if this track 20 is down then the default static route entry points to ISP2 will be withdrawn from the routing table and traffic matched by ACL 100 under the sequence number of 10 of the route-map will be routed according to the normal routing table which is through ISP1 ( because at this stage we have only one default static route left  points to ISP1).  Any other traffic has not matched by ACL 100 will use the route map sequence 30 with the same concept described above

Now we can see how IP SLA controlling the routing table and the  PBR choice !!!

route-map ISP2 permit 10
match ip address 10
match interface FastEthernet2/0
!
route-map ISP1 permit 10
match ip address 10
match interface FastEthernet1/1

those two Route maps will be used by the NAT command
Please note that we have in each of the route-maps match interface this interface representing the exit interface of that nat
this command is important if we do not use it the router always will use the first nating statement and all our traffic will be sourced in our example from 192.168.1.1 !!
we will see that later in this document the effect of removing the match interface from the route-map

ip nat inside source route-map ISP1 interface FastEthernet1/1 overload
ip nat inside source route-map ISP2 interface FastEthernet2/0 overload

this is simply our nating commands each with is corresponding interface and route-map

verifications:

for the verifications purposes we will use a loopback interface created on both ISP routers in our example to represent an destination in the Internet
which is 100100.100.100/32

show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
    192.168.1.2      Route metric is 0, traffic share count is 1
  * 172.16.1.2      Route metric is 0, traffic share count is 1

we have two default route in our routing table which means both ISP routers IP addresses are reachable by SLA icmp echo

show route-map PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop verify-availability 172.16.1.2 1 track 20 [up]  Policy routing matches: 24 packets, 1446 bytes
  route-map PBR, permit, sequence 30
  Match clauses:
    ip address (access-lists): 101
  Set clauses:
    ip next-hop verify-availability 192.168.1.2 2 track 10  [up]  Policy routing matches: 60 packets, 6840 bytes
both SLA traks 10 and 20 in UP state shown in the route maps show command

now lets ping 100.100.100.100 from the an internal host in subnet 10.1.1.0/24 and we enable debug of NATing on the Internet edge router to see the translated traffic

ping 100.100.100.100

*Dec 19 20:24:44.103: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [80]
*Dec 19 20:24:44.371: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [80]

this is showing us that icmp traffic translated to ->192.168.1.1,

this means that icmp traffic has been match with ACL 101 and because track 10 is up traffic sent to 192.168.1.1 then translated using NAT
this is the PBR debug result for the above ping

*Dec 19 20:25:12.247: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, len
100, FIB policy match
*Dec 19 20:25:12.251: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, g=19
2.168.1.2, len 100, FIB policy routed
*Dec 19 20:25:12.259: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [81]
*Dec 19 20:25:12.623: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [81]

Now lets see the result when we do a telnet session from the internal network:
telnet 100.100.100.100

*Dec 19 20:26:00.375: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, len
44, FIB policy match
*Dec 19 20:26:00.375: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, g=17
2.16.1.2, len 44, FIB policy routed
*Dec 19 20:26:00.383: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [57504]    --- the traffic used 172.16.1.1 link -----
*Dec 19 20:26:01.159: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [25782]

lets shut down ISP1 link to simulated a link down and see how IP SLA will work in this situation:

ping 100.100.100.100

*Dec 19 20:27:54.139: %TRACKING-5-STATE: 10 rtr 1 reachability Up->Down
*Dec 19 20:27:57.895: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [82]
*Dec 19 20:27:58.099: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [82]

now our ICMP traffic match by ACL 101 is using the link of ISP2 with 172.16.1.1 as the source IP.

we can see bellow that interface connected to ISP 1 is still up, but because the next hop not reachable via ICMP,  IP SLA removed the default route that uses ISP1 next hop from the routing table

interfaces up/up but default route to ISP1 disappeared because of SAL track 10

FastEthernet1/0            10.1.1.1        YES NVRAM  up                    up
FastEthernet1/1            192.168.1.1     YES NVRAM  up                    up
FastEthernet2/0            172.16.1.1      YES manual up                    up

show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 172.16.1.2      Route metric is 0, traffic share count is 1

lets bring it back to up now

*Dec 19 20:31:29.143: %TRACKING-5-STATE: 10 rtr 1 reachability Down->Up

Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 192.168.1.2      Route metric is 0, traffic share count is 1
    172.16.1.2      Route metric is 0, traffic share count is 1

ping 100.100.100.100

*Dec 19 20:32:15.559: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [183]
*Dec 19 20:32:16.071: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [183]

Now lets remove the match interface command from each of the NAT route-maps and see the result

(config)#route-map ISP1
(config-route-map)#no ma
(config-route-map)#no match in
(config-route-map)#no match interface fa1/1
(config-route-map)#route-map ISP2
(config-route-map)#no ma
(config-route-map)#no match int fa2/0
(config-route-map)#

#clear ip nat translation *

then we do ping and telnet we will see al the traffic will be translated to 192.168.1.1 regardless which exit the traffic is using !!!

ping 100.100.100.100
*Dec 19 20:33:47.615: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [184]
*Dec 19 20:33:48.067: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [184]

*Dec 19 20:34:51.675: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [
64704]
*Dec 19 20:34:51.679: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [
64704]
*Dec 19 20:34:51.683: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [64704]
*Dec 19 20:34:51.847: NAT*: o: tcp (100.100.100.100, 23) -> (192.168.1.1, 21603)
[52374]
*Dec 19 20:34:51.847: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [52374]
*Dec 19 20:34:52.123: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [
64705]

lets put match interface back  to the nat route-maps

*Dec 19 20:36:23.379: NAT*: i: icmp (10.1.1.10, 16) -> (100.100.100.100, 16) [18
5]
*Dec 19 20:36:23.383: NAT*: i: icmp (10.1.1.10, 16) -> (100.100.100.100, 16) [18
5]
*Dec 19 20:36:23.387: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [185]
*Dec 19 20:36:23.827: NAT*: o: icmp (100.100.100.100, 16) -> (192.168.1.1, 16) [
185]
*Dec 19 20:36:23.827: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [185]

telnet 100.100.100.100
*Dec 19 20:36:52.099: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46655]
*Dec 19 20:36:52.099: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46655]
*Dec 19 20:36:52.103: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [46655]
*Dec 19 20:36:52.259: NAT*: o: tcp (100.100.100.100, 23) -> (172.16.1.1, 16305)
[41145]
*Dec 19 20:36:52.259: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [41145]
*Dec 19 20:36:52.355: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46656]
*Dec 19 20:36:52.359: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [46656]
*Dec 19 20:36:52.375: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46657]

Conclusion:
to conclude the above configuration example, by using NAT with other Cisco IOS features in particular IP SLA the network will be more automated and reliable, we can track the next hop reachability and we may use other advanced features of IP sla such as link jitter, in the case that we have VOIP traffic. Also by using PBR functionalities we were able to classify our traffic and send it based on the requirements over the two links to avoid congesting one link and leave the other link as passive/back up only.

cisco class traffic shaping

Table Of Contents

Class-Based Shaping

Feature Overview

Configuring GTS on a Traffic Class

Specifying Average Rate or Peak Rate Traffic Shaping

Configuring CBWFQ Inside GTS

Benefits

Restrictions

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

Configuring Class-Based Shaping

Configuring CBWFQ Inside GTS

Verifying the Configuration of Policy Maps and Their Classes

Configuration Examples

Class-Based Shaping Example

CBWFQ in Conjunction with GTS Example

CBWFQ Inside GTS Examples

Example 1

Example 2

Verifying the Configurations

Command Reference

service-policy (class map)

shape

shape max-buffers

Class-Based Shaping

---

This feature module describes the Class-Based Shaping feature. This document includes the following sections:

•Feature Overview

•Supported Platforms

•Supported Standards, MIBs, and RFCs

•Configuration Tasks

•Configuration Examples

•Command Reference

Feature Overview

Traffic shaping allows you to control the traffic going out an interface in order to match its transmission to the speed of the remote, target interface and to ensure that the traffic conforms to policies contracted for it. Traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.

Using the Class-Based Shaping feature, you can do the following:

•Configure generic traffic shaping (GTS) on a traffic class

•Specify average rate or peak rate traffic shaping

•Configure class-based weighted fair queueing (CBWFQ) inside GTS

Class-based shaping can be enabled on any interface that supports GTS.

Configuring GTS on a Traffic Class

Using the Class-Based Shaping feature, you can configure GTS on a class, rather than only on an access control list (ACL). In order to do so, you must first define traffic classes based on match criteria including protocols, ACLs, and input interfaces. You can then apply traffic shaping to each defined class.

Specifying Average Rate or Peak Rate Traffic Shaping

Traffic shaping limits the rate of transmission of data. In addition to using a specifically configured transmission rate, you can use GTS to specify a derived transmission rate based on the level of congestion.

You can specify two types of traffic shaping; average rate shaping and peak rate shaping. Average rate shaping limits the transmission rate to the committed information rate (CIR). Using the CIR ensures that the average amount of traffic being sent conforms to the rate expected by the network.

Peak rate shaping configures the router to send more traffic than the CIR. To determine the peak rate, the router uses the following formula:

peak rate = CIR(1+Be/Bc)

where:

•Be is the Excess Burst rate.

•Bc is the Committed Burst rate.

Peak rate shaping allows the router to burst higher than average rate shaping. However, using peak rate shaping, the traffic sent above the CIR (the delta) has the potential of being dropped if the network becomes congested.

If your network has additional bandwidth available (over the provisioned CIR) and the application or class can tolerate occasional packet loss, that extra bandwidth can be exploited through the use of peak rate shaping. However, there may be occasional packet drops when network congestion occurs. If the traffic being sent to the network must strictly conform to the configured network provisioned CIR, then you should use average traffic shaping.

Configuring CBWFQ Inside GTS

Prior to this release, when GTS queues packets that, when sent, cause the traffic flow to violate the configured rate, only flow-based WFQ was supported for the queued packets.

Using the Class-Based Shaping feature, CBWFQ is supported for the queued packets. You can use CBWQ to configure classes of queued traffic and provide relative or absolute bandwidth guarantees to those classes. Note that the relative or absolute bandwidth guarantees are with regard to the configured CIR.

Benefits

Flexibility of Match Criteria

Applying GTS to classes provides greater flexibility for configuring traffic shaping. Previously, this ability was limited to the use of ACLs.

Better Use of Bandwidth

Specifying peak rate shaping allows you to make better use of available bandwidth by allowing more data than the CIR to be sent if the bandwidth is available.

Bandwidth Allocation

CBWFQ allows you to specify the exact amount of bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, you can configure up to 64 classes and control distribution among them, which is not the case with flow-based WFQ.

Flow-based WFQ applies weights to traffic to classify it into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. These weights, and traffic classification, are dependent on and limited to the seven IP Precedence levels.

Coarser Granularity and Scalability

CBWFQ allows you to define what constitutes a class based on criteria that exceed the confines of flow. CBWFQ allows you to use ACLs and protocols or input interface names to define how traffic will be classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete classes in a service policy.

Restrictions

Peak and average traffic shaping is configured on a per-interface or per-class basis, and cannot be used in conjunction with commands used to configure GTS from previous versions of Cisco IOS. These commands include the following:

•traffic-shape adaptive

•traffic-shape fecn-adaptive

•traffic-shape group

•traffic-shape rate

Adaptive traffic shaping for Frame Relay networks is not supported using the Class-Based Shaping feature. To configure adaptive GTS for Frame Relay networks, you must use the commands from releases prior to Release 12.1(2) of Cisco IOS software.

Related Documents

For related information on this feature, refer to the following documents:

•Cisco IOS Quality of Service Solutions Configuration Guide, Cisco IOS Release 12.1

•Cisco IOS Quality of Service Solutions Command Reference, Cisco IOS Release 12.1

Supported Platforms

•Cisco 1600 series

•Cisco 2500 series

•Cisco 2600 series

•Cisco 3600 series

•Cisco 4500 series

•Cisco 4700 series

•Cisco 7200 with NPE150 or higher for T1/E1/Ethernet rates

•Cisco 7200 with NPE200 or higher for T3 rates

•Cisco Route Switch Processor (RSP)

Supported Standards, MIBs, and RFCs

Standards

None

MIBs

None

RFCs

None

Configuration Tasks

See the following sections for configuration tasks for the Class-Based Shaping feature. Each task in the list is identified as either optional or required.

•Configuring Class-Based Shaping (Required)

•Configuring CBWFQ Inside GTS (Optional)

•Verifying the Configuration of Policy Maps and Their Classes (Optional)

Configuring Class-Based Shaping

To configure Class-Based Shaping, use the first two commands in global configuration mode to specify the name of the policy map and the name of the class map. Use the remaining commands in class-map configuration mode to specify average or peak rate.

	Command	Purpose
Step 1	Router(config)# policy-mappolicy-map	Specifies the name of the policy map to be created or modified.
Step 2	Router(config)# class-mapclass-map-name	Specifies the name of the class map to be created.
Step 3	Router(config-pmap-c)# shape{average | peak} cir [bc] [be]	Specifies average or peak rate shaping.
Step 4	Router(config-pmap-c)# shape max-buffers number-of-buffers	(Optional) Specifies the maximum number of buffers allowed on shaping queues.

Configuring CBWFQ Inside GTS

To configure CBWFQ inside GTS, use the first two commands in global configuration mode to specify the name of the policy map and the name of the class map. Use the remaining commands in class-map configuration mode to specify average or peak rate and to attach the service policy to the class.

	Command	Purpose
Step 1	Router(config)# policy-map policy-map	Specifies the name of the policy map to be created or modified.
Step 2	Router(config)# class-map class-map-name	Specifies the name of the class map to be created.
Step 3	Router(config-pmap-c)# shape{average | peak} cir [bc] [be]	Specifies average or peak rate shaping.
Step 4	Router(config-pmap-c)# service-policy policy-map	Attaches the service policy to the class.

Verifying the Configuration of Policy Maps and Their Classes

To display the contents of a specific policy map, a specific class from a specific policy map, or all policy maps configured on an interface, use one of the following commands in global configuration mode:

Command	Purpose
Router# show policy policy-map	Displays the configuration of all classes comprising the specified policy map
Router# show policy policy-map class class-name	Displays the configuration of the specified class of the specified policy map
Router# show policy interfaceinterface-name	Displays the configuration of all classes configured for all policy maps on the specified interface.

Configuration Examples

This section provides the following configuration examples:

•Class-Based Shaping Example

•CBWFQ in Conjunction with GTS Example

•CBWFQ Inside GTS Examples

Class-Based Shaping Example

The following example defines one class, c1. Class c1 is configured to shape traffic to 384 kbps, with a normal burst size of 15440 bits.

Router(config)# policy-map shape

Router(config-pmap)# class c1

Router(config-pmap-c)# shape average 384000 15440

Router(config-pmap-c)# configure terminal

Router(config)# interface Serial 3/3

Router(config-if)# service out shape

CBWFQ in Conjunction with GTS Example

The following example uses CBWFQ at the interface and shapes the traffic before it is queued to CBWFQ.

In this example, two classes are defined—cust1 and cust2. The class cust1 is ensured a bandwidth of 256 kbps, and the output is shaped to 384 kbps. The class cust2 is ensured a bandwidth of 384 kbps, but if enough bandwidth is available on the interface, the class can obtain throughput up to a peak of 512 kbps.

Figure 1 illustrates this example.

Figure 1 CBWFQ in Conjunction with GTS

The following commands are used to configure this example:

Router(config)# policy-map shape-cbwfq

Router(config-pmap)# class cust1

Router(config-pmap-c)# shape average 384000

Router(config-pmap-c)# bandwidth 256

Router(config-pmap)# class cust2

Router(config-pmap-c)# shape peak 512000

Router(config-pmap-c)# bandwidth 384

Router(config-pmap-c)# configure terminal

Router(config)# interface Serial 3/3

Router(config-if)# service out shape-cbwfq

CBWFQ Inside GTS Examples

This section provides two examples of configuring CBWFQ inside GTS.

Example 1

The first example uses hierarchical policy maps and configures CBWFQ inside GTS.

In the following example, three policy maps are defined—cust1-classes, cust2-classes, and cust-policy. The policy maps cust1-classes and cust2-classes have three classes defined—gold, silver, and bronze.

For cust1-classes, gold is configured to use 50 percent of the bandwidth. Silver is configured to use 20 percent of the bandwidth, and bronze is configured to use 15 percent of the bandwidth.

For cust2-classes, gold is configured to use 30 percent of the bandwidth. Silver is configured to use 15 percent of the bandwidth, and bronze is configured to use 10 percent of the bandwidth.

The policy map cust-policy specifies average rate shaping of 384 kbps and assigns the service policy cust1-classes to the class cust1. The policy map cust-policy specifies peak rate shaping of 512 kbps and assigns the service policy cust2-classes to the class cust2.

Figure 2 illustrates this example.

Figure 2 Hierarchical Policy Maps Using Class-Based Shaping

Configuration for cust1-classes

Router(config)# policy-map cust1-classes

Router(config-pmap)# class gold

Router(config-pmap-c)# bandwidth percent 50

Router(config-pmap)# class silver

Router(config-pmap-c)# bandwidth percent 20

Router(config-pmap)# class bronze

Router(config-pmap-c)# bandwidth percent 15

Configuration for cust2-classes

Router(config)# policy-map cust2-classes

Router(config-pmap)# class gold

Router(config-pmap-c)# bandwidth percent 30

Router(config-pmap)# class silver

Router(config-pmap-c)# bandwidth percent 15

Router(config-pmap)# class bronze

Router(config-pmap-c)# bandwidth percent 10

Configuration for Customer Policy and QoS Features

Router(config)# policy-map cust-policy

Router(config-pmap)# class cust1

Router(config-pmap-c)# shape average 384000

Router(config-pmap-c)# service-policy cust1-classes

Router(config-pmap)# class cust2

Router(config-pmap-c)# shape peak 51200

Router(config-pmap-c)# service-policy cust2-classes

Router(config-pmap-c)# interface Serial 3/2

Router(config-if)# service out cust-policy

Example 2

In this example, the Class-Based Shaping feature is configured for the class named shaped in the policy map named GTS_in_ModCLI. The class shaped is shaped to an average rate of 241,000 bits per second (bps). CBWFQ is also enabled on the class, which guarantees a bandwidth of 241 kbps during times of congestion at the interface.

The shaped class is a congestion point for all the subclasses that comprise that class. Therefore, the subclasses can be further differentiated in the shaped class. All these subclasses are part of the policy map, CBWFQ_in_GTS, that is attached to the shaped class.

Configuration for Policy Map GTS_in_ModCLI

Router(config)# policy-map GTS_in_ModCLI

Router(config-pmap)# class shaped

Router(config-pmap-c)# bandwidth 241

Router(config-pmap-c)# shape average 241000

Router(config-pmap-c)# service-policy CBWFQ_in_GTS

Configuration for Policy Map CBWFQ_in_GTS

The policy map, CBWFQ_in_GTS, has four CBWFQ classes:

Router(config)# policy-map CBWFQ_in_GTS

Router(config-pmap)# class cust_A

Router(config-pmap-c)# bandwidth percent 25

Router(config-pmap)# class cust_B

Router(config-pmap-c)# bandwidth percent 25

Router(config-pmap)# class cust_C

Router(config-pmap-c)# bandwidth percent 25

Router(config-pmap)# class class-default

Router(config-pmap-c)# fair

Verifying the Configurations

The output of the show policy-map command for GTS_in_ModCLI displays an expanded configuration, including the subclasses:

Router# show policy-map GTS_in_ModCLI

  Policy Map GTS_in_ModCLI

   Class shaped

   Weighted Fair Queueing

       Bandwidth 241 (kbps)  Max Threshold 64 (packets)

   Traffic Shaping

    Average Rate Traffic Shaping

            CIR 241000 (bps) Max. Buffers Limit 1000 (Packets)

     Policy Map CBWFQ_in_GTS

     Class cust_A

     Weighted Fair Queueing

         Bandwidth 25 (%)    Max Threshold 64 (packets)

     Class cust_B

     Weighted Fair Queueing

         Bandwidth 25 (%)    Max Threshold 64 (packets)

     Class cust_C

     Weighted Fair Queueing

         Bandwidth 25 (%)    Max Threshold 64 (packets)

     Class class-default

     Weighted Fair Queueing

         Flow based Fair Queueing

The policy map GTS_in_ModCLI can be attached to any logical interface that provides a congestion point. Run-time statistics after attaching to interface Serial 3/0 are shown.

Router# show policy interface Serial 3/0

 Serial3/0 

 output : GTS_in_ModCLI

  Class shaped

   Weighted Fair Queueing

       Output Queue: Conversation 267 

         Bandwidth 241 (kbps) Max Threshold 64 (packets)

         (pkts matched/bytes matched) 3852/947384

         (pkts discards/bytes discards/tail drops) 0/0/0

   Traffic Shaping

     Target    Byte   Sustain   Excess    Interval  Increment Adapt

     Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active

     241000    1928   7712      7712      32        964       -

     Queue     Packets   Bytes     Packets   Bytes

     Depth                         Delayed   Delayed   Active

     41        3980      978872    3967      975686    yes

    Class cust_A

     Weighted Fair Queueing

         Output Queue: Conversation 41 

           Bandwidth 25 (%) Max Threshold 64 (packets)

           (pkts matched/bytes matched) 0/0

           (pkts discards/bytes discards/tail drops) 0/0/0

    Class cust_B

     Weighted Fair Queueing

         Output Queue: Conversation 42 

           Bandwidth 25 (%) Max Threshold 64 (packets)

           (pkts matched/bytes matched) 0/0

           (pkts discards/bytes discards/tail drops) 0/0/0

    Class cust_C

     Weighted Fair Queueing

         Output Queue: Conversation 43 

           Bandwidth 25 (%) Max Threshold 64 (packets)

           (pkts matched/bytes matched) 0/0

           (pkts discards/bytes discards/tail drops) 0/0/0

    Class class-default

     Weighted Fair Queueing

         Flow Based Fair Queueing

         Maximum Number of Hashed Queues 32 

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications.

•service-policy (class map)

•shape

•shape max-buffers

service-policy (class map)

To attach a policy map to a class, use the service-policy class-map configuration command. To remove a service policy from a class, use the no form of this command.

service-policy policy-map

no service-policy

Syntax Description

policy-map

The name of a service policy map (created using the policy-map command) to be attached.

Defaults

No service policy is specified.

Command Modes

Class-map configuration within policy map

Command History

Release	Modification
12.1(2)T	This command was introduced.

Usage Guidelines

You can attach a single policy map to one or more classes to specify the service policy for those classes. This command is only available for the output interface, which is assumed.

Examples

In the following example, three policy maps are defined—cust1-classes, cust2-classes, and cust-policy. The policy maps cust1-classes and cust2-classes have three classes defined—gold, silver, and bronze.

For cust1-classes, gold is configured to use 50 percent of the bandwidth. Silver is configured to use 20 percent of the bandwidth, and bronze is configured to use 15 percent of the bandwidth.

For cust2-classes, gold is configured to use 30 percent of the bandwidth. Silver is configured to use 15 percent of the bandwidth, and bronze is configured to use 10 percent of the bandwidth.

The policy map cust-policy specifies average rate shaping of 384 kbps and assigns the service policy cust1-classes to the policy map cust1-classes. The policy map cust-policy specifies peak rate shaping of 512 kbps and assigns the service policy cust2-classes to the policy map cust2-classes.

To configure classes for cust1-classes, use the following commands:

Router(config)# policy-map cust1-classes

Router(config-pmap)# class gold

Router(config-pmap-c)# bandwidth percent 50

Router(config-pmap)# class silver

Router(config-pmap-c)# bandwidth percent 20

Router(config-pmap)# class bronze

Router(config-pmap-c)# bandwidth percent 15

To configure classes for cust2, use the following commands:

Router(config)# policy-map cust2-classes

Router(config-pmap)# class gold

Router(config-pmap-c)# bandwidth percent 30

Router(config-pmap)# class silver

Router(config-pmap-c)# bandwidth percent 15

Router(config-pmap)# class bronze

Router(config-pmap-c)# bandwidth percent 10

To define the customer policy with cust1-classes and cust2-classes and QoS features, use the following commands:

Router(config)# policy-map cust-policy

Router(config-pmap)# class cust1

Router(config-pmap-c)# shape average 384000

Router(config-pmap-c)# service-policy cust1-classes

Router(config-pmap)# class cust2

Router(config-pmap-c)# shape peak 51200

Router(config-pmap-c)# service-policy cust2-classes

Router(config-pmap-c)# interface Serial 3/2

Router(config-if)# service out cust-policy

Related Commands

Command	Description
policy-map	Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
show policy-map	Displays the configuration for the specified class of the specified policy map.

shape

To specify average or peak rate traffic shaping, use the shape class-map configuration command. To remove traffic shaping, use the no form of this command,

shape {average | peak} cir [bc] [be]

no shape {average | peak} cir [bc] [be]

Syntax Description

average	Specifies average rate shaping.
peak	Specifies peak rate shaping.
cir	Specifies the committed information rate (CIR) in bits per second (bps).
bc	Specifies the Committed Burst rate in bits.
be	Specifies the Excess Burst rate in bits.

Defaults

No default behavior or values.

Command Modes

Class-map configuration within policy map

Command History

Release	Modification
12.1(2)T	This command was introduced.

Usage Guidelines

Traffic shaping limits the rate of transmission of data. In addition to using a specifically configured transmission rate, you can use generic traffic shaping (GTS) to specify a derived transmission rate based on the level of congestion.

You can specify two types of traffic shaping; average rate shaping and peak rate shaping. Average rate shaping limits the transmission rate to the CIR. Using the CIR ensures that the average amount of traffic being sent conforms to the rate expected by the network.

Peak rate shaping configures the router to send more traffic than the CIR. To determine the peak rate, the router uses the following formula:

peak rate = CIR(1+Be/Bc)

where:

•Be is the Excess Burst rate.

•Bc is the Committed Burst rate.

Peak rate shaping allows the router to burst higher than average rate shaping. However, using peak rate shaping, the traffic sent above the CIR (the delta) has the potential of being dropped if the network becomes congested.

If your network has additional bandwidth available (over the provisioned CIR) and the application or class can tolerate occasional packet loss, that extra bandwidth can be exploited through the use of peak rate shaping. However, there may be occasional packet drops when network congestion occurs. If the traffic being sent to the network must strictly conform to the configured network provisioned CIR, then you should use average traffic shaping.

Examples

The following example sets the uses average rate shaping to ensure a bandwidth of 256 kbps:

shape average 256000

The following example uses peak rate shaping to ensure a bandwidth of 300 kbps, but allow throughput up to 512 kbps if enough bandwidth is available on the interface:

bandwidth 300

shape peak 512000

Related Commands

Command	Description
bandwidth	Specifies or modifies the bandwidth allocated for a class belonging to a policy map.
class (policy map)	Specifies the name of the class whose policy you want to create or change, and the default class (commonly known as the class-default class) before you configure its policy.
policy-map	Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
service-policy	Attaches a policy map to an input interface or VC, or an output interface or VC, to be used as the service policy for that interface or VC.
shape max-buffers	Specifies the maximum number of buffers allowed on shaping queues.

shape max-buffers

To specify the maximum number of buffers allowed on shaping queues, use the shape max-buffers class-map configuration command. To remove the maximum number of buffers, use the no form of this command.

shape max-buffers number-of-buffers

no shape max-buffers number-of-buffers

Syntax Description

number-of-buffers

Specifies the maximum number of buffers. The minimum number of buffers is 1, the maximum number of buffers is 4096.

Defaults

The default setting is 1000 buffers.

Command Modes

Class-map configuration within policy map

Command History

Release	Modification
12.1(2)T	This command was introduced.

Usage Guidelines

You can specify the maximum number of buffers allowed on shaping queues for each class configured to use generic traffic shaping (GTS).

Examples

The following example configures shaping and sets the maximum buffer limit to 100:

shape average 350000

shape max-buffers 100

Related Commands

Command	Description
bandwidth	Specifies or modifies the bandwidth allocated for a class belonging to a policy map.
class (policy map)	Specifies the name of the class whose policy you want to create or change, and the default class (commonly known as the class-default class) before you configure its policy.
policy-map	Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
service-policy	Attaches a policy map to an input interface or VC, or an output interface or VC, to be used as the service policy for that interface or VC.
shape	Specifies average or peak rate traffic shaping.