Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Stuck Virtual-access interface with EZVPN DVTI config


I have a "persistent" virtual-access interface that is associated wrongfully with a /28 network that already has a virtual-access interface associated with it. What's more, it seems that the buggy virtual-access is a member of the vtemplate recycle queue, so it gets used and has configuration added which messes up routing, since the /28 at that point has 2 virtual-access interfaces with 2 tunnel destinations:

atm-host-router#sh ip route

Routing entry for

Known via "static", distance 1, metric 0

Redistributing via eigrp 100

Advertised by eigrp 100 metric 1024 10 255 10 1500 route-map routes-ou

Routing Descriptor Blocks:

* directly connected, via Virtual-Access12 <---CORRECT ONE

Route metric is 0, traffic share count is 1

Route tag 2886781519

directly connected, via Virtual-Access80 <-- WRONG, MEMBER OF RECYCLE QUEUE

Route metric is 0, traffic share count is 1

Clearing ip route for, clearing crypto sessions, and clearing the virtual-access itself don't work..Any ideas?


Re: Stuck Virtual-access interface with EZVPN DVTI config

An L2TP network server (LNS) that is configured for Path MTU Discovery (PMTUD) and that has discovered a lower IP MTU for a virtual-access interface does not return to the original IP MTU after the 10-minute PMTUD timer expires. You can see the IP MTU in the output of the show ip interface virtual-access command. This symptom is observed on a Cisco router that functions as an LNS and that is configured for PMTUD. Change the IP MTU can be changed on the affected virtual-access interface by entering the ip mtu command. The IP MTU affects only IP traffic. When the IP MTU is not increased to the original IP MTU on the virtual-access interface, IP traffic is fragmented, irrespective of whether or not this is necessary, and IP traffic that has the DF-bit is dropped at the LNS.