The first article in this series discussed
The second article discussed This article looks at We'll wrap this series up next month with an article on RSVP, which deserves an article of its own. I realize these articles have been mostly configuration commands. That's partly a response to having had several articles in a row that were light on configuration. It's also an attempt to make the new 11.1 CC and 12.0 commands a little more accessible, since many of us haven't had time to go poking around in the documentation for these IOS releases. I plan to include some words reviewing what these QoS functions can do, trying to place them within a Big Picture.I myself am still looking for some good design ideas as to using these tools across groups of routers. I sometimes think of all this as ponds and colored water. For present purposes, think Federal Express and colored tags (next day, 2nd day, etc.). Think of each router as a FedEx office. The queues are racks near the loading dock for the outbound trucks. Your policy controls which packages get loaded on trucks and planes first. (FedEx is a bad example in that they and the Post Office don't put excess low-priority packages in the dumpster -- an article I read a while back claimed the Italian Post Office actually sells excess mail for paper recycling occasionally, when it backs up too much).
What's missing here is how to engineer a system that works well. What you ultimately get to do is pick which packets get out of each router first, and which traffic gets dropped when there isn't enough bandwidth. This is highly dependent on the traffic in your network, in its variability, and in your Service Level Agreement (i.e., how important it is to you to supply adequate capacity for infrequent but large traffic flows). Going back to our FedEx example, you size trucks and planes to your average business with some sparing capacity. You need to manage capacity, queues, latency to deliver good service. You need to watch how deep on average the queue is getting at each priority level or class of service, as well as how many output drops occur. This requires appropriate network management reporting tools -- I know of nothing currently that does all this.
It's also clear that some people think very differently about all this. I recently skimmed a trade magazine article that criticized Cisco traffic shaping (traffic controlling?) performance in a test. The commentary said that the queuing or traffic shaping was not active unless output queues were full. So I suspect the magazine tested Custom Queuing. (And by the way, as far as I know, CQ kicks in when the queues have some data in them, not just when they're full). In any case, the article criticized the Cisco product because it didn't control traffic flows that added up to less total traffic than the T1 output link. Why would one want to control traffic in this circumstance: you're penalizing one form of traffic and leaving unused bandwidth?
For previous articles, see either http://www.pcinews.com/cisco/index.htm or http://www.netcraftsmen.net/welcher/papers/index.htm . For a good set of links on QoS, see also http://www.wiley.com/compbooks/ferguson .
Traffic Shaping allows you to control how fast packets are sent out an interface, any interface. You might want to do this to avoid congestion either locally or elsewhere in your network, for example if you have a network with different access rates or if you are restricting some traffic to a fraction of the available bandwidth. For example, if one end of the link in a Frame Relay network is 256 Kbps and the other end of the link is only 128 Kbps, sending packets at 256 Kbps at the very least causes congestion. Somewhere.
You can traffic shape all traffic on an interface, or use an access list to specify certain traffic. On Frame Relay interfaces, additional per-virtual-circuit features are available with Frame Relay Traffic Shaping.
Traffic shaping is not supported with optimum, distributed, or flow switching. If you enable traffic shaping, all interfaces will revert to fast switching.
traffic-shape group access-list bit-rate [burst-size [excess-burst-size]]
The former command traffic shapes all traffic on an interface. The latter uses an access-list to specify which traffic is to be traffic shaped.
bit-rate: Bit rate that traffic is shaped to in bits per second.
burst-size: Sustained number of bits that can be transmitted per interval. The default is the bit-rate divided by 8.
excess-burst-size: Maximum number of bits that can exceed the burst size in the first interval in a congestion event. The default is equal to the burst-size.
The measurement interval is calculated by dividing the burst-size (if non-zero) by the bit rate. If the burst-size is zero, the excess-burst-size is used (if non-zero).
For Frame Relay, you can use:
traffic-shape adaptive [bit-rate]
This command uses the configured bit rate as a lower bound, with the bit rate specified by the traffic-shape rate command as the upper bound for bandwidth. The actual rate that the traffic is shaped to lies between those two rates. It should be configured at both ends of the link because it also configures the devices to reflect forward explicit congestion notifications (FECN's) as BECN's, enabling the faster end of the link to adjust to congestion at the other end.
show traffic-shape statistics [interface]
interface Ethernet1
traffic-shape rate 5000000 625000 625000
See a prior article, "What's New in Frame Relay", for more detail and configuration examples, at http://www.netcraftsmen.net/welcher/papers/newfr.htm .
If you're choosing outbound interface or next hop in response to destination , then you're doing normal routing, subject to some policy perhaps. Policy routing in the Cisco world refers specifically to routing based on source or other traffic characteristics, other than destination. Since this may have performance impact, use it only where needed and appropriate.
Policy routing has performance impact: it is process or fast switched. It is therefore suitable for setting precedence at low speed edge routers, but not elsewhere.
ip policy route-map map-tag
The route map blocks then are defined using:
route-map map-tag [permit | deny] [sequence-number]
Route-map match conditions used for policy routing can match either packet length or an IP extended access list.
To match the Layer 3 length of the packet, use:
match length min max
To match IP sources and destinations based on standard or extended access list(s):
match ip address {access-list-number | name} [... access-list-number | name]
The route-map block's set conditions can specify precedence value, next-hop for IP routing, or output interface.
To set the precedence value in the IP header:
set ip precedence value
To specify the next hop to which to route the packet (it need not be adjacent):
set ip next-hop ip-address [... ip-address]
To specify the output interface(s) for the packet:
set interface type number [... type number]
To specify the default route next hop for use when there is no explicit route:
set ip default next-hop ip-address [... ip-address]
To specify the default output interface(s) for use when there is no explicit route:
set default interface type number [... type number]
Fast-switched policy routing supports all of the match commands and most of the set commands, except for the set ip default command and some use of the set interface command. The set interface command is supported only over point-to-point links, unless a route-cache entry exists using the same interface specified in the set interface command in the route map.
When process switching policy routing, the routing table is used to check output interface sanity. During fast switching, if the packet matches, the software blindly forwards the packet to the specified interface. To configure fast-switched policy routing on an interface:
ip route-cache policy
Packets generated by the router are not normally policy-routed. To enable local policy routing of such packets, specify the route map to use. This is a global configuration mode command.
ip local policy route-map map-tag
show ip local policy
access-list 1 permit ip 1.1.1.1
access-list 2 permit ip 2.2.2.2
!
interface serial 1
ip policy route-map equal-access
!
route-map equal-access permit 10
match ip address 1
set ip default next-hop 3.3.3.3
route-map equal-access permit 20
match ip address 2
set ip default next-hop 4.4.4.4
route-map equal-access permit 30
set default interface null0
Note that this allows you to set up a policy at one BGP speaking router, and propagate that to other routers via BGP. Hence the name. This means that at the service provider router connecting to a site, a policy can be set up so that inbound traffic elsewhere is classified into the right class of service (IP Precedence bits). This can then interact with Tag Switching, or MPLS.
If you set the QoS group ID, it can then be used for rate-limiting or WFQ based on QoS group ID. This expands on the classes of service provided by the 8 IP precedence values.
If you use IP precedence, it can now be set based on source or destination address.
[no] bgp-policy output ip-prec-map
[no] bgp-policy output ip-qos-map
show ip bgp community-list community-list-number
show ip cef prefix
show ip interface
show ip route prefix
int hssi0/0/0
ip address 210.210.2.1 255.255.255.252
bgp-policy input ip-prec-map
Configuring BGP to set QoS groups:
router bgp 210
neighbor 210.210.14.1 remote-as 210
neighbor 210.210.14.1 route-map comm-relay-prec out
neighbor 210.210.14.1 send-community
!
ip bgp-community new-format
!
access-list 1 permit 210.210.1.0 0.0.0.255
!
route-map comm-relay-prec permit 10
match ip address 1
set community 210:5
!
route-map comm-relay-prec permit 20
set community 210:0
Configuring BGP to set TOS bits (precedence):
router bgp 210
table-map precedence-map
neighbor 200.200.14.4 remote-as 210
neighbor 200.200.14.4 update-source Loopback0
!
ip bgp-community new-format
!
ip community-list 1 permit 210:5
!
route-map precedence-map permit 10
match community 1
set ip precedence 5
!
route-map precedence-map permit 20
set ip precedence 0
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .