☰

>= 3.6 Linux 커널에서 IPV4 경로 캐시가 제거되었습니다.

tag-icon • tag-icon linux networking kernel
>= 3.6 Linux 커널에서 IPV4 경로 캐시가 제거되었습니다.

3.6 Linux 커널 변경 로그를 검토하는 동안 메일(http://article.gmane.org/gmane.linux.network/238256) 커널에서 IPV4용 라우팅 캐시 제거에 관한 David S Miller의 글입니다. 이제 ICMP 리디렉션, PMTU 기능이 어떻게 작동할지 궁금합니다. Mail에서는 또한 경로가 사전 캐시되지만 서브넷 마스크에 따라 여러 경로에 여러 개의 가능한 항목이 있을 수 있다고 언급합니다. 어떻게 작동합니까? 누구든지 이것에 대해 어떤 생각을 갖고 있나요?

감사해요.

답변1

실제 패치를 읽어보세요.

라우팅 캐시에 PMTU 및 ICMP 리디렉션을 저장하는 대신 라우팅 항목의 일부인 "라우팅 예외" 구조에 저장됩니다. 그리고 모든 항목(소스, 입력 인터페이스, tos, 대상, 표시)에 대해 하나의 경로 항목만 선택됩니다. 따라서 경로 항목이 변경되지 않는 한 라우팅 예외는 항상 사용됩니다.

답변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보다 큰 패킷으로 ping을 시도합니다(그러나 OS에 의해 패킷이 조각화되어야 할 정도로 크지는 않습니다). 테스트할 때 처음 몇 번의 핑을 놓칠 수 있으며, 조각 필요 메시지가 표시됩니다.

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

관련 정보