Aaron’s Worthless Words

I had an article a few weeks ago about the [tag]Cisco[/tag] [tag]CSM[/tag], which is a load-balancer module for the 6500 series switches. This thing is a pretty good device, but monitoring the connections to each VIP and RIP is not very straightforward. If you have an [tag]SNMP[/tag] monitoring system like Cacti or MRTG, you need to know the [tag]OID[/tag] to [tag]monitor[/tag], but it doesn’t work like anything else in the world.

Let’s start with the OID for the vserver. First, there’s the base OIDs that you can look up on CCO. This is just standard SNMP stuff that Cisco defined long ago. The slot number that the CSM is in is added to that base OID. You then have to add the length of the vserver name — don’t ask me…I don’t know. Next comes the really stupid part — you have to take the names of the vserver and get the ASCII values of every character in the name and add each to the end to get the full OID. Yes, it’s that stupid.

<BASE VSERVER CONN OID>.<SLOT>.<LENGTH>.<VSERVER NAME>

The serverfarm OID is pretty close — the base OID and slot. You then add the length of the serverfarm name along with the ASCII values of the serverfarm name (quite like we did for the vserver). Finally, the only part that might make sense, you take the IP of the real server and add it to the end with the instance of “0″. Again, I have no clue why it’s like this or what Cisco was trying to do. It’s terrible.

<BASE SF CONN OID>.<SLOT>.<LENGTH>.<SF NAME>.<REAL IP>.0

How about an example. Let’s say you have a vserver called VSERVER1 that you want to monitor. This vserver is configured to use the serverfarm FARM1, which has two reals of 192.168.1.101 and 192.168.1.102 that you also want to monitor. You also know that the CSM is in slot 3. The base OID for vserver connections is .1.3.6.1.4.1.9.9.161.1.4.1.1.17; the base OID for serverfarm connections is .1.3.6.1.4.1.9.9.161.1.3.1.1.5. This all gives you this:

VSERVER: .1.3.6.1.4.1.9.9.161.1.4.1.1.17.3.8.86.83.69.82.86.69.82.49
RIP1: .1.3.6.1.4.1.9.9.161.1.3.1.1.5.3.5.70.65.82.77.49.192.168.1.101.0
RIP2: .1.3.6.1.4.1.9.9.161.1.3.1.1.5.3.5.70.65.82.77.49.192.168.1.102.0

Did I mention it’s overly-complicated and terrible? It’s actually so bad that I just wrote a Perl script to do it for me because, for God’s sake, I’m not doing that by hand. Let me know if you need any help with it.

• (0)

We’ve done some tracking with [tag]HSRP[/tag] in other articles, but there are lots and lots of ways to use [tag]object[/tag] [tag]tracking[/tag] on an HSRP device. In our example network, we tracked the interface, and, if it went down, we decremented the standby priority. What if just the line protocol goes down? How about if the BGP peer on the other end stops sending you routes? If you don’t know that object tracking is the answer, you didn’t read the title.

In doing any type of object tracking, the first thing you is…wait for it…create the object. Let’s do the line protocol object first.

track 100 interface S0/0 line-protocol

This creates an object with the object number of 100 that tracks the line protocol of interface S0/0. Now what? If we look back to the HSRP setup we have two routers with HSRP running on each of the FastEthernets. If we add an interface S0/0 for Internet access (or corporate access or POS access or access to your toilet), we probably want to track the line protocol of those interfaces to make sure the interface is still healthy. Here’s the new configuration on the FastEthernet interfaces.

interface FastEthernet 0/0
ip address 10.1.1.11 255.255.255.0
[tag]standby[/tag] 75 ip 10.1.1.1
standby 75 priority 50
standby 75 preempt
standby 75 track 100 decrement 55

Now, when the line protocol of S0/0 goes down, the priority of standby group 75 goes down by 55. Sweet. How about if S0/0 is to an Internet circuit, and the BGP peer stops providing routes? It’s just as easy to set up.

First, you need to find an route in your BGP table that’s going to be stable. I like Google or Yahoo, but it doesn’t really matter. Let’s say the route you want is 1.2.0.0/20, so let’s build the object.

track 101 ip route ip route 1.2.0.0/20 reachability

We put this in the config, and we end up with this.

interface FastEthernet 0/0
ip address 10.1.1.11 255.255.255.0
standby 75 ip 10.1.1.1
standby 75 priority 50
standby 75 preempt
standby 75 track 101 decrement 55

If your router doesn’t have the exact route in object 101, the priority of standby group 75 goes down by 55. Notice I said exact — if you have a bigger or smaller route, it won’t match. You knew that, though. And, yes, you can have more than one track statement in each standby group, so you can track the route and the line protocol at the same time if you want. Good stuff.

If you implement HSRP anywhere, you should probably do tracking of some kind. Check out Cisco’s page on Enhanced Object Tracking for a list of the tracking objects you can use.

• Read comments... (1)

I like [tag]layer-3[/tag] [tag]switch[/tag]es. They give some great flexibility and bang-for-the buck, but most people overlook one issue with these things that can cause security problems. Most people configure the [tag]VLAN[/tag]s, put an IP on the VLAN interfaces, and put it in production, but the packets don’t actually flow the way they think they do.

Let’s check an example. Here’s what the proverbial you had in mind when you plugged your web server, management server, and firewall into your 3750.

This works, but most of the time, I don’t think they really want your web servers to pass traffic directly to your management servers. Yes, your web server can send packets to your management server all day long without the firewall even knowing what’s going on. And so can anyone who compromises your web server.

Your web server has a default route pointing to interface VLAN101 on your switch. Any packet is sent that way, and the switch accepts the packet and does a route lookup for it. You’ve got a static route on the switch for the management network pointing to the firewall, so it should go there, right? Wrong. The switch actually ignores your static route since it has a better one — a connected route via interface VLAN201. Remember that both routers on the diagram are the same device! Connected routes take precedence over static routes, so packets always go directly to the management server. [tag]Policy[/tag] [tag]routing[/tag] is the only way that you can override the routing table.

So, what do we do? We first make an ACL that matches the traffic we want to policy. We then create a route-map that matches the ACL and sets the next-hop address. Finally, we apply the route-map to the properly interface. Let’s say that, like in the diagram, your web server has an IP of 192.168.0.51/24, and the management server has an IP of 192.168.1.88/24. We want to send traffic from 192.168.0.0/24 to 192.168.1.0/24 through the firewall (172.16.0.84/24).

First, let’s build an [tag]access list[/tag]. Anything that matches the [tag]ACL[/tag] (that is, anything that is permitted) will be considered interesting to us.

access-list 101 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

Easy. Now let’s build the [tag]route-map[/tag]. We want every packet that matches ACL 101 to be sent to 172.16.0.84, so let’s try this:

route-map WEB-to-MGMT permit 10
match ip address 101
set ip next-hop 172.16.0.84

route-map WEB-to-MGMT permit 20
set interface Null 0

What did that do? Nothing so far, but it will do something in a minute. The priority 10 set says that any packet that matches ACL 101 goes to 172.16.0.84 — the firewall. Sweet. The priority 20 set says that everything else is dropped. One last step — let’s apply the policy to the interface.

interface VLAN101
ip policy route-map WEB-to-MGMT

Now we’re cooking. When a packet lands on interface VLAN101 that matches ACL101, it’s sent to the firewall instead of being directly routed to the management network.   The policy is only applied to packets that come into the interface, so packets that go out won’t be affected.  Make sure you do it to the traffic coming back the other way.

Let me know if you have any problems. Policy routing can get tricky sometimes.

• (0)

[tag]Cisco[/tag]’s [tag]Content Switching Module[/tag] ([tag]CSM[/tag]) is an application accelerator. Or is it an application networking service module? I hate those fancy buzzwords — it’s a [tag]load balancer[/tag]. It’s a module for the [tag]6500[/tag] series switches that lets you load balance services in any VLAN and can also be set up for high-availability. I could go on for a while about the features, but let’s keep it simple for now. A short [tag]tutorial[/tag], if you will.

Configurations to the CSM are made in the [tag]IOS[/tag] itself. It’s a little different than other modules where you have to session over or SSH to the module. The only trick is that you go into CSM mode like this.

Switch#conf t
Switch#(conf)module csm 3
Switch#(conf-csm)

So, what’s first? The first thing is setting up the [tag]VLAN[/tag]s. I’ll assume you’ve already got the VLANs set up on the switch part (like you always do to get everything talking). I’m also assuming that you want to use routed processing mode (don’t ask).

The VLANs have to be configured as either server or client — the servers themselves sit on the server VLAN, and the virtual IP addresses sit on the client VLAN (this is where the client comes in to access the service). Let’s look at the client VLAN first. You obviously need to have the VLAN ID. You also need to configure the IP address for that VLAN to put a layer-3 address and a gateway, which is what the CSM uses to send return packets back to the client from the server. It’ll make sense if you think about it for a bit.

Switch#(conf-csm) vlan 1 client
Switch#(conf-csm-vlan-client) description My first client VLAN
Switch#(conf-csm-vlan-client) ip address 10.0.0.1 255.255.255.0
Switch#(conf-csm-vlan-client) gateway 10.0.0.254

Ok, then. Let’s do the server VLAN. You need the VLAN ID and the IP address the same as you did for the client VLAN. The difference here is that you don’t configure a gateway. Whereas the IP address on the client VLAN is just to have a leg into that network, the IP on the server VLAN is generally used as the default gateway for the server on that network. By the way, you don’t have to have the servers on that VLAN directly; the servers simply have to be accessed from that VLAN, so you can put servers a few hops away.

Switch#(conf-csm) vlan 2 server
Switch#(conf-csm-vlan-server) description My first server VLAN
Switch#(conf-csm-vlan-server) ip address 10.0.1.1 255.255.255.0

No problems so far, eh? I hope not because here’s the complicated part. Now we’re going to configure a new load-balanced IP that uses a couple of web servers to server pages. Let’s start with configuring the serverfarm, which is a group of servers that serve the same function.

Switch#(conf-csm) [tag]serverfarm[/tag] WEBFARM
Switch#(conf-csm-sfarm) real 10.0.1.11
Switch#(conf-csm-real) inservice
Switch#(conf-csm-real) real 10.0.1.12
Switch#(conf-csm-real) inservice

I think you can figure out what that config does. Yes, the “inservice” is required. The reals are often referred to as real IPs, or [tag]RIP[/tag]s.

Now we need to configure the vserver, which is an object that includes the virtual IP ([tag]VIP[/tag]), protocol, port, serverfarm, VLAN, etc. This is the main guy and, if you do some more advanced stuff, you’ll have a vserver config longer than the iPhone line. Look first, then I’ll tell you what we’re doing.

Switch#(conf-csm) vserver VIRTSERVER
Switch#(conf-csm-vserver) [tag]virtual[/tag] 10.0.0.11 tcp 80
Switch#(conf-csm-vserver) serverfarm WEBFARM
Switch#(conf-csm-vserver) vlan 1
Switch#(conf-csm-vserver) inservice

It’s pretty easy to see what we’re doing. We’re creating a VIP of 10.0.0.11 that serves traffic sent to TCP/80. When traffic is sent to this VIP on that port, the CSM will round-robin load-balance using serverfarm WEBFARM. We also have told the CSM to only answer requests to this VIP if they come from VLAN 1 (If you don’t include the VLAN line, the CSM will answer on all VLANs that it’s configured to use. In my opinion, this is a design problem and it’s fixed in the ACE.).

Let’s do a quick packet trace to be sure we’re all clear.

You open your browser and ask for the page at http://10.0.0.11. Your packets go through the network and eventually land on VLAN 1. The CSM knows that it needs to answer for it, so it accepts the packet. Since there is an existing vserver on TCP/80, it send the packet to its [tag]SLB[/tag] (server load balancing) algorithms. Through the SLB magic, the CSM picks what server in the serverfarm to use and changes the destination address of the packet to the RIP and passes it on.

On the way back, the RIP sends the packets back to the server VLAN address. The CSM knows that we’re accessing the VIP, so it changes the source address to the VIP and passes it on to the gateway for VLAN 1. The packet eventually lands back on your machine, and you never knew anything happened to the packet along the way.

That’s the basics. We went through and configured the VLANs and a simple vserver. The CSM can do dozens of more things, but that’s for another time.

• Read comments... (1)