나는 어찌할 바를 모르고 있으니 도움을 주시면 감사하겠습니다.
이웃 광고 전송을 무작위로 중지하는 IPv6 호스트(Linux 4.15.1-gentoo SMP x86_64)가 있습니다. tcpdump를 실행하면 많은 이웃 요청 요청이 표시되고 해당 요청에 대한 반응이 거의 0입니다. 때때로 호스트는 여전히 NA를 전송하지만 수십 개의 NS 요청이 무시된 후에만 전송됩니다. 분명히 이로 인해 IPv6 연결이 완전히 중단됩니다.
관련이 있는지는 모르겠지만 IPv6은 브리지 인터페이스에 구성되어 있습니다(두 개의 lxc 컨테이너도 해당 브리지에서 실행 중입니다). 브리지는 STP가 꺼진 일반적인 brctl 브리지입니다.
IPv6은 정적으로 구성됩니다(호스트와 게이트웨이 모두).
ndsend원치 않는 이웃 광고(예: from 사용)로 네트워크를 수동으로 넘치게 하면 vzctl문제가 약간 완화될 수 있지만 분명히 해결책은 아닙니다.
더 이상한 점은 procfs( )를 통해 인터페이스에서 ipv6을 비활성화했다가 다시 활성화하고 /proc/sys/net/ipv6/conf/br0/disable_ipv6이를 재구성( ip -6 addr add등)하면 문제가 일시적으로 "수정"된다는 것입니다. 그래도 하루 이틀 지나면 또 그런 일이 일어납니다.
완전성을 기하기 위해 호스트에서 실행 중인 nftables 방화벽이 있지만 모든 icmpv6 트래픽( ip6 nexthdr ipv6-icmp accept모든 곳을 통해)을 명시적으로 허용합니다. 문제가 나타날 때 방화벽을 비활성화해도 아무 변화가 없습니다.
따라서 질문은 다음과 같습니다. 근본적인 문제를 정확히 찾아내기 위해 무엇을 할 수 있습니까?
업데이트: 저에게는 몇 번의 커널 업데이트 후에 문제가 사라졌지만, 이후 커널 버전, 특히 대규모 라우팅 테이블 및/또는 다수의 이웃에서 유사한 문제가 보고되었습니다. 보고된 바에 따르면, 여기서 가능한 원인 중 하나는 커널의 ipv6 경로/이웃 캐시 크기에 대한 작은 제한입니다. 비슷한 문제가 있는 경우 sysctl 매개변수를 실행 및/또는 편집 등을 통해 net.ipv6.route.max_size상대적으로 큰 값(예: )으로 높여보세요 . 또한 가비지 수집기를 너무 자주 실행하지 않기 위해 레이즈를 원할 수도 있습니다 . 또한, Neighbor Cache에 유난히 많은 레코드가 있는지 확인해 보세요 . 보다1048576sysctl -w net.ipv6.route.max_size=1048576/etc/sysctl.confnet.ipv6.route.gc_threshnet.ipv6.neigh.default.gc_thresh1net.ipv6.neigh.default.gc_thresh2net.ipv6.neigh.default.gc_thresh3https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt그 모든 옵션이 하는 일에 대해.
답변1
방금 Linux VLAN 인식 브리지의 multicast_snooping에 버그가 있음을 발견했습니다. 라우터 광고는 건드리지 않지만 multicast_flooding이 켜져 있어도 이웃 검색을 차단합니다. 무슨 일이 일어나면 시스템 부팅 시 아빠가 할 일이 되고 아빠는 멀티캐스트 전달 데이터베이스에 남게 됩니다. 하지만 그것은 200~300초 후에 만료됩니다. 그 후에 모든 이웃 검색 멀티캐스트 패킷은 해당 포트로 삭제됩니다. 이는 라우터 광고가 아닌 이웃 검색에서만 발생합니다. 다음을 수행하여 이를 목격할 수 있습니다.
bridge mdb show
항목이 표시되면 multicast_snooping이 켜져 있는 것입니다. 그리고 당신은 버그를 경험할 수도 있습니다. 내 경우에는 내가 설정한 시스템의 약 80%가 이웃 검색 멀티캐스트만 차단하기 시작했습니다. 다른 모든 멀티캐스트는 플러딩되거나 올바르게 스누핑됩니다.
현재 해결 방법은 multicast_snooping을 끄는 것입니다.
echo 0 > /sys/net/devicename/bridge/multicast_snooping
시간이 나면 테스트 설정을 만들어 보겠습니다. 이 버그는 2년 동안 나를 괴롭혔고, 마침내 긴급 유지 보수 중에 문제를 완전히 이해할 수 있는 시간을 갖게 되었습니다.
답변2
4.16.2-gentoo 커널에서도 같은 문제가 발생했습니다. 하지만 제 경우에는 커널과 전혀 관련이 없는 것으로 나타났습니다.
문제의 상자는 ipv6 VPN-Gateway 역할을 하며 안정적인 연결을 유지하고 있었습니다. 그 뒤에 있는 서브넷 라우터도 완벽하게 괜찮았지만 라우팅된 서브넷 자체만 지속적으로 연결이 끊어졌습니다.
TL;DR;
방화벽내 경우에는 범인이었어. IPv6rpfilter설정이 내 서브넷 라우터의 이웃 요청을 필터링했습니다.
로그인을 활성화하여 이에 대해 알아냈습니다./etc/firewalld/firewalld.conf
LogDenied=all
이로 인해 다음과 같은 로그라인이 생성되었습니다(MAC 및 SRC가 단축되고 난독화됨).
kernel: rpfilter_DROP: IN=enp6s0.100 OUT= MAC=XX:…:XX SRC=fe80:…:beaf DST=ff02:0000:0000:0000:0000:0001:ff00:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
왜 이런 일이 발생하는지 알아낼 수 있을 때까지 ipv6 rpfilter를 비활성화했습니다. 설정은 매우 간단하고 모든 것이 괜찮아 보이지만 인터페이스가 VLAN인 문제일 수도 있습니다.