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_GRATUITOUS_INTERVAL 15 ARP_RATE 10 ARP_RETRIES 3 ARP_LEARN_MODE 1 ARP_REPLY_FOR_NO_INSERVICE_VIP 0 ADVERTISE_RHI_FREQ 10 AGGREGATE_BACKUP_SF_STATE_TO_VS 0 COOKIE_INSERT_EXPIRATION_DATE Fri, 1 Jan 2010 01:01:50 GMT ...
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.
Sources:
1: CSCtd31622 *
2: Cisco EOL/EOS for CSM 3.1.x and 4.1.x *
* May require CCO access
https://masto.ai/@aconaway
- Generating Network Diagrams from Netbox with Pynetbox - August 23, 2023
- Out-of-band Management – Useful Beyond Catastrophe - July 13, 2023
- Overlay Management - July 12, 2023
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 http://www.jaluri.com/ seems to be stealing your content? Calls itself a Blog Aggregator but looks like straight theft of content to me!
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.
Steve-
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 😉 )
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.