Well I have been playing with this and was going to write up a post until I came across this
How Fantastic 6500 VSS configuration and Best Practice
This Guys has a awesome Blog, really good at putting thoughts on paper (screen) and explaining things. Really suggest you head over there for a look.
I came across this in secureCRT and thought I would share it.
When labing things up (and indeed on real networks), there are times when you need to send the same command to multiple devices. you can of course copy and paste between the sessions but what about if you want to past the exact same block of configuration to 20 devices, or just want to do something simple like save the running configuration on your devices in you lab before you close down?
Well SecureCRT has a nice little feature to do this, so before enabled secure CRT looks much like below, as you can see I have several tabs open.
Default SecureCRT Window
However by going in to the view menu up the top there is a option to enable the “chat window”, this will bring up an extra panel at the bottom of the screen. Then by right clicking in this new panel you can enable the “send chat to all tabs” option as shown below.
Chat window enabled
Now any command typed in the chat window will be sent to all devices. Commands typed in the main terminal are still only sent to a single device.
What would be even nicer is if you could highlight multiple tabs and have the commands only sent to those terminal sessions. At the moment it is an all or nothing solution, maybe I will go suggest it to them as an improvement for future versions 🙂
The more I use CRT the more I like it, written quite a few scripts for it now, if you know any VB script or Java you can pretty much do what ever you like as SecureCRT has a nice simple API in to it.
I am finally moving house this week, so after that should have more time to post on here, and will take some of the script I have and tidy them up and post them for people.
Take care
DevilWAH
OK time to get on with it. And seeing as I have just been brushing up on switch security what better place to start.
Not going to tell you how to configure DHCP snooping or show you my lab set up, there are plenty of great documents on the net you can find for that, www.cisco.com/dhcp-cconfig for instance. But I suposes theres no harm in a quick recap about what DHCP snooping is and why it is used.
Really the hint is in the name, when enabled on a Switch, any DHCP packets, (both requests and replies) the switch listens in on and can filter and in some cases altered. The main function is of course to prevent rogue DHCP servers from being placed on the network, so in its most basic set up, you simple enable it on a switch and mark all ports on the uplink path to the DHCP server as trusted, this will allow DHCP responce packets to be sent down this path. Easy hey!? You can add in limiters to how many request packets a untrusted port can send to the DHCP server to prevent DoS attacks on the DHCP servers, and there are other options of course (always is in IT), but prevention of DoS attacks and prevention of Rogue DHCP servers are the two biggie’s.
What DHCP snooping also does of course as it reads the DHCP packets passing through its ports, is to build up a data base of what IP address and MAC address have been assigned by DHCP to which Switch port. This can then be used for IP source guard, this works by assigning an ACL on a per port basics that restricts the source IP address in packets, to the IP stored in the DHCP snooping database. And for Dynamic ARP inspection, where the ARP packets are filtered by the switch to insure the information contained in them matches the information gained from DHCP snooping.
So by combining DHCP snooping with IP source guard, Dynamic ARP inspection and port-security, you can mitigate many of the Layer 2 switch based attacks.
The one thing that really interested me when I was going through DHCP snooping was the setting to enable option 82. It was kind of mentioned in passing in the CCNP course material, so I had a little look up about what it was. Well this seemed simple enough, when the switch recives an incoming DHCP request packet from the switch it adds in some information. namely the switch port the client is connected on , the vlan it is assigned to and the id of the switch adding the information. This Document sums it up nicely. And then you read that this information can be used by the DHCP server for how it assigns address, and can be stored by the DHCP agent. I thought hey… cool.. So I enable this option, turn on support on the windows 2003 DHCP servers, and BING!! I would have a list of DNS name, IP address, MAC address, and switch and port location.. But sadly it seems windows 2003 does not support this option.. poor form if you ask me.
It got me thinking though, ways to trace a client device to a physical location. Not just what area of a building by down to the switch port it is connected to. This can be very useful for tracing PC’s with problems on the network, or trace back were strange traffic is coming from, and the quicker you can do it the better.
There the manual way of course, use the CAM tables and show commands to trace a MAC address back to its switch port. You first of course have to resolve the DNS name back to the MAC. Then at the other end you could enable 802.1x port-based authentication, and run a CISCO ACS server to do the authentication. Run a report on the ACS server and it will give you all the information you need.
My personal solution was to use Kiwi cat tools to run an audit on all the switch devices and build up a database of MAC address to switch ports. I already have a data base of DNS names – MAC address from our auditing software and it was a 5 minute job to set up the link between them.
So from looking at DHCP Snooping, to ways to monitor the network. All in a days studying :). Now one more run though of the config for this on my lab and then its on to practising MSTP’s.
Well there you have it, first real post, now to see what the general public think.
Take care all.