Cisco 1751 not tagging hmmm

mattsthe2 · June 2009

**edit this is just for VoIP IP calls, no analog calls at all**

I have a Cisco 1751 that we are going to use for backup voice however when i do a sh policy-map QoS int no packets are being tagged as EF, which is causing the voice to cut out. With a similar configuration on a 2811 router the packets tag just fine.

What gives. Here is the sh ver and sh run:

IDS-Decatur-1751#sh ver
Cisco IOS Software, C1700 Software (C1700-BK9NO3R2SY7-M), Version 12.4(25), RELEASE SOFTWARE (fc2)
Technical Support: Cisco - Shortcut
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Tue 21-Apr-09 09:35 by prod_rel_team

ROM: System Bootstrap, Version 12.2(1r)XE1, RELEASE SOFTWARE (fc1)

IDS-Decatur-1751 uptime is 14 hours, 3 minutes
System returned to ROM by power-on
System restarted at 20:42:48 EDT Wed Jun 10 2009
System image file is "flash:c1700-bk9no3r2sy7-mz.124-25.bin"

Current configuration : 5030 bytes
!
! Last configuration change at 20:55:44 EDT Wed Jun 10 2009 by admin
!
version 12.4
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
!
hostname BackupVoice-1751
!
boot-start-marker
boot-end-marker
!
card type t1 0
logging buffered 4096 debugging
enable secret 5 $1
!
no aaa new-model
memory-size iomem 15
clock timezone EST -5
clock summer-time EDT recurring
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!

!
!
ip cef
no ip domain lookup
ip domain name thdg.com
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
controller T1 0/0
framing esf
linecode b8zs
cablelength long 0db
channel-group 0 timeslots 1-24
!
!
class-map match-all VOICE-CONTROL
match ip dscp cs3
match ip dscp af31
class-map match-all VIDEO
match ip dscp af41
class-map match-all VOICE
match ip dscp ef
match ip dscp cs5
!
!
policy-map QoS
class VOICE
priority 768
set dscp ef
class VIDEO
priority 334
class VOICE-CONTROL
bandwidth 50
set dscp af31
class class-default
fair-queue
set dscp default
!
!
!
!
!
!
interface FastEthernet0/0
description *** LAN Interface ***
ip address 172.17.14.3 255.255.255.0
no ip mroute-cache
speed auto
full-duplex
standby ip 172.17.14.1
standby priority 90
standby preempt
!
interface Serial0/0:0
description *** Backup MPLS Cir ***
bandwidth 1536
ip address XXX 255.255.255.252
no cdp enable
service-policy output QoS
!
interface Serial1/0
ip address XXX 255.255.255.252
ip access-group PROTECT in
no cdp enable
!
router bgp 65000
no synchronization
bgp router-id 172.17.14.3
bgp log-neighbor-changes
network 172.17.14.0 mask 255.255.255.0
neighbor 172.17.14.2 remote-as 65000
neighbor XXX remote-as 6745
neighbor XXX update-source Serial0/0:0
neighbor XXX route-map PREPEND out
no auto-summary
!
ip default-gateway 172.17.14.1
no ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Serial0/0:0
no ip http server
no ip http secure-server
!
!
!
!
ip access-list extended GRE
permit gre 172.17.255.0 0.0.0.255 172.17.255.0 0.0.0.255

logging trap warnings

!
route-map PREPEND permit 10
set as-path prepend 65000 65000 65000
!
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
exec-timeout 180 0
password 7 10
login local
line vty 5 15
login local
!
ntp clock-period 17179841
ntp server 192.5.41.40
ntp server 172.17.0.11
ntp server 172.17.0.77 prefer
end

thanks

networker050184 · June 2009

It looks like you are matching based on EF and CS5 for your VOICE class. Are you sure the packets are being marked correctly before they make it to the router? I'd sniff the traffic before it gets to the router to make sure.

mattsthe2 · June 2009

Good idea, but im pretty sure they are because last night when i tested it we moved that WIC and circuit over to the 2811 and we are matching the same on that router too and packets were being marked. Switch port config is the same also.

Is it my IOS version?

The only difference between the two routers is that there is dial-peers and vocie class codecs config'd on the 2811 which i am unable to configure on the 1751.

pitviper · June 2009

Changing the class-map match-all VOICE to class-map match-any VOICE should do it.

networker050184 · June 2009

It shouldn't have anything to do with your IOS or the dial peers. Since you are relying on the packets to be marked prior to reaching the router that is most likely where your problem lies.

Your best bet and quickest way to know for sure would still be to sniff the traffic. Just set up a monitor for the LAN port hooked to the router and use wireshark.

EDIT: Good catch pitviper! I totally missed that. That should fix your issue assuming the markings are correct.

mattsthe2 · June 2009

pitviper wrote: »

Changing the class-map match-all VOICE to class-map match-any VOICE should do it.

Can you explain this theory a little please. Thanks for replying I'd love it if it fixed the issue.

Our 2811 its config'd with class-map match-all and that is working fine....

networker050184 · June 2009

Match all would mean the packet would have to be marked with binary 101000 and 101110 in order to match the class. Since a packet can not be marked with both it will never match.

Are you sure its the same config on the 2800?

pitviper · June 2009

mattsthe2 wrote: »

Can you explain this theory a little please. Thanks for replying I'd love it if it fixed the issue.

Our 2811 its config'd with class-map match-all and that is working fine....

Theoretically the voice packets should be coming in as CS5 or EF – Your criteria would only match the VOICE class if the packets were tagged as both.

pitviper · June 2009

networker050184 wrote: »

Match all would mean the packet would have to be marked with binary 101000 and 101110 in order to match the class. Since a packet can not be marked with both it will never match.

Are you sure its the same config on the 2800?

What he said

mattsthe2 · June 2009

networker050184 wrote: »

Match all would mean the packet would have to be marked with binary 101000 and 101110 in order to match the class. Since a packet can not be marked with both it will never match.

Are you sure its the same config on the 2800?

Networker please shoot me.......

The 2800 is NOT the same. Heres the 2800 config.

class-map match-any VOICE-CONTROL
match ip dscp af31
match ip dscp cs3
class-map match-all VIDEO
match ip dscp af41
class-map match-any VOICE
match ip dscp ef
match ip dscp cs5

grrrrrrrrrrrrrrrrrrr......

Ok so i really want to test this now, but i cant because its a production network and failing over to the 1751 cant be done right now.

However im going to try to put ip route on the 2800 (as this is there default gateway) of a single Phone's IP and direct it over to the 1751.

I'll post my results.

pitviper · June 2009

It's easy to mix-up since the default is "match-all".

mattsthe2 · June 2009

Gang not quite....

heres the new config:

class-map match-any VOICE-CONTROL
match ip dscp cs3
match ip dscp af31
class-map match-all VIDEO
match ip dscp af41
class-map match-any VOICE
match ip dscp ef
match ip dscp cs5
!
!
policy-map QoS
class VIDEO
priority 334
class VOICE
priority 768
set dscp ef
class VOICE-CONTROL
bandwidth 50
set dscp af31
class class-default
fair-queue
set dscp default

i created a ip route on the 2800: ip route 172.17.100.57 255.255.255.255 172.17.14.3

100.57 is my phone across the WAN and 14.3 is the 1751.
I confirmed the routing is working by a trace route.

As the 2800 is the first hop and usally exits out of a serial interface do i need a: service-policy output QoS on the LAN interface that the packet arrived on, because of the redirection to the 1751?

pitviper · June 2009

Hmmm, do you see any matches when you do a show policy-map on the outgoing interface on the 1751 (other then class-default)?

mattsthe2 · June 2009

pitviper wrote: »

Hmmm, do you see any matches when you do a show policy-map on the outgoing interface on the 1751 (other then class-default)?

no only the class default increments...

any ideas

ill try to mock up a lab tomorrow, frustrating!

networker050184 · June 2009

Have you tried matching on IP or using NBAR rather than matching on marking? That would let you know if your markings are coming in correct.

mattsthe2 · June 2009

networker050184 wrote: »

Have you tried matching on IP or using NBAR rather than matching on marking? That would let you know if your markings are coming in correct.

Matching by IP does **not** work.
I've double checked the source IP address and im matching that on the ACL and applying it to the class map. Code attached.

[code]

class-map match-any VOICE-CONTROL
match ip dscp cs3
match ip dscp af31
class-map match-all VIDEO
match ip dscp af41
class-map match-any VOICE
match ip dscp ef
match ip dscp cs5
match access-group 101
!
!
policy-map QoS
class VIDEO
priority 334
class VOICE
priority 768
set dscp ef
class VOICE-CONTROL
bandwidth 50
set dscp af31
class class-default
fair-queue
set dscp default

Extended IP access list 101
10 permit ip any host 172.17.14.23
20 permit ip host 172.17.14.23 any
30 permit ip any host 172.17.14.59
40 permit ip host 172.17.14.59 any

from the source device i even did a trace route and can see the first hop as the 2800 and the second hop as the 1751.

The default class keep on incrementing.

Any other suggestions guys?

networker050184 · June 2009

I'd place an ACL inbound on the 1700 (on the interface connecting to the 2800). Permit your IPs and watch for hits on the ACL to make sure the traffic is actually coming in the way you think it is. Kind of like a low end IP accounting.

If you are not getting any hits when matching by IP address, they are either not coming in or are coming in with a different IP address. I'd also remove the policy and reapply after any changes if you are not doing that already.

If you want to make sure its not a bug and that the class will actually match you can just do a permit ip any any so you can see hits in your policy map.

mattsthe2 · June 2009

networker050184 wrote: »

I'd place an ACL inbound on the 1700 (on the interface connecting to the 2800). Permit your IPs and watch for hits on the ACL to make sure the traffic is actually coming in the way you think it is. Kind of like a low end IP accounting.

If you are not getting any hits when matching by IP address, they are either not coming in or are coming in with a different IP address. I'd also remove the policy and reapply after any changes if you are not doing that already.

If you want to make sure its not a bug and that the class will actually match you can just do a permit ip any any so you can see hits in your policy map.

Thanks for your response, let me give that a whirl this afternoon. How frustrating is this.

In my Lab setup though matching by the ACL actually works, just not in the production setup. I'm wondering if its just a bad 1700.

I'll get back with you.

mattsthe2 · June 2009

i downgraded to 12.3 and its working now (well at least by ACL)

APA · June 2009

if you have a service contract.... let TAC know about the bug, assuming that it is definitely a bug and not a config error

I've checked the Cisco Bug Toolkit for 12.4(25) and there are no known\lodged marking\QoS bugs for the 1700 series... yet anyway...

pitviper · June 2009

mattsthe2 wrote: »

i downgraded to 12.3 and its working now (well at least by ACL)

Glad to hear that it's working - that's a head scratcher though!

Cisco 1751 not tagging hmmm

Comments