I was doing an HSRP lab the other day, and a project from the past popped into my head. A customer had a host on a network that was separated from the rest of the network by a 1700 with a couple of FEs. They wanted that host to be NATted to a local address so that they didn’t have to do any routing, which makes sense, I guess. This is just your standard 1-to-1 NAT, so we plunked down a quick config.

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.

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.

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.

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.

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.

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.

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.

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.

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.