回答:
質問に順番に対処するには：
デュプレックスの不一致が発生する理由を完全に理解するには、テクノロジーがどのように進化したかを理解する必要があります。
元々、すべてのイーサネットは半二重でした。全二重が登場したとき、誰か（特に半二重デバイスと全二重デバイス）は、通信方法と自動ネゴシエーションも入力する方法について合意する必要があると賢明に判断しました。
ただし、これらの古い半二重デバイスは自動ネゴシエーション用に設計されていなかったため、標準が作成されたとき、自動ネゴシエーションデバイスは、相手側がネゴシエーションに参加しなかった場合に、それが実行されると想定していました。反対側のデバイスは半二重のみに対応する必要があるため、半二重モード。
他の人が指摘したように、自動ネゴシエーションは早い段階で常にうまく機能するとは限らなかったため、多くのデバイスは静的な速度とデュプレックス設定（多くの場合100 /全二重）で構成され、ネゴシエーションデバイスがそのようなデバイスに接続されている場合、デュプレックスは不一致が発生します。
この問題に関しては、デュプレックスのミスマッチは、半二重モードで実行するよりもはるかに悪い場合があります。これは、一方の側（全二重）が、現在受信中であっても、いつでも送信できると考えているためです。半二重側はこれを衝突と見なしてバックオフし、全二重側は送信を続けます。
全二重側が大量のデータを送信する傾向がある場合、送信前にメディアがクリアされるのを待っているため、半二重側が「枯渇」し、フレームがキューに入れられ、最終的にドロップされます。
全体として、あるべき悪い状況であり、修正すべき状況です。
不一致の検出に関しては、エラーを探すことができます。全二重側では、通常、多くのラントがあり、多くの場合CRCエラーが発生します（ベンダーによっては、異なる用語が使用される場合があります）。半二重側では、衝突やバッファ障害が頻繁に発生します。まともな管理システムであれば、予想よりも多くのエラーを生成しているインターフェースのリストを提供できるはずです。
最近最も一般的な原因は、一方のシステム（ネットワークまたはエンドデバイス）が手動で構成され、もう一方のシステムが自動であるリンクです。
初期の自動ネゴシエーション（全二重10Mbおよびファストイーサネット）では、デバイスが正しくネゴシエーションに失敗することは珍しくありませんでした。
このため（およびその他の慣性に関連する理由により）、多くの大企業およびSPネットワークでは、一部またはすべてのリンクを手動で構成する必要がありました。
最近はこれを行う正当な理由はなく、実際にはギガビットイーサネット（少なくとも銅）では自動ネゴシエーションが必要であり、正常に動作するデバイスでは無効にすることができません。これは明確でない場合があります。たとえば、一部のCiscoキットでは、ギグリンクで自動ネゴシエーションを「無効にする」と、自動ネゴシエーションプロセスで許容される値が制限されるだけです（予期しないインターフェイス速度で警告しない場合に役立ちます）。 ＆デュプレックス）。