CSCtd31622 – CSM, Cookies, and the year 2010

It seems that we have another piece of evidence that Cisco doesn’t like the CSM.  From what I’m able to creatively interpret, the software developers didn’t think anyone would be running the CSM for very long, so they set a variable that expires CSM-inserted cookies at 01:01:50GMT on 1 January 20101.  If you’re using cookies to make connections sticky, that means you may see some unexpected results; this shouldn’t affect the web servers’ cookies.

The bug tookit lists 4.3(3) as the “first found in” version, but I’m fairly confident that it exists in every version before 4.3(3).  If you want to be sure you have the bug, you can run the show mod csm # variable command and look for the COOKIE_INSERT_EXPIRATION_DATE value.  It should look something like this.

Switch#sh mod csm 2 variable

variable                        value
ARP_INTERVAL                    300
ARP_LEARNED_INTERVAL            14400
ARP_RATE                        10
ARP_RETRIES                     3
ARP_LEARN_MODE                  1
ADVERTISE_RHI_FREQ              10

The “real fix” is to upgrade to 4.3(3.1) or 4.2(12.1).  Of course that means a reboot of the CSM and an outage and all that.  A workaround includes setting the COOKIE_INSERT_EXPIRATION_DATE variable to some time in the future.  The bug text gives an example of some time in 2020, but any time in the distant future will do.  Assuming your CSM is in slot 2 and you’ve selected 1 Jan 2020 at 00:00:00 for your expiration, you would do this.

Switch(config)#mod csm 2
Switch(config-module-csm)#variable COOKIE_INSERT_EXPIRATION_DATE "Web, 1 Jan 2020 00:00:00 GMT"

That’s much easier than upgrading the CSM, eh?  If you’re still using your CSM by 2020, you can set it again if you want, but you’ll be well past the EOL on that guy (4.1 goes EOL on 13 Oct 20122)

Send any space shuttle launch tickets questions my way.


1: CSCtd31622 *
2: Cisco EOL/EOS for CSM 3.1.x and 4.1.x *

*  May require CCO access