デュプレックスミスマッチの症状と対処|全二重と半二重の違いから解説

  • URLをコピーしました!
目次

はじめに

「リンクは正常にアップしていて ping も通るのに、通信が異常に遅い」。デュプレックスミスマッチは、このような形で現れるため発見が遅れやすい障害のひとつです。原因は、対向する 2 つのインターフェース間でデュプレックス(全二重・半二重)の設定が一致していないことにあり、オートネゴシエーションの仕様を理解していないと、意図せず作り込んでしまうケースがあります。

本記事では、全二重と半二重の違いという基礎から始めて、デュプレックスミスマッチの症状の切り分けと対処手順までを実務目線で整理します。

この記事でわかること
  • 全二重(Full-duplex)と半二重(Half-duplex)の違いと CSMA/CD の仕組み
  • オートネゴシエーションの動作と、片側 auto・片側固定の組み合わせで半二重に落ちる理由
  • デュプレックスミスマッチの症状(late collision と CRC エラー)の切り分けと対処手順

結論を先に述べると、デュプレックスミスマッチが発生した場合、半二重側のインターフェースには late collision が、全二重側には CRC エラーが計上されるという非対称な現れ方をします。この対応関係を知っていれば、show interfaces のエラーカウンタから原因を素早く特定できます。対策は、原則として両側をオートネゴシエーション(auto)に統一することです。

全二重(Full-duplex)と半二重(Half-duplex)の違い

デュプレックス(duplex)とは、1 本のリンク上で送信と受信をどのように行うかを表す通信方式です。両者の違いを整理すると次のとおりです。

項目半二重(Half-duplex)全二重(Full-duplex)
送信と受信片方向ずつ時間を分けて通信両方向を同時に通信
100BASE-TX での帯域送信と受信あわせて最大 100 Mbps送信・受信それぞれ最大 100 Mbps
コリジョン(衝突)発生する発生しない
CSMA/CD使用する使用しない
主な利用場面リピーターハブ接続などのレガシー環境スイッチ接続(現在の標準)

CSMA/CD と半二重通信の仕組み

半二重通信では、複数の機器が同一の伝送路を共有するため、送信が重なると信号の衝突(コリジョン)が発生します。これを制御する仕組みが CSMA/CD(Carrier Sense Multiple Access/Collision Detection)です。動作の流れは次のとおりです。

  1. 送信前に伝送路が使用中でないかを確認する(Carrier Sense)。
  2. 空いていれば送信を開始する。複数の機器が同時に送信を始めることもある(Multiple Access)。
  3. 衝突を検知した場合は送信を中断し、ジャム信号を送出して衝突を全機器に通知する(Collision Detection)。
  4. ランダムな待ち時間の後に再送する。

一方、全二重通信は送信と受信で伝送路(信号線のペア)が分離されたポイントツーポイント接続を前提とするため、そもそも衝突が発生せず、CSMA/CD 自体が不要になります。

参考: Troubleshooting Ethernet Collisions(Cisco)
“In full-duplex Ethernet, collision detection is disabled.”
(全二重イーサネットでは、コリジョン検出は無効化されている)
https://www.cisco.com/c/en/us/support/docs/interfaces-modules/port-adapters/12768-eth-collisions.html

この「半二重ではコリジョンが正常動作の一部である」という点は、後述するデュプレックスミスマッチの切り分けで重要になります。半二重側でコリジョンが計上されること自体は異常ではなく、異常のサインとなるのは late collision(フレーム送信開始から 512 ビット時間を超えて検出された衝突)です。詳細は「デュプレックスミスマッチの症状と発生条件」のセクションで解説します。

現在のイーサネットで半二重が残る場面(実質レガシーである理由)

現在のネットワークでは、機器同士がスイッチを介したポイントツーポイントで接続されるため、全二重が事実上の標準です。半二重が登場するのは、次のような限られた場面です。

  • リピーターハブ(共有型 HUB)を使用している環境。ハブは CSMA/CD を前提とした半二重のみをサポートする。
  • 10BASE-T / 100BASE-TX 世代の古い機器や、一部の組み込み機器・産業機器との接続。
  • オートネゴシエーションの失敗により、意図せず半二重にフォールバックしたリンク(次セクションで解説)。

規格の面でも、半二重はレガシーな位置づけになりつつあります。1000BASE-T では半二重モードが規格上定義されているものの対応する実装はほとんど存在せず、2.5G / 5G / 10GBASE-T では全二重のみが定義されています。つまり、現在のネットワークで半二重リンクを見かけた場合、それは「設計されたもの」ではなく「オートネゴシエーション失敗の結果」である可能性をまず疑うべき状態です

オートネゴシエーションの仕組み

オートネゴシエーションは、対向する 2 つのインターフェースが速度とデュプレックスを自動決定する仕組みです。便利な機能ですが、「片側だけ auto、もう片側は固定」という組み合わせで半二重に落ちる仕様を理解していないと、デュプレックスミスマッチを意図せず作り込むことになります。

FLP バーストによる速度とデュプレックスの決定

オートネゴシエーションでは、FLP(Fast Link Pulse)バーストと呼ばれるパルス信号を使い、互いに対応可能なモード(速度・デュプレックス)を通知し合います。双方の能力を突き合わせた後、両者が共通して対応するモードのうち、次の優先順位で最上位のものが選択されます。

  • 速度が高いモードを優先する。
  • 同じ速度であれば、半二重より全二重を優先する。

このため、両側が auto であれば、双方が対応する最良のモード(例: 1000 Mbps・全二重)に自動的に収束します。

片側 auto・片側固定で半二重にフォールバックする理由

問題は、片側のインターフェースに速度・デュプレックスを固定設定した場合です。多くの機器では、固定設定を行うとオートネゴシエーション自体が無効化され、FLP に応答しなくなります。このとき auto 側は、parallel detection(並列検出)と呼ばれる代替手段に移行します。

parallel detection では、受信信号の電気的特性から相手の「速度」は判別できますが、「デュプレックス」を知る手段がありません。そのため IEEE 802.3 の規定に従い、auto 側は安全側の既定値である半二重を選択します。結果として、固定側が全二重・auto 側が半二重という、デュプレックスミスマッチの典型パターンが完成します。

設定の組み合わせと結果を整理すると次のとおりです。

機器 A の設定機器 B の設定結果
autoauto双方が対応する最良のモードに収束(正常)
100 Mbps・全二重(固定)100 Mbps・全二重(固定)全二重で一致(正常。ただし後述の理由で現在は非推奨)
100 Mbps・全二重(固定)autoA は全二重、B は半二重となりミスマッチが発生
100 Mbps・半二重(固定)auto双方半二重で一致(正常。ただし帯域は半二重相当)

かつては「オートネゴシエーションは実装差異による不具合が多いため、重要リンクは両側固定が安全」という運用が広く行われていました。初期の IEEE 802.3u(1995 年)時代にベンダー間の相互接続性問題が実際にあったためです。しかしこの「固定運用」こそが、設定変更漏れや機器リプレース時のミスマッチを生む温床となってきました。

1000BASE-T 以上でオートネゴシエーションが必須である理由

現在、この「固定が安全」という考え方は規格レベルで成立しなくなっています。1000BASE-T では、リンク両端の PHY 間で MASTER / SLAVE 関係(クロック同期の役割分担)を決定する必要があり、この決定はオートネゴシエーションによって行われるためです。IEEE 802.3 Clause 40.5.1 では次のように規定されています。

参考: IEEE 802.3 Clause 40.5.1(IEEE 802.3 Interpretation より)
“All 1000BASE-T PHYs shall provide support for Auto-Negotiation (Clause 28)”
(すべての 1000BASE-T PHY はオートネゴシエーション(Clause 28)のサポートを提供しなければならない)
https://www.ieee802.org/3/interp/interp-2-0705.pdf

10GBASE-T でも同様にオートネゴシエーションは必須です。機器によっては 1 Gbps 以上でも speed / duplex を固定「設定」できる場合がありますが、これは実際にはオートネゴシエーションを止めているのではなく、アドバタイズする能力を絞っているだけであることが一般的です。つまり 1000BASE-T 以上のリンクにおいて、オートネゴシエーションは「使うかどうかを選ぶもの」ではなく前提となる仕組みであり、「固定が安全」は 10 / 100 Mbps 時代の古い常識と言えます。

デュプレックスミスマッチの症状と発生条件

デュプレックスミスマッチの厄介な点は、リンクがアップし少量の通信は成立してしまうことです。ここでは、切り分けの鍵となるエラーカウンタの非対称性と、発見が遅れやすい理由を整理します。

半二重側は late collision、全二重側は CRC エラー

ミスマッチ発生時、両側のインターフェースには次のメカニズムで異なるエラーが計上されます。

  1. 全二重側は、受信中であっても構わずフレームを送信する(全二重では衝突という概念がないため)。
  2. 半二重側は、自分の送信中に受信が発生すると「衝突」と判断し、送信を中断・再送する。このうちフレームの先頭 512 ビット時間を超えて検出された衝突が late collision として計上される。
  3. 半二重側が中断したことで生じた不完全なフレーム断片を、全二重側は受信エラー(CRC / FCS エラーや runts)として計上する。

この結果、エラーの現れ方は次のように非対称になります。

インターフェース計上される主なエラー
半二重側late collision の増加
全二重側CRC(FCS)エラー、runts の増加

「片側で late collision、対向側で CRC エラーが同時に増えている」場合、デュプレックスミスマッチをまず疑うのが切り分けの定石です。なお、正常な半二重リンクでも通常のコリジョンは発生するため、コリジョンカウンタ単体では異常と判断できません。正常なイーサネットでは発生しないはずの late collision が判断基準となります。

ping は通るのに遅い、が発見を遅らせる

デュプレックスミスマッチは、リンクの物理的な接続判定(リンクパルスの検出)とは無関係に発生します。つまり、デュプレックスが不一致でもインターフェースのステータスは connected / up のままです。

参考: Configure and Verify Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation(Cisco)
“The status can be connected even if duplex is incorrectly negotiated or incorrectly configured.”
(デュプレックスが誤ってネゴシエートまたは設定されていても、ステータスは connected になり得る)
https://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/10561-3.html

さらに、ping のような低頻度・小サイズの通信は、送受信のタイミングが重なりにくいため正常に応答が返ります。症状が顕在化するのは、ファイル転送やバックアップなど双方向のトラフィックが増えたときで、衝突と再送の多発により実効スループットが大きく低下します。「リンクは正常、ping も通る、しかし転送だけが異常に遅い」という報告があった場合は、経路上のリンクのエラーカウンタを確認することを推奨します。

デュプレックスミスマッチの切り分けと対処手順

ここでは、Cisco 機器を例にエラーカウンタと CDP ログによる切り分け手順を整理し、あわせて対向となることが多いサーバー・PC 側(Linux / Windows)の確認方法をまとめます。

Cisco: show interfaces のエラーカウンタと CDP ログ

まず、対象インターフェースの現在のデュプレックスと速度を確認します。show interfaces status の出力では、a- プレフィックス付きの値(a-fulla-100 など)はオートネゴシエーションで決定されたことを示します。

Switch# show interfaces status
Port      Name   Status       Vlan       Duplex  Speed Type
Gi1/0/1          connected    10         a-full  a-1000 10/100/1000BaseTX

次に、show interfaces でエラーカウンタを確認します。前セクションで整理したとおり、着目するのは late collision と CRC です。

Switch# show interfaces GigabitEthernet1/0/1
(省略)
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
(省略)
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
  • 自装置側で late collision が増加 → 自装置側が半二重、対向が全二重の疑い。
  • 自装置側で CRC(および runts)が増加 → 自装置側が全二重、対向が半二重の疑い。

カウンタは過去からの累積値のため、clear counters で一度リセットし、トラフィックを流しながら増加傾向を観察すると判断しやすくなります。

また、Cisco 機器同士の接続で CDP が有効であれば、ミスマッチ検出時に次のログが出力されます。

%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/1 (not full duplex), with R1 Ethernet0/0 (full duplex).

注意点として、CDP はミスマッチを「検出して通知する」だけであり、設定を自動修正するわけではありません。また、CDP が無効な環境や対向が Cisco 以外の機器(サーバーの NIC など)の場合はこのログに頼れないため、エラーカウンタの非対称性による切り分けが基本となります。エラーカウンタの詳細は Cisco 公式ドキュメント(https://www.cisco.com/c/en/us/support/docs/interfaces-modules/port-adapters/12768-eth-collisions.html)を参照してください。

なお「リンクは正常なのに転送だけ遅い」という症状は、デュプレックスミスマッチのほかに MTU / MSS の不整合でも発生します。切り分けの際は、詳細は関連記事『MTU / MSS 一覧と確認方法』あわせて参照してください。

Cisco: speed / duplex 設定の確認と修正

対処の基本は、両側のインターフェースをオートネゴシエーション(デフォルト設定)に戻すことです。Cisco Catalyst スイッチでは speed / duplex の auto がデフォルトのため、interface 配下の固定設定を削除すれば auto に戻ります。

Switch# configure terminal
Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# speed auto
Switch(config-if)# duplex auto
Switch(config-if)# end

設定時の注意点は次のとおりです。

  • speed が auto の場合、duplex を手動設定できない機器があります(duplex は speed に従属するため)。
  • レガシー機器との接続などでやむを得ず固定する場合は、必ず両端をセットで同一設定にすること。片側だけの固定が、前述の半二重フォールバックによるミスマッチの典型原因となります。

また、近年の Catalyst(IOS XE)では、速度のネゴシエーション対象に 1 Gbps 以上が含まれる場合、そもそも半二重を設定できない旨のエラーが返されます。半二重が 100 Mbps 以下に限定された機能であることが、CLI の挙動にも反映されています。

Switch_1(config-if)# duplex half
% Duplex cannot be set to half when speed autonegotiation subset contains 1Gbps,2.5Gbps,5Gbps or 10Gbps

本セクションの設定・出力例は Cisco 公式ドキュメント(https://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/10561-3.html)に基づいています。

Linux(ethtool)と Windows での確認方法

ミスマッチの片側はスイッチ、もう片側はサーバーや PC の NIC であるケースが多いため、ホスト側の確認方法も押さえておくと切り分けが速くなります。

Linux の場合

ethtool コマンドで、現在のリンク状態を確認できます。

# ethtool eth0
Settings for eth0:
(省略)
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
(省略)
        Link detected: yes

確認するポイントは SpeedDuplexAuto-negotiation の 3 行です。Duplex: Half となっている場合、対向の固定設定によるフォールバックを疑います。設定を変更する場合は -s オプションを使用します。

# 100 Mbps・全二重に固定する場合(オートネゴシエーションを無効化)
# ethtool -s eth0 speed 100 duplex full autoneg off

# オートネゴシエーションに戻す場合
# ethtool -s eth0 autoneg on

参考: ethtool(8) — Linux manual page
“autoneg on|off Specifies whether autonegotiation should be enabled.”
(autoneg on|off: オートネゴシエーションを有効にするかどうかを指定する)
https://man7.org/linux/man-pages/man8/ethtool.8.html

なお、ethtool -s による変更は再起動で失われるため、恒久的に設定する場合は NetworkManager(nmcli)などディストリビューションのネットワーク設定に反映する必要があります。また、仮想マシンやクラウド環境の仮想 NIC では速度・デュプレックスの変更がサポートされないことが一般的です。

Windows の場合

GUI では、デバイスマネージャー > 対象のネットワークアダプター > プロパティ > 詳細設定タブ内の「Speed & Duplex」(ドライバーにより「リンク速度とデュプレックス」等、名称が異なる場合があります)で確認・変更できます。

PowerShell では、次のコマンドレットで現在のリンク速度とデュプレックスを確認できます。

# リンク速度と全二重かどうかの確認
Get-NetAdapter | Select-Object Name, Status, LinkSpeed, FullDuplex

# Speed & Duplex の設定値と選択可能な値の確認
Get-NetAdapterAdvancedProperty -DisplayName "Speed & Duplex" |
    Format-List DisplayName, DisplayValue, ValidDisplayValues

設定変更は Set-NetAdapterAdvancedProperty で行います。-DisplayValue に指定できる値は NIC ドライバーに依存するため、事前に ValidDisplayValues の確認を推奨します。コマンドレットの仕様は Microsoft Learn(https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapteradvancedproperty)を参照してください。

設計上の推奨: auto を基本とし、固定設定は例外に限る

ここまでの内容を設計方針として整理すると、現在のネットワークでは「両側 auto」を標準とすることを推奨します。理由は次のとおりです。

  • 主要ベンダーの機器・OS はいずれも auto がデフォルトであり、ベンダー各社も IEEE 802.3u 準拠機器間ではオートネゴシエーションの使用を推奨している。
  • 1000BASE-T 以上ではオートネゴシエーションが規格上の前提であり、「固定運用」という選択肢自体が実質的に存在しない。
  • 固定設定は「設定した時点」では正しくても、機器リプレースや NIC 交換の際に片側だけ auto に戻り、ミスマッチが再発する運用リスクを抱え続ける。

固定設定を検討するのは、オートネゴシエーションに対応しないレガシー機器・産業機器との 10 / 100 Mbps 接続や、ベンダーから明示的な指示がある場合など、例外的なケースに限定することを推奨します。その場合も、両端をセットで固定することと、構成管理台帳や作業手順書に固定リンクである旨を明記しておくことが、将来の事故防止につながります。

また、ミスマッチは発生してから気づくのではなく、late collision と CRC エラーのカウンタを監視項目に含めておくことで早期検知が可能です。L2 設計全般の考え方については、関連記事『STP の仕組みと設計』もあわせて参照してください。

まとめ

デュプレックスミスマッチは、リンクがアップし ping も通るため発見が遅れやすい障害です。切り分けの核心は、半二重側と全二重側でエラーの現れ方が非対称になる点にあります。対策は原則として両側をオートネゴシエーションに統一することであり、固定設定は例外的なケースに限定するのが現在の設計指針です。

  • 半二重は時分割で送受信し CSMA/CD を使う通信方式
  • 全二重は送受信を同時に行い衝突が発生しない通信方式
  • 片側 auto・片側固定では auto 側が半二重に落ちてミスマッチが発生
  • 半二重側は late collision、全二重側は CRC エラーが増加
  • ping は通るが双方向の転送でスループットが大きく低下
  • 対処の基本は両側をオートネゴシエーションに統一すること
  • 1000BASE-T 以上ではオートネゴシエーションが規格上の前提

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次