cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
922
Views
0
Helpful
5
Replies
Highlighted
VIP Mentor

VoIP QoS Classification

I am planning to imlement QoS in our campus environment ( Used this guide for reference

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html)

I would like to know what is the recommended way to classify VoIP traffic at the access layer. I am looking at the following two options & objective is to minimize wrongly classify other traffic into this category & get prioratization over the network.

ip access-list extended VoIP-TRAFFIC

permit udp any any range 16384 32767

OR

ip access-list extended VoIP-TRAFFIC

permit udp any any range 16384 32767

permit udp any range 16384 32767 any

Does this bidirectional port classification is required or not ?

Also is there any updated QoS reference guide talks about Sup2T (v4.0 is only upto Sup720-10G) which I can refer to ?

5 REPLIES 5
Highlighted
Hall of Fame Expert

Here is the config guide for 12.SY release which can be run on Sup-2T.  Of course you can also use IOS 15, but I don't think there is much of different between this version and 15.  You can also simply configure auto qos.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SY/configuration/guide/sy_swcg.html

HTH

Highlighted

Thanks Raza, It helps. I went through the config guides of 15.0Y as it is the version we are running.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.0SY/configuration/guide/15_0_sy_swcg.html

I am having issues with DSCP based queuing on WS-6816-10G line cards. Documentation say it support DSCP based queuing fro this line card, but when I apply policy into the interface show run does not show it. Also show queueing interface command does not show the value I configured.

But on cli it appears to be applying the policy

6506-E(config-if)#service-policy type lan-queuing input 6816-10G

Propagating [attach] lan queueing policy "6816-10G" to Te4/2 Te4/3 Te4/4

Does anyone experience similar issues with this line card when configuring QoS ?

Here is the my full config related to this

platform qos queueing-only
!
class-map type lan-queuing match-any NETWORK-CONTROL
match dscp 48 56
!
class-map type lan-queuing match-any VOIP-TRAFFIC
  match cos 5
  match dscp 46
!
class-map type lan-queuing match-any MULTIMEDIA-TRAFFIC
  match cos 4
  match dscp 34
class-map type lan-queuing match-any CRITICAL-DATA
  match dscp 22
!
class-map type lan-queuing match-any BULK-DATA
  match dscp 16
!
class-map type lan-queuing match-any SCAVENGER
  match dscp 8
!
policy-map type lan-queuing 6816-10G
   class VOIP-TRAFFIC
   priority
   !
  class NETWORK-CONTROL
   bandwidth remaining percent 10
    !
class MULTIMEDIA-TRAFFIC
   bandwidth remaining percent 20
  !
class CRITICAL-DATA
   bandwidth remaining percent 20
!
class BULK-DATA
   bandwidth remaining percent 40
     !
class SCAVENGER
  bandwidth remaining percent 5
   random-detect dscp-based
  random-detect dscp 8 percent 70 100
  !
class class-default
  bandwidth remaining percent 5
  random-detect multiple-type-based aggregate
  random-detect cos values 0 1 2 3 percent 40 70
  random-detect cos values  6 7 percent 50 100

Highlighted
Hall of Fame Expert

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Ideally, you want to only examine traffic as it enters your network and also, ideally, the source of the traffic should mark itself.

When the source of the traffic marks itself, you may (should) verify the marking is deserved.  For example, packets from a VoIP phone would be expected to have your desired VoIP markings (e.g. DSCP EF for VoIP bearer), but packets from a file server would not be expected to have these markings.

You can verify markings by additional examination of the packet (i.e. does it look like the kind of packet such a packet should be) and/or verify it's bandwidth usage (e.g. VoIP bearer packets, per flow, shouldn't exceed about 128 Kbps).

If devices are incapable of self-marking and/or you can't verify the source of the traffic, then you can resort to the type of examination like you ACL.  Unfortunately, ACLs often only support rudimentary analysis and to insure you get all the packets intended, you might incorrectly mark other traffic.

On Cisco routers, that support NBAR, or Cisco switches that support FPM, "better" packet examination might be done.  (Note some proxies and firewalls can also perform "better" packet examination, but they might not want to remark the ToS.)

Highlighted

Hi Joseph,

Thanks for that information. I think FPM only supports in routers (& not available in access layer switch platforms eg 3750X in my case).

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6723/product_data_sheet0900aecd8034bd93.html

Looks like I have to live with  this inaccurate marking (small %) based on the primitive acl classification using.

thanks again for the response.

Highlighted

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

BTW regarding FPM only in routers, if I remember correctly, FPM first appeared on a special variant of the sup32, the sup32 PISA.