cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1707
Views
0
Helpful
6
Replies

QoS for Cisco 2811 with HWIC-4ESW

orochi_yagami
Level 1
Level 1

Hi Expert,

In face i've posted the same thread under section voice, video and colaboration but didn't receive any advices.

I've defined a class-map that match the voice rtp traffic from ippphone connected to a hwic-4esw module. I'm not sure why the voice rtp traffic doesn't match the DSCP value (EF,46) defined in the class-map.Instead, I got to add in additional matching condition using NBAR which match the protocol RTP, then the counter show increment when there is an active call.

The class-map and policy defined as below:

I

!
class-map match-any Voice-SIG
match ip dscp cs3
match ip dscp af31
class-map match-any Voice-RTP
match ip dscp ef
  match protocol rtp
!

     Class-map: Voice-RTP (match-any)
           104613 packets, 6695232 bytes
          5 minute offered rate 25000 bps, drop rate 0 bps
          Match: ip dscp ef (46)
            0 packets, 0 bytes
            5 minute rate 0 bps
          Match: protocol rtp
             104613 packets, 6695232 bytes
            5 minute rate 25000 bps
          Priority: 24 kbps, burst bytes 1500, b/w exceed drops: 0

Why the voice rtp doesn't match ip dscp value here? Is it because of the legacy HWIC?

Thanks

6 Replies 6

orochi_yagami
Level 1
Level 1

Hi all,

Any help would be appreciate.

Thanks

Hi Expert,

Any help would be appreciate!!!

TIA

stephenshaw
Level 1
Level 1

Hi,

you may not be getting a match on the DSCP 46 because it's not marked. Where is the marking being done? Is the network path, on a per hop basis, trusting the value or do you have to remark at each hop?

i.e. just because a phone is able to mark the traffic, doesn't mean that the network, end-to-end, will accept the value without altering it. You may have a port or trunk that changes the value back to DSCP 0 and consequently, although, you are sending RTP traffic, it won't match at DSCP EF in the class-map.

Please post the relevant QoS configs from the point where marking is done to where the service-policy is applied.

HTH,

Steve

Hi Steve,

The phone is conneted to the HWIC-4ESW directly,and i was not able to apply any QoS relevant parameters on the fa interface due to the limitation on the old firmware.

!
class-map match-any Voice-SIG
match ip dscp cs3
match ip dscp af31
class-map match-any Voice-RTP
match ip dscp ef
  match protocol rtp audio

match access-group 101
!
policy-map WAN-EDGE
class Voice-SIG
    bandwidth 18
class Voice-RTP
    priority 24
   compress header ip rtp

!
policy-map MQC-FRTS-768
class class-default
    shape average 729600 7296 0
   service-policy WAN-EDGE
!
!
interface Serial0/1/0.102 point-to-point
bandwidth 768
ip address 10.10.112.2 255.255.255.0
ip pim sparse-dense-mode
snmp trap link-status
frame-relay interface-dlci 102  
   class FR-MAP-CLASS-768
!
map-class frame-relay FR-MAP-CLASS-768
frame-relay fragment 960
frame-relay fair-queue
service-policy output MQC-FRTS-768
!

access-list 101 permit udp any range 16384 32767 any

access-list 101 permit udp any any range 16384 32767

TIA

Hi Steve,

According to what you descrbe,the RTP might not match the DSCP 46,and get overwrite to DSCP 0.If this the case,

the DSCP traffic should be treated as "best effort CS1", and how to explain the traffic that matched the "match protocol rtp audio"?

The traffic counter under "macth protocol rtp audio"increase when there's an active call.

So i don't think the rtp get overwrite to DSCP 0.

Need your advice.

TIA

Hi,

Use a sniffer and be sure what the phone is actually sending. Wireshark is freeware and easy to install and use.

As a practical example, we have QoS for a video system. The video system is marking traffic at DSCP 46 (EF) yet the Telco was not seeing matches in their QoS ACL. Sure enough, even though the video system was set to mark the traffic, a sniffer trace showed that it actually was sending out traffic marked at DSCP 0 - a reboot of the system solved that problem.

Please note that my response is based on your original posting too which shows this:

"class-map match-any Voice-RTP
match ip dscp ef
  match protocol rtp "

Do a google search on "match protocol rtp audio" and you'll see some possible explanations as to why sometimes you see a match and other times you don't.

Regards,

Steve