Aaron’s Worthless Words

We have a location that’s a few blocks down from the main office here, and we were reviewing the circuit size to make sure it was sized properly.  Since not one person knows what’s going on and the trending graphs gave us conflicting details, one of our network dudes took me down to the site to do a physical survey to see what’s going on.  Well, besides the fact that no one was there, we discovered a hodgepodge of routers and switches that were cross-connected to one another on multiple floors of the building (I really wish I could post pics to emote the effect).  It’s kind of hard to figure out what’s going on when you can’t see both ends of the cable, so we had to abandon all hope.

What are our options, then, to see how things are uplinked and connected?  In this case, CDP is the answer.  The Cisco Discovery Protocol (CDP), if you don’t know, tells you what other Cisco devices a particular Cisco device in plugged into.  So, if you have a 2811 plugged into a 2960, you can see what ports they’re connect on along with some other details.  Here’s an example.

Switch1#sh cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
Router1                    Gig 0/10              122             R       3640      Fas 0/1
Switch2                    Gig 0/9               141            S I      WS-C2950G-Fas 0/48

As you can see from the output, Switch1’s G0/10 is plugged into Router1’s F0/1 interface, and Switch1’s G0/9 is plugged into Switch2’s F0/48.  You can also see that Router1 is a 3640 and a router (the “R” under Capability).  Switch2 is a 2950G switch.

So, today, I’m going to start at the head end of my frazzled location and try to figure out where everything is connected.  I’ll get all the CDP neighbors for that device, document it, then repeat for the next hop until I’m all the way through.  When I’m done, I should have a nice physical map.

Beware, my friends, that the “C” stands for Cisco.  It doesn’t stand for Juniper or Nortel or anybody else.  The rule is that CDP only shows your Cisco devices that are connected together and won’t show any other devices in the path, but there are exceptions.  Since it’s broadcast-based, a lot (maybe all?) non-Cisco switches just pass along the packet to the next hop on layer 2, so you may see CDP neighbor adjacencies between switches that aren’t connected to one another.  CDP will think they are, and I don’t know of any way to detect that, so be careful.

Send me money Halloween candy comments if you feel inclined.

• Leave a comment... (2)

We ran into this today, and, though I knew it existed, I never actually saw it in the wild.  I’m talking about MAC access-lists.

In the example setup, we have a DMZ off of a firewall that contains a whole mess of servers — email, web, ftp, etc.  These should all be in the DMZ for sure, but they shouldn’t talk to each other.  If a bad guy was able to own my FTP server, he would have a nice platform to use to attack my email server.  That’s not cool, so we’ve put in MAC access-lists to help out.

MAC access-lists do just what you think they do; they put access controls on what MAC addresses can talk to what on a  particular port.  You build a list of permit and deny lines that you want to use to control access and apply them to a port.  Sound familiar?  Yeah…it does sound a lot like IP ACLs, doesn’t it?  Here’s some technical detail for those that care.

• MAC ACLs can be numbered or named.  The range for numbered ACLs is 700-799.  The naming conventions follow the same rules as an IP list.
• A port must be a in access mode before you can apply a MAC ACL.  You can’t apply them to trunks.
• You can use the any and host directives instead of using MAC/mask combos.
• If you’re feeling froggy, you can actually do a MAC/mask combo, but, since the MACs on your hosts probably aren’t sequential, I don’t see the point.

Let’s build one.  Suppose we have a host with the MAC 1111.2222.3333 plugged into a switch on port F0/1.  It is a web server and needs access to the mail server on the same network (4444.5555.6666) and the firewall (9999.8888.7777) as a gateway.  How do we set it up so that the web server can only speak to those guys?

mac access-list extended WEBSERVER
permit host 1111.2222.3333 host 4444.5555.6666
permit host 1111.2222.3333 host 9999.8888.7777

int f0/1
mac access-group WEBSERVER in

Now that host can only speak to those two MACs on layer 2.  Pretty simple yet again.  There are some things to note, though.

First of all, this just keeps this host from talking to other MACs on the same network and does nothing to keep packets from other host from reaching our webserver.  Though the webeserver won’t be able to respond, one could argue that it’s best practice to apply an outbound MAC ACL that mirrors the inbound.

There’s also an issue of broadcast.  Say that the webserver is now trying to send a packet to the mail server to send an alert.  One of the first things that it will do is to send a broadcast (ffff.ffff.ffff) asking for an ARP reply.  Guess what?  That MAC isn’t in the ACL.  You could put static ARP entries on the boxes, but it may be easier just to allow the host to talk to the broadcast.

Don’t get layer-2 security mixed up with layer-3 security.  This restricts access on (usually) a single  IP network where you don’t have routers or firewalls between hosts.  Use the old-fashioned IP ACL for between networks and MAC ACLs for between hosts on a network.

Questions?  Comments?  Bribes?  Free money?  Send them all my way.

• Leave a comment... (2)

Like (nearly) everything in the Cisco world, you can set up your CSM to fail over to another module when the primary dies a horrible death.  You can have two in the same chassis or even have them in separate chassis — the process is the same no matter how you have it set up.  Either way, you have a primary and a secondary module in fault tolerance (FT) mode.

First, we’ll establish a VLAN that the CSM will use to do its configuration and state syncing over.  This is just an ordinary VLAN; there’s nothing special about it, really, but it should be dedicated for the CSM to use for syncing.  Let’s randomly choose VLAN 83.

vlan 83
name CSM-Sync

You will, of course, have to do this on every switch that holds a CSM, so, if you’re using them in two different chassis, you’ll put the same VLAN on each making sure they can see each other through a trunk.  Cisco recommends that you dedicate a trunk between the two switches for the sync VLAN in order to remove the chance of other traffic stepping on the sync packets, but I’m not convinced that’s necessary.  Use your judgement on that one.

Back to it.  Next, you need to decide on a FT group ID.  This is similar to a HSRP group and lets you run multiple FT groups on the same VLAN.  The group ID needs to be in the range of 1 to 256, so, since this is the first one, let’s just use 1.  Get into config mode for the CSM that you want to be the primary and do this.

ft group 1 vlan 83

This takes you to the config-slb-ft prompt.  Just like HSRP, we need to set priorities for each device and whether or not it should preempt, so let’s configure.  Yes, we want to preempt, right?  Let’s set the priorities to 100 and 90, too.

priority 100 alt 90
preempt

This sets the primary CSM to priority 100 and the secondary to 90; both will preempt.

What about configuring the secondary for FT? That’s easy.  Go into CSM config mode on the secondary and enter the ft group 1 vlan 83 command.  That’s it. The two CSMs will do a little arguing and come back as the primary and secondary.  After that, all configuration is done on the primary, which is synced over to the secondary just like an ASA.  Pretty cool, eh?

When configuring things like IP addresses, though, you’ll need to make provisions for the secondary with the alt directive (remember that one from the priority).  I won’t go into much, but you’ll need it mostly when settings IPs to VLANs.  Here’s an example of setting an IP address on client VLAN 100 for both the primary and secondary.

vlan 100 client
ip address 192.168.0.11 255.255.255.0 alt 192.168.0.12 255.255.255.0

Alright…one more thing.  The configurations don’t sync automagically (at least not on my old version of code).  If you make a change to the primary CSM, you’ll see an out-of-sync message when you look at the FT status.

Switch#sh mod csm X ft
FT group 1, vlan 83
This box is active
Configuration is out-of-sync
priority 100, heartbeat 1, failover 3, preemption is on
alternate priority 90

If the primary goes down now and the secondary takes over, the changes you just made won’t be reflected on the secondary.  You fix this with the hw-module contentSwitchingModule X standby config-sync command (where X is the module slot in the chassis).  Alternatively, you can just type hw c X s c as a shortcut.  It’ll take a few minutes depending on your configuration, so check your logs for when it’s finished.  Note that the secondary does not save the new configuration to its startup-config; you’ll have to log in and save that manually (or automatically through CiscoWorks or something) to save changes there.

Let me know if you have any questions and check out my page on getting output from Cisco’s fine mid-tier load balancer. 

• Leave a comment... (1)