Super-Networking Blog

So if you want to limit one or more of your real servers in a virtual server farm to a certain amount of connections you can do it with the “maxconns” command.

Login to the CSM go into config mode, go into the serverfarm you want to restrict then go into the real server. Type in “maxconns #” replacing the # with the max connections you want to go to that real server. This way if you want to test something under real traffic but don’t want it to get slammed you can.

Also if you specify this command it will send out a syslog when the max has been reached.

%CSM_SLB-6-RSERVERSTATE: Module # server state changed: server X.X.X.X:0 in serverfarm ’serverfarm’ has reached configured max-conns

The CSM will then send the rest of the traffic to the other real servers in that serverfarm.

First you need to know what module your CSM is in, most of you know I am sure but otherwise use this at the enable prompt:

“show module”

Next you need to session into the CSM with the following command replacing the slot number with the module number you found using the command above:

“sessions slot 1 processor 0″

Finally you need to tftp the core dump file off of the CSM with the command:

“tftp core_dump tftp-ip-addr”

You need to replace the tftp-ip-addr with the IP of your TFTP server. Also if you have multiple core dump file you can put the name of the file you want to tftp after tftp-ip-addr.

I have been working on setting up a test for one over our load balanced webservers to be placed behind the new firewall we have installed. With putting this server behind the firewall I am also switching that webserver to use one-armed mode for load balancing.

Basically the main thing with one-armed CSM configs is that you put the MSFC as the default gateway for your load balanced servers instead of the CSM. You then put a PBR on the MSFC to point load balanced traffic to the CSM, all other traffic bypasses the CSM without having to add static routes on the servers.

Here is a couple of things you need to add for server originated connections in the One-Armed mode.

serverfarm FORWARD

no nat server

no nat client

predictor forward

vserver CATCHALL

virtual 0.0.0.0 0.0.0.0 any

vlan #

serverfarm FORWARD

persistent rebalance

Be careful when using the “variable ROUTE_UNKNOWN_FLOW_PKTS 2” this can cause issues with some server originated connections.

Here is a document on the subject of FWSM and CSM in One-Arm Mode.

I have been working lately on setting up a new design on our CSM. It currently is running in bridged mode and all of our servers need routes on them to function correctly. The default gateway on the servers in the CSM and any internal traffic you want to work needs a route on the server. This is one of my pet peeves, I completely disagree with having routes on the servers. For one if it a pain when you add a new subnet and you need to add a router to 100 servers and the other is the reason you have routers is to route!

So unlike the currently design One-Armed routed mode sends all traffic to the MSFC or “router” and only seems load balanced traffic through the CSM, this is done without routes on the servers. So the servers have a default route of the MSFC and through the use of route-maps decides if the traffic needs to be routed through the CSM. Two of the best benefits to this method is that it gets rid of excess traffic going through the CSM and it takes away the needs of routes on the servers.

Here is a document from Cisco that will help you when putting this method into place. This will not work for everyone’s situation but is a good starting point. One thing that I had to modify in this design is I had to change my route map to change “ip next-hop” instead of “ip default next-hop”. The reason for this is that the ip default next-hop basically assigns a new default route and will only take affect if the router doesn’t have a route for that IP address the server is trying to go to. If you use BGP on the same router this traffic is going through the default route will have little effect, in a BGP situation where you have routes to the majority of subnets the default route is used very little. How I got around this is as follows.

route-map server-client-traffic-CSM permit 10
match ip address 1
continue
set ip default next-hop X.X.X.1
route-map server-client-traffic-CSM permit 20
match ip address 2
set ip next-hop X.X.X.2

This first route-map points to access-list 1 which I tell it to look for any traffic from the load balanced servers to an internal IP. It then switches the default gateway to the regular default-gateway. This route-map is to weed out internal non load balanced traffic. The continue key work tells it to continue to the next route map if it doesn’t match current one. In the second route map it points to access-list 2 and in access-list 2 I tell it to watch for any traffic coming from the load balanced servers going to anywhere not internal and set next-hop to the CSM.

The other tricky part to this setup is the server initiated traffic which you don’t want going through the CSM but is going external so it matches the 2nd route map. A side effect to this is a routing loop between the CSM and the MSFC for server initiated traffic. How I got around this is to nat the real server in the CSM and on the MSFC. What happens then is the real server sends out traffic to say get windows updates to the MSFC, the traffic matches the 2nd route-map, goes to the CSM, the CSM nats it and sends the traffic to the MSFC which sends the traffic to the Internet, the traffic comes back to the MSFC and goes straight to the server bypassing the CSM. This config is working well so far but I am still testing and tweaking it.

Here is a nice little config extra for your Cisco Content Switch Module or CSM. Basically what this will give you is whatever partial URL you put in the match statement, when sent to your vserver will be redirected to whatever URL you put in the webhost relocation statement. In the match statement do not put the full http://domain.com/etc…. because it will not work. If you just put in everything after the domain then your DNS will point that traffic to your vserver anyways. Questions about this just comment on this post.

policy TEST
url-map TEST
serverfarm TEST_REDIRECT

serverfarm TEST_redirect
nat server
no nat client
redirect-vserver TEST-RD
webhost relocation http://domain.com/redirected.html
inservice

vserver TEST-VS
virtual X.X.X.X tcp www
serverfarm TEST-SF
persistent rebalance
slb-policy TEST
inservice

map TEST url
match protocol http url “*original.html*”

Sometimes it is quite hard to find info on the Cisco CSM Load balancer module so as I find info I try to post here for others.

Latest thing I was looking into was persistent rebalance. I new it was a good thing and it is enable by default but I am not a default kind of guy so I try to looking to setting to see what they are for and it the default is right in all situations. It the case of persistent rebalance I believe that it is. Normally what I had seen on this is just persistent rebalance allows for support of HTTP 1.1 persistence. My question was do you need this persistence if the content you are serving is just static content like pictures. The answer is yes and below is the reason why.

The CSM allows HTTP connections to be switched based on a URL, cookies, or other fields contained in the HTTP header. Persistent connection support in the CSM allows for each successive HTTP request in a persistent connection to be switched independently. As a new HTTP request arrives, it may be switched to the same server as the prior request, it may be switched to a different server, or it may be reset to the client preventing that request from being completed.

As of software release 2.1(1), the CSM supports HTTP 1.1 persistence. This feature allows browsers to send multiple HTTP requests on a single persistent connection. After a persistent connection is established, the server keeps the connection open for a configurable interval, anticipating that it may receive more requests from the same client. Persistent connections eliminate the overhead involved in establishing a new TCP connection for each request.

HTTP 1.1 persistence is enabled by default on all virtual servers configured with Layer 7 policies. To disable persistent connections, enter the no persistent rebalance command. To enable persistent connection, enter the persistent rebalance command.

So basically you are saving on TCP connection overhead by having this in place, always good to know exactly what the setting does not just that it is a default setting.

I am going to be blogging about Load balancing in the quite a bit in the near future. I will try to go in depth on different subjects as time allows but to start will a couple of links to some devices you might want to look into. If you want to load balance network devices in a single datacenter such as web servers, firewalls or VPN you can buy a Cisco device called a CSS or Content Services Switch. This device will load balance your network devices by setting up VIPs or Virtual IPs that you point your traffic to and the CSS will load balance to real servers. If you have a 7600 series router then you can buy this same device in Blade form. This load balancer is called a CSM or Content Switch Module.

The above is great for load balancing devices in a datacenter but what if you need to take this to the next level. If you want to load balance to multiple geographically diverse datacenters you can buy a Cisco GSS or Global Site Selector Appliances. This devices basically replaces your DNS servers and is able to load balance and failover DNS resolutions to different datacenters. This device talks to your CSS or CSM and determines not only if the resource is up but can track which datacenter is busier and even which datacenter is closest to the client’s request. I will blog more in detail at a later date on both of these platforms.