Setting up Lock and Key

I remember searching around for ages looking for this solution a few years back, so I thought I would share it with you. Bear in mind that there are much more secure solutions around, such as 802.1x port based authentication. However these require a lot more setting up, not to mention the kit to support it. For what it is “Lock and Key” is one of these ideas that does exactly what it says on the tin..

So what exactly is it that “Lock and key” does any way. The idea behind it is to allow you to on demand open up access between subnet / networks. May be it is clearer if we look at the following digram.

Figure 1

In Figure 1 we have the IT PC’s, the users PC’s, the servers and the DRAC cards all on separate networks. If you have not come across DRAC cards before, they are an additional card that can be fitted to Dell servers, that have there own redundant NIC, if the server should crash, you can connect to the DRAC card and force a hard reboot among other things. Very useful for remote management of server! However as you can image not some thing you want to allow users near!!

So looking at the digram above you may place an access list on the incoming traffic from the user network (192.168.20.0) to block any access to the DRAC network. While leaving the IT admin PC’s able to reach them. But what happens if you are at a users PC, the server has crashed and you need to reboot it? This is where the “Lock and Key” idea come in.

By using a dynamic Access list along with the user name auto command. you can on the fly open up the blocking access list you have created to allow the PC you are working on have access to the Drac network.

First we need to set up the a dynamic IP access list under global config, remember this access list has to be applied to the interface connection to the user PC’s, we will be applying it in the “in” direction.

ip access-list extended Lock-key
dynamic Dracacess timeout 60 permit ip any 172.64.20.0.0 0.0.0.255 log
deny  ip any 172.64.20.0 0.0.0.255
deny ip any 172.16.10.0 0.0.0.255
permit ip any any

So before “lock and Key” is active users are prevented from accessing the IT unit PC’s and the Drac network, but have access to every thing else.

Next we set up the user we are going to use as the “Key”

username Dracs secret CISCO
username Dracs autocommand access-enable host timeout 15

So here we set up the user Drac and add the auto command to run when they log in. The 15 minute time out here is the idle time out. However as we have set an absolute time out above in the access list its self, this will log out the user after 60 minutes if they are active or not.

Lastly we need to go in to the interface that faces the users network and assing the Access list, and set the VTY line for telnet access and to use the local user database. so from global config again.

interface <ID>
ip access-group Lock-key in

exit

vty 0 15

transport input telnet

login local

exit

Now to use it is simple, from a users PC start a telnet session with the router, at the user name and password prompt users the user name of Drac and password configured. The connection will be droped by the user but you an extra line will be added to the access list along the lines of.

permit ip host xxx.xxx.xxx.xxx 172.64.20.0.0 0.0.0.255 log

Any you user PC now has access as long as it is sending data or until the limit of 60 minutes.

Of course you may not like using telnet and it is possible to use SSH (but then the user PC needs a ssh client installed), you can also change the port that the router listens for telnet or SSH on a VTY line. You can also apply the auto command to the VTY line so any one who logs on through that VTY line will trigger the lock and key. If you do this then you will need to set up some VTY lines to use one port with the autocommand config, and some other VTY lines to use a different port with out the autocommand. Other wise you will not be able to mange the router!!!

This Link covers some more examples.

As I said at the beginning there are much better ways to do this, 802.1x as i mentioned is just one of them and some thing I will cover in more detail soon.  But for a small/medium size networks, where cost is an issue, but you still want to add an extra bit of security. They are a nice way to restrict users, while allowing network admins to carry on working efficiently away from there desks.

DevilWAH

The Peculiar case of the missing bandwidth.

Where I work we have a slightly strange network set up, as an agency of the government we run under what is knows as the GSI (government secure internet). What this means in practice is that our main site + the 16 or so regional sites have there WAN routers managed by a central government IT centre, and all traffic to the outside world has to pass through there systems. This in its self causes no end of issues in terms of restrictions such as no VPN access and no FTP allowed. But leaving that aside it does mean we sit behind a very secure gateway. All you really need to understand is that we have  “10mbs” full duplex fibre as our primary link of the main site, through which both internet and WAN traffic is routed. Oh and of course we have no access to the WAN router to see what is going on.

Well last Friday, the network grinds to a screeching halt..  What was a 20msec latency link to the regional sites has now become 4000msec (yep that’s right 4 seconds!!). As I say no access to the WAN router but from out 4506 that connects to it I can see the link to it is looking fine. So nothing for it but to call the service provider, after a short chat they agree that traffic has dropped and latency has shot up and start looking in to it for me.

A few hours pass (well 3 days to be more correct during which time we have moved over to the 4 mbs backup link) and they finally come back saying that the link seems to have dropped and the most data they can push through it is 1.6mbs, and they think it is a routing issue on our sites subnet as latency to the outside address of the router seems fine.

Now at this point my mine is saying 1.6mbs??? hmmm why does that number sound familiar, may be if they measured it a bit more accurately they would find it was actually 1.54mbs which of course is a T1 link speed.  Which suggests to  me either some one added a bandwidth policy along the link or the route had changed to pass across a T1 link. But no “defiantly not!!”, I am told with absolutely certainty that no changes have been made to the configuration and some one will attend site to test it out.

Following day the service provider has an engineer on site, after hours of testing the local loop section on the fibre can’t find anything wrong signal strength is perfect and router on site has low latency to next hop. After hours on the phone and a few more suggestions from me that 1.6mbs suggests a T1 link some where along the line. I am told again there have been no changed to the configure or routes, but he say he will call head office and have them check the configs. He come of the phone and says he will try one last test… And what do you know the Link is suddenly back working, latency’s dropped back to the 20msec region and pushing about 9mb of data across the link.

So what did they change? “Nothing”, all they did was set a 10mbsec bandwidth policy on one of the interfaces along the router… So why did it drop in the first place “no idea, some times these things happen”. Hold on so they are telling me they changed nothing, the link just stopped working on its own, and where as it had worked fine for the last 4 years with out the policy configured, it now just happens that adding it has solved the issue??

Forgive me for feeling that someone made a cock up, and had to fix it in a hurry, and I have not been told the full story.

So great after 4 days all back up and working. Or is it? For a long time now I have been suggesting that we don’t have the 10mbs full duplex link we have been paying for. In tests I have never been able to get more than 9mbs total throughput. As I push the outgoing traffic if pulls the incoming down. (Of course as I said I don’t have access to the routers so all I can do is push traffic from our devices at either end). But one of the engineers mentioned in passing that our link was 2 X 4.5mbs??? Which  is exactly 9mbs which is what my test show… So not only did they muck up the link for 4 days but for the last 4 years they have not been providing the service we pay for!!

Not really impressed with them over the last week (not that I have been overly impressed with them before, although a few members of there staff I have to say have been very helpful to me over the years), but maybe some thing good will come out of it and I will have the full 10mbs full duplex link promised.

It is also quite nice in the sense that I informed management and the service providers of my consern’s about the link speed, about 2 years ago when I first really had reason to look at it. All of who dismissed me, and told me it was a 10mbs full duplex and that I was only seeing 9mbs due to the type and volume of traffic. So I would be laying if I said I didn’t slip the “as I told you 3 years ago” in to my report to management this time round. 🙂

I still can’t believe that no one can hold there hands up though and tell us what really happened last Friday. This is where network device management accounting comes in handy, can’t even log on to my devices, let alone update config with out it getting logged. It’s not just I like to spy on people, but if all changes are logged on the syslog server, then if some one does make a change, and the next day when they are off it all falls apart. I can view the last 24 hours, 3 days, etc, of changes at a glance and see what has happened. No need for them to remember to document every change they make, that’s all done for them.

Well I wait to see what come of this episode. But after this I not sure I will ever trust a service provider again.

laters all

DevilWAH

Setting up HSRP (or how not to..)

OK need time out from reading about wireless networks, its all a bit of a repeat to be honest and I’m getting brain ache. I have update my ANKI flashcard pack though with some of it.

But I thought a few words on HSRP would help clear my mind.

HSRP (hot spare routing protocol), its a wonderful idea of CISCO’s. Two or more Routers on a subnet, sharing one IP address. You assign you client PC’s this IP as there default gate way, and in the event of one of the routers failing another takes over and keeps connectivity for you clients! And so simply to set up (both cisco routers and switches with the advanced IP feature set have this).

On the Primary router enter the config mode followed by the interface you wish to configure this on, and enter the following commands

(config-if)#ip address 192.168.14.200 255.255.255.0
(config-if)#standby 1 preempt
(config-if)#standby 1 ip 192.168.14.254
(config-if)#standby 1 priority 100

Then on the secondary router enter the following.

(config-if)#ip address 192.168.14.100 255.255.255.0
(config-if)#standby 1 preempt
(config-if)#standby 1 ip 192.168.14.254
(config-if)#standby 1 priority 95

And there we have it, now the first router will respond to any ARP requests for the 192.168.14.254 address which can be used as the DFGW for you clients. What is even better is that the routers will share the same MAC address for this IP. So in the event of the primary router failing with in 3 seconds (default timers) the secondry router takes over and all currently active clients will be able to carry on where they left off.

As always that is far from all you can do with HSRP, one of the main limitation you may notice is only one gateway is active at any one time, and although you can play with HSRP to achieve load balancing (See here), there is a much better way by using GLBP (Gateway Load Balancing Protocol). You can also have HSRP track interfaces and IP SLA counters to increase and decrease a routers priority to insure the router in the best position is running as the active, this cisco document covers the settings in far more detail than there is space for here.

Now for the how not to do it part 😉

By default the timers on HSRP are set to send a hello every 1 second and the standby router becomes active if it fails to hear a hello from the active route for more than 3 seconds. you don’t have to enter this of couse but the command would like like this to set it up

(config-if)#standby 1 timers 1 3

But 3 seconds ????!!!!!!!!!!!! three second network outage I cried! Hitting the question mark after typing (config-if)#standby 1 timers ?… what’s this I see msec. Yay I cried and after checking the documentation so see this really did reduce timers to the msec range, I proceeded to configure a hello timer of 50msec and a hold timer of 150msec ( you can actual configure it as low as 10msec). A quick test and yes almost instance fail over, not even a packet dropped, and I went home a happy lad.

However I configured that in the evening with little traffic on the network, next day just before lunch however…. Oh this is not so good, no one can get out of site? Things start to move then crash to a stop again. Well better log on to the core switches I suppose and see what the logs are saying….. Umm nope they wont let me on just hanging. Finally after switching off the secondary switch the primary one magically let me log in again and after checking its logs I could see what was happening. With such short hello timers packets where getting dropped, the switches started flapping between active and standby and in doing so just made the issue worse. And they could not settle on who was in charge.

From this I learnt two important things, First the don’t go below 200msec hello timers and 700msec hold timers (come on still less than a second fail over), and only do this is the routers/switches are directly attached. Secondly add in a preempt delay statement

(config-if)#standby 1 preempt delay 10

This will stop the flapping between active and standby. Once a device has change state away from being the active router, with the configuration above it must wait at least 10 seconds before it can take over again.

And finally just because you can do some thing does not mean you should or need to. The time out in the TCP stack in XP (and most other systems) is at least 9 seconds. In the case of VoIP and Video a few seconds delay may make a call hicup, but it will normally stay up. And people will not mine or take much notice of a slight hicup as long as it only happens once ever 6 months.

There are cases when you need better fail times, in which case you need the correct equipment. HSRP is a great technology but as I found back a few years ago when I did this. You can push a good thing to far.

For those of you with out CISCO devices, the industry standard version is VRRP (Virtual Router Redundancy Protocol), and some information on that can be found in this document.

Well I hope some of you will learn from my mistake, thankfully because I had played around with HSRP a lot on a test network, I was in a good position to trouble shoot and had it back up and working quickly. But still it is one of the times few times I have had to hold up my hands to management. Thank fully these times are rare and so far non-critical and short lived…

Well back to work tomorrow. Night all have a good one.

SSH port Forwarding (or how to Remote Desktop over SSH)

I found this one out quite recently, but wish I had come across it years ago.

Image you have SSH access to a device inside a remote network, what you really want is a remote desktop to a device inside, but firewalls are blocking RDP and you have no way to change there setting (maybe you need to be on the desktop to configure the firewalls?)

Well as long as you can meet the two basic requirements below then fear not, because another of SSH’s little tricks is to allow you to tunnel traffic over it.

  1. First you must have a SSH client on your local station that can carry out port forwarding. such as Putty or Teraterm.
  2. An SSH remote client that is allowed to send traffic on the RDP ports to the final end station you want to remote desktop to.

All set then lets go..

First you need to set up the local telnet client. Here I will show it with Tera Term, as its the one I have installed, but the settings for putty and others are straight forward to match. What we are doing is mapping a local IP and port for Tera term to catch data sent to, and then relay it across the SSH connection to the remote SSH client where it will be forwarded on to the destination remote desktop client using the IP and Port set up.

First open up Tera Term and chose Setup then SSH forwarding from the menu, once the box pops up chose add. For the local forwarding port you can chose any random valid port, for this example I will use 3390. For the remote IP enter the IP of the machine you want to remote desktop to and the RDP port it is set to listen on, by default this is 3389 so we will use this.  (hint if you want to RDP to multiply remote hosts, simple set up a different local port for each one) Click OK and you should have a screen something like below.

Now click on the OK button.

The final steps are easy, in Tera Term click on file new connection, and connect up an SSH session to the SSH remote host as you normally would. While this connection is active open up the RDP client on the local host and enter the computer to connect to as shown.

Note the use of the Local port we configured above. Clicking on connect, Tera Term will now tunnel the traffic over the SSH connection where it will be forwarded on to the remote desktop host.

Yes you can achieve a more user friendly set up using VPN’s and I would not suggested it for end users. But I have found this very helpful in admin situation. And your remote SSH client can be any thing that supports SSH, Linux box or Cisco device all work just great.

Well hope you have all had a great Saturday and have good things to look forward to tommorrow.

Night from the Devil.

Tree’s that Span the network

Lets start with a few links.

Cisco’s introduction to STP.

Cisco’s configuration guide

Before I learnt about sub-netting, trunk links, access ports, or vlan’s, I started looking in to STP. In fact my introduction to networking went along the lines of. Learn to log on to a 3COM 3300 super stack, assign it an IP address, sort out spanning tree. I had only been working in IT a few months with no previous IT experience when I was given the job of single handily auditing the network and assigning management IP address.  At the time the network was a pure Layer 2 single VLAN domain containing around 120 switches spread over 30 buildings. It was during this audit and while setting up a monitoring system that I first notice these network reconfiguration messages that kept popping up, not one to be able to leave alone I looked in to the cause and discovered STP!

I look back on horror as I dread to think how many of those reconfiguration where due to me rebooting a switch, or altering configs. those 3COM’s only ran old CST (802.1d) so every time I was causing up to 50 seconds of down time.. I can only plead ignorance and hope over the past 4 years I have made up for it.

The Spanning Tree Protocol (STP) I think is at its fundamental core, one of the more straight forward networking topics to understand. STP runs at layer 2 and its core function is to prevent loops in the network. Why do we need to prevent loops? Layer 2 has no default inbuilt method to detect if a switch has forwarded the same frame before, so if there are any cabling loops in the network frames will circle endlessly round them, clogging up bandwidth and switch CPU causing poor performance before it all grinds to a halt. At the same time though surely duplicate links are a good thing, if one fails you have one spare?

And this is where all versions of STP come along, by analysing the network as a whole, by sending special packets (bridge discover protocol units BPDU’s)  along every link of the network and seeing where the end up, the switches can detect any loops. They will then decided on which links to “block” so that there is only a single complete path across the network. And of course they have there methods to bring back up any of the blocked links in the event any of the primary links they back up should fail.

Before we get in to how this work lets recap the various versions of STP.

CST = 802.1d = Low =SLOW
PVST+ = CISCO = High = SLOW (default)
RSTP = 802.1w = Medium = FAST
PVRST = CISCO = Very High = FAST
MSTP = 802.1s = Medium/High = FAST

Lets start with PVST+, This differers from CST only in that it runs a separate instance for each VLAN on the switch, this allows load balancing or backup links as we shall see.  First lets get a digram up so we have some thing to refer to.

STP works by each switch determining which of its own ports should be forwarding and which should be blocking to insure the network is loop free. Because this is carry out in isolation of what ports other switches and to reduce the time and traffic the network administrator selects a central switch (the ROOT bridge) to act as a reference point for all the other switches. This central switch sends out packets (BPDU’s) on all its ports that are connected. As other switches receive these they note on what ports they are received and then add on the cost of the link. This cost is based on the speed of the link, the following is the table of defaults but these can be tuned if needed.

10Mbs =100
100Mbs = 19
1Gbs = 4
10Gbs = 2

So our fist step should be to configure what switch is root. This should be your core switch, as this will become the centre of the network with all other switches sending there traffic through it. In the case above we can used Switch A.

Switch_A(config)#spanning tree mode pvst
Switch_A(config)#spanning tree VLAN <ID> root Primary

All done…

Switch A is now the root bridge for the spanning tree on what ever VLAN ID you enter. The keyword root will cause Switch A to listen out on the network for BPDU’s being advertised on the VLAN, each switch advertise its root priority in its BPDU. Switch A will listen for the lowest and then set its own priority lower again. (lowest wins). This only happens as you enter the command. If at a later time another switch is set to a lower priority this switch will take over the root, Switch A will NOT lower its priority again. For this reason there are things like Root Guard that can be enabled.

At the moment the network digram still has loops so how does STP sort it out? Fist of all, ALL ports on A will be in the forwarding state (unblocked), and it is sending out BPDU’s. So lets see how Switch B figures it all out. First it receives a BPDU from Switch A on port F0/1, this has come in over a 100>bs link so it is given a cost of 19, the BPDU on port F0/2 has come via switch D, this will have added a cost of 19 is self as it received it, and Switch B will add a further cost of 100, giving a total root cost of F0/2 as 119. Working the same way F0/3 will be 19 + 100 + 19 = 138.

So the as the lowest cost port becomes the root back to port, Switch B will assign F0/1 as the root port. Repeat for switches C and D, and you will find, for switch C the root port is  F0/1 with a cost of 38 and for Switch D it is F0/1 with a cost of 19.

And what now? well now the root ports are sorted out we need to move on to designated ports. These are ports that are connected upstream pointing away from the root. With Switch B and D we see there is a stale mate, both have a 100Mbs link to the root and are connected together by a 10Mbs link. Next STP look towards port priority and as this is the same (both using same port ID) it looks to the MAC address. We will assume Switch B has the lower mac and so it has the higher priority). Switch B will there for place its port F0/3 in to a designated state, Switch D on the other hand seeing Switch B is higher Priority will leave its port with out a STP state.  Both Switch B and D will place ports F0/2 that connect to switch C in to the designated state. Switch C already having a root port to B, and seeing that port F0/2 also leads back to the root will again leave this port in a non designated state.

Once the Switches have decided what ports are assigned what states, any port still with out a state and that is receiving the Root BPDU, is put in the blocking state. So we end up with the logical network below.

As you can see where a link is blocked, one end will be in the designated state on one in the blocking state. In the case of CST and PVST, all BPDU’s are send from the root bridge. In the event of a link failure the affected switch must wait for the Root bridge to send out a BPDU (20 seconds time out by default), Only then does the switch start to listen for BPDU’s on its blocked ports before bringing them up. and this process in its self requires 15 seconds in the listing phase (listing out for the BPDU and building the STP) and a further 15 seconds of learning MAC address before the switch is again forwarding traffic across the back up link. So a total of 50 seconds can elapse.

RSTP and PVRSTP, address this issue, By allowing all switchs in the STP to send and recive BPDU’s, and keeping a note of what are the back up links that are currently being blocked, RSTP and PVRSTP can bring up a failed link with in a second or two. They introduce two new port states. The backup port, which is a second link back to the root. (in the network digram here port F0/3 on switch D and F0/2 on C would be back up ports) And the alternative port, this is when two links connect to the same uplink switch, Imagen switch B and C has two links directly between them, then one would be in the designated port state and the other blocked in the alternative state. By holing a note of the back up links, if the link between Switch D and the root failed, it knows it can bring the link on port F0/3 to switch B up with out danger of causing a loop.

So that’s STP in a nutshell, I will cover MSTP another day, but hopefully there’s enough there to get you head round it, with out load of configuration. All you need to remember is to define your root bridges correctly and insure all you switches are using and support the same STP mode. Once you have that configured correctly then STP will work for you. You then can spend the time tuning it and securing it. Which is a whole other post.

CCNP SWITCH CERT Updates

Those of you doing you switch exam my be interested to read these. Some updates to the CCNP SWITCH cert guide have been released. It looks like they cover some the the Planning topics, and also in there is some SVI stuff.

There has been a lot of discussion over CISCO’s handling of the planing part of this exam, so hopefully this extra material will help clear it up. Having glanced though it I remain to be convinced, but I will reserve full judgement till later.

Enjoy the read and will be back later with a new CCNP topic to review.

CISCO SDM why oh why oh why!

You would think a company like cisco would be able to produce a management tool that works.

Now I know SDM has issues with different java versions in windows and that in its self seems to be pot luck if it works or not.

But getting it running under Linux, oh my god! every thing sees to be against me here. And the worst thing about it all is how close I can get. I sure its doing this just to tease me.

I have tried old and new Firefox, about 6 versions of JAVA and still no joy. Its time to go home now and no remote access to the firewall so it will have to wait till Tuesday for my next play. So email still not working..

Ah well the weekend ahead, walks with the dogs, and some nice food to look forward to. Oh and of course lots of studying. 😉

Have a great one.

Filtering the VLAN Traffic

So it ended up I decided to do a recap on VLAN access control lists (ACL’s) before I got back into Spanning Tree. I also covered Private VLAN’s tonight but will come back to them some other time for the blog.

Over the years I have had lots of dealing with port and router based ACL’s, but VLAN based ACL’s I only came across when I started studying for my CCNP. And I already have plans to use them to limit the traffic on some of our more sensitive network segments.

Now if you know you VACL set up, here is the point to stop reading, what follows is a run through of the config, with some description of the steps.

Still with me? OK lets get to it.

The first step in creating a VACL’s is in fact to create some “standard” ACL’s first, these will be used to classify what traffic is filtered once the VACL is applied. the VACL will accept two types of access lists as arguments IP and MAC, so lets set some up.

(config)#access-list 100 permit ip host 172.168.5.5 any

(config)#mac access-list extended MAC-ACL
(config-ext-mac)#permit any host b7d4.5f6d.8e31

So two simple ACL’s created, now you can you the IP access list command and create named access lists as will if you wish.

So now we need to create the VACL and add these lists to it.

(config)#vlan access-map <name> 10
(config-map)#match ip address 100
(config-map)#action drop
(config-map)#vlan access-map <name> 20
(config-map)#match mac-address MAC-ACL
(config-map)#action drop
(config-map)#vlan access-map <name>30
(config-map)#action forward

Notice by default if a VACL is configured on a VLAN is a packet does not match the VACL it will be dropped. As we can see each section in the VACL has a sequence number, a match statement (can have more than one) and an action to take. In this set up any traffic that matches the two ACL’s we set up will be dropped. By adding a sequence with out any match statement and only an action, we have set up a “catch all”  situation, just like you may do with a “standard ACL when you enter “permit any any”.

So there we have it the VACL all set up and ready to go, now its just a case of applying it to a VLAN or two.

(config)#vlan filter <name> vlan-list 10

And there you have it, now any traffic passing across the switch on the configured VLAN’s will be subject to the statements in you VACL. I think there great for adding that extra layer of security to your network, and keeping traffic where it should be.

OK so not an exciting post tonight, but I will get back to STP tomorrow and I can tell you from past experience how not to configure it.

Night all and take care.

DHCP snooping and Option 82

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.