[c-nsp] [cisco-voip] QoS

[Michael Crilly]

Hi,

Thanks for the replies.

The network, 10.200.*.* is a VoIP only network and is on its own VLAN 
(VLAN 11). No other traffic passes through this network. I think I will 
include the port range as it does, as you say, potentially prevent other 
traffic getting priority too, whether by mistake or through a malicious act.

A good point has been raised about the marking done by SIP phones. The 
point made basically stated that even the cheapest of handsets will tag 
its traffic as 'EF' (46) and therefore as priority traffic. I think I 
will take this into consideration as Cisco does recommend you get that 
Trust Boundary as close to the source as possible, and nothing is closer 
than the phone its self. I will check exactly what phones are being used 
and what marking they can do.

I will let you guys know how I get on.

That being said, I feel my question has been some-what missed. I was 
wanting to understand whether or not my configuration, which does seem 
to be getting hits from 'show mls qos interface gi0/2 statistics', is 
actually using a priority queue? How can I check? Is there no way of 
looking at each queue and the traffic as it is actually sitting in the 
queue over a 5-minute average?

Cheers guys.

On 03/02/2011 19:44, Cristobal Priego wrote:
> correct me if i'm wrong but from what i see on your access list
> any udp traffic coming on subnet 10.200.x.x will be marked as ef (46) 
> even if it's an ftp transfer
> i'd modify my access list and create extended access list
>
> ip access-list extended VVLAN-VOICE
>   permit udp 10.200.0.0 0.0.255.255 range 16384 32767 any
>   permit udp any 10.200.0.0 0.0.255.255 range 16384 32767
>
> so you will make sure that only your voice packets gets to the 
> priority queue only
>
> just a thought
>
> 2011/2/3 Michael Crilly <michael.crilly at comtek.co.uk 
> <mailto:michael.crilly at comtek.co.uk>>
>
>     After some playing around, I am getting this output from the 'mls
>     qos int gi0/2 stat' command:
>
>     salesSwitch#show mls qos int gi0/2 st
>     GigabitEthernet0/2
>     Ingress
>      dscp: incoming        no_change     classified     policed  
>      dropped (in bytes)
>        46:          732        0                     0              
>      0             0
>     Others: 1843820098 1740299668 103521162  0             0
>     Egress
>      dscp: incoming         no_change  classified   policed    dropped
>     (in bytes)
>        46: 580616            n/a              n/a            0        
>          0
>     Others: 304803305    n/a              n/a            0              0
>
>     This to me looks as though my policy-map is working on the fa0/1 -
>     24 range of ports:
>
>     Policy Map VPOLICY-IN
>        Class VCLASS-IN
>          set dscp ef
>
>     Class VCLASS-IN:
>
>      Class Map match-any VCLASS-IN (id 1)
>       Match access-group name VACL-IN
>
>     VACL-IN:
>
>        10 permit udp 10.200.0.0 0.0.255.255 any
>        20 permit udp any 10.200.0.0 0.0.255.255
>
>     Does this look to you guys as though the marking is working? Also,
>     I assume the following configuration for the Gi0/1 - 2 ports is
>     everything needed to allow QoS to work for DSCP 46 (which goes
>     into queue 4, the priority queue):
>
>     interface GigabitEthernet0/1
>      switchport trunk encapsulation dot1q
>      switchport mode trunk
>      mls qos monitor dscp 46
>      macro description cisco-switch
>      wrr-queue bandwidth 10 20 70 1
>      wrr-queue cos-map 1 0 1
>      wrr-queue cos-map 2 2 4
>      wrr-queue cos-map 3 3 6 7
>      wrr-queue cos-map 4 5
>      priority-queue out
>      spanning-tree link-type point-to-point
>     !
>     interface GigabitEthernet0/2
>      switchport trunk encapsulation dot1q
>      switchport mode trunk
>      mls qos monitor dscp 46
>      macro description cisco-switch
>      wrr-queue bandwidth 10 20 70 1
>      wrr-queue cos-map 1 0 1
>      wrr-queue cos-map 2 2 4
>      wrr-queue cos-map 3 3 6 7
>      wrr-queue cos-map 4 5
>      priority-queue out
>      spanning-tree link-type point-to-point
>
>     All help appreciated greatly.
>
>     Cheers,
>
>     -- 
>
>     Michael Crilly
>     ICT Systems Administrator
>     Comtek Network Systems
>
>     M: 07771133663
>     E: michael.crilly at comtek.co.uk <mailto:michael.crilly at comtek.co.uk>
>
>     _______________________________________________
>     cisco-voip mailing list
>     cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>     https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

-- 

Michael Crilly
ICT Systems Administrator
Comtek Network Systems

M: 07771133663
E: michael.crilly at comtek.co.uk