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 <[email protected]
<mailto:[email protected]>>
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: [email protected] <mailto:[email protected]>
_______________________________________________
cisco-voip mailing list
[email protected] <mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
--
Michael Crilly
ICT Systems Administrator
Comtek Network Systems
M: 07771133663
E: [email protected]
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
