みなさんこんにちは！ 今日は、ネットワーク機器をセットアップするときに犯す標準的なミスについてお話したいと思います。 コンソールに次のコマンドを入力すると、誰もがコンソールの応答が停止し、地球の反対側の機器（設定したばかり）が応答しなくなったことに突然気づいたときの感覚を誰もが知っていると思います。 その瞬間、呼吸が一瞬止まり、心臓の鼓動がはっきりと聞こえ始めます。 強化された聴力は、完全に鳴り響く電話に完全に焦点を合わせています。 体が収縮し、これが終わりであることを理解します。 もちろん、つぶすことは終わりではなく、あなたが自分自身を運転した状況の英雄的な克服の始まりです。 そして、偉業、あなたの偉業についての物語、そしておそらく同僚からのスタンディングオベーションがあります。 そして最も重要なことは、二度とそれをしないという誓いをもう一度自分に与えることです。 多くの人は、これは彼らについてのものではなく、彼らは、真の専門家はこれを許可していないことに反対します。 これは素晴らしいことであり、私は彼らにとって心から幸せです。 しかし、本当の専門家は生まれておらず、一晩になることはありません。
今日、私はコンソールを備えた若い戦闘機のコースで説明されている状況を検討したいと思いますが、それらを踏んだ後に初めて本当の意味を持ち始めます。 当初は、シスコの機器をセットアップする際にいくつかの特定の間違いに専念したかったのですが、記事を準備する過程で、より一般的な点を検討することにしました。 それらは誰かにとってささいなように見え、誰かが彼がかつてこれをやったことを虚偽に覚え、そして誰かが再び不快な状況に入らないようにそれらを使用するでしょう。
静かにやろう
ネットワークで何かを変更する必要があります。 誰にも警告せずに静かに行うことにしました。 急に持ち運び、再構成を調整する必要はなく、それに時間をかけます。 結局、ネットワーク上で再構成が合意された場合、彼らは最初に、営業時間後にこれらの作業を実行するよう依頼することができます。 そして第二に、ほとんどの場合、小規模な作業でも調整する場合、リスク、時間間隔、以前の作業構成にロールバックするための指示、および新しい構成をテストするための計画を示す詳細な規制を準備する必要があります。 その結果、1つまたは2つのチームを適用するには、多くの準備作業を行う必要があります。 そして、あなたはすぐに設定して忘れることができます。 小さな些細なことを変える必要がある。 しかし、すべての既知の法律に従って、静かな方法で再構成することが常に可能であるとは限りません。 そして、すべてが迅速に発生し、被害者がほとんどいない場合、それは良いことです。 会社のゼネラルディレクターが小規模ネットワークの再構成について知っている場合はさらに悪い。
提言
急がないでください、それを再び計量し、可能であれば、他の人に警告することをお勧めします。 つまり、警告すると、武装を意味します。 そして、すべてがスムーズに進むことを完全に確信していない場合は、作業を最も痛みのない時間に移してください。 そして、仕事が数時間後に行われたとしても、とにかく他の人にそれを知らせる方が良いです。 おそらく、今日誰かが仕事にとどまり、夜遅くまで働くことを決めたのでしょう。
100のトラブル-1回のリセット
自分の能力に完全に自信を持っているあなたは、機器の重要な設定をリモートで変更することにしました。 さらに、デバイスは、私たちの国の遠く離れた美しい街にあります。 このためにそこに行かないでください。 それは可能ですが、当局は理解しませんが。 したがって、私たちはリモートアクセスで自分自身を武装します。 ネットワークの小さな中断が許容される時間を選択します。 接続されています。 クラッツ、クラッツ。 そして、思いがけず、私たちはデバイスへのアクセスを失います。 多くの理由が考えられます：平凡な不注意（ユニットではなくアドレスで私はデュースを示しました）から、この技術やその技術の仕事についての知識が不十分である（まあ、私はそれを読みませんでした、それは皆に起こります）。 問題ではありません。今度は、誰かにデバイスの再起動を依頼する必要があります。 結局、構成を保存することができませんでした。 しかし、デバイスをリモートで再起動しても機能しないことがわかりました。 現在は夜があり、タイムゾーンがまったく異なるため、誰もいません。 朝待つ必要があります。 そして、夜になるとそこから朝が始まります。 一般的に、「悪い頭と体の残りの部分に平和はありません。」
提言
このコマンドを使用して、一定時間後にデバイスを自動的に再起動できます。
cbs-rtr＃10でリロード
*上記の例では、ルーターは10分後に再起動します
何かがうまくいかず、指定した時間後にデバイスにアクセスできなくなった場合、デバイスは再起動し、最初からやり直すことができます。 もちろん、デバイスの再起動が許容される場合にのみ、このコマンドを使用できます。
デバイスの自動再起動をオフにすることを忘れないでください。 そして、それはさらなる作業の過程で小さな驚きになるかもしれません：
cbs-rtr＃リロードキャンセル
今、私はそれをどうしますか
多くの場合、問題を解決する過程で、デバイス上でデバッガーを実行する必要があります（より一般的な「デバッグ」という言葉は後で使用されます）。 特にパンを積極的に処理するデバイス上で実行する場合、必要なデバッグによって多くのメッセージが生成されることがあります。 そのため、最初にターミナルセッションで表示を有効にしてデバッグを開始します。 それで、すぐに間違いを見つけて、すぐに分析したいので。 しかし、その後、コンソールは遅くなり始めます。 前に少し問題があったことを一晩忘れます。 そして、きしみがあれば、大切な「すべてのデバグ」を駆り立てることができるのは良いことです。 さらに悪いことに、ハングできるコンソールの静的な画像しか見ることができません。
提言
デバッグをバッファのみに出力することをお勧めします。 同時に、そのサイズを事前設定します。 それは小さくてはなりません（または、欲しがるすべての行がそこに到達するわけではありません）。
cbs-rtr（config）#logging console informational //コンソールへのデバッグメッセージのロギングを削除
cbs-rtr（config）#logging buffered debugging //デバイスバッファへのデバッグメッセージのロギングを有効にします
cbs-rtr（config）#logging buffered 100000 //バッファサイズを設定します。この場合は100,000バイトです
デバッグからのログエントリが多数ある場合、デバイスにまったく保存されないように、この情報の最も一般的なsyslogサーバーへの転送を構成できます。
cbs-rtr（config）#logging host 10.0.0.1 // syslogサーバーのIPアドレスを指定します
cbs-rtr（config）#logging trap debugging // syslogサーバーへのデバッグメッセージの送信をオンにします
それで、私たちとは何ですか？
ネットワークは、生物のように、常に変化しています。 新しいサービスが表示され、新しい機器が接続され、古いサービスが切断されます。 常にいくつかの変更を加える必要があります。 すべてを覚えることは不可能です。 そのため、デバイスに接続するときに、このルートが一度設定されたものを思い出すだけで多くの時間を失うことがあります。 または、なぜアクセスリスト（ACL）にこの行が必要なのですか。 複数の人がネットワークを管理している場合、状況は悪化します。 それではどうしますか？ 最初の答えは文書化することです。 私は同意しますが、これはどこにもありません。 しかし、実際には、ドキュメントを最新の状態に保つのはどれほど難しいでしょう。 特に詳細な場合。 したがって、妥協案として、デバイス構成自体が「リマインダー」として適しています。
提言
構成内のさまざまなエンティティを設定するプロセスでは、「通話」名を使用することをお勧めします。 たとえば、ルータの外部インターフェイスでin方向にハングするACLを作成する場合、たとえば「FW-OUTSIDE-IN」と名前を付けることができます。 さらに構成を調べて、その名前のACLを見ると、彼がここに住んでいる理由がすぐに明らかになります。 このような名前は、クラスマップ、ポリシーマップ、オブジェクトグループ、ルートマップなどにも使用できます。
2番目のポイント：構成内の特定の行に説明を追加することを忘れないでください。 これは、たとえば次のコマンドを使用して実行できます。
- インターフェース用-説明;
- 暗号マップ用-説明;
- ルートマップの場合-説明。
- ACLの場合、備考。
- 静的ルートの場合、名前。
一時的なものほど永続的なものはありません
問題を解決するときには、さまざまなデバッグを実行し、トラフィックをキャプチャ（キャプチャを使用）、トラフィックをミラーリング（SPAN / RSPAN / ERSPAN）、テストACLを使用などする必要がある場合があります。あなたはちょうどTsiskaのマスターになりました）、すべての時間設定に対処する特定の欲求はありません。 これは、問題との闘いが一度にいくつかの面で起こった場合でも悪化します。 そして、それらの1つでの勝利の栄光では、攻撃に投入されたデバッグ、ケプチャー、その他の手段が存在しない敵と英雄的に戦っている他の面に注意を払うことはできません。 これが何をもたらすかを描くことはあまり価値がないと思います。 少なくともデバイスやネットワーク全体に追加の負荷が発生するまでは、それが最も不適切な瞬間に私たちと対戦する可能性があります。
問題に対処するもう1つの側面は、一時的なルーティングまたはトラフィック処理スキーム、無効化された機能（排除によって問題を特定しようとする場合）などです。
提言
デバッグの無効化、キャプチャ、テストACLおよびその他の一時的な構成の削除を忘れないでください。 問題を検索するときに無効にされたすべての機能を再アクティブ化する必要があります。
再び問題...
ネットワークに障害が発生する場合があります。 はい、それは起こります。 主なことは、頻度を減らすことです。 現時点では、パニックに陥らないようにすることが非常に重要ですが、コールドヘッドの問題を見つけようとします。 理由を十分にすばやく見つければ、この事件はあなたの心理状態に違反することなく、ほとんど結果なしで終わります。 それが機能しない理由を理解し、状況を修正しようとするすべての試みが無駄になることが判明したとき、それは完全に異なる問題です。 この場合、パニック気分は、誤動作が検出されてからの経過時間に正比例して増加します。 同僚からのさまざまな触媒は、できるだけ早くすべてを修正することが非常に重要であることを要求します。そうでなければ、「そうでなければ」という言葉の後に多くのバリエーションがあり、それらはサポートの言葉とはほとんど考えられません。
このような状況での主なことは、トラブルシューティング（トラブルシューティング）のプロセスを構築することであり、どこで痛いのかを推測できるように、あちこちで体系的にねじれようとしないでください。 そのような行動は、人が特定のサイクルに入り、常に同じことをして問題を解決しようとするという事実につながることが非常に多くあります。
提言
最初にトラブルシューティングのプロセスを検討し、段階に分けて特定のアクションスキームを選択することを強くお勧めします（たとえば、下から上に向かって、IOSの物理レベルを確認してから徐々に上昇します）。 さらなるステップを調整するために、得られた結果を絶えず分析することが非常に重要です。 最終的には、少なくとも問題を特定することができます。 さて、それを解決するか、何らかの回避策を考えてください。
新しいことは良いことを意味するものではありません
iOSの交換は一般的な手順です。 何らかの問題を解決するためにそれを行っているか、新しい機能を取得する必要があります。 しかし、常に新しいiOSはより信頼性が高いです。 必要なバグ（バグ）が解決されたiOSを置き換えて、新しいものをプレゼントとして受け取ることがあります。 いわば、「片方は治り、もう片方は不自由になります」。 もちろん、これはそれほど頻繁には発生しませんが、そのような状況に備えておく必要があります。 大規模な参照ネットワークが通常、IOSの特定の参照バージョンを使用することは無駄ではありません。 そして、それらを交換する問題は非常に問題です。
提言
iOSを交換する場合は、デバイスが機能を正しく実行することを確認することをお勧めします。 もちろん、すぐにすべてを確認することはできません。 そして、それは価値がない、そうでなければ少し妄想的に見えるでしょう。 したがって、近い将来このデバイスに問題が発生した場合、その発生の理由の1つが最近のIOSの交換である可能性があるという事実を念頭に置くだけで十分です。
おわりに
ああ、すべてのそのような状況について読んで、すぐに正しく構成し始めるのは素晴らしいことです。 しかし、IT部門では、各ステップの結果を考え始める前に、これらすべてのレーキを何度も踏まなければならないことが非常に多くあります。 その後、自分自身でそれぞれの状況を経験して初めて、それらを将来防ぐことができます。