342 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN
Ethernet frame. Although the PFC does not perform any policing or QoS services for the
WAN traffic, it does switch WAN traffic at Layer 3. However, the PFC does not modify the
Layer 3 type of service (ToS) field when processing these packets.
Aside from the FlexWAN performing its own set of QoS functions, there are other things
to consider when deploying QoS on a 6500 with an MSFC and FlexWAN. When a frame is
sent either to the MSFC or FlexWAN, the Layer 2 CoS settings applied to that frame are
not maintained. By default, a 6500 equipped with a PFC I sets the CoS to zero if the frame
is processed and forwarded from the MSFC or the FlexWAN. With a PFC II, CoS is derived
from the precedence value in the IP header. This feature is not configurable. For IP and IPX
packets, the MSFC is not normally involved in the forwarding process. Therefore, careful
consideration must be given when applying QoS policies to the MSFC and FlexWAN so
that the outcome results in the desired behavior. The QoS policies discussed in this chapter
center on the FlexWAN module. Although the MSFC is required for configuring the FlexWAN
module, it is not possible to run many of the mechanisms discussed without a FlexWAN
module. The exception to this is network-based application recognition (NBAR). With Cisco
IOS Release 12.1(13)E, software-assisted NBAR is supported without a FlexWAN module. At
the time of this writing, hardware-assisted NBAR is not yet supported.
Classification
Classification is the first step in applying QoS policies within a network. If traffic is not
classified, policies cannot be applied. Classification categorizes network traffic and assigns
those categories to different classes of service. When the traffic is classified, QoS mecha-
nisms are used to maintain the appropriate service levels for a particular category or class.
Voice traffic, for example, is extremely vulnerable to delays in the network, and as a result
requires expeditious handling on an end-to-end basis. Contrary to the voice traffic, HTTP
or web-based traffic is not significantly impacted by delays or drops experienced in the
network. Therefore, based on the diverse handling requirements, it is necessary to classify
these types of traffic differently. When all traffic is assigned to the appropriate class, mecha-
nisms, such as Low Latency Queuing (LLQ) for voice or Class-Based Weighted Fair
Queuing (CBWFQ) and marking for web-based applications, are applied to accommodate
the required service levels.
There are several ways to implement classification. One method is to classify all traffic
traveling through a specific interface. However, this is primarily for situations where a
homogenous mixture of traffic is present. For those instances, all traffic departing or leaving
a particular interface should be provided the same service level. However, this type of
classification policy is more the exception than the norm. If the previous policy is applied
to an interface where there is a heterogeneous mixture of traffic, any benefits obtained from
deploying QoS are negated. This QoS negation results because no distinctions are being
made between the different assigned priority levels for the various traffic flows.
Classification 343
Another classification method is to use standard and extended access lists. Access-control
lists (ACLs) match addressing information, protocol IDs, or Layer 4 port numbers. When
configuring ACLs, however, prior knowledge of the actual applications and protocols
operating on the network is necessary. Matching values previously specified in the ToS field
of the IP header, either IP precedence or differentiated services codepoint (DSCP), is yet
another classification method. This allows forwarding decisions and policies to be applied
based on predetermined values assigned at either the access or distribution layers of the
network.
One other classification mechanism implemented on the Catalyst 6500 for the FlexWAN
and MSFC is distributed network-based application recognition (dNBAR). dNBAR,
through the use of packet description language modules (PDLMs), recognizes and
classifies a wide range of IP-based applications, as well as HTTP traffic found on networks.
Not only does dNBAR recognize applications using static port assignments, it is capable of
classifying applications that utilize dynamic port assignments, as well as classifying HTTP
traffic based on subport characteristics. dNBAR was initially only supported on the Catalyst
6500 with a FlexWAN module with Software Release 12.1(6)E. However, Cisco IOS
Software Release 12.1(13)E expanded NBAR support to include LAN interfaces and does not
require a FlexWAN module. NBAR is supported only with the MSFC II. This section briefly
describes NBAR and demonstrates how NBAR may be deployed on the Catalyst 6500.
NOTE PDLMs provide the necessary information to the NBAR inspection process, allowing
NBAR to recognize the various applications. PDLMs can be loaded into Flash, and do not
require downtime for the system. As new PDLMs become available, they can be loaded on
the Catalyst 6500 for additional protocol support. PDLMs are only available through Cisco.
For a current list of protocols supported by NBAR at the time of this writing, refer to the
following document at Cisco.com:
“Cisco IOS Software Release 12.2T Network-Based Application Recognition”
Or download PDLMs directly from the following website:
www.cisco.com/cgi-bin/tablebuild.pl/pdlm
NBAR Protocol Discovery
The first step in being able to classify network traffic is to actually know what protocols and
applications are running on the network. This knowledge enables administrators to prior-
itize business-critical information and applications over less-important applications. Unfor-
tunately, to configure ACLs to classify network traffic you must have prior knowledge of
the network applications, as well as their associated protocol or port numbers. One option
for discovering the protocols currently traversing an interface within the network is using
NBAR protocol discovery. NBAR is capable of recognizing any protocol included within
344 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN
the PDLM file. Protocol discovery is applied to the desired interface or group of interfaces
using the following command at each intended interface:
ii
ii
pp
pp
nn
nn
bb
bb
aa
aa
rr
rr
pp
pp
rr
rr
oo
oo
tt
tt
oo
oo
cc
cc
oo
oo
ll
ll
--
--
dd
dd
ii
ii
ss
ss
cc
cc
oo
oo
vv
vv
ee
ee
rr
rr
yy
yy
When protocol discovery is applied to the interface, statistics are gathered depicting the
active protocols traversing the interface. To view the results of the protocol discovery
process, use the following command:
show ip nbar protocol-discovery [ii
ii
nn
nn
tt
tt
ee
ee
rr
rr
ff
ff
aa
aa
cc
cc
ee
ee
type num
]
Example 9-1 demonstrates the behavior of the NBAR protocol discovery process.
Example 9-1 Configuring and Verifying NBAR Protocol Discovery
MSFC#configure terminal
MSFC(config)#interface serial 3/1/0
MSFC(config-if)#ip nbar protocol-discovery
MSFC#show ip nbar protocol-discovery interface serial 3/0/0
Serial3/0/0
Input Output
Protocol Packet Count Packet Count
Byte Count Byte Count
30 second bit rate (bps) 30 second bit rate (bps)
------------------------ ------------------------ ------------------------
fasttrack 1142 25636899
53674 7691069400
0 1988000
secure-http 2227281 32046128
104682300 6409225600
27000 1657000
ssh 209780 22432288
9859648 5608071500
0 1449000
realaudio 19227675 217434
4806918750 10219398
1242000 2000
ntp 2990024 6409226
140531614 961383900
38000 249000
icmp 36144 102
2170488 10608
0 0
eigrp 19540 9724
1242576 620451
0 0
bgp 812 406
39788 17864
0 0
(text omitted)
Total 5702157 140751114
268799486 34224484573
67000 6585000
Classification 345
NBAR Classification
For low-speed serial connections, it is essential to ensure critical applications are given
precedence to the available bandwidth. You can use NBAR protocol discovery to discover
what applications are utilizing network resources, as well as roughly estimate the
bandwidth consumption of those protocols. You can use this information to determine
effective policies to sustain end-to-end service levels.
In the preceding show ip nbar protocol-discovery output, for example, NBAR recognizes
Fasttrack as one of the applications utilizing considerable bandwidth on this connection.
Fasttrack is a protocol used for peer-to-peer applications, such as Kazaa and Grokster. In
this example, protocols matching these descriptions are not mission-critical and are deemed
low-priority. To restrict the bandwidth used by the protocols matching these descriptions,
the following example uses a policer. As a result, access to the available bandwidth is
restricted for these applications. The policer is configured using the MQC and is verified
using show policy-map interface {type num}.
In the preceding configuration, NBAR classifies Fasttrack traffic. The match protocol
statement enables the administrator to specify one of the protocols recognized by NBAR as
match criteria. In the example, the fasttrack keyword is selected. Although it is not
depicted, multiple protocols may be specified as match criteria. Also if multiple protocols
are listed, the class map may be configured to match all conditions, or any one of the condi-
Example 9-2 Configuring Distributed NBAR Classification and Verifying Configuration
MSFC#configure terminal
MSFC(config)# class-map match-all Fasttrack
MSFC(config-cmap)#match protocol fasttrack
MSFC(config)#policy-map Non-critical-apps
MSFC(config-pmap)#class Fasttrack
MSFC(config-pmap-c)#police 128000 1500 1500 conform-action set-prec-transmit 0
exceed-action drop
MSFC#show policy-map interface serial 3/0/0
Serial3/0/0
service-policy output: Non-critical-apps
class-map: Fasttrack (match-all)
190667 packets, 57200100 bytes
30 second offered rate 1345000 bps, drop rate 10000 bps
match: protocol fasttrack
police:
128000 bps, 1500 limit, 1500 extended limit
conformed 18263 packets, 5478900 bytes; action: set-prec-transmit 0
exceeded 5 packets, 1500 bytes; action: drop
violated 76902 packets, 23070600 bytes; action: drop
conformed 129000 bps, exceed 0 bps violate 548000 bps
class-map: class-default (match-any)
640676 packets, 143760844 bytes
30 second offered rate 3387000 bps, drop rate 0 bps
match: any
640676 packets, 143760844 bytes
30 second rate 3387000 bps
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.