☰

IPv6 연결이 갑자기 끊어지고 IPv6 인접 라우터 상태가 동시에 STALE이 됩니다. 어떻게 피할 수 있나요?

tag-icon • tag-icon ipv6 arp best-practices
IPv6 연결이 갑자기 끊어지고 IPv6 인접 라우터 상태가 동시에 STALE이 됩니다. 어떻게 피할 수 있나요?

브리지 네트워킹이 있는 호스트에 VM이 있습니다(따라서 자체 MAC 주소가 있음). 호스트와 VM 모두 CentOS를 실행합니다. 이들의 네트워크는 /etc/sysconfig/network-scripts/ifcfg-enpXsY고정 IP 주소가 포함된 간단한 파일로 관리됩니다 . IPv4는 잘 작동합니다.

데이터 센터에서 올바르게 라우팅되는 VM(호스트에도 주소가 있음)에 IPv6 주소를 할당했습니다. 그러나 대부분의 연결은 IPv4를 사용합니다(아직 머신에 대한 DNS AAAA 항목이 없으며 여전히 IPv6를 테스트하고 있습니다).

VM을 부팅하면 완전한 IPv6 연결이 가능합니다. 하지만,잠시 후 IPv6 연결이 작동을 멈춥니다.(IPv6 마법?). 문제를 이웃(ARP/NDISC 캐시) 데이터로 좁혔습니다.

IPv6가 작동하지 않음, IPv6 입출력으로 핑하거나 연결할 수 없는 경우 다음이 표시됩니다.

# ip -6 neighbour 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router STALE

캐시를 새로 고치는 수정/해결 방법:

# ip -6 neighbour flush dev enp1s2
# ip -6 neighbour
(empty, as expected)

그런 다음 ping6VM 내의 호스트가 캐시를 채웁니다.

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 time=2.35 ms
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 time=0.468 ms
^C
# ip -6 neighbour
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router REACHABLE
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY

IPv6 인접/ARP 테이블이 유효성으로 복원되었으며 연결이 들어오고 나가고 있습니다!

그래서 내 질문은 다음과 같습니다

  1. 캐시가 오래되는 이유는 무엇입니까?
  2. 그것을 피하려면 어떻게 해야 할까요?'
  3. 위의 명령으로 문제가 해결되는 이유/방법은 무엇입니까?

물론 작업에서 해당 명령을 실행할 수 있지만 cron(얼마나 자주?) IPv6가 일반적으로 작동하는 데 실제로는 필요하지 않다고 생각합니까?

추신: 테스트용 스크립트를 사용했습니다.IPv6 스택은 약 20분마다 분해됩니다.. RFC로 설명할 수 있나요?

PPS: 방화벽 구성(축약된 출력, 모든 관련 비트가 희망됨):

# ip6tables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9023  709K ACCEPT     icmpv6    !lo    *       ::/0                 ::/0                
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9360  785K ACCEPT     icmpv6    *      !lo     ::/0                 ::/0

따라서 ICMPv6은 VM에서 입출력을 허용했습니다. 호스트에서 필터링을 확인해야 합니까?

답변1

일반적으로 오래된 상태는 좋은 것입니다. 실제로는 오래된 상태가 있는 것이 허용됩니다.

RFC 4861, 섹션 5.1을 살펴보겠습니다. :

  STALE       The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.

이웃에 더 이상 연결할 수 없는 것으로 알려져 있으며(타이머 만료, 최근 트래픽 없음 등) 트래픽이 이웃에 다시 전송되면 연결 가능성이 '확인'됩니다.

따라서 이웃에게 다시 트래픽을 보낼 수 있다면 문제가 없습니다.

관련 정보