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.

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.

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.

Sources:

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

*  May require CCO access

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. @aconaway@mstdn.social

More Posts

4 comments for “CSCtd31622 – CSM, Cookies, and the year 2010

Leave a Reply

Your email address will not be published. Required fields are marked *