05-01-2013 11:44 PM
On a Cisco 867VAE router IOS 15.1(4)M6 I am using ATM0/ADSL as the WAN interface. The EzyVPN client is configured on Dialer0 (outside) and VLAN1 (inside). The service policy is configured on Virtual-Template 1 interface. When the ipsec tunnel comes up the Virtual-Access 1 interface is getting cloned from Virtual-Template1, as expected. The tunnel passes traffic both directions fine, however the problem is the policy is not getting applied to the virtual-access interface. I opened a TAC SR but the engineers have no explanation so I am throwing it out there in the odd chance someone knows why. As far as I can tell from the DVTI QoS docs what I am doing is supported. policy-map shaper class class-default shape average 704000 service-policy voip ! policy-map voip class voice bandwidth 200 class internetwork-control priority percent 5 class class-default ! crypto ipsec client ezvpn CISCOCP_EZVPN_CLIENT_1 connect auto group xxxxxxxxxxxx key xxxxxxxxxxxxxxxxx mode network-extension peer xxx.xxx.129.138 virtual-interface 1 username xxxxxxxxxxxxx password xxxxxxxxxxx xauth userid mode local ! interface Dialer0 description $FW_OUTSIDE$ ip address negotiated no ip redirects no ip unreachables no ip proxy-arp ip mtu 1452 ip nbar protocol-discovery ip flow ingress ip flow egress ip nat outside ip virtual-reassembly in zone-member security out-zone encapsulation ppp dialer pool 1 dialer-group 1 ppp authentication chap pap callin ppp chap hostname xxxxxxxxxxx ppp chap password xxxxxxxxxxx ppp pap sent-username xxxxxxxxxxp password 7 xxxxxxxxxxxxxxxx crypto ipsec client ezvpn CISCOCP_EZVPN_CLIENT_1 end ! interface Virtual-Template1 type tunnel no ip address no ip redirects no ip unreachables no ip proxy-arp ip flow ingress zone-member security ezvpn-zone tunnel mode ipsec ipv4 service-policy output shaper end r1#sh crypto session detail Crypto session current status Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, T - cTCP encapsulation X - IKE Extended Authentication, F - IKE Fragmentation Interface: Virtual-Access1 Uptime: 00:49:58 Session status: UP-ACTIVE Peer: xxx.xxx.129.138 port 500 fvrf: (none) ivrf: (none) Phase1_id: xxx.xxx.129.138 Desc: (none) IKEv1 SA: local xxx.xxx.113.246/500 remote xxx.xxx.129.138/500 Active Capabilities:CDX connid:1022 lifetime:23:09:16 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 Active SAs: 2, origin: crypto map Inbound: #pkts dec'ed 113 drop 0 life (KB/Sec) 4450184/591 Outbound: #pkts enc'ed 6 drop 0 life (KB/Sec) 4450198/591 r1#sh int virtual-access 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of Dialer0 (xxx.xxx.113.246) MTU 17940 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL CDMA vaccess, cloned from Virtual-Template1 Vaccess status 0x44, loopback not set Keepalive not set Tunnel source xxx.xxx.113.246 (Dialer0), destination xxx.xxx.129.138 Tunnel Subblocks: src-track: Virtual-Access1 source tracking subblock associated with Dialer0 Set of tunnels with source Dialer0, 1 member (includes iterators), on interface Tunnel protocol/transport IPSEC/IP Tunnel TTL 255 Tunnel transport MTU 1452 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 849531 packets input, 189761356 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 976452 packets output, 590723320 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out When I show policy-map interface there is no instance for Virtual-Access 1. r1#sh policy-map interface Virtual-Template1 Service-policy output: shaper Service policy content is displayed for cloned interfaces only such as vaccess and sessions r1# A similar config on another 867VAE works, the difference is the working router is using 'wan mode ethernet' rather than 'wan mode dsl' so the EzyVPN client outside interface is Gigabitethernet1 not Dialer0. I am wondering if this is a QoS on DVTI bug specific to Ezvpn on a Dialer interface ?
01-20-2014 08:04 PM
Hi,
Just wondering if you ever got a workaround, or bug DDTS number for this? I'm seeing the same thing - applying even a basic QoS policy to a Dialer in the outbound direction just fails to apply, with no error. This is with 15.2M and 15.3M also (and it's not fixed in 15.4(1)T either...)
Reuben
01-21-2014 03:57 AM
Hi Reuben,
An enhancement bug was filed, CSCuh05155. Not sure what Cisco did though, they were requested to also update the doco.
We ended up not being able to do QoS on the Dialer ,no time to wait for any enh, so we used the Ethernet wan interface instead with an external DSL modem in bridge mode. QoS was then done on the Ethernet wan int.
Cheers
Dallas
01-21-2014 04:16 AM
Check this new feature in 15.3T.
http://www.cisco.com/en/US/docs/ios-xml/ios/qos_conavd/configuration/15-mt/qos-conavd-dial.html
01-21-2014 04:23 AM
Yes - it works on other platforms, just not on the 867VAE (I have the same shaping config on my 1941 doing PPPoATM on a Dialer as well, and it's fine, but the same config doesn't apply on the 867VAE). Tested with 15.2M/15.3M/15.4T.
Thanks for the bug ID Dallas, I'll open a TAC case also and see what I can get TAC to say and do. It looks definitely like a bug to me too..
04-15-2014 08:17 PM
Hi Dallas
I have a TAC case open on the issue of the policy not applying to a Dialer over ATM - SR 629050379. TAC have reproduced the problem and believe it is a platform specific issue to the 867VAE. The details of this case match your notes except that this is reproducible without a VTI.
If you're interested in following it, open another case up referencing my case, the more people who log cases referring to it the greater the likelihood it will be fixed, since TAC will then see that this impacts multiple customers.
Thanks,
Reuben
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide