Cisco 6500 Egress Queueing Query (is it working correctly)

mgg · ‎02-06-2014

hi all

We have a test setup in our lab that we are working with and we believe we must be missing something.

The kit is a 6500, Sup 720B, WS-X6748-48-GE-TX line cards.

We are attempting to implement PFC QOS to ensure uninterupted throughput of real time data (dscp=EF).

Our basic configuration

mls qos map cos-dscp 0 8 16 24 32 46 48 56

mls qos

policy-map QosVoice

class allvoip

set ip dscp ef

class class-default

set ip dscp af21

interface GigabitEthernet1/1

switchport

switchport access vlan 6

switchport mode access

mls qos vlan-based

mls qos trust dscp

interface Vlan6

ip address 10.0.2.149 255.255.255.0

service-policy input QosVoice

In our setup we are passing data from a far end interface into the 6500 and through to vlan internface 6 (and out port gi1/1).

If what I believe is correct then data coming to the switch from vlan6 and out via gi1/1 will pass through QosVoice (and I confirm using wireshark that this is happening), the allvoip class is marking dscp=ef (from the packet capture).

My concern though is that this data is not being placed into the strict priority egress queue on the 6748 line card.

"show queueing interface gi1/1" suggests it is (see end of post).

However when I do some "real world" testing I truely don't believe that traffic in class "allvoip" is really getting strict priority how I would expect. I for example temporarily placed icmp data into this class and when doing large downloads the ping times would be impacted (changing from <1ms to between 3 and 6 ms) - with a strict queue I woudl expect those ping packets to stay totally stable independant of traffic in other queues.

Can I get any input or feedback on our setup?

regards

Mark

Interface GigabitEthernet1/1 queueing strategy: Weighted Round-Robin

Port QoS is enabled

Trust boundary disabled

Trust state: trust DSCP

Extend trust state: not trusted [COS = 0]

Default COS is 0

Queueing Mode In Tx direction: mode-cos

Transmit queues [type = 1p3q8t]:

Queue Id Scheduling Num of thresholds

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

01 WRR 08

02 WRR 08

03 WRR 08

04 Priority 01

queue thresh cos-map

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

1 1 0

1 2 1

1 3

1 4

1 5

1 6

1 7

1 8

2 1 2

2 2 3 4

2 3

2 4

2 5

2 6

2 7

2 8

3 1 6 7

3 2

3 3

3 4

3 5

3 6

3 7

3 8

4 1 5

Jon Marshall · ‎02-06-2014

Mark

Where were the pings coming from and going to in relation to gi1/1 and in relation to the downloads ?

Jon

mgg · ‎02-06-2014

hi Jon

Another vlan another port (sorry should have added that configuration to my original post)

(10.0.3.0/24 network) connected to vlan 2 on gi1/2.

so

testpc (10.0.2.10) <-> cisco 6500 on port gi1/1 (vlan6) <-> port gi1/2 (vlan2) <-> Server (10.0.3.2)

As data comes from the server to the testpc the allvoip class is being used and the packets are definately marked EF by the 6500, however when I "aggitate" the link between teh testpc and cisco 6500 the allvoip traffic gets impacted.

Am I right to assume if the traffic is being assigned the way it should DSCP=EF -> COS 5 and COS 5 associated with the 1p queue on the egress of the 6748 line card) then that traffic should always "go first" and get the strict priority that the queue should provide?

!

interface GigabitEthernet1/2

description Uplink to Core

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 2,99

switchport mode trunk

mls qos vlan-based

mls qos trust dscp

interface Vlan2

ip address 10.0.3.1 255.255.255.0

mpls ip

Kind regards

Mark

Jon Marshall · ‎02-06-2014

Mark

Am I right to assume if the traffic is being assigned the way it should DSCP=EF -> COS 5 and COS 5 associated with the 1p queue on the egress of the 6748 line card) then that traffic should always "go first" and get the strict priority that the queue should provide?

On egress yes it should. It may be but the schematic is a little confusing. Should it look like -

test PC -> (gi1/1) 6500 (gi1/2) -> server

if so the download is taking place beween the test PC and the server. What are the source and destination IPs of the ping ?

Jon

mgg · ‎02-06-2014

Hi Jon

Sorry it may be my drawing of it .

Source is server 10.0.3.2 sending data to clientpc 10.0.2.10

the clientpc has a gateway of 10.0.2.149 (vlan 6 interface IP on the 6500).

I think all is wired right however the egress queueing doesn't seem to be right.

does my configuration look like we've missed something with the QOS?

cheers

MArk

mgg · ‎02-06-2014

Hi Jon

I meant to ask this as part of my post.

Is there any method to actually see the counters on the queues on the egree on the 6500 line cards,

show queueing int gix/y

shows the queueing configuration but it doesn't show any active counters on the 1p3q8t etc. So as data traverses the port I can't see a way to interogate the switch to get that information.

regards

Mark

Jon Marshall · ‎02-06-2014

Mark

Your configuration looks okay and the output of "sh queueing interface" suggests CoS 5 is being mapped to the priority queue.

What i was trying to understand is where the pings were going from and to. For example if you were pinging an IP on the 6500 itself then that is not necessarily a good indicator of repsonse times because the 6500 has to to process these in the main CPU rather than on the hardware ASICs ie. they are software switched.

If you were pinging through the switch to the server then the the packets will be hardware switched but then you have to take into account the ingress queues on gi1/2 as well as your egress queues on gi1/1.

So by pinging from the test PC to either the 6500 or the server (or somewhere else) you need to take into account either the 6500 processing ICMPs or the end to end path the packets have to take.

To answer your question about seeing the counters this is one of the biggest frustrations with the 6500 and QOS (and most hardware switches) in that you cannot see the real time counters in terms of how many packets are being placed in each queue.

Or if there is such a command i haven't found it yet.

Jon

mgg · ‎02-06-2014

Hi Jon

Many thanks for that reply. I agree the inability to see the counters ticking over on each queue on the ports is a bit of a frustration.

Based on what you've said I'm going to have a play further with it and see.

However can I ask one more question regards this (for now atleast) - if I place ICMP Into that allvoip class then would you expect the 1p strict priority queue to keep that data perfectly "clean" - from my reading any data in the priority queue would be processed before any data in the remaining queues (which are then wrr).

cheers

Mark

Jon Marshall · ‎02-06-2014

Mark

I had a reread looking at all the port configs and i have a few questions -

1) on gi1/2 you are trusting DSCP but then you classify and mark on the vlan 6 SVI. You haven't included the full QOS config so i don't know what the class allvoip matches but are the markings from the server not set correctly or is this for testing.

2) why are you doing vlan based QOS. Not saying it's not right just want to understand the reasoning.

However can I ask one more question regards this (for now atleast) - if I place ICMP Into that allvoip class then would you expect the 1p strict priority queue to keep that data perfectly "clean" - from my reading any data in the priority queue would be processed before any data in the remaining queues (which are then wrr).

You can ask as many questions as you like and if i can answer them i will

Depends what you mean by clean. If there any packets in the strict priority queue then they will be serviced before any packets in any other queues. But that is obviously local to the linecard ie. for it to work properly the treatment of the EF packets needs to be end to end.

Jon

mgg · ‎02-06-2014

Hi Jon

Many thanks

I'm using vlan based QOS because later I'll add more vlans to the configuration, this is just initially to see how to use the QOS function on the 6500 - later we'll use this with more vlans. Essentially the port that is currently gi1/1 may later be a truck port with 10+ vlan's bound to it (with associated vlan interfaces on the 6500).

Data arriving from the Server to the 6500 most likely won't have any or valid dscp markings,

allvoip is currently simplified just for icmp traffic for testing - so it's looking like this:

class-map match-all allvoip

match access-group 100

access-list 100 permit icmp any any

What is just concerning me is that when I have a continuous ping running I'm getting deltas in the ping times when I have other data downloading off gi1/1 (which makes me think the strict priority queue isn't quite right).

--

If I can ask, if I wanted to rate limit the data on vlan6 (say limit the data to 10Mbit) and still also do marking in dscp to enable allocation to the differnet egress queues do you have any suggestions? I can use a police statement classes on the policy-map but I don't really want to police each class seperately

kind of like

vlan 6 entire capacity policed to 10mbit

then inside that

allvoip marked EF (and then assigned COS 5 and 1P)

etc etc

cheers

Mark

Jon Marshall · ‎02-06-2014

Mark

What is just concerning me is that when I have a continuous ping running I'm getting deltas in the ping times when I have other data downloading off gi1/1 (which makes me think the strict priority queue isn't quite right).

But where is the continous ping going from and to ie. it is going from the test PC but what is the destination IP of the pings ?

In terms of vlan based QOS i have never used it so i need to have a quick read up on it to see what is available. What exactly do you want to do ie. rate limit the traffic as whole to a certain amount regardless of the marking or rate limit depending on the actual class ?

Jon