service-policy doesn't recognise marked packets on Dialer interface
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-02-2014 10:55 AM - edited 03-04-2019 10:14 PM
Hi,
i am using a service-policy on the Dialer interface for my DSL WAN connection to seperate traffic classes in upstream direction:
class-map match-all cos-map-dscp-ipsec-1
match dscp af31
!
class-map match-all cos-map-dscp-clients-1
match dscp af21
!
class-map match-all cos-map-dscp-nm-1
match dscp cs6
!
policy-map cos-po1-di-4-out
class cos-map-dscp-ipsec-1
bandwidth 487
queue-limit 80 packets
set dscp af31
class cos-map-dscp-clients-1
bandwidth 487
queue-limit 80 packets
set dscp af21
class cos-map-dscp-nm-1
bandwidth 65
queue-limit 20 packets
set dscp cs6
class class-default
bandwidth 128
queue-limit 25 packets
!
interface Dialer4
description *** Dialer to the internet ***
bandwidth 1167
vrf forwarding INTERNET
ip ddns update he.net
ip address negotiated
no ip unreachables
ip mtu 1492
ip nat outside
ip virtual-reassembly in
ip verify unicast source reachable-via rx allow-default allow-self-ping
zone-member security INTERNET
encapsulation ppp
load-interval 30
dialer pool 4
dialer idle-timeout 86400
dialer-group 1
ppp authentication chap callin
ppp chap hostname <USER>
ppp chap password <PASSWORD>
ppp pap refuse
max-reserved-bandwidth 100
service-policy output cos-po1-di-4-out
end
When I verify the policy with "show policy-map interface" command, everything seems fine on the Dialer interface:
Dialer4
Service-policy output: cos-po1-di-4-out
Class-map: cos-map-dscp-ipsec-1 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp af31 (26)
Queueing
queue limit 80 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 487 kbps
QoS Set
dscp af31
Packets marked 0
Class-map: cos-map-dscp-clients-1 (match-all)
48080 packets, 3582796 bytes
30 second offered rate 2000 bps, drop rate 0 bps
Match: dscp af21 (18)
Queueing
queue limit 80 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 487 kbps
QoS Set
dscp af21
Packets marked 48080
Class-map: cos-map-dscp-nm-1 (match-all)
23 packets, 5990 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp cs6 (48)
Queueing
queue limit 20 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 65 kbps
QoS Set
dscp cs6
Packets marked 23
Class-map: class-default (match-any)
211 packets, 36212 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 25 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 128 kbps
But on the Virtual-Access-Interface it seems that all marking of "client"/"ipsec"(not used since the reload of the router) packets is lost and everything is forwarded in the class-default:
Virtual-Access2
Service-policy output: cos-po1-di-4-out
Class-map: cos-map-dscp-ipsec-1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp af31 (26)
Queueing
queue limit 80 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 487 kbps
QoS Set
dscp af31
Packets marked 0
Class-map: cos-map-dscp-clients-1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp af21 (18)
Queueing
queue limit 80 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 487 kbps
QoS Set
dscp af21
Packets marked 0
Class-map: cos-map-dscp-nm-1 (match-all)
47 packets, 3426 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp cs6 (48)
Queueing
queue limit 20 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 65 kbps
QoS Set
dscp cs6
Packets marked 47
Class-map: class-default (match-any)
816 packets, 21357 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 25 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 128 kbps
Even using the additional "set dscp" statement in the policy terms doesn't change this behavior.
Any ideas how to fix that issue?
It's a 1841 router with the newest available IOS:
Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 15.1(4)M7, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Sun 15-Sep-13 23:44 by prod_rel_team
ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)
<HOSTNAME> uptime is 2 hours, 5 minutes
System returned to ROM by reload at 17:44:18 MET Sun Feb 2 2014
System restarted at 17:46:46 MET Sun Feb 2 2014
System image file is "flash:c1841-adventerprisek9-mz.151-4.M7.bin"
Last reload type: Normal Reload
...
Cisco 1841 (revision 7.0) with 221184K/40960K bytes of memory.
Processor board ID FCZ112810YA
2 FastEthernet interfaces
2 ISDN Basic Rate interfaces
2 Virtual Private Network (VPN) Modules
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
62720K bytes of ATA CompactFlash (Read/Write)
- Labels:
-
Other Routing

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-02-2014 11:45 AM
Try placing "qos pre-classify" under the virtual-template. I can lab this up if that doesn't resolve the issue.
HTH,
John
*** Please rate all useful posts ***
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-02-2014 12:26 PM
Thank you for your reply.
Can you help me on how to bind a virtual-template to the dialer interface?
I tried some variantions, but "qos pre-classify" isn't applied to the virtual-access configuration.
Thanks you in advance!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-02-2014 03:21 PM
Can you post your config?
HTH,
John
*** Please rate all useful posts ***
