QoS question

[juniorb2000]

Hi,

We have a 6509 at our core/distrubution and stacks of 3750s at the access. We are using port-chanels for the uplinks configured as trunks. All layer 3 information is on the 6509.

We are looking to deploy Alcatel IP phones which will be marking audio and signalling as ef and af31 respectively. The phones will have their own dedicated ports on the 3750s (ie not sharing with the PCs) on a seperate VLAN.

I want to ensure voice traffic is priotised on the uplinks to the core. As I understand, I shouldn't need to do any Qos config on the ports that connect the handsets as they are dedicated, witt the exception of 'mls qos trust dscp'. Then on the uplinks, I should just be able to use 'auto qos voip trust' and this will transpose the DSCP markings to cos 5 and pop the voice traffic in the priority queue for the uplink to the core? Does this sound like an adequate configuration?

Many Thanks,

James

 

[ADB100]

Hi,

We have a 6509 at our core/distrubution and stacks of 3750s at the access. We are using port-chanels for the uplinks configured as trunks. All layer 3 information is on the 6509.

We are looking to deploy Alcatel IP phones which will be marking audio and signalling as ef and af31 respectively. The phones will have their own dedicated ports on the 3750s (ie not sharing with the PCs) on a seperate VLAN.

I want to ensure voice traffic is priotised on the uplinks to the core. As I understand, I shouldn't need to do any Qos config on the ports that connect the handsets as they are dedicated, witt the exception of 'mls qos trust dscp'. Then on the uplinks, I should just be able to use 'auto qos voip trust' and this will transpose the DSCP markings to cos 5 and pop the voice traffic in the priority queue for the uplink to the core? Does this sound like an adequate configuration?

Many Thanks,

James

Why bother? Its a pretty poor design already... Its unlikely you will have problems if you just leave QoS disabled everywhere and just concentrate on the forwarding of traffic. Enabling QoS is probably going to make things worse with a design like you describe IMO - certainly enabling QoS on the stackable 3750's without some more thought is likley to degrade performance (for non-VoIP data traffic) without actually improving anything.

Sorry to be so blunt but you describe a design from the 1990's and then talk about QoS to provide differential services to your VoIP traffic.....

Think about the design, get it right and you won't have any issues....

Andy

 

[juniorb2000]

I appreciate your input, but I beg to differ, quite strongly. The design is perfectly valid and up-to-date. (ever read Cisco's Smart Business Architecture, Bordeless Networks for Midsize organisations, 2010?)

The links that make up the LAGs are spread across different line cards on the 6500 and different switches in the 3750 stacks giving a star design. This offers resilience without the requirement for spanning-tree failover (of course it is left switched on in case of cabling errors) I should add that the 6500 has redundant sup720s, though naturally you could argue the chassis is a spof....

Whether or not you like the design is entirely subjective however. I'm fully aware resilience without spanning-tree & hsrp can be done by taking layer3 to the Access and using routing protocols, but the above was the design settled upon some time back and has served extremely well.

"certainly enabling QoS on the stackable 3750's without some more thought is likley to degrade performance"

Well yeah, that's kinda obvious. To some extent enabling QoS anywhere on any network is going to degrade the performance of some traffic at time of congestion. (ie that has lower priority) Your suggestion of leaving QoS disabled everywhere is a totally valid option and may still be the route we take though I'm investigating all avenues..

My uplinks are pretty chunky to the point where I'm not worrying about them being congested too often. The main reason I'm looking to prioritise the voice on these is case of occasional bursts which may cause rtp or singalling traffic to be dropped.

Thanks

 

[VinceWhirlwind]

I know where ADB100 is coming from, but I don't see why he's so down on your design.
There's nothing wrong with a 6500 core with aggregated links out to a stack of 3750s. The bit about seperate interfaces on the 3750s is pretty dumb - you end up with twice as many active ports and twice as much cabling, but I guess that wasn't your choice but an idiotic decision by management.

If you're happy with auto-qos, just put this on all the ports:
auto qos voip trust
mls qos trust dscp

 

[juniorb2000]

Thanks Vince. I totally take you point about the ports, it's pretty dumbass and yes you are correct in saying it was management decision!

That was kinda the jist of my original question though. As the ports are dedicated, I figure I could just trust dscp on the those ports and only use autoqos (+ trust dscp) on the uplinks where there's the possibility of contention. I'm hoping then that the ef and af31 traffic will get put in the priority queue for the uplinks.
Naturally I'd do the same on the core end of the uplinks...
cheers

 

[ADB100]

I appreciate this is all my own opinion but please bear with me.

I understand its a valid design but with the equipment you have why compromise what could be a platinum-class network? In my experience big layer-2 networks are just painful - I have troubleshot that many I have lost count... We have customers with huge layer-2 domains and they wonder why when they have problems they always have BIG problems. Regardless of QoS being enabled if there is a layer-2 issue it affects the whole of the layer-2 domain.
Break your network down into layer-3 chunks and it will just work better. Once you have a nice layer-3 design, then think about QoS (if its needed?).

Andy

 

[VinceWhirlwind]

Ah, ADB, you've adopted the Cisco approach. Layer-3 to the edge isn't *my* cup of tea. (Not usually, anyway).
It seems to me the reason Cisco produced propaganda in favour of it was due to their competitors' better layer-2 redundancy features (at the core).
Ultimately, you need to choose between the balance of skills required for ongoing support (and increased latencies) vs. any genuine improvement to reliability.

 

[ADB100]

Vince as I said I have had many many bad experiences with layer-2 networks. When they break they break big time and if the broadcast domain is the entire campus its the entire campus that goes down. I've seen Universities, Hospitals and even some Enterprise networks all fall down due to the same layer-2 design approach (or simply a lack of a design?).
Troubleshooting is always a nightmare - where is that MAC address? Ok lets start looking. Oh it appears on that uplink and that uplink and that uplink. Oh it might be a loop? is everyone complaining? Ok, lets start pulling cables...

What I don't understand is why design it this way if you don't need to? Saying its easier is just a cop out. If the hardware can support it build it so its as perfect as it can be.

All in my opinion of course...

Andy - CCIE

 

[VinceWhirlwind]

Part of the problems you describe is caused by the textbooks that still push the (stupid) idea of VLAN separation by *function* instead of by geography.

If his stacks of 3750s each have one VLAN on them, and that VLAN doesn't go anywhere else (except the core) then a problem affecting one broadcast domain affects one wiring closet. Tracking PCs is easier because even 1st-level support will soon learn that "ip address 10.1.205.nn is in wiring closet 5 on the second floor", or whatever your scheme is.

 

[dgrizzard]

Unless you're not using VTP (or at least pruning), and you're limiting the VLANs that are crossing each trunk port...then L2 issues in a large L2 domain are always huge.

Some supervisor freaks out in your core and all of a sudden the whole campus is down and you've taken 2 data centers with it. Not to mention all your branch offices that depend on those two data centers as well. Oops.

If you're going to go through all that though...why not do it the right way and at least have L3 links in your core/distribution?

 

[ADB100]

I agree Vince and if you do that then fine. But why bother if you can remove the potential layer-2 issue altogether? If you only have layer-2 switches then you have no choice, but we are talking cat 3750s here....... If the pc or server team know they can extend a layer-2 network between wiring closets or from the server access layer to a user access layer where their pc is they inevitably will....
I am working on a network at the moment and its just all this - lots of vlans everywhere, secondary IP's and its a problem fiasco. The team who look after it like the ability to put themselves in the server vlans wherever they happen to be connected.... And they wonder why when they accidentally connected two access layers together via an IP phone the whole thing fell up its own you know where. Admittedly this isn't a Cisco campus but the same principles apply.

Andy

 

[VinceWhirlwind]

I don't think "a 6509 at our core/distrubution and stacks of 3750s at the access" justifies a distribution layer, and if his core crashes, it will take everything out regardless of whether his 3750s have IP enabled or not..

His primary objective at the moment would be to get a redundant core.

I think Cisco's default "trunk" config that allows all VLANs is a problem. They should have to be added manually, thus encouraging people to prune.

I have nightmares about "lots of VLANs everywhere".
A couple of years ago I started working on a network and the boss told me he wanted everybody put on VLANs. He wanted everybody in finance on a finance VLAN, HR on an HR VLAN, printers on a printer VLAN, etc...
They get this from textbooks, which still push this crap.

 

[ADB100]

A separate distribution layer is overkill definitely but moving the layer-3 functionality from the core to the access-layer I'd certainly consider it if the hardware can do it? As I say remove the potential for allowing someone to span VLANs between access layers 'just because they can'..... For a network of this size I think a single 6500 is overkill and also under-designed. Everything in one box - bad idea already, but everything in one hugely expensive box? Why not buy two less expensive layer-3 switches (or stacks)?

Anyway but back to the original QoS question..... I'd say just leave it disabled unless you are actually seeing any issues. If you really want to enable it then download the older QoS SRND (v3.3) and follow the guidelines in there (the latest one seems too much in my opinion (input queue tuning? why?). There are examples in the Campus section for each switch type. On uplinks and ports connected to phones or voice appliances set them to trust DSCP and be done. The only caveat to this would be with the 2960,3560 & 3750 QoS queue-set defaults that need changing to get around the agressive dropping of high-rate (non-voice) flows.

Andy

 

[VinceWhirlwind]

Yeah, the 6500 doesn't look like the best choice. In his situation, I've usually gone for just another stack of 3750s for the core. Gives you redundancy and flexibility without the outrageous cost.