cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
245
Views
0
Helpful
1
Replies

Improving QoS on 6509-E

I have inherited a network that includes a single C6509E that is operating as a distribution switch.  I've not used one f these in quite a while, so I'm a tad rusty.

The 6509 is running sup-bootflash:s72033-pk9sv-mz.122-17d.SXB11a.bin.  I'm pretty sure I need to upgrade it to 12.2(18).  I'm not sure if it will support 15.x.  Since I'm only running layer 2, which build should I require.

The Access layer consists of a approximately 10 3750 stacks, each connected to the 6509 via a PortChannel on anywhere from 4GB to 8GB in size.  As would be expected, each Port Channel is evenly distributed across two WS-6748-GE-TX cards.

The current Core is a pair of Nexus 5596 switches.  The 6509 is L2 only.  Prior to the arrival of the Nexus routers, the 6509 was one of a pair, which provided layer 3, with no core layer to speak of.  So, this is somewhat of an improvement.

In all, things appear to work OK for the most part.  All of the pipes appear to be larger than needed, so capacity on the trunks does not appear to be an issue. 

We recently added a new site , and this site has it's own CUCM cluster, which is connected via a SIP trunk over MPLS (10M).  Since it is new, the phones that were ordered at the new site are video-capable.  With the exception of a couple of test phones, none of the phones (<300) at the old site support video.  In trying to ascertain the bandwidth being needed for the MPLS, I started looking at QoS across the enterprise.  The intent is that video would be lower priority (AF41) than audio (EF) on MPLS.  The MPLS is is all configured correctly, but I find that traffic leaving the old site isn't being queued in that manner, and a number of video calls could result in filling the EF queue.

So, I thought I'd take a look at the old network to see what's up.  In looking at the access switch connected to a video phone, I see that the EF and AF41 traffic are both identified, so that led me to believe that the 6509 isn't configured well.

I found a copy of the "Cisco Catalyst 6500 Voice Deployment Guide (http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/catalyst-switching-voice-solutions/net_implementation_white_paper0900aecd804c7087.pdf), and while dated, it appears to point out that I'm missing a few things:

1) Need of an upgrade to support Software Modularity

2) Trunks to access switches missing "mls qos trust cos"

3) Trunks to core switches missing "mls qos trust dscp"

4) No wrr queueing on any of the CUCM trunks

5) Instead of rapid spanning-tree, the 6509 is using PVST.  

While I have yet to determine that the Nexus is configured correctly, I'm pretty sure that the local MPLS router got installed correctly.  There is also an ASA in between the MPLS router and the Nexus, but I thought I'd start at the 6509 and work back.  

It appears to me that the QoS was configured on the Access switches, but they sort of forgot about the distribution switch.

Am I on the right trail here?

 

 

1 Reply 1

Rajeev Sharma
Cisco Employee
Cisco Employee

Hey,

Regarding your questions:

1) Need of an upgrade to support Software Modularity - Feel free to move up to 15.x series, adding the link for safe harbor releases: http://www.cisco.com/c/en/us/solutions/enterprise/safe-harbor-testing/index.html

2) Trunks to access switches missing "mls qos trust cos" - Yes, it should be there.

3) Trunks to core switches missing "mls qos trust dscp" - Yes but make sure cos-dscp maps are showing correct mapping

4) No wrr queueing on any of the CUCM trunks - It would be required for reserving bandwidth for critical traffic

5) Instead of rapid spanning-tree, the 6509 is using PVST - Again, feel free to jump to rapid.

HTH.

Regards,

RS.

Review Cisco Networking products for a $25 gift card