IPv6 인접 테이블 오버플로: 라우터가 멀티캐스트 주소를 캐싱하는 것을 방지

IPv6 인접 테이블 오버플로: 라우터가 멀티캐스트 주소를 캐싱하는 것을 방지

간단히 말해서:IPv6 이웃 요청이 이웃 캐시에 멀티캐스트 항목을 생성하는 것을 방지하는 방법은 무엇입니까?


최근에 다소 눈에 띄지 않는 것을 설치했습니다.파다완 RT-N56U보다 안정적인 인터넷 연결을 얻기 위해 이전 Asus RT-N56U 라우터에 펌웨어(Linux 3.4.110)를 설치했지만 곧 IPv6 구성 문제가 발생했습니다. 내 ISP는 훌륭하고 훌륭하게 작동하는 라우터 광고를 사용하여 상태 비저장 DHCPv6을 지원합니다. 내 라우터는 DNS 항목을 포함하여 DHCP에서 얻을 수 있는 모든 이점을 얻습니다.

그러나 ISP는 이웃 테이블을 막고 있는 icmp6멀티캐스트 주소로 이웃 요청 패킷을 보내고 있습니다.ff02::1:

/home/root # ip route show cache table all | grep -c ff02
1681

테이블은 오버플로 지점까지 반복됩니다.

Sep  8 16:53:39 kernel: net_ratelimit: 705 callbacks suppressed
Sep  8 16:53:39 kernel: ipv6: Neighbour table overflow
Sep  8 17:02:41 kernel: net_ratelimit: 83 callbacks suppressed
Sep  8 17:02:41 kernel: ipv6: Neighbour table overflow
Sep  8 17:03:41 kernel: net_ratelimit: 1762 callbacks suppressed
Sep  8 17:03:41 kernel: ipv6: Neighbour table overflow

WAN 포트에서 TCP 패킷을 캡처할 때:

/home/root # tcpdump -i eth3 -v ip6
11:07:27.055286 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ce4e:24ff:fe1c:3300 > ff02::1:ff5a:c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has [redacted ipv6 GUA]
      source link-address option (1), length 8 (1): cc:4e:24:1c:33:00
11:07:27.055330 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ce4e:24ff:fe1c:3300 > ff02::1:ff86:1d: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has [redacted ipv6 GUA]
      source link-address option (1), length 8 (1): cc:4e:24:1c:33:00
11:07:27.055348 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ce4e:24ff:fe1c:3300 > ff02::1:ffa6:8015: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has [redacted ipv6 GUA]
      source link-address option (1), length 8 (1): cc:4e:24:1c:33:00
11:07:27.055376 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ce4e:24ff:fe1c:3300 > ff02::1:ff5b:8: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has [redacted ipv6 GUA]
      source link-address option (1), length 8 (1): cc:4e:24:1c:33:00

가비지 수집 메커니즘의 강도를 변경할 수 있다는 것을 알고 있지만 단순히 이러한 멀티캐스트 주소를 캐시하지 않는 방법이 있습니까? 어쩌면 이것은 현명하지 못한 기본 동작이고 최신 버전에서 수정되었을 수도 있습니다.


편집하다:NDP 사양이웃 캐시가 유니캐스트 정보를 보유해야 한다고 선언합니다.

최근에 트래픽이 전송된 각 이웃에 대한 항목 집합입니다. 항목은 이웃의 온링크 유니캐스트 IP 주소로 입력됩니다. [...]

글쎄, 이건 버그인 것 같아. 스택의 구성 요소에 문제가 있으면 답변해 드리겠습니다.

관련 정보