3750 interface - how to disable

[cammaher]

Hi,

I am hoping someone here might be able to offer some advice on hot to achieve a security measure we are trying to implement.

Our objective is to be able to administratively disable an interface on our 3750 switches after a period of inactivity. The aim is to have ports enabled, but if there has been no activity on them for 30 days to then place them in 'shutdown'. We want this to be done automatically, not manually!

Does anyone know of any inbuilt Cisco commands/software that could achive this.

Thanks,
Cameron

[Somasundaram Jayaraman]

Hi

I guess by using port-security features we can achieve this requirement

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_40_se/configuration/guide/swtrafc.html

Cheers

Somu

[cammaher]

Hi,

Thanks for the quick reply. We have looked at the port security commands but can't find anything that allows a port to be shutdown based on a time limit of inactivity. There are a bunch of other ways a port can be shutdown, but not the one we want - I'd be more than happy if you showed me we are wrong!!

Thanks,

Cam

[smogra]

I guess we dont have any such command which shuts down the unused interface automatically after a period of inactivity. We have many other commands where you can timeout the mac-addresses or the user sessions etc, but not these kind of command exist as far as I know.

--Sweta

[Leo Laohoo]

Our objective is to be able to administratively disable an interface on our 3750 switches after a period of inactivity. The aim is to have ports enabled, but if there has been no activity on them for 30 days to then place them in 'shutdown'. We want this to be done automatically, not manually!

In my humble opinion, this does not make sense.  I know where you are coming from and this is due to security issues.  Let me explain:

Ok, let's presume you have a TCL script to shut down the port automatically.  Next question I am going to throw at you is HOW are you going to enable the port?  What happens if someone wants to use the port, plugs the laptop and don't see any link light?  This is the reason why this is not easy to achieve using automation.

In our case, it was far easier to generate a report (via SNMP) and tell us which ports haven't been used.  Next we manually disable the ports.  We also put descriptions in our interfaces on which ports go to which data outlets.  It's a  tedeous job in the beginning but it got better as we move along.   And finally, unless you wield a whip, some people will just go "bah, humbug" and won't do it.

HOWEVER, I've always used manual intervention is this case.  We check how long an interface has been down, compare the uptime and manually shut down the port. 

[cammaher]

Hi,

Thanks for the information - and I agree that what we are trying to do is not 'normal'. But in the industry that I work in there are a lot of security measures that don't make sense to me, but are forced upon us, if that makes sense.

In answer to your question about HOW the ports will be enabled, this will be done at our helpdesk, as the helpdesk staff has a limited access to our network infrastructre using the AAA model. I do udnerstand that this will generate work (as users may go on holiday, leave, etc then come back to work, plug in their laptop and no link). When we look at the security policies that we have to adhere to and a bunch of other factors, having this ability would provide us with the least amount of effort. I know it sounds strange, but believe me, it's true! So the re-enabling of the ports will be a manual process, we have no problems with that.

Rregarding the idea behind generating reports and doing it all manually - we have been doing something similar to that for a while now and are finding that it just doesn't work. As soon as you place a human in a process, errors will occur - just a fact! If you can automate as much as possible you eliminate errors!

Thanks again,
Cameron

[Leo Laohoo]

TCL scripting will work.

Another method is to use 802.1x.  It won't disable the port but will put un-identified users an a quarantine VLAN.

[Jon Marshall]

Cameron

If you already use AAA and yoir security concerns are that great then i think Leo's suggestion of using 802.1x is a very good one. Microsoft has a built in 802.1x supplicant that you could use.

The problem with the TCL script Ricky has linked to is when you actually run it. For example lets says you run it every evening to check the status of the ports. What the script actually does is a "sh ip interface brief" and then check the status of the interface. If it is up or adminstratively down it ignores it but if it down it records it in a file. If a certain number of days pass, in your case 30 and the interface is still there then it will automatically shut it down.

But that's the problem really. What if you have a user who works with their laptop who connects in the morning and then at 5:00 disconnects and takes the laptop home. The TCL script has no way of knowing that the interface was up during the day, it simply sees it as down.  You could run it during the day but then again hotdesking etc. means ports are often up and down during the day so you are relying more on chance than anything.

So if you do use the TCL script it's important to know when to run it and how often to make sure that you don't start accidentally shutting interfaces down that are actually used.

To be honest though, if you work in an industry that requires a lot of security you probably should be looking at 802.1x.

Jon

[cammaher]

Hi Jon,

Thanks again for providing some very valuable information.

We have discussed the use of 802.1x and it would provides a perfect solution for us - the one problem we have run into is the wide variety of devices that are present on the network (PC's, MAC'S, every variant of Linux, Sunray's, Thin terminals (Wyse, HP, etc), the list goes on). We cannot dictate what devices a client wants to use - lack of goverance! Because of this the use of 802.1x was deemed not be an effective one.

Thanks for highlighting the issue with teh TCL script. I hadn't thought of the scenairos you propsed in your post.

Again, thanks for all the replies and suggestions everyone - it is great to get so many ideas and support from other Network Engineers.

Cheers,

Cameron

[Leo Laohoo]

802.1X is widely accepted in government agencies where security is the main concern.

We are currently using 802.1X for our wired and wireless networks.  Windows and Apple are our predomant OS and 802.1X works.  I'm not sure about the other OS though.

Just my opinion.

[cammaher]

Hi,

I think we must work in a similar agenecy - security takes precedence over common sense sometimes!

We did look at (and even test) the use of 802.1x in our environment, but as I mentioned, the fact that we have such a a variety of difference devices connecting meant that it would not suit our needs.

Thanks,
Cameron

[Richard Michael]

Hello Cameron,

The below link might interest you,

https://supportforums.cisco.com/thread/176341;jsessionid=5F85D66726D26AC1BA8F5605666B7F60.node0

TCL script would definetly do the job. configuring TCL scripts has it own caveats, its upto you to make the decision

Thanks,

Ricky Micky

Pls rate if this is useful

[cammaher]

Hi Richard,

Thanks very much for the link and information. I was unaware of the EEM functionality of Cisco devices and it does open up a whole bunch of new possibilities - very, very helpfull post.

Thanks again,

Cameron