Layer 2 Overview

Figure 1

I’ve been meaning to add a dedicated cisco section to my site for a while, I thought it’d be helpful if I converged my rants with work a little I’m hoping to build up a personal archive of notes for work, and in doing so help other with similar roles & problems. I’ve gone through and added any cisco related posts to my archive , useful cisco bookmarks have always been online with del.icio.us , and now to finish off I have a config files directory. Usual rules apply to this an all other posts – see disclaimer.

Moving from a general security reseller to a “cisco cisco cisco” house has meant that templates have become important in my life; lets take security products like checkpoint or websense, not only are they gui driven (which makes templating difficult) but their implementation is very specific to their environment, as such companies that install with templates here usually aren’t doing a very good job. Switches or Routers on the other had can be templated, because there are only a few design scenarios (engineers usually stick to a favourite) and once you’re happy with a design, moving it from customer to customer usually only involves changing ip’s and passwords (of course a little intelligence to spot what else might need changing also helps).

This is a switch design my boss has handed down, it’s a basic collapsed core (i.e. no distribution layer) site campus implementation. I’m not going to take all the credit for the content as Frank helped a great deal (thanks mate).

Each access layer switch has two connections up to the core, and the core has an etherchannel link to provide the resilient triangle loop – See Figure 1. There a couple of things you need to pay attention two within this design…

1. The obvious one is that all the layer3 takes place in the core, now there is currently a cisco document circulating that we should be pushing the layer3 to the edge to take advantage of QoS for all things new like voice and video, I am aware of these considerations, but I haven’t found it entirely applicable*, which brings me to…
2. The design relies on having two VLANS on each access layer switch. Why ? Because is my experience cable and physical faults occur more often (human errors excluded of course) in cisco networks than switch failure, as such it’s good to have a design where by all cables have traffic flow. If traffic flows down all ports then MRTG can be used to view the usage, and if the “bloke that changes the light bulb” accidentally cuts through a fibre link you’re aware… this is much more preferable than having a standby link that’s never used/tested fail just as you need it. In short why two vlans, traffic for both routes. – See Figure 2. *why do I need QoS on my campus if I have two vlans, one dedicated for voice, and the other for data

Splitting the VLANS

Figure 2

Hopefully I’ve explained this well enough, if you take a look at the configs you’ll see that I’ve mirrored up the active HSRP SVI with the STP root bridge. This implementation ensures that I get the desired traffic flow, and distributed processing, i.e. if I force a route bridge on core b, why send it to core a for layer3 ? With all the technologies working correctly we have a completely resilient solution.

Mainly for my reference the example configs have some default security settings, these settings closely meet the safe blueprint but may need tuning, i.e. if you have a large campus you should be using TACACS+ rather than local user names and passwords…. it’s also important to note, if you don’t know what some of this does, you should probably google for it to find out The configs have been applied to cat4500/6k type devices in the core, and a stack of 4 3750′s at the edge (access layer). You should be aware that not all functionality is available on all switches , note I’m using vlan acls for rfc 2827 filtering, this probably isn’t available on lesser switches.

Anyway, enjoy !