Aaron’s Worthless Words

Have I talked about the Cisco Firewall Services Module (FWSM) before? It’s a firewall on a module for the 6500 and is based on the PIX firewall. The term “based on” is important here, since it does a lot of stuff the PIX does but everything. It obviously does connection inspection and filtering, but it does not do any VPN stuff. It’s not a license thing; it just won’t do it. If you want to do VPNs on the 6500, you have to get the IPSec VPN Service Module.  The VPN thing isn’t true, actually.  I believe version 3.1 and higher has support for VPNs.

Anyway, we won’t be going over any configs this time, but we can get some in the future. I just wanted to go over some stuff that you may need to know to get an FWSM working.

The FWSM does not have any physical ports on it. It uses the backplane of the switch to get a foot in the networks that you need it to. What does that give you? Well, it’s ultrafast on the 256Gbps backplane, which is a lot better than the 1Gbps on a physical interface. It also lets you have more interfaces than you could ever have on a firewall appliance (I think you can have 128 interfaces…someone correct me). I don’t know any firewall appliance that has more than 20 or so interfaces. It also is good for your cabling guy since there are no cables. I love it since I’m the cabling guy, too.

The FWSm can be set up with several security contexts. That means that you can chop up the resources of the module into “virtual firewalls” that operate separately from each other. This is pretty cool, actually, since you can, say, make a firewall for each of your hosting customers so that configurations on one don’t affect the others. You can also set the thing up in single context mode so it acts just like a single firewall. You’ll have to do some research to figure out what you want to do, and there are a lot of possibilities.

You can also set each context up in either routed or transparent mode. Routed mode is the “traditional” way to set up a firewall, where each interface is a different IP network with packets being routed through the FWSM. Transparent mode is where the FWSM has two interfaces that bridge the same IP network. I’ve always used routed mode everywhere, but you may have some use for transparent mode.

You also have to do some stuff on the 6500 to get the FWSM working. You make a vlan-group (a list of VLANs) to present to the FWSM and then assign that to the module. If you have more than one FWSM, you can have multiple vlan-groups; different FWSMs can control access in and out of different networks. Remember the context thing? If you have an FWSM in multiple contexts, you present the module with all the VLANs on all the contexts and split them up when you get to the context config part.

No configs. This is weird, but you’ll need to get all this information straightened out before you can get an FWSM configured properly.

• Leave a comment... (0)

In my billion years in the industry, when I’ve asked for network diagrams, I’ve inevitably received a physical diagram — a diagram that shows where stuff is plugged in. This is fine and dandy and has lots of information, but that’s not really enough these days. In the times of Arthur, when every piece of network gear did a single thing, you only needed to know where things were plugged in. In the modern era, devices do more — a switch can route and house wireless, an ASA can terminate VPNs and be a switch — so you need more than just where the cables run.

Logical diagrams show layer-3 (the IP networks) and how those are interconnected. From that, the diagram inherits the data paths as well — how does the packet get from network A to network B and back. You can’t see that with physical diagrams in a lot of cases.

Here’s a physical diagram of a single Internet router and a 6509 with an FWSM. It literally shows a router and a switch. How many IP networks do I have? How many firewall interfaces do I have? How many layer-3 interfaces on the 6509 am I using? This logical diagram, however, shows the same network from layer-3. A big difference, eh? Didn’t know I had 8 networks, did you?

Don’t go replacing all your physical diagrams with logical ones, though. You still have to know where things are plugged in, so keep the physical…just add a logical as well.

Tip of the day: Use Visio tabs for logical and physical diagrams on the same document.

• Leave a comment... (4)

Here’s a scenario I ran into long ago. We had several sites that had a frame relay link back to headquarters and a DSL line. Each link was terminated into a different router on a flat LAN with the users. The DSL was for Internet access, but also terminated a VPN as a backup to the frame circuit. The requirements were something like this.

• Corporate traffic had to go across the frame relay link during normal operations.
• Internet traffic had to go across the DSL line during normal operations.
• If the DSL circuit went down, Internet traffic should be moved over to the frame relay circuit to use the corporate Internet link.
• If the frame went down, traffic should be sent out the VPN tunnel for access to corporate stuff.

We set the default routes of the machines (via DHCP) to the frame relay router. That router’s default route sent traffic to the DSL router, which, of course, had a default route towards the provider. Both routers were participating in EIGRP with the rest of the corporate network, so they all knew where to route traffic destined for corporate traffic. If there was a frame outage, the default routes kicked in and sent traffic to the DSL router, which had the VPN tunnels. The problem came when there was a DSL outage.

At first, we were just monitoring the DSL IP and manually changing default routes when there was an outage, but you know DSL. We were lucky to have only 3 or 4 a day go down, so it was taking up a lot of our time just moving default routes around. We had to go to an automated solution, so we looked at doing object tracking but came up just short; it just didn’t do what we wanted. We had to go one more step and discovered reliable static routing (RSR).

In normal object tracking, you can track an interface or a route to an IP. With RSR, you can track reachability to an IP via ICMP (or a whole list of other things). This is just what we needed. We figured Yahoo was a site that would always be up, so we went about tracking one of Yahoo’s IPs from the frame routers, and, if it went down, we could send traffic back across the frame relay cloud.

To set up RSR, you have to set up an IP SLA entry, build a tracking object, then have the default route track the object. First, the IP SLA entry that we made.

ip sla monitor 1
type echo protocol ipIcmpEcho 66.94.234.13
frequency 10


This built IP SLA entry 1 to ping 66.94.234.13 every 10 seconds. With IP SLA, you also have to set a schedule for it to run. We wanted it to start ASAP and run forever, so we just did one of these.

ip sla monitor schedule 1 start-time now

This schedules entry 1 to start now, so every time the box came up, the IP SLA process started pinging away. You then combine the entry with a tracking object like this.

track 100 rtr 1 reachability

We built object 100 to monitor the reachability of SLA entry 1, so now we have an object to track if a host is unreachable. Sweet. How about the static part of the route? We set the default route of the frame router as the LAN IP of the DSL router tracking object 100. We also set a weighted default route pointing out the frame relay circuit to use when the object fails. Assume 10.0.0.0/24 for the frame cloud and 192.168.0.0/30 for the LAN.

ip route 0.0.0.0 0.0.0.0 192.168.0.1 track 100
ip route 0.0.0.0 0.0.0.0 10.0.0.254 250

In this setup, the default route is the DSL router, and, if the tracking object fails, it rolls to the frame cloud. Can you spot the flaw, though? When the route changes over, the object has recovered since it can reach Yahoo through the corporate Internet, and the default route get moved back to the DSL router…which then fails again…and rolls back…and…ack! An easy fix is to set a static route for the tracked IP to the DSL router.

ip route 66.94.234.13 255.255.255.255 192.168.0.1

This route also lets the frame monitor monitor the DSL service, so, when it comes back up, the tracking object recovers. Of couse, if someone at the site tried to get to Yahoo on that IP during a DSL outage, they would time out (shouldn’t they be working?), but, when the DSL recovered, the router would know.

• Leave a comment... (2)

In my professional life at some point, I came across someone who had a stack of Catalyst 2950 switches all trunked together with their Internet routers connected to the top of the stack. This was all well and good until they kept adding hosts to the “middle” of the stack, then they had all sorts of latency and packet loss.

The old adage of your chain only being as strong as your weakest length holds true in this case. Here, the weakest link is actually the most-congested trunk, though. Let’s step through to see. A 2950 is a 10/100 switch, so a single trunk can handle 100Mbps of traffic. We have 10 of these guys, Switch1 to Switch10, all trunked to the one above and below. If a server in the center of the stack on Switch5 is sending a lot of data to the Internet routers on Switch1, the trunks off of Switch5 will start to get saturated. Switch4 has a few hosts doing the same thing, so traffic from both Switch4 and Switch5 heads towards Switch1, further filling the trunks. Same for Switch3. Same for Switch2. Next thing you know, there’s 184Mbps or so trying to go across a 100Mbps link.

I fixed the problem using EtherChannel. EtherChannel, sometimes called trunking (not Cisco trunks…don’t get confused) or bonding, takes up to 8 interfaces of a switch and binds them logically as one Port-channel interface. The switch then load-balances (not really, but can be pretty close) the traffic across all the links, so, in essence, if you have 2 100Mbps ports in an EtherChannel, you get 200Mbps of bandwidth. If you put in 8 ports, you’ll get 800Mbps. Or, at least, close to it.

There are, as usual, stipulations for using it.

• All ports on the EtherChannel must terminate to the same device on both ends. You can’t have one port go to one switch and another to another switch.
• The ports must use identical media. You can’t have a copper port and a fiber port in the same group.
• The ports must have the same capabilities. You can’t put a 100Mbps port and a 1Gbps port in the same group.
• The ports must be configured identically or it won’t work. This is actually pretty easy to maintain since configuring the Port-channel actually sets the config on all participating ports.
• Both ends of the ports must be EtherChannel. You can’t run it on one switch but not the other.

Enough of that. Let’s configure. The scenario is that you have SwitchA and you want to bind F0/1 and F0/2 into an EtherChannel. Of course, you want to carry traffic from all VLANs, so let’s make it a trunk.

int F0/1
channel-group 1

int F0/2
channel-group 1

int Port-channel 1
speed 100
duplex full
switchport trunk encapsulation dot1q
switchport mode trunk

Easy as pie. Do the same thing on the other end and you have a 200Mbps, bonded trunk.

• Leave a comment... (0)

If you’re running iBGP, you may have run across this. What if you had three routers — R0, R1, R2 — that were running BGP under the same ASN, but R1 and R2 weren’t peered? Any routes coming from R1 would not show up on R2 and vice versa. iBGP, by standard, does not pass on routes it learned via the same ASN. That is, if a router learns a route from another router in the same autonomous system, the route does not get forwarded. I guess it just assumes that all iBGP routers are fully meshed…I don’t really know.

That sucks, right? One of several fixes for this is the route-reflector-client directive under the BGP neighbor configuration. A route-reflector literally reflects the routes from one client to the others just as if you’ve got a fully meshed network. Here’s a sample config for the reflector, R0.

router bgp 65000
neighbor 10.0.0.11 remote-as 65000
neighbor 10.0.0.11 route-reflector-client
neighbor 10.0.0.12 remote-as 65000
neighbor 10.0.0.12 route-reflector-client

There’s actually no additional config on R1 and R2 at all; the router reflection is transparent to them. They actually see the route just as though they got the update directly from the originating router, so any routes received from the reflector appear as though they came from the originator. In that same breath, you have to realize that R1 and R2 must have routes to each other since the untouched BGP routes will have a next-hop address as the originating router.

Edit: Here’s a crayon drawing I did to show an example of where you would use route-reflectors. R0 is connected to R1 and R2 via different WANs, but R1 and R2 aren’t connected at all.

• Leave a comment... (0)

VLAN Trunk Protocol (VTP) is a little gem on Cisco switches that allows you configure VLANs in one place and have them appear on all of your switches. This is great for large enterprises with 8457839 switches all trunked together because who wants to configure the new VLAN for that one-off application on all 8457839 switches?

VTP works by having designated VTP servers (not real servers like your Linux box, but a switch) tell the rest of the switches in the network with what VLANs they should be configured. All the designated VTP clients say “OK” and configure themselves with those VLANs. When you take a VLAN out of the server, all the clients take it out; when you add a new VLAN, all the clients add it as well. The server and client designation is known as the VTP mode, and there’s one more to mention. When a switch is in VTP transparent mode, he will see VTP from the servers but will ignore them and pass them on to the next switch as if nothing ever happened.

To configure VTP, you have to define the VTP domain, which is a name for a group of switches that exchange VTP information. In general, in an enterprise, all your switches will probably be in the same VTP domain, but there are situations where you have multiple VTP domains on a LAN (like production and test networks). Next, you set the mode on the switch — server, client, transparent. I would suggest you configure a password as well to at least appear as though you’re practicing good security practices (I’m not sure it’s actually secure or not since every switch has the same password and the hash is sent in every packet…somebody enlighten me, please).

Get on your configuring gloves while I give you some more detail. VTP only works over 802.1q or ISL trunks. Also, VTP packets are Ethernet frames with the VTP stuff shoved into the data section. A switch can only be in one VTP domain at a time and can only be in one mode at a time. You can have more than one VTP server for a domain if you’d like (via a revisioning mechnism where the latest update always wins).

Here’s your scenario. You have SwitchA’s port G1/1 plugged into SwitchB’s G2/1. You want SwitchA to be the VTP server and SwitchB to be the client. Let’s get the config in place.

SwitchA(config)#interface G1/1
SwitchA(config-if)#switchport trunk encapsulation dot1q
SwitchA(config-if)#switchport mode trunk
SwitchA(config-if)#exit
SwitchA(config)#vtp mode server
SwitchA(config)#vtp domain VTP-DOMAIN
SwitchA(config)#vtp password VTP.PASS

SwitchB(config)#interface G2/1
SwitchB(config-if)#switchport trunk encapsulation dot1q
SwitchB(config-if)#switchport mode trunk
SwitchB(config-if)#exit
SwitchB(config)#vtp mode client
SwitchB(config)#vtp domain VTP-DOMAIN
SwitchB(config)#vtp password VTP.PASS

Both switches are now in VTP domain “VTP-DOMAIN” and share the password “VTP.PASS”. When you add a VLAN to SwitchA, it automatically gets added to SwitchB. When you add a VLAN to SwitchB, it actually errors out and says something like “Dude, I’m a VTP client. You can’t update me.”

At work, we have a large number of ports but a small number of switches. We also make very few changes to VLANs, so the work needed to maintain the VLANs is very low. Because of that, we actually do use transparent mode on all the switches. I’m also a bit of a purist, and configuring VLANs is something I like to do by hand; in my opinion, some things, especially mechanisms that can take whole networks down, are better left to the human. That’s just me, though.

• Leave a comment... (0)

A lot of IOS commands give you a lot of information. Most of the time, though, it’s way too much information, and it sure would be nice to do some grep-like stuff on the output, right? Well, just like on Linux, you can use the pipe (|) to do such. That’s not a butt cheek, by the way.

The most useful function is the include directive. This is the equivalent of just plain grep on Linux, and will show you only lines that match a string that you give it. Say that you want to find what ports on your switch are down, but don’t want to grind through all the lines of a show ip interface brief. If you just pipe it to the include command followed by the word “down”, you’ll see something like this.

Switch#show ip interface brief | include down
GigabitEthernet0/4 unassigned YES unset down down
GigabitEthernet0/7 unassigned YES unset down down
GigabitEthernet0/17 unassigned YES unset down down
GigabitEthernet0/18 unassigned YES unset down down
GigabitEthernet0/19 unassigned YES unset down down
GigabitEthernet0/20 unassigned YES unset down down

You can also use the exclude directive, which is the same as a grep -v on Linux. I hope you figured out that this gives you all lines that don’t match the word, so, let’s use the exclude directive to found out what ports are down. How about we just ignore the lines that are up.

Switch#show ip interface brief | exclude up
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/4 unassigned YES unset down down
GigabitEthernet0/7 unassigned YES unset down down
GigabitEthernet0/17 unassigned YES unset down down
GigabitEthernet0/18 unassigned YES unset down down
GigabitEthernet0/19 unassigned YES unset down down
GigabitEthernet0/20 unassigned YES unset down down

Well, this won’t exactly give you all the ports that are down. What if the port is up/down?

What else can you use with the pipe? What if you want to look at the configurations of all the ports or interfaces on a box but don’t want to go through the config hitting the spacebar over and over. If you use the begin command, you’ll see the output beginning from the first match, so, using the string interface will show you the config starting at the first interface.

Switch#show running-config | begin interface
interface GigabitEthernet0/1
description Server
switchport access vlan 4
switchport mode access
spanning-tree portfast

…

Another good one is the section command. It’s usually used on the output of show running-config and shows you sections of the config that match your string. Huh? If you want to see the BGP section of the configuration, you can do something like thing just to see that part of the configuration.

Router#show running-config | section bgp
router bgp 1
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 version 4

There are a few other commands for use with the pipe, so explore on your own. You might also want to check out regular expressions on the Cisco IOS if you want to match more than just simple text.

• Leave a comment... (6)

I realized the other day that I haven’t mentioned EIGRP once. As a Cisco guy, I think I’m required to do at least one article on it, so here it goes.

Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco-proprietary routing protocol. Routing protocols share routes, right, but “interior” is the keyword here; it’s used to distribute routes on your internal network (Contrast that with BGP, which is allows you to share your routes with others). In a nutshell, each router in the EIGRP cloud tells everyone what subnets it has connected to him.  A receiving router then combines that information with everything that it already knows and passes on any new information.  Do that recursively for a while, and, eventually, every routers knows all the subnets in the network.

When you configure EIGRP, you have to tell it some stuff to get it moving.  First, you have to configure a AS number, which is very similar to the AS number is BGP.  When two routers talk EIGRP, they always include their AS numbers, so, if one router receives an update for an AS it isn’t configured for, it ignores it.  Besides the AS, the only other thing you need to configure is what networks you want advertised via that EIGRP AS.  It’s simple and easy, but there are thousands of combinations of commands that you can use.

Basic config time!  The scenario is that you have two routers, R0 and R1, that share a LAN segment 192.168.0.0/24 off their F0/0 interfaces.   R0 has the network 192.168.100.0/24 off F0/1, and R1 has 192.168.101.0/24 off F0/1.  You want both routers to know where every subnet on the network is, and we’ll use AS 1 for simplicity.

On R0:

router eigrp 1
network 192.168.0.0
network 192.168.100.0

Every interface to falls into these network ranges will now participate in EIGRP AS 1.  If you had another interface on another subnet, that interface would not participate.  On the flip side, if your F0/0 as 192.168.0.0/25 and F0/1 was 192.168.0.128/25, then you would only need the one network line to cover both interfaces.  Notice that there’s no subnet or wildcard mask in these lines.  EIGRP is very classful, so it summarizes routes to network boundaries before inserting the more-specific route from EIGRP, so keep an eye out for that to be sure it doesn’t bite you.

On R1:

router eigrp 1
network 192.168.0.0
network 192.168.101.0

Almost immediately, you should see some lines talking about new adjacencies or neighbor changes.

If you do a show ip route on each router, you should see some routes from EIGRP.  Here’s the output from R0.

C    192.168.0.0/24 is directly connected, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/1
D    192.168.101.0/24 [90/30720] via 192.168.0.2, 00:00:47, FastEthernet0/0

The big ol’ D at the beginning of the line tells you that this is an EIGRP route, so you know it’s working.

Check out one of Cisco’s pages for more info.

• Leave a comment... (0)

We just talked about tagging traffic and policing traffic, but we haven’t talked about prioritizing traffic. Tagging just sets a value in the header. Policing sets a “bandwidth ceiling” that can’t be crossed. Prioritization guarantees a certain amount of bandwidth for a flow/app/etc. no matter what’s going on.

Prioritization offers you a certain amount of bandwidth; it doesn’t carve it out and hand it over. If you’re using less than the priority value, you only get as much as you need and the rest of the reserved bandwidth goes into the pot for everyone to use. As priority traffic grows, though, you’re given as much as you need up to the configured value. When you go over that, your extra traffic just goes into the best-effort queue with everything else (Note: Don’t go over the limit with VOIP traffic. Echoes and artifacts suck). For example, if you give your VOIP traffic 70% of the bandwidth of an interface but are only using 40%, the other 30% can be used by the other apps on the line. If you’re using 80%, that 10% over is competing with everything else for bandwidth.

Let’s get on with it, shall we? To configure prioritization, you go through the same steps as we did with policing, but, instead of setting the policy-map for police, you set it up for…wait…wait…priority. Here’s the scenario, then. You have a router that has a VOIP system behind it. That router tags all VOIP packets as AF41, so we want to give any AF41 packets 70% of the bandwidth on the interface. The tagging router is directly attached to your F0/0 network, and your users are out F0/1.

We don’t use an access list this time since we’re looking for DSCP values in the packets. We’ll start with the class-map.

class-map VOIP
match dscp af41

Remember that class-maps define what traffic you’re interested in, so this line says that we want to do something with any packet that’s tagged AF41. Let’s tell the router what we want to do with it, then.

policy-map PMAP
class VOIP
priority percent 70

With this configuration, any packet with a DSCP value of AF41 is given priority and is guaranteed up to 70% of the total bandwidth available. So, what is 70% of the total bandwidth available? That depends on where we apply the policy-map. If it’s on a T1, that’s 1.08Mbps. On our FastEthernet, that’s 70Mbps.

Let’s apply it to the interface to finish up.

interface F0/1
policy-map output PMAP

Since we’re worried about squashing VOIP traffic on F0/1, we apply it outbound there (towards the users). We could apply it inbound on F0/0, right? Not really. Once the packets hit the interface, it’s too late to do any prioritization on them; they’re already on the router in the order that the switch is delivering them to us. Prioritization really only works outbound.

So, if nothing’s going on, VOIP can use up to 100Mbps, but, if the link is saturated, it’s guaranteed 70% of the bandwidth or 70Mbps. Of course these numbers should be tweaked to suit your needs, but you can see how useful prioritizing is.

• Leave a comment... (0)

We covered QoS tagging the other day, but that just marks packets. I think you’re old enough now that we should actually do some policing. Policing is where you restrict the amount of bandwidth that a flow or set of flows can use. For example, say you have a site that serves webpages to the rest of the network. HTTP is the primary function, but the SysAdmins also have to maintain the boxes via SSH, right? To make sure that their SSH sessions don’t squash the bandwidth that your HTTP servers need, you can police the SSH sessions by giving the a bandwidth ceiling that they can’t cross.

Let’s set up a scenario. You have a router with two Ethernet ports. E0/0 goes to your webservers on 192.168.1.0/24, while E0/1 goes to SysAdmins’ PCs on 192.168.2.0/24. We want to restrict all SSH access from 192.168.2.0/24 to 192.168.1.0/24 to 8k of bandwidth. That’s right, you don’t like your admins and want them to struggle with their daily tasks. Let’s set it up.

Remember the steps? ACL, class-map, policy-map, interface. First, create an ACL that matches the traffic you want to police.

ip access-list extended SQUASHSSH
permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 22

Next, create a class-map that matches that traffic.

class-map SQUASHSSH-CMAP
match access-group name SQUASHSSH

Create your policy-map. This is where you actually set the bandwidth restrictions.

policy-map SQUASHSSH-PMAP
class SQUASHSSH-CMAP
police 8000 conform-action transmit exceed-action drop

Last time, we just did a set dscp af43, but this time we actually take action on a packet instead of just marking it. The long lines does three things — it sets the ceiling to 8000 bits per second, transmits if the rate is below that number, and drops if its exceeded. So, if one of the admins tries to SCP a file over, he’s gonna be in for a surprise with only an 8k window to use. If he goes over 8k, the packets are just dropped, and it’s up to TCP to retransmit. It’ll take a while. Remember, too, that this policy applies to anything matching the ACL, so, if two admins are SCPing files at the same time, they have to share that 8k. Wow, you’re mean!

Setting it up on the interface is pretty straightforward. It’s just like we did before.

interface E0/0
service-policy output SQUASHSSH-PMAP

I set this up in a dynagen lab to test it, but, instead of SSH traffic, I policed ICMP. If I did a normal, 5-packet ping, it worked great. If I sent a 100-packet set, drop, drop, drop. Or if I increased the size of the packets. Just to be sure it was the service-policy doing the dropping, I sent a 100-packet set and removed the policy from the interface; it missed a few at first, but, when the policy was removed, it zoomed right along without a single miss or hesitation.

NOTE: I do not condone policing traffic from your coworkers machines to 8k, but it would be funny.

• Leave a comment... (4)