IPV4 ルート キャッシュは Linux カーネル 3.6 以上から削除されました

IPV4 ルート キャッシュは Linux カーネル 3.6 以上から削除されました

3.6 Linuxカーネルの変更ログを調べていたところ、メールを見つけました(http://article.gmane.org/gmane.linux.network/238256) カーネル内の IPV4 のルーティング キャッシュの削除に関する David S Miller からのメッセージです。ICMP リダイレクト、PMTU 機能はどのように動作するのでしょうか。メールには、ルートは事前にキャッシュされるが、サブネット マスクに応じて複数のルートが複数のエントリを持つ可能性があるとも書かれていますが、これはどのように動作するのでしょうか。これについて何かご存知の方はいらっしゃいますか。

ありがとう。

答え1

実際のパッチを読んでください。

PMTU および ICMP リダイレクトは、ルーティング キャッシュに保存されるのではなく、ルーティング エントリの一部である「ルーティング例外」構造に保存されます。また、いずれの場合も (ソース、入力インターフェイス、tos、宛先、マーク)、選択されるルート エントリは 1 つだけです。したがって、ルート エントリが変更されない限り、ルーティング例外は常に使用されます。

答え2

ホストのパス MTU に関する詳細情報は、次のように取得できます。最初にキャッシュ情報を入力する必要があることに注意してください。このテストは、3.13 Ubuntu カーネルで実行されました。最初にホストの現在のキャッシュを検証します。ホストと通信していないため、情報がありません。

johnf@mtutest:~$ ip ro get 192.168.3.48
192.168.3.48 dev eth0  src 192.168.1.22
    cache

次に、MTU より大きいパケット (ただし、OS によってパケットが断片化されるほど大きくない) で ping を試みます。テスト時に最初の数回の ping が失敗する可能性がありますが、Frag needed というメッセージが表示されます。

johnf@mtutest:~$ ping -s 1460 192.168.3.48 -c 10
PING 192.168.3.48 (192.168.3.48) 1460(1488) bytes of data.
From 192.168.2.0 icmp_seq=1 Frag needed and DF set (mtu = 1220)
1468 bytes from 192.168.2.0: icmp_seq=2 ttl=252 time=1973 ms
[...]
--- 192.168.3.48 ping statistics ---
10 packets transmitted, 9 received, +1 errors, 10% packet loss, time 9016ms
rtt min/avg/max/mdev = 95.681/516.815/1973.697/568.969 ms, pipe 2

ICMP MTU 超過メッセージを受信した後、カーネルはパスの制限を反映するようにルート キャッシュを調整する必要があります。

johnf@mtutest:~$ ip ro get 192.168.3.48
192.168.3.48 dev eth0  src 192.168.1.22
    cache  expires 588sec mtu 1220

関連情報