[c-nsp] QOS - 6509 - Next Step?
Peter Salanki
peter.salanki at bahnhof.net
Thu Feb 1 11:33:14 EST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If you can CPU switch all your traffic in a 6500 MSFC, you really
should think of selling those 6500s to me and buying 2811s :D
1 feb 2007 kl. 17.11 skrev Paul Stewart:
> 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/
>>
>>
>
> _______________________________________________
> 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/
Sincerely
Peter Salanki
Chief Network Engineer
Bahnhof AB (AS8473)
www.bahnhof.se
Office: +46855577132
Cell: +46709174932
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFFwhZLiQKhdiFGiogRAuCPAJ9YDO2Wax/gMJyM0YFLVbh8AhFWBACfTupZ
ZMoQhJsPYTKowi7+7dzxtOg=
=jHKe
-----END PGP SIGNATURE-----
More information about the cisco-nsp
mailing list