Getting Something Out of the CSM

Thanks, Clint. I’m trying to get back on track.

Hi, Droudpeyma. Thanks for commenting.

In the serverfarm configuration, there are two lines that deal with NAT — “nat client” and “nat server”. By default, client (source) NATting is off, and server (destination) NATting is on, so the source IP of the connection inbound to the serverfarm does not get changed before it’s passed on to the servers in the farm.

Here’s what the source and destination of the packets are at various steps in the process. Let’s assume the source IP is 12.34.56.78, the VIP is 1.1.1.1, and the serverfarm only has one server with the IP of 2.2.2.2. Assume that no other NATting is done in our little setup.

The packet leaves the client:
S: 12.34.56.78, D: 1.1.1.1
The CSM receives the packet and passes it on to the RIP:
S: 12.34.56.78, D: 2.2.2.2
The packet lands on the server:
S: 12.34.56.78, D: 2.2.2.2
The server generates a return packet:
S: 2.2.2.2, D: 12.34.56.78
The CSM gets the packet and sends it back to the client:
S: 1.1.1.1, D: 12.34.56.78
The client receives the packet:
S: 1.1.1.1, D: 12.34.56.78

Hope that helps. Let me know if it doesn’t.

Hey, David.

I think if you turn off cleint NAT, you should be alright. Just go into your serverfarm for the VIP and do a “no nat client”. After such, you should see the clients appear unNATted.

Thanks for reading, Dhalmar.

The out-of-sync status means that your secondary CSM doesn’t have the same version of the configuration on the primary. I should have put this in my article on configuring fault tolerance, but you can just do a

hw-module csm X standby config-sync

I think that’s the command, but I don’t have a CSM in front of me to verify. I usually just do a

hw c x s c

This command is required to sync the configs between CSMs and forces the current active configuration to replicate to the secondary. That should clear that right up.

Thanks for reading, Eamon. I always appreciate input from the community.

I did some experimentation on a CSM running 4.2(4), and I was not able to recreate what you described. I selected several serverfarms, picked a real in each, and ran the “clear mod csm X conn real A.A.A.A” command on them. The connections to the chosen real cleared, and the rest of the farm didn’t notice anything. I looked through the bugs for the CSM and couldn’t find anything of interest.

Does it happen to any real you try to clear or just a handful?

I don’t know what to tell you, Eamon. It obviously shouldn’t do that, and I can’t find a bug that matches what you’re seeing. There is an upgrade to 4.3(3) on Cisco’s website, but I would open a ticket with the TAC before going down that path.

Let me know how it goes.

Hi, Kashi. Thanks for reading.

I don’t believe you have to enable traps to be able to monitor the state of the CSMs; you can simply query the correct OID to get the information you want. If you want the switch to send a trap when the FT state changes, you would then enable the traps.

Wow…thanks for the kind words, Kashi; that might be the nicest thing anyone has ever said to me over the Internet. I’m always happy to hear someone is getting something out of the blog.

I’ve never tried to enable SNMP traps for the CSM, so I’m just going off of information from the CCO. This page says that the command snmp enable traps slb ft is actually entered in CSM config mode instead of global config mode. I run an older CSM version, so I can’t tell you if it actually works or not.

Did that help?

Yeah. I couldn’t find that command either, Kashi. Even looking at the 4.2.x command reference shows that it should be available, but it’s obviously not. If I get a chance, I’ll drop a note to the TAC to see what’s up with that.

We monitor the CSM status changes with syslog, actually. Every time there’s a state change with probes, RIPs, VIPs, etc., a syslog message is generated and sent to a collector. The collector parses the message and generates an email or an alert in the monitoring system.

They, Kashi. Sorry to take so long to get back with you.

1) On your switch, you should see four GEs on the same slot as your CSM; these are those virtual GEs you mentioned. You should also see a high-number port-channel interface (from 257 to 282 from a quick scan of documentation); this is the port channel group for those virtual GEs. If you want to monitor the traffic to and from the CSM, you would monitor those interfaces.

2) You can use the serverfarm failaction directive to send traffic destined for a failed server to another. I’ve got an article on it here.

3) That’s the only way I know how to do it. There may be an SNMP set command to do it, but I don’t know what that OID would be. Tools like CiscoWorks can send commands to your switch on a schedule. CiscoWorks is expensive, though, butKiwi Cattools can probably do that for you well. Another solution may be the kron directive. I’ve never done it this way, but I’ve found this page that looks to be pretty good.

I hope that helps. Ask more questions as you need them. I love answering questions for people.

Hello again, Kashi.

1) You can monitor those interfaces via SNMP with any SNMP-based tool such as MRTG or Cacti. We use Cacti, and it works great!

2) The failaction tells what to do if a server with an active connection goes out of service. If a server fails and you have a failaction of purge, the CSM sends a RST to the client. An action of reassign will just rebalance that connection without the client knowing anything happened. See my blog article about failaction for some more reading.

3) The hw-module csm X standby config-sync will take up resources, but it is very low-impact. I would have no problem running it every time I make a change to the CSM. You could do a weekly or daily sync if you would like, but you run the risk of failing over to a non-current config if something happens to your primary. As far as I know, there is no auto-sync feature. There may be an SSO-type of config for the whole box, but that may not be what you’re looking to do. You’ve piqued my interest now, and I’ll keep an eye out for an auto-config feature.

As for your second comment, you’re right; the purge is resetting the client connection instead of reassigning it to the other server.

Does that cover your questions?

Hey, Kashi.

The CSM checks the health of the servers in a few different ways. First, it makes sure the RIPs are reachable (that is, do they answer ARP requests). The CSM also monitors the connections for any problems such as RSTs coming from the RIPs. The probes, however, are used to do a lot more in-depth health checking. If you had a probe that checked for TCP/80 connectivity on the server, the CSM would periodically connect to that port and use the information it gathers to determine the health of the server. That way, if IIS died on you and stopped answering requests, the CSM could take that server out of service.

I’ve written an article on CSM probes.

I can field some questions on the FWSM if you would like. How about we take this offline, though, since this is a CSM article. Check the “About” page to find an email addresses where you can reach me.