The real problem is that those customers will call in and complain that they cant connect to Internet. We have to clear those virtual interfaces up by command clear interface virtual-access # all the time. Now we are creating a script doing this. But it wont resolve the actual problem.
Seem to me, this magnitude of the problem relates the configuration command virtual-template 1 pre-clone xxx; the larger the # xxx is, the severer the problem is. When I drop the number down to 50, fewer customers complain. But the routers CPU utilization starts getting higher than normal (one of routers CPU actually reached 91% when over 2000 customers terminated on that router).
I also noticed that the most of those customers with such problem configure their home ADSL modems with so-called nailed-in connection instead of automatically timeout after a certain idle time. Personally I like this option since it seems to refresh the PPP sessions but would not destroy the VPDN tunnels; unfortunately, most of those customers dont like this idea.
Could anyone here explains on this issue in details or help me find some information (such as white papers, URLs. I am very interested in the theory behind this)? The most important thing question is: how could I fix this from my site?
the problem is that the "dead" l2tp virtual access interfaces don't get closed as they should. i duplicated the problem by turning off adsl modem (test account); according the cisco reading materials, the cooresponding virtual access interface should be closed too. No, it was not. it was there for very long time even the remote adsl modem was shut down; because of this, the test account could not be used it until i cleared the virtual access interface.
here is the config:
local name isp
l2tp tunnel timeout no-session 10
ip unnumbered Loopback1
ip tcp adjust-mss 1452
no logging event link-status
peer default ip address pool sun-adsl
ppp mtu adaptive
ppp lcp predictive
ppp authentication chap pap
ppp ipcp predictive
ppp timeout idle 600
i seriously suspect that there are some kind of bugs for this problem
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...