[cisco-bba] SNMP is administratively shutting down the Virtual-Access on the LNS

[Andy Saykao]

Thanks guys, found the culprit.
 
There is a script which will issue snmp disconnection requests to
reshape customers if it doesn't know that the router can handle CoA
requests. We maintain a list of LNS that can handle CoA but the LNS with
the issue wasn't on that list. Have added that LNS to the list so it
should be using CoA now instead of snmp.
 
Thanks.
 
Andy

________________________________

From: Andy Saykao 
Sent: Thursday, 26 August 2010 8:43 AM
To: 'cisco-bba at puck.nether.net'
Subject: SNMP is administratively shutting down the Virtual-Access on
the LNS


Hi All,
 
Just wondering if anyone has come across a situation where snmp is
administratively shutting down the Virtual-Access on the LNS. What snmp
command would be issued to the LNS to cause this?
 
Aug 26 00:08:43.687 AEST: %SYS-5-CONFIG_I: Configured from 210.15.210.x
by snmp
Aug 26 00:08:43.783 AEST: %LINK-5-CHANGED: Interface Virtual-Access3,
changed state to administratively down
Aug 26 00:08:44.784 AEST: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Virtual-Access3, changed state to down
 
We do have a script that runs from 210.15.210.x that clears any "ghost"
sessions but it only telnets to the LNS and invokes any commands via
telnet, so a little bit stump as to why we're seeing the Virtual-Access
shut via snmp.
 
When the Virtual-Access goes administratively goes down, users can no
longer establish a session on the LNS and the only way to restore the
Virtual-Access is to reboot the LNS.
 
The LNS is a Cisco 7201 running 12.4(12.2r)T. It's happened twice this
month already.
 
Thanks.

Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-bba/attachments/20100826/b64db5f0/attachment.html>