VSSを使用した魅力的なストーリーの始まりは1年前であり、この投稿で説明されています。
そのため、ちょうど1年後、今年の1月の四半期予防保守で、いつものように、項目「コア掃除機」が作業計画に含まれていました。 ネットワークのコアは、Cisco Catalyst 6509スイッチのVSSペアであることを思い出させてください。
各スイッチには、1つのSUPエンジン720 10GEが搭載されています。
スタンバイシャーシから掃除機をかけることにより、ダスト除去プロセスを開始することが決定されました。 オフにし、掃除機をかけた。 含まれています。 油絵-構成の同期エラーにより、スタンバイシャーシが周期的に再起動しました。
イベントがさらに発展する方法に興味がある場合は、
今回は、ヒロイズムとイニシアチブを示さず、スタンバイシャーシをオフにすることを決定しました。 彼らはそうしました。 主翼で飛行し続けました。 スタンバイシャーシの周期的な再起動中のネットワークパフォーマンスは影響を受けませんでした。 午前中、必要なすべての情報がインテグレーターのテクニカルサポートに送信され、インテグレーターはCisco TACでケースを開き、待機し始めました。 CTACからの応答はすぐに続きました。 周期的な再起動で状況を再現し、スタンバイシャーシがオンのときに次のデバッグを削除するように求められました。
「冗長構成のデバッグ同期バルク」
「冗長性の進行をデバッグする」
夜、デバッグは削除され、CTACに送信されました。 ここでは公開しませんでした。 多くのテキストがあり、ほとんど理解されていません。
CTACは、この動作がDDTSで説明されていると報告しました。
Csctx12231
構成の同期：ACLのPRCの不一致によるバルク同期の失敗
tools.cisco.com/bugsearch/bug/CSCtx12231/?reffering_site=dumpcr
表示するにはcisco.comのアカウントが必要なので、ここに画面を投稿します。
ただし、 12.2（33）SXJ6リリースは「既知の修正済みリリース」としてリストされています。 問題は理解不能です。 「show redundancy config-sync failure prc」の出力に表示されたACLから重複行（ACE）を削除するように依頼されました。
スタンバイシャーシをロードしてみてください。 すぐに質問がありました。CTACからの回答をスクリーンショットで以下に示します。
1.「show redundancy config-sync failure prc」と結論づけたり、重複したACEの削除が正しいことを確認する他の方法で完了したり、これを確認するためにスタンバイを実行する必要がありますか？
2.アクティブシャーシがリブートされた場合、このバグはスタンバイへの切り替えを妨げますか？
3. IOSで重複したACEを追加できない場合がありました。 このようなチェックが実行される場合と実行されない場合（おそらくオブジェクトグループに関連する）のシナリオを明確に理解したいと思います。 どこに特に注意を払い、何を再確認するかを知る必要があります。
その結果、スタンバイをオフにしたアクティブシャーシの構成から重複したACEを削除しましたが、その後「show redundancy config-sync failure prc」の出力は変更されず、スタンバイシャーシをロードしようとしたときにこのチェックが発生することが示されました。 次の技術ウィンドウが計画され、その間にスタンバイシャーシが起動されました。 結論-すべてが起動し、重複したACEに関するメッセージが「show redundancy config-sync failure prc」の出力から消えました。
これですべてが機能するようになりました。状況の繰り返しを防ぐために、ACLの編集に特別な注意を払っています。 IOSのリリースがこのバグから修正済みとしてリストされた理由と、IOSが期限内に重複したACEを許可した理由についての質問については、Cisco TACからの回答をお待ちしています。
CTACからの新しい情報が表示されたら、投稿を更新するか、コメントの登録を解除します。
戦場の皆さんに幸運を！