[c-nsp] QOS - 6509 - Next Step?
Paul Stewart
paul at paulstewart.org
Thu Feb 1 11:11:40 EST 2007
Thanks.. yeah, it's a big step for us.. kind of forced by VOIP transversing
our network... I have about 120 routers/switches here to migrate into a
"VOIP plan" .. management is "overdressing" the need for QOS that it's the
"end all be all" of streamlining the network - we've approached in the
technical side more as a "network tool" :)
Anyways, on one of the cards we've done the following and I've love to hear
more (thanks for your feedback and also Peter who told us that NBAR is only
software switched on this platform - which is fine for now as we have tonnes
of CPU cycles to spare and the switches/routers don't do a lot of load)....
remembering that the ONLY markings we are doing are DSCP=EF which I
understand is the same as COS=5 (or am I missing a "translation" here) ??
interface GigabitEthernet6/4
description Mail Server
switchport
switchport access vlan 11
switchport mode access
no ip address
wrr-queue bandwidth 30 70
wrr-queue queue-limit 40 30
wrr-queue random-detect min-threshold 1 40 80
wrr-queue random-detect min-threshold 2 70 80
wrr-queue random-detect max-threshold 1 80 100
wrr-queue random-detect max-threshold 2 80 100
wrr-queue cos-map 1 1 1
wrr-queue cos-map 1 2 0
wrr-queue cos-map 2 1 2 3 4
wrr-queue cos-map 2 2 6 7
no cdp enable
Interface GigabitEthernet6/4 queueing strategy: Weighted Round-Robin
Port QoS is enabled
Port is untrusted
Extend trust state: not trusted [COS = 0]
Default COS is 0
Queueing Mode In Tx direction: mode-cos
Transmit queues [type = 1p2q2t]:
Queue Id Scheduling Num of thresholds
-----------------------------------------
1 WRR low 2
2 WRR high 2
3 Priority 1
WRR bandwidth ratios: 30[queue 1] 70[queue 2]
queue-limit ratios: 40[queue 1] 30[queue 2] 30[Pri Queue]*same as
Q2
queue random-detect-min-thresholds
----------------------------------
1 40[1] 80[2]
2 70[1] 80[2]
queue random-detect-max-thresholds
----------------------------------
1 80[1] 100[2]
2 80[1] 100[2]
queue thresh cos-map
---------------------------------------
1 1 1
1 2 0
2 1 2 3 4
2 2 6 7
3 1 5
Queueing Mode In Rx direction: mode-cos
Receive queues [type = 1q2t]:
Queue Id Scheduling Num of thresholds
-----------------------------------------
1 Standard 2
queue tail-drop-thresholds
--------------------------
1 100[1] 100[2]
queue thresh cos-map
---------------------------------------
1 1 0 1 2 3 4 5 6 7
1 2
Packets dropped on Transmit:
BPDU packets: 0
queue thresh dropped [cos-map]
---------------------------------------------------
1 1 0 [1 ]
1 2 0 [0 ]
2 1 0 [2 3 4 ]
2 2 0* [6 7 ]
3 1 0* [5 ]
* - shared transmit counter
Packets dropped on Receive:
BPDU packets: 0
queue thresh dropped [cos-map]
---------------------------------------------------
1 1 0 [0 1 2 3 4 5 6 7 ]
-----Original Message-----
From: nealr [mailto:neal at lists.rauhauser.net]
Sent: Thursday, February 01, 2007 10:33 AM
To: Paul Stewart
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] QOS - 6509 - Next Step?
Paul,
We're working on this now with some of the smaller switches. I just had
to give an encapsulation of what I'd learned about the 3550 through 3750
line and egress queueing. I think you'll find these principles apply to the
6500 but there are varying features based on line cards.
IP precedence and DSCP are layer 3 markings for QoS. When the traffic
is to egress a switch these pieces of information must first be mapped to
one of eight CoS values, and then the CoS values themselves must be assigned
to one of four (on 3550 - 3750) egress queues. Within the egress queues
themselves there can be two different thresholds before discard begins which
allows for some granuality within the queue.
Congestion control may be tail drop or WRED. Some switches support the use
of one of their four queues as a FIFO priority queue.
Interesting stuff - I'm facing no fewer than three definite projects and
two others that are very likely where diffserv domains on Catalyst 3550,
3650, and 3750 play a role. I'm glad to see I'm not the only one wrestling
with this stuff.
Neal
Paul Stewart wrote:
> Hi there...
>
> I'm working on providing priority within our core of 6509's and
> prefer to do marking via NBAR. Is this a very bad idea in general?
> We have NBAR support in all our routers pretty much throughout...
>
> This is not to address congestion as our core and distribution has no
> congestion (referring to maxxing out link speeds etc. specifically)...
>
> So I have started working with several VLAN interfaces on our 6509
> (layer 3
> interfaces) and have DSCP=EF for SIP/MGCP/RTP traffic like this:
>
> class-map match-any QOS-VOIP
> match protocol sip
> match protocol rtp
> match protocol mgcp
> !
> !
> policy-map QOS
> class QOS-VOIP
> set dscp ef
> class class-default
> set dscp default
>
> interface Vlan104
> description xxxxxxxxxxxxxxxxxxx
> bandwidth 100000
> ip address xxx.xxx.xxx.105 255.255.255.248 ip nbar
> protocol-discovery service-policy input QOS
>
> On VLAN interfaces I can only apply the service policy inbound - not
> outbound:
>
> dis1-rtr-mb(config-if)#service-policy output QOS MQC features are not
> supported in output direction for this interface
>
> I don't believe this is a problem because I understand that QOS is
> applied in one direction only - outbound, which on a VLAN layer3
> interface would actually mean traffic *leaving* the interface is marked ..
correct??
>
> So, I've been doing a lot of reading from "End-to-End QOS Network Design"
> which is a great book... I'm faced right now with too much
> information..;)
>
> Next step would be to assign queues on the actual interfaces? Can I
> assign queues to vlan interfaces or only physical interfaces? My
> problem is that the cards are 6148 and 6248 cards so limited
> queues.... as I understand it the 6248 is 1Q4T and the 6148 is 1P2Q2T?
>
> I hope someone can point me in the right direction for the "next
> step"...;)
>
> Thanks very much,
>
> Paul
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
More information about the cisco-nsp
mailing list