私が行ったときはおやつ時だったせいか、かなり空いてた。

注文は鶏油じゃい麺白一枚入り。煮卵もつけようとしたが品切れだった。
煮卵を食べられなかったのは残念だったが、昼は行列ができるほどだったそうなので仕方ないか。

麺が旨い。今日の麺は腰がかなり出てた。香りも好み。
スープは油多めだったが、かえって良かった。ダシも効いており、旨い。
シナチクはちょっと太すぎ。あの半分の太さでいい。

漬け物はいい出来だった。
わずかな甘みとさっぱりした酸味の味付けのバランスが良かった。

今日も美味しかった。ごちそうさまでした。

サーバを設置しにとあるデータセンターへ行った。そこで Linux マシン2台がネットワークにつながらないというトラブルに見舞われた。今後、類似のトラブルを招かぬよう、教訓とするためメモしておく。また、このメモを読んだ人がトラブルを疑似体験できるように、結論から書くことはせずに、時系列に沿って書くことにする。

- 現象

Linux マシンは2台。それぞれの IP アドレスは 10.16.50.145/26 と 10.16.50.146/26 が割り当てられている。ネットワークインターフェイスはどちらのマシンも一つのみ。
デフォルトゲートウェイを 10.16.50.129 に設定。
ブロードキャストアドレスは 10.16.50.191 に設定。

この環境で、まずデフォルトゲートウェイ 10.16.50.129 に ping が通らない。
ブロードキャストアドレスに ping -b しても返ってこない。
10.16.50.145 から 10.16.50.146 に ping しても返ってこない。
10.16.50.146 から 10.16.50.145 に ping しても返ってこない。

- 確認したこと

スイッチは Cisco Catalyst 2950。スイッチのポートは 100Base-TX Full Duplex 固定なので、Linux マシンの NIC が 100Base Full 固定になっていることを確認。/etc/modules.conf のパラメータは正しく 100Base Full を指定していた。念のため dmesg でカーネルメッセージを確認したところ、100 Full で Link up していた。

eth0: Intel(R) 8255x-based Ethernet Adapter
Mem:0xfa021000  IRQ:11  Speed:100 Mbps  Dx:Full
Hardware receive checksums enabled

ping のサイズを変えてみる。

ping -s 1000 10.16.50.129

として、パケットのサイズを大きくしてみるが、やはり返ってこない。

/sbin/ifconfig で、ドロップパケットと エラーパケットが発生していないかを確認。どちらも値はゼロ。Full Duplex なのでコリジョンも発生していない。

Catalyst 2950 にログインして確認。ポートは 100Base Full 固定で動作中。ドロップもエラーも発生していない。ICMP パケットは受け取っているようだ。

10.16.50.145 から ping を Catalyst 2950 の管理用アドレスに流しっぱなしにして、ethereal で パケットをキャプチャしてみる。キャプチャ結果で見る限り、パケットは Linux マシンから正常に Catalyst に飛んでいるようだ。しかし、リプライが返ってこない。キャプチャを続けていると、不可解な現象2が起きた。

- 現象2

ping を30秒くらい流しっぱなしにしていると、突如リプライが返ってくる。表示を見ると、シーケンス番号 1から40のリプライが返ってきているが、その次のリプライのシーケンス番号は70に飛ぶ。シーケンス番号だけを見ると、周期的につながったり切れたりを繰り返しているように見える。

- わからない

まったくもって原因がわからない。現象2から察するに、何かタイムアウトを待ってるような気もするが、わからない。こういうときは下のレイヤから疑っていくべきだと思い、ケーブルとスイッチの交換を提案しようとしたとき、担当者の一人が気づいた。「デフォルトゲートウェイのアドレスって、10.16.50.129 で良かったんでしたっけ?」

- 原因判明

データセンターが発行した資料に書かれていたデフォルトゲートウェイのアドレスが間違っていた。
10.16.50.129 ではなく、10.16.50.130 が正しいアドレスだった。これが今回の障害の原因だ。

- 教訓

ネットワークにつながらないときは、もう一度 IP アドレス、サブネットマスク、デフォルトゲートウェイをネットワーク管理者 (ここ重要) に確認しよう。

まったくこんなことで30分以上悩むなんて、もう二度としちゃいけないよなあ。

- 疑問

10.16.50.145 から 10.16.50.146 への ping は同じサブネット内の通信なのに、なんでデフォルトゲートウェイのアドレスが関係あるんだろう?
同じサブネット内だったらブロードキャストアドレスに arp して MAC アドレスを解決しさえすれば、後はそのノードだけで通信ができるはず。

- 疑問への回答と教訓2

ping コマンドが DNS を逆引きしようとしていたようだ。そのため、ローカルの通信でも DNS を引きに行こうとするが、DNS サーバは同じセグメントには存在しない。同じセグメントに存在しないので、ping はデフォルトゲートウェイを経由して名前解決をしようとするが、肝心のデフォルトゲートウェイのアドレスが間違っているため、パケットを渡しても中継されずにタイムアウトしてしまう。今回は素の ping ではなく、逆引きをしない ping -n を使うべきだったのだ。