cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1654
Views
0
Helpful
5
Replies

Ezyvpn & QoS - Policy Map not getting applied to Virtual Access Interface

dmcloon
Level 1
Level 1
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 ? 

5 Replies 5

Reuben Farrelly
Level 3
Level 3

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

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

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..

Reuben Farrelly
Level 3
Level 3

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