【入門編】 ICMPラテラルレートリミット（Rate Limiting）が診断に与える影響と対策 – トラブルシューティング＆ネットワーク運用監視実践ガイド

「pingが届かない！」その犯人はルーターの“お節介”かも？ICMPレートリミットの正体

ネットワークエンジニアの皆さん、こんにちは。現場で叩き上げられてきたNOCのシニアエンジニアです。

皆さんは、こんな経験はありませんか？
「サーバーの設定は完璧なはずなのに、pingを打つとたまにパケットがロスする」「tracerouteを走らせると、途中のルーターが * * * となって詳細を教えてくれない」。

画面を睨みつけ、設定ファイルを見直し、深夜のデータセンターで頭を抱える……。その苦労、痛いほど分かります。でも、実はその犯人、「ネットワーク機器のセキュリティ機能によるお節介」かもしれません。

今日は、初心者エンジニアが必ず一度はハマる「ICMPレートリミット（通信制限）」について、現場の知見を交えて優しく解説します。

—

そもそも「ICMP」と「レートリミット」って何？

まず、身近な例で考えてみましょう。

ping は「郵便物」を送って「返事（応答）」を待つ仕組みです。あなたが手紙を出せば、相手が「届いたよ！」と返してくれる。これが正常な状態ですよね。

しかし、もしあなたが1秒間に1,000通もの手紙を送りつけたらどうなるでしょう？相手は返事を書くのに忙殺されて、本来の仕事（Webサイトの表示など）ができなくなってしまいますよね。

ルーターやファイアウォールといったネットワーク機器は、自分を守るために「一定時間内に返事をするのは、せいぜい10通まで。それ以上は無視するぞ！」というルールを持っています。これが「レートリミット（通信制限）」です。

なぜこれが診断を邪魔するのか？

traceroute は、宛先までの一歩一歩のルーターに対して「お前は誰だ？」と聞くツールです。もしルーターが「こいつ、短時間に聞きすぎ！無視！」と判断したら、診断結果には * * * （タイムアウト）と表示されます。これが、初心者エンジニアが「回線が途切れている！」と勘違いする最大の原因です。

—

現場で遭遇する「見えない敵」との戦い方

では、実際に現場でどう切り分けるべきか。まずは状況を確認するためのコマンドを整理しましょう。

1. ping のロスを冷静に分析する

単に ping を打つだけでは、一瞬のロスは見逃してしまいます。少し長めに、そして間隔をあけて様子を見るのが基本です。

# -c 100 で100回送る。-i 1 で1秒間隔にする（急かさないのがコツです）
ping -c 100 -i 1 192.168.1.1

もし、これで「たまに1〜2パケットロスする」程度なら、それは回線障害ではなく、機器が「ちょっと忙しいから後にして！」とICMPを捨てているだけの可能性が高いです。

2. traceroute が * * * になったら？

traceroute は通常、UDP というプロトコルを使います。しかし、UDPが制限されている場合、ICMP を使った traceroute に切り替えることで、見える景色が変わることがあります。

# Linux系なら -I オプションでICMPを指定
traceroute -I 8.8.8.8

これで結果が出るなら、その経路のルーターは「UDPでの問い合わせは無視するが、ICMPなら答えてやる」という設定になっているだけ。安心してください、障害ではありません。

—

対策：現場で設定を調整する（管理者向け）

もしあなたがネットワークの管理者なら、必要に応じてこの制限を緩和したり、逆に厳しくしたりすることができます。

例えば、Cisco機器で「pingに対する応答をもう少し柔軟にしたい」という場合、以下のような設定が考えられます。

! レートリミットを制御する設定例
! 1秒間に10パケットまでICMPを許可し、バーストは20パケットまでとする
ip icmp rate-limit unreachable 1000
ip icmp rate-limit echo 1000

※注：これはあくまで例です。無闇に制限を解除すると、悪意ある攻撃者に負荷をかけられる可能性があるため、現場ではセキュリティポリシーと相談しながら慎重に行ってくださいね。

—

最後に：焦らず「正常な挙動」を知ろう

初心者のうちは、ツールがエラーを返すとすぐに「どこかが壊れた！」と焦ってしまいます。でも、百戦錬磨のエンジニアから見れば、「ネットワークは、時々わざと意地悪をする生き物」のようなものなんです。

ping は「返事の催促」であること。
* * * は「障害」ではなく「無視されているだけ」かもしれないこと。
診断するときは、ツールを急かさず、少し余裕を持って送ること。

これらを意識するだけで、トラブルシューティングの景色は一変します。

もし現場で「あれ？おかしいな？」と思ったら、コマンドの結果をただ見るのではなく、「機器は今、どんな理由で返事をくれないのか？」と、ネットワーク機器の視点に立ってみてください。そうすれば、きっと解決の糸口が見えてくるはずですよ。

それでは、また次の現場でお会いしましょう。皆さんのネットワークが今日も快適に動きますように！