QoS on Catalyst 6500

w.speckle · ‎11-19-2003

Hello All,

got a question regarding classification/colouring on a Cat 6500 with IOS 12.1.13 (E9):

We get the output: (all classes dscp 0)

H1C#sh mls qos ip fa 3/11

[In] Policy map is COS-Test [Out] Default.

QoS Summary [IP]: (* - shared aggregates, Mod - switch module, F - install error)

Int Mod Dir Cl-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk

--------------------------------------------------------------------------------

Fa3/11 1 I GOLD 0 0* No 0 1060798 0

Fa3/11 1 I SILVER 0 0* No 0 1060798 0

Fa3/11 1 I BRONZE 0 0* No 0 1060798 0

Fa3/11 1 I PLATINUM 0 0* No 0 1060798 0

H1C#

after applying the following config:

version 12.1

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname H1C

!

boot system sup-bootflash:c6sup22-js-mz.121-13.E9

!

no ip domain-lookup

!

class-map match-any GOLD

description high priority traffic

match access-group name SAP

class-map match-any BRONZE

match access-group name FTP

class-map match-any PLATINUM

description real time protocols

match access-group name VoIP

class-map match-any SILVER

match access-group name HTTP

match access-group name default

!

policy-map COS-Test

class GOLD

set ip dscp 10

class SILVER

set ip dscp 18

class BRONZE

set ip dscp 28

class PLATINUM

set ip dscp 46

!

mls flow ip destination

mls flow ipx destination

mls qos statistics-export

mls qos

!

redundancy

mode rpr-plus

main-cpu

auto-sync running-config

auto-sync standard

!

interface FastEthernet3/11

no ip address

service-policy input COS-Test

switchport

!

ip access-list extended FTP

permit tcp any eq ftp-data any

permit tcp any eq ftp any

permit tcp any any eq ftp-data

permit tcp any any eq ftp

ip access-list extended HTTP

permit tcp any any eq www

permit tcp any eq www any

permit icmp any any

ip access-list extended SAP

remark classification of SAP R3 traffic

permit tcp 10.1.0.0 0.0.255.255 range 3200 3699 any

permit tcp any 10.1.0.0 0.0.255.255 range 3200 3699

remark classification of SAP R3 traffic

ip access-list extended TELNET_SSH

permit tcp any any eq 22

permit tcp any eq 22 any

permit tcp any eq telnet any

permit tcp any any eq telnet

ip access-list extended VoIP

remark Voice over IP classification

permit udp any range 16382 32766 any range 16382 32762

remark Voice over IP classification

ip access-list extended default

remark classification of not identified traffic

permit tcp any any

permit udp any any

permit eigrp any any

permit ospf any any

permit gre any any

remark classification of not identified traffic

!

Any mistakes ? Any hints ?

Cheers, Wolfgang

evanlau · ‎11-19-2003

Try placing the service policy on the VLAN interface to which port fa3/11 belongs.

w.speckle · ‎11-20-2003

Hello,

finally we could identify the cause of the problem:

15:08:14: %QM-4-TCAM_ENTRY: Hardware TCAM entry capacity exceeded

Which is a pretty weired behaviour, because 5 access-lists do not fill up TCAM.

Currently we are investigating if it is a problem of just that test-box or a general one.

We could make it work with just one class either on a VLAN interface or on a physical one - both worked.

The VLAN int is tricky because only the initial flow-setup is routed, subsequent traffic flows are switched directly and do not pass the VLAN interface anymore ...

Many Thanks, Wolfgang

evanlau · ‎11-20-2003

Shouldn't be a problem with applying it to the VLAN int. Even though the flows are 'switched directly', any policies applied to the initial packet is still applied to the subsequent packets, including your policy map (or any other policies for that matter).

w.speckle · ‎11-20-2003

Hello,

unfortunately I can not confirm this:

Colouring on the VLAN int ended up with no result,

(only very little hits on the access-list which identifies VLAN sourced traffic)

The same service-policy applied to a physical int worked fine ...

Wolfgang

evanlau · ‎11-20-2003

This would seem to indicate that most of the traffic is contained within the same VLAN, not routed. In this case, you are correct in saying that the service policy has to be applied to the physical interface, not the VLAN interface.

Is this a correct assumption?