☰

Кэш маршрутов IPV4 удален из ядра Linux >= 3.6

tag-icon • tag-icon linux networking kernel
Кэш маршрутов IPV4 удален из ядра Linux >= 3.6

Просматривая журнал изменений ядра Linux 3.6, я наткнулся на письмо (http://article.gmane.org/gmane.linux.network/238256) от Дэвида С. Миллера относительно удаления кэша маршрутизации для IPV4 в ядре. Мне интересно, как теперь будут работать функции перенаправления ICMP и PMTU? В Mail также упоминается, что маршруты будут предварительно кэшироваться, но несколько маршрутов в зависимости от маски подсети могут иметь несколько возможных записей, как это будет работать? Есть ли у кого-нибудь идеи по этому поводу?

Спасибо.

решение1

Просто прочитайте сами патчи.

Вместо хранения перенаправлений PMTU и ICMP в кэше маршрутизации, они хранятся в структуре «исключения маршрутизации», которая является частью записи маршрутизации. И для любого (источник, входной интерфейс, tos, пункт назначения, отметка) выбирается только одна запись маршрута. поэтому исключения маршрутизации всегда будут использоваться, пока запись маршрута не будет изменена.

решение2

Подробную информацию о MTU пути для хоста можно получить следующим образом. Обратите внимание, что сначала необходимо заполнить кэш-информацию. Это тестирование проводилось с ядром Ubuntu 3.13. Сначала я проверяю текущий кэш для хоста, я с ним не общался и не имею никакой информации:

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

Затем я пробую пинговать его пакетом, превышающим MTU (но не настолько большим, чтобы пакет пришлось фрагментировать ОС). Вы можете пропустить первые несколько пингов при тестировании, вы должны увидеть сообщение 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 Exceeded ядро ​​должно скорректировать кэш маршрутов, чтобы отразить ограничения пути:

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

Связанный контент