CSS や CSM でたびたび発生している 828 日問題について、簡単にまとめておきます。
CSS/CSM は 32 bit VxWorks をベースとしています。
また、VxWorks の clock は 60Hz (1/60秒で1増加) でカウントされています。 この値は、下記 URL にある tickGet() という API を用いることで得ることができます。 例えば、起動後 5 秒後に tickGet() を取得すると 60Hz x 5sec = 300 (0x12c) という値が返ってきます。 CSS や CSM は様々な用途でこの値を参照し動作しています。
http://www.vxdev.com/docs/vx55man/vxworks/ref/tickLib.html
tickGet() は 32bit タイマーであるため、最大値は 2^32 = 4294967296 であり、それを超えると、カウンタがリセットされ 0 に戻ってしまいます。
つまり、下記計算式より 828 日 12 時間経過すると tickGet() で返ってくる値が 0 に戻ってしまいます。
そのため、828 日経過すると様々な問題が発生します。
2^32 / (60Hz x 60sec x 60min x24hr) = 828.5days
CSS が定期的に送信する keepalive を例にしてもう少し説明します。
CSS は死活確認のため、サービスに対してデフォルトで 5 秒おきに icmp パケットを送信します。
CSS 内部では現在の時刻を確認し、それに 5 秒 (0x12c) を足した時間を次に送信する時間としてセット (next_keepalive = tickGet() + 0x12c) します。
例えば、起動後 3600 秒経った時点で keepalive を送信した場合()、次に icmp パケットを送信するのは 3605 秒になります。
tickGet() で値を取得し、その値が 3605 秒よりも大きくなっている (tickGet() > next_keepalive) 場合、keepalive packet が送信されます。
tickGet() の値が 0xfffffff0 の場合、next_keepalive の値は 0x1000011c とセットされますが、tickGet() の最大値は 2^32 = 0xffffffff であるため、それを超えると 0 に戻ってしまいます。
この状態になると、永遠に tickGet() > next_keepalive という条件を満たすことができなくなるため、CSS が keepalive パケットを送信しなくなります。
ベースとなる OS を 32bit から 64bit へ変更するとその上で動作する CSS/CSM も大幅な変更が必要になるため、様々な事情により CSS/CSM では、tickGet() が 0 に戻っても動作し続けるよう、問題が発生したコードを個別に修正/対応することになりました。
そのため、828 日経過すると発生する不具合が多数修正されています。
CSS/CSM 共に修正可能な既知の不具合に関しては修正を行ったものの、根本的な部分を修正しているわけではないため、現在まで報告されていない不具合が残っている可能性がありますが、開発が終了しているため、今後新たに不具合が見つかったとしても、新規不具合修正は行えません。
End of SW Maintenance Releases Date: September 20, 2012
http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/ps792/end_of_life_c51-657403.html
End of SW Maintenance Releases Date: August 26, 2011
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps780/end_of_life_c51-577764.html
潜在的な問題が発生することを回避するため、828 日経過する前に CSS/CSM を再起動することをお勧めします。 (既に 828 日経過し、問題が発生していないユーザは特に再起動の必要はないと思いますが、一部ユーザで新規不具合と思われる報告があったため、リスク回避のため、2 年に 1 回、通信影響の少ない時間帯に再起動することをお勧めします。)
また、解析の結果修正ができないと判断された不具合も報告されています。
これらの問題を回避するためにも、2 年に 1 回程度の再起動をお勧めいたします。
When the CSS has an uptime of 828 days, it cannot send packets to the management port for 18 minutes. This issue affects management port only. The circuit and VIP addresses works fine. We recommend that you reboot the CSS before its uptime is 828 days.
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v8.20/release/note/RN820_X.html#wp223623
When 828 days have elapsed since the CSM was booted, the HTTP probe will fail and will stay in the down state for about 18 minutes. Reboot the CSM before 828 days have elapsed. (CSCso08858)
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csm/4.2.x/release/notes/ol_6897.html#wp274406
