ケースの背景
ある大手グループ会社の県会社の情報イントラネットPCでは、県会社の業務や市会社の業務にアクセスする際、断続的に非常に遅いアクセス接続が発生します。また、イントラネットPCを使用して県会社のDNSサーバーや市会社の公式ウェブサイトのIPに継続的にpingを送信する際、不規則なパケットロスが発生します。遅いアクセス接続は、情報イントラネットの通常のビジネス交流に深刻な影響を及ぼし、特にマーケティング部門が県企業の課金システムサーバーへのアクセスを要求しています。
図1のネットワーク・トポロジー図：
図1 大企業のネットワーク・トポロジー
Kelaiネットワークバック分析システムは、県会社の情報イントラネットのコアスイッチにバイパスされ、障害が断続的に発生するため、県会社から市会社へのバックボーンの出口トラフィックをキャプチャするために長い時間を行う必要があります。また、Kelaiネットワーク分析システムを使用することで、市会社のコアスイッチとCルータ間の下流インターフェイスのトラフィックを途切れることなくキャプチャすることができます。比較分析法を用いて、2箇所からキャプチャされたトラフィックを障害発生時に正確に分析します。
ケーススタディ
I. 輸出フローの分析
Kolaiネットワークバックトラッキング解析システムで通信トラフィックを長期間保存し、障害発生時の通信トラフィックの障害再現を実施。県会社のキャプチャポイントで、障害発生時間帯のデータをバックトラック。4分間の分析ウィンドウを選択すると、バーストトラフィックや通信トラフィック0は見られません。ブロードキャストおよびマルチキャストトラフィックは正常で、TCP SYN比率は正常範囲内。
この時間帯のネットワーク・アプリケーションを分析すると、トラフィック占有率***のネットワーク・アプリケーションは、HTTP、Unknown、Proxyで、これらは通常のビジネス動作です。ネットワークアプリケーションにはCIFSスキャンがありますが、このアプリケーションの通信パケットは少なく、バックボーンリンクの伝送に与える影響はほとんどなく、ネットワークセキュリティインシデントはパケットロスの原因ではありません。
県会社の主要なビジネス標準アプリケーションの監視と結合へのアクセスは、ネットワークリンクの伝送品質は良好で、パケット損失現象によるリンクの輻輳を除いて。しかし、10.176.X.XサーバーにアクセスするクライアントのTCPセッションには98回のTCP再送があり、アップリンクの再送回数は97回です。TCPの再送回数が多いと、セッションの確認が遅れ、セッションの品質に深刻な影響を与えます。TCPの再送回数のほとんどは上りリンクで発生しており、パケットロスの場所は県企業と地方企業の間であることを示しています。
TCPセッションのデコード
アクセス遅延の具体的な原因を特定するために、アプリケーション要求のTCPセッションをデコードします。選択された障害時間帯に、PCホスト10.178.x.xから県内企業の情報イントラネット上の10.176.X.Xにアクセスするアプリケーション通信トラフィックと、ポート2487を使用して10.176.x.xのTCPポート80にアクセスするクライアント10.178.x.xは、ネットワークリンクの伝送品質は良好で、リンクの輻輳はありませんでした。
さらに下方分析を続けると、県会社のキャプチャポイントのTCPセッションのパケット77が271ms後にパケット73のSeq4245726722に再送されており、パケット73が県会社の情報イントラネット・オフィスコアスイッチの出口に到達していることが判明しました。市中企業のキャプチャポイントでは、クライアント10.178.x.xから送信されたパケットSeq4245726722で同じセッションが1回だけキャプチャされていますが、このパケットはSeq4245725830とSeq4245728182の間には出現せず、200ms以上の間隔をあけて1回だけ出現しており、市中企業では再送されたパケットのみがキャプチャされたことを示しています。クライアント10.178.x.x****回が送信したSeq4245726722パケットは、県会社と市会社の間で廃棄されました。
キャプチャした2つのTCPセッションの比較分析を図2に示します：
図2 キャプチャされた2つのTCPセッション
TCPセッションには多数のTCP再送があり、2つのパケットキャプチャポイントでのTCPセッションの比較分析により、パケットロスの原因は県企業と市町村企業間のミドルウェアのネットワーク機器にあると判断。また、全TCPセッションにおいて、クライアントとサーバの応答時間に異常は見られず、これまでのネットワークリンクの伝送品質の解析と合わせ、県営企業から県営企業および市営企業への業務アクセスが断続的に遅延する原因は、ミドルウェアのネットワーク機器によるパケットの廃棄にあると判断しました。
III.故障箇所
トポロジー図によると、県会社から市会社のコアスイッチへの経路は、3台のルータを経由して転送する必要があります。ルータBにアクセスしている障害時間中に、県と市の会社の業務システムにアクセスしている他の地区と県の情報イントラネットPCのTCPセッションをデコードして分析します。3回のハンドシェイク時間は7.9msで、リンクの輻輳はありません。3回のハンドシェイク時間は7.9msで、ネットワークの伝送品質は良好で、リンクの輻輳もなく、TCPセッションのパケットロスや再送もなく、クライアントとサーバーの応答も正常です。クライアントもサーバも正常に応答していることから、障害発生時間帯にアクセスパケット損失が発生したのは、県の企業情報イントラネットのみであることがわかります。従って、障害範囲は県企業→ルータA→ルータBに絞られます。
県会社からルートBまでの各ルーティングインタフェースを1つずつ調べたところ、県会社に接続されているルータAの下りインタフェース光モジュールに、入力方向のCRCチェックサムエラーログが多数存在することが判明。
CRC巡回冗長検査コードのエラーには3つの可能性があります：
1、両側のネットワークカードの作業モードが異なります；
2.リンクチャネルの信号減衰が激しい；
3.ネットワークカードの故障。
光モジュールの動作モードは反対側のルーターAと同じであるため、****の可能性は除外されます。県会社とルーターA間のファイバーチャネルの減衰テスト。2番目の可能性を除外。
CRCチェックサムエラーログは、ルータAと県会社の間の下流インタフェースの入力方向でチェックされ、県会社のルータの上流インタフェースでパケットのCRC巡回冗長チェックサムカプセル化に断続的な障害が発生し、ルータAの下流インタフェースでパケットのCRCチェックサムをデコードする際にエラーが見つかったことを示します。エラーとなったCRCチェックサムパケットは廃棄されます。
IV.トラブルシューティング
県会社からルータAへの光モジュールを交換し、一定時間通信を復旧させた後、ルータAの下りインタフェースを確認し、CRC巡回冗長検査符号の値が増加していないこと。県会社が県市会社の業務システムにアクセスするTCPセッションをデコードし、双方の通信相互作用は正常であり、TCPセッションの統計情報に再送およびパケットロスがないこと。TCPセッションの統計情報に再送とパケットロスがなく、県企業と省市企業間の通信は正常に戻っています。
ケースの結論
1.県企業と市企業の間のリンクトラフィックの値は大きくなく、トラフィックの傾向は不安定です。 2.県企業と市企業の間のビジネス交流のTCPセッションを分析した結果、クライアントのRTT値は正常で、サーバーのRTT値も正常で、リンクの輻輳は見られません；
2、県会社と市会社のパケットキャプチャ分析の比較を通じて、TCPセッションのビジネスの相互作用が深刻なパケットロス現象があることを発見し、場所を特定し、分析した後、県会社の国境ルータの出口の光モジュールは、CRCチェックサムエラーであることがわかりました；
3、郡会社の国境ルータの出口の光モジュールの交換は、CRCチェックサムエラープロンプトは、もはや増加、ビジネスの相互作用のトラフィック解析、パケットロス現象は、正常に戻ってビジネスコミュニケーション。
