こんにちは！ネットワークの世界へようこそ。
インフラやネットワークの勉強を始めると、次から次へと専門用語が出てきて「うっ…」と頭が痛くなりますよね。でも、一歩ずつ目の前の仕組みを紐解いていけば、決して怖いものではありません。
今回は、ネットワークの現場でベテランエンジニアたちが思わず冷や汗をかくトラブル、「フレームチェックシーケンス（FCS）エラー」を取り上げます。「なんだか難しそうな名前だな…」と思ったそこのあなた、大丈夫です！身近な「郵便配達」に例えながら、一緒に優しく読み解いていきましょう。
—
1. 郵便配達で例える「FCS（フレームチェックシーケンス）」の正体
私たちが普段何気なく見ているWebサイトの閲覧や動画の視聴。これらはすべて、細切れのデータ（パケットやフレーム）が、目にも止まらない速さでネットワークという道路を駆け巡ることで成り立っています。
ここで、ネットワークのいちばん下を支える「物理層（LANケーブルやコネクタなど）」と、その上の「データリンク層（イーサネットなど）」の役割を、「手紙の郵送」に例えてみましょう。
- 物理層：手紙を乗せたトラックが走る「道路」や「橋」そのもの。
- データリンク層：手紙が汚れたり破れたりしないように入れる「封筒」、そして中身が途中でボロボロになっていないかを確かめる「封のスタンプ」。
FCSってなにをしているの？
この「封のスタンプ」や「封筒の隅っこに書かれた計算結果」に相当するのが、今回主役のFCS（Frame Check Sequence）です。
送信側のパソコンは、手紙（データ）を送り出すときに、「この手紙の中身を計算すると、合計値は『123』になるはずだ」というチェック用の数字（これがFCSです）を計算して、封筒の最後にペタッと貼り付けます。
受信側のパソコンに封筒が届くと、こう考えます。
「どれどれ、届いた手紙の中身を自分で計算してみるか…。あれ？ 計算結果が『122』になるぞ？ 送信側が書いたFCSは『123』だから…おっと、途中で手紙の文字がかすれたか、誰かに書き換えられたな！」
これが、FCSエラーの正体です。物理的なケーブルの不調や、近くを走る強力なノイズ（モーターや蛍光灯など）のせいで、流れてきたデータの「0」と「1」のビットが途中でひっくり返ってしまい、計算が合わなくなってしまうのです。
—
2. 物理層のちょっとした傷が、上位層の「大渋滞」を引き起こす
「たかが計算が合わないだけでしょ？ ちょっとくらい大目に見たら？」なんて思うかもしれませんが、ネットワークの世界はそう甘くありません。
FCSエラーを検知した受信側の機器（スイッチやPC）は、冷酷にこう判断します。
「中身が壊れている手紙は信用できないから、今すぐゴミ箱に捨てよう！」
これが、パケットの「破棄」です。
上位層（TCP）のやさしい（けれど厳しい）世界
ここで、もう少し上の階層（トランスポート層）で活躍するTCPというプロトコルの登場です。TCPは、いわば「確実にお届けするよ」がモットーの書留郵便のような仕組みです。
物理層やデータリンク層でFCSエラーによってパケットが捨てられてしまうと、TCPはこう思います。
「あれ？ 送ったはずの手紙の返事（確認応答）が来ないな…。もしかして途中で迷子になったのかな？ もう一回同じ手紙を送るね！」
これが「再送制御」です。
スループットの急降下という悲劇
一見、再送してくれるなら安心のように思えますよね。しかし、ここに大きな罠があります。
1. ボロボロのLANケーブルが原因で、常にFCSエラーが発生する。
2. 送ったデータの半分が途中で捨てられる。
3. TCPが「再送しなきゃ！」と、同じデータを何度も何度も送り直す。
4. 結果として、本当に送りたい新しいデータが道路を走れなくなり、ネットワーク全体が大渋滞（スループットの低下）を起こす。
たった1本の「爪の先ほどの傷がついたLANケーブル」や「緩んだコネクタ」が原因で、会社全体のWebアクセスが劇的に遅くなる……。これが、物理層の不備が上位層のパフォーマンスに与える恐ろしい連鎖反応です。
—
3. 現場でFCSエラーを見つける！Ciscoルータでの確認方法
では、もし現場で「最近なんだかネットワークが重いぞ…」となったとき、私たちはどうやってFCSエラーを見つけ出せばよいのでしょうか？
ネットワークエンジニアの必須ツールであるCiscoルータやスイッチを例に、インターフェースの状態を確認するコマンドを見てみましょう。実務でも本当によく使うコマンドです。
Switch# show interfaces gigabitethernet 0/1
GigabitEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0011.2233.4455 (bia 0011.2233.4455)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/1, lo-load 1/1g
Encapsulation ARPA, loopback not set
Keepalive set (105 packets input, 35 packets output, idr)
Last input never, output never, output hang never
Last clearing of "show interfaces" never
Queue strategy: queuing, output ignored 0 drops, purs, drops
5 minute input rate 12000 bits/sec, 15 packets/sec
5 minute output rate 8400 bits/sec, 10 packets/sec
1254350 packets input, 854320 packets output
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- ここに注目！
142850 input with dribble condition
542 total output errors, 0 drops, 0 output errors, 0, inters:注目してほしいのは、下から数行目の「CRC」や「frame」といったカウンターです。
もしここに、時間が経つにつれて「100」「500」「10000」と数字がモリモリ増えていくようであれば、それは「物理層のどこかでデータが激しく破損している（FCSエラーが起きている）」動かぬ証拠です。
—
4. トラブルシューティングの現場から：私たちエンジニアのアプローチ
FCSエラーの数値が上がっているのを確認したら、ベテランエンジニアたちは次のような手順で原因を特定し、解決へと導きます。
1. 物理的目視チェック
- まずはLANケーブルがしっかりカチッと音がするまで挿さっているか確認します。半刺しはノイズに非常に弱いです。
2. ケーブルの交換（切り分けの王道）
- 怪しいパッチケーブルを、新品の良品ケーブルにサクッと交換します。これでエラーがピタッと止まれば、原因は「ケーブルの劣化や断線」でした。
3. 経路の再確認（SFPモジュールやHUBのポート）
- ケーブルを換えてもエラーが消えない場合は、機器側の差込口（SFPモジュールやスイッチのポート自体）が故障している可能性があります。ポートを変えて様子を見ます。
4. 電磁ノイズ源の特定
- 天井裏や床下で、LANケーブルが強力な電源ケーブルや大型のモーター（空調など）と平行にベタ這いになっていないかを確認し、配線を離します。
—
まとめ：目に見えないレイヤーをつなぐ意識を持とう
今回は、物理層の小さな乱れ（FCSエラー）が、いかにして上位層のパフォーマンスに大きな影響を与えるかを解説しました。
- FCSエラーは、届いたデータが途中で壊れていたことを示す「赤信号」。
- 物理層のノイズやケーブル不良が原因で発生する。
- エラーが起きるとパケットが破棄され、TCPの再送が多発し、結果としてネットワーク全体の大渋滞（スループット低下）を招く。
インフラやネットワークの仕事をしていると、どうしても画面上の設定ファイルやIPアドレス（論理的な世界）ばかりに目を奪われがちです。しかし、すべてのデータは必ず「一本の物理的なケーブル（現実世界）」を通って流れています。
「なんだか最近、通信がもたつくな…」と感じたら、ぜひ今日の話を思い出して、足元のLANケーブルやインターフェースのエラーカウンターに優しく目を向けてあげてくださいね。それではまた、次の技術の旅でお会いしましょう！
コメント