Stuck Virtual-access interface with EZVPN DVTI config

Unanswered Question
Aug 14th, 2007

Greetings,

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 10.99.37.80

Routing entry for 10.99.37.80/28

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 10.99.37.80/28, clearing crypto sessions, and clearing the virtual-access itself don't work..Any ideas?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
amritpatek Tue, 08/21/2007 - 05:58

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.

Actions

This Discussion