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.


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. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:

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

  1. Steve B
    January 10, 2010 at 4:25 pm

    Ours are running 4.1(6) and don’t have a COOKIE_INSERT_EXPIRATION_DATE variable value, it’s just blank. Running config just shows: variable COOKIE_INSERT_EXPIRATION_DATE “”

    Guess leaving it blank equals no expiry date.

    Also do you know seems to be stealing your content? Calls itself a Blog Aggregator but looks like straight theft of content to me!

  2. January 11, 2010 at 7:02 pm

    Interesting, Steve. Did someone set it to null, or did it ship like that? If a cookie doesn’t have an expiry, that means it expires when the browser closes, so you may find some unexpected results – depending on what you’re trying to do with it.

    Thanks for the heads up about the aggregator. I’ve seen them straight up ripping off my stuff, but I haven’t thought much of it. I’m not really sure how to react.

  3. Eric M
    February 2, 2010 at 7:03 pm


    How is a blog aggregator theft? The site has no advertisements and references plus links to Aaaron’s blog. How is there theft when there’s no monetary gain. A blog aggregator aggregates blogs, nothing more. I find it convenient. Aaron can also create summaries in RSS so the entire content isn’t displayed by RSS readers. If he doesn’t want to share his content he should disable RSS (but please don’t 😉 )

  4. February 2, 2010 at 8:03 pm

    It’s all a matter of opinion, I guess. I don’t mind my content elsewhere, but, if I actually made any ad money with this blog, he would be taking away hits and thus cash. On the other hand, that’s my stuff!

    I’ll probably just not worry about it unless it gets out of hand.

Leave a Reply

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