Wednesday 5 March 2014

Finding empty ports on a Cisco switch

Now I've started working for a new agency that has cisco switches that we look after internally and with most media agencies, there always seems to be desk moves etc. With this in mind it is always important to find free ports on the switches before a move.

Now 95% of our users have laptops so you cannot rely on the port not being active today as the user could be working away from their desk and plug back in using their ethernet cable when they are back.

A very easy way of finding free ports and when they were last used is to login to the cisco switch and run the following command:

Sh int | inc Gig|Last input

This will list all ports on the switch and show their status (connected or not connected) along with the last time data was passed through. As you can see below Port 23 is very much still in use and Port 24 is disconnected and was last used 11 weeks and 5 days ago, so I would say it is safe to re-use this port. Now remember to always check the config of the port before you re-assign the port as it's config could be important and required in the future for some random legacy system etc.

GigabitEthernet2/0/23 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 5835.d981.9a97 (bia 5835.d981.9a97)
Last input 00:00:04, output 00:00:09, output hang never

GigabitEthernet2/0/24 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is 5835.d981.9a98 (bia 5835.d981.9a98)
Last input 11w5d, output 11w5d, output hang never

Now you've saved time by not having to crawl under desks and find unpatched ports and free up ports, you can pop down the pub and have a few well earnt pints!

Wednesday 22 January 2014

Syslogging a Cisco switch

Now when it comes to looking after a large IT estate, it can be a pain to keep track of all those errors and warnings in logs. Most people put alerting in place for their servers and firewalls which is great, however you can never forget those poor switches that carry all that data around your network. If one of those fails then it is back to using carrier pigeons for you!
To configure a cisco switch to send out syslogs to a server you need to first of all enter config mode
tekctrl-3570-01#conf t

Then you need to set the switch to timestamp the logs, otherwise it won't make any sense in your syslog server
tekctrl-3570-01(config)#service timestamps log datetime

You need to then inform the cisco switch where to send the logs to
tekctrl-3570-01(config)#logging x.x.x.x

You then need to configure the level of events the cisco switch will send over. 7 is the most active (debug) and will send EVERYTHING across. I have set this one to 4 (warning) so that any emergencies, alerts, critical errors and warnings are sent over but notification information such as someone plugging a cable into a port is not sent over (because come 17:30 your syslog server will be filled with damn near every good user powering down and disconnecting from the switches!)
tekctrl-3570-01(config)#logging trap 4

The next line will also set the local level of logging for the cisco switch. local7 is the default so we might as well stick with it
tekctrl-3570-01(config)#logging facility local7

Now exit the config mode
tekctrl-3570-01(config)#end

And for f*ck sake save the running config or you'll be kicking yourself (and I'll be kicking you too!) when the switch reloads and all this heavenly syslog glory is lost..
tekctrl-3570-01#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]

Now confirm the logs are appearing in your syslog server and f*ck off to the pub and let the syslog server deal with all the whining and moaning your Cisco kit is producing