ロキ・ジョーゲンソンのネットワーク入門
二重通信ミスマッチ【前編】――コンフリクトはなぜ起きるのか
二重通信コンフリクトの原因特定作業を経験したことがないなどというネットワーク管理者はほとんどいないだろう。この問題は、対処するのは難しくないが、問題そのものを特定し、局所化するのは途方もなく難しい。
二重通信のコンフリクトというのは、なかなか厄介な問題だ。この10年間にわたってIPネットワークをさいなんできた二重通信コンフリクトは依然として、パフォーマンス低下の最大の元凶であるようだ。10Mbpsイーサネット時代から引きずっているこの問題は、対処するのは難しくないが、問題そのものを特定し、局所化するのは途方もなく難しい。そして、インタフェースの状態(動作/停止)が時間的に変化し、またネットワークホストがアップデートされたり変更されたりするのに伴って問題が再発する。
二重通信コンフリクト(「二重通信ミスマッチ」ともいう)の原因特定作業を経験したことがないなどというネットワーク管理者はほとんどいないだろう(あるいはイーサネット技術に詳しくない管理者かもしれない)。この問題は、ありとあらゆるアプリケーションに甚大な悪影響をもたらす可能性がある。その症状は非常に一過性のものであり、pingを使っても損失が示されないこともあれば(「ネットワークは「盲人と象」のようなもの」参照)、100Mbpsのネットワークパスで60%以上の損失が発生することもある。一般的には、大量のデータ転送が引き金になることが多く、VLANやQoSを採用していてもVoIPに影響を与える可能性もある。
パフォーマンス低下の最も一般的な原因は、ダウンレベルのNICドライバの使用だが、二重通信問題もこれと同じくらい一般的であり、エンドユーザーエクスペリエンスにはるかに激しい影響を及ぼすケースが多い。NASA(米航空宇宙局)が実施した調査では、障害通知の50%以上が二重通信コンフリクトによるものであることが判明した。Internet2では、二重通信問題を最も一般的な3つの問題の1つに挙げている(残りの2つはTCPバッファの設定ミスとNICドライバの問題)。ベリタス(現シマンテック)のサポート部門が受けたネットワーク依存型製品(NetBackupなど)に関する問い合わせ電話2万件に基づいて行われた2005年の調査では、38%近くがネットワーク問題に起因するトラブルに関するものだった。ネットワークに関連した問い合わせのうち20%がNICドライバの性能不足に起因するものであり、6%近くが二重通信コンフリクトが原因であることが判明した。
オートネゴシエーション機能を使えば解決できそうなものなのに、なぜ、それほど問題になるのだろうか。
ここ10年間に登場したイーサネットNICのほとんどは、ほかのデバイスとの互換性を保証するために、さまざまな速度および二重通信モードを備えている。最も一般的な速度は10Mbps(Ethernet/802.3i/10BASE-T)と100Mbps(Fast Ethernet/802.3u/100BASE-TX)であるが、1000Mbps(Gigabit/802.3ab/1000BASE-T)も一般化しつつある。二重通信モードには半二重方式と全二重方式がある。半二重方式では、デバイス同士が送信と受信の両方向で同じ媒体を共有する(例えば1対の銅線を使用)。全二重方式では、送信と受信で互いに独立した接続を使用する(例えば2対の銅線を使用)。
二重通信コンフリクトの最も単純なケースは、2つのインタフェース(例えば、スイッチ上のポートとワークステーション上のNIC)が、異なる二重通信モード(ただし速度は同じ)に手作業で設定された場合である(図では、スイッチ側は半二重、ワークステーション側は全二重に設定)。
スイッチはワークステーションが送信時には衝突検知機能(CSMA/CD)を用いて送信を回避するのに対し、ワークステーションはスイッチの状態にかかわらず、必要があればいつでも送信を行う。このため、ワークステーションから送信されたパケットがスイッチからのパケットと衝突する可能性がある。衝突が発生した場合、スイッチは再送信を試みるが、ワークステーションは再送信を行わない。
アプリケーションユーザーにとっては、アプリケーションが何の問題もなく動作を開始しても、ネットワークが「遅い」ように感じられる。その典型的な症状は、FTPクライアントが接続を確立して転送を開始したのはいいが、そこから遅々として進まず、比較的小さなファイルを転送するのに何十分もかかるという状況である。この場合、TCPは衝突によるパケット損失を渋滞のせいだと誤って解釈し、転送速度を落とし続けているのだ。
ネットワークレベルでは、双方向トラフィックの比率が増えるのに伴い、二重通信コンフリクトは深刻なパケット損失として顕在化する可能性がある(pingでは、通常は1度に1個のパケットを送信するだけであるため、ほかのアプリケーションが同じリンクを使用しているのでなければ、損失がまったく示されないかもしれない)。スイッチ側のインタフェースは多数の衝突回数(フレーム損傷を引き起こす「遅延衝突」型)を示し、ワークステーション側のインタフェースは多数のCRCエラーを記録する。
これらのインタフェースが正しく構成されていれば、損失が一切なく、設定された速度で動作するだろう。手作業でインタフェースを設定するというのは、技術知識のないユーザーにとっては問題が多く、設定すべきインタフェースが何千個もあるような企業では管理不可能である。このため、速度と二重通信モードの最適な設定をインタフェース自身に選択させるのが望ましい。
オートネゴシエーションが最初から(および状況に応じて)アクティブになるように2つのイーサネットインタフェースが構成されていれば、両インタフェースは相互にネゴシエーションを行って共通の構成を確立しようとする。オートネゴシエーション機能と自動認識機能は、2つのインタフェースがさまざまな状況(一方のインタフェースがオートネゴシエーションの方法を知らない場合も含む)において最適な構成を正しく選択するためのメカニズムを提供する。
自動速度選択(自動認識)機能は基本的に信頼性が高く、障害時には一切接続できなくなる。このため、速度のミスマッチはめったに起きず、仮にミスマッチが起きた場合でも、比較的すぐに分かる。一方、二重通信モード選択のためのオートネゴシエーション機能は信頼性がずっと低く、動作はしていても、特定の条件の下ではパフォーマンスが大幅に低下するような接続状態になることもある。一般的には、この問題の原因はオートネゴシエーション機能それ自体にあるのではない。それよりも、一方のインタフェースがオートネゴシエーションを使用するよう設定されていて、もう一方が特定の速度/二重通信モードに設定されているために、オートネゴシエーションが実質的に無効になってしまうことが原因であることが多い。
オートネゴシエーションプロトコルは、インタフェースがネゴシエーションに失敗した場合には半二重モードに戻るよう要求する。このため、一方が100Mbpsの全二重モードに設定され、他方がオートネゴシエーションに設定されていれば、二重通信コンフリクトが起きるのはほぼ間違いない。この典型的なミスが起きるのは、技術知識のないユーザーが、プリンタなどのイーサネット対応デバイスを追加するためにワークステーションとスイッチの間にハブを取り付けたときなどだ。この場合、IT管理者は、オートネゴシエーションに伴う問題を避けるために、ワークステーションとスイッチの間で固定構成(100Mbps/全二重など)を使用しているかもしれない。すべてのハブは元来、半二重モードで動作するため、ユーザーがハブを追加するだけで二重通信コンフリクトが発生するのである。
「二重通信ミスマッチ 後編」では、二重通信コンフリクトがギガビットイーサネットおよびQoSに与える影響、ならびにオートネゴシエーションのベストプラクティスについて論じる。
本稿筆者のロキ・ジョーゲンソン博士はアパレントネットワークスのチーフサイエンティストで、18年以上にわたりコンピュータ、物理学、数学、科学の視覚化、シミュレーションなどの分野で活躍してきた。クイーンズ大学とマギル大学で計算物理学を専攻。哲学、グラフィックス、教育技術、統計力学、論理学、数論など広範な分野で著作がある。また同氏は、サイモンフレーザー大学で数学の非常勤教授を務めるとともに、同大学でCenter for Experimental and Constructive Mathematics(CECM)を共同設立した。民間部門のパートナーおよび政府機関との緊密な連携の下、ハイパフォーマンスコンピューティングやデジタルパブリッシングなどに関する多数の学術プロジェクトで研究を指導した経験もある。アパレントネットワークスでは、ジョーゲンソン氏はハイパフォーマンス、ワイヤレス、VoIP、アプリケーションパフォーマンスなどに関連したネットワーク研究の責任者を務める。これらの研究の多くは、学術機関やBCネット、テキサスA&M、CANARIE、Internet2などの最先端研究組織との共同で進められている。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー