If you’re running an LNS terminating PPP sessions on Cisco, here’s a quick tip for forcing a reconnect of an end user session.
First find the session that you’re after and wanting to clear
lns-1#show vpdn session | i 09033847111
30532 29804 31238 09033847111@dsl.tld, Vi2.6 est 1w5d 510
lns-1#Take the Interface name from the session and run the below to clear it. This will force the session to re-establish.
lns-1#clear interface Virtual-Access2.6Came across this one today as an ASA that I look after started reporting ‘Resource ‘conns’ limit of 10000 reached for system’. Turns out this is a TCP session limit that’s being hit and at least in my case was a TCP SYN Flood attack. By running the following you can find out how many open sessions there currently are on the ASA:
ciscoasa# show conn count 1941 in use, 3739 most used
The above is a pretty sane amount but the maximum is 10000 so to incorporate some ‘basic’ TCP syn flood protection you can restrict the maximum amount of half-open TCP connections as follows:
class-map SYN_Prevention match any ! policy-map global_policy class SYN_Prevention set connection embryonic-conn-max 1000 per-client-embryonic-max 30
The above basically configures your ASA to permit a maximum of 1000 ‘half-open’ tcp sessions at a time globally and a per client maximum of 30 (per end user ip address).
Hope this helps:)
Jay
A quick tip on cisco logging. If you’re running Cisco IOS and are wondering why the ‘show log’ is showing the number of days and weeks since the last reload rather than showing dates and times then there’s a small configuration change you need to make:
router(config)# service timestamps log datetime show-timezone
This sets IOS to display the timestamps in the log based on the datetime known to IOS. You will obviously also need to ensure that IOS knows the date, time and timezone as per the below example:
router(config)# clock timezone GMT 0 router(config)# clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 2:00 router(config)# ntp server 64.236.96.53
You will then see output like the below when running ‘show log’:
.Sep 20 14:01:15 UTC: %SYS-5-CONFIG_I: Configured from console by user on vty1
Jay Greig
Following on from my previous post I found that in some instances it was either not practical or not possible down to the feature set of the IOS being run to successfully terminate xconnects on subinterfaces and have them actually pass traffic despite coming up.
Another workaround if you do want to achieve an alternative to terminating an xconnect on an SVI is to use portchannels (etherchannel). By terminating an xconnect on a port channel you can then place up to 8 ports into a channel group for example:
#interface Port-channel100 #no ip address #xconnect 92.60.104.41 1003 encapsulation mpls #! #interface GigabitEthernet3/3 #description XC: Backup servers #no ip address #channel-group 100 mode on #!
Ensuring that your ports are ‘no shut’ then you should find that running the following will show the link as up and you should be passing traffic:
#do sh mpls l2t vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------- --------------- ---------- ----------
Gi3/2 Ethernet 92.60.104.34 1002 UP
Gi3/1 Ethernet 92.60.104.37 1001 UP
Po100 Ethernet 92.60.104.41 1003 UP
Now time to call it a day:)
James Greig
Ever gone to try and terminate a cisco L2TPv3 xconnect on an SVI on Cisco 6500 and wondered why the hell it wouldn’t come up? You run the following:
switch# sh mpl l2transport vc
and find that the output is always down no matter what. Well, cleverly Cisco decided you’re not allowed to do that. A useful technology introduced to improve things actually ends up making things a little more difficult. It *is* possible if you have a SIP line card (ES20) for example, but if you’re reading this it’s doubtful you have one of these.
There is a possible workaround to achieve what you’re probably after. Although you cannot terminate the xconnect on an SVI you can, however, terminate the xconnect on a sub interface and in turn sub interface’s can be placed into a vlan. It’s not an ideal work around and in some cases it’s probably not very practical – nonetheless it is a sometimes feasible workaround if required. All that you should need to do is create a sub interface on the upstream facing link with the xconnect configuration and place the sub interface into a dot1q vlan – et voila
Hope this helps people:)
Also see the follow up article for another workaround: Xconnects on SVIs Part 2
James Greig