채널의 모든 IPv6 노드를 ping합니다.

새로운 흐름이 시작될 때까지 며칠이 남았습니다. "네트워크 엔지니어" OTUS에서. 이와 관련하여 해당 주제에 대한 유용한 자료의 번역을 여러분과 공유하고 싶습니다.

IPv6 핑 문제 해결을 위한 팁과 요령에 대한 일련의 블로그 게시물(ICMPv6 에코 요청/에코 응답)

저는 Linux(특히 Fedora 31)를 사용하고 있지만 다른 운영 체제에 대한 ping 명령 구문은 매우 유사할 것으로 예상됩니다.

채널의 모든 IPv6 노드를 ping합니다.

첫 번째이자 가장 간단한 팁은 링크의 모든 IPv6 노드를 ping하는 것입니다.

IPv6은 모든 유형의 일대다 통신에 멀티캐스트 주소를 사용합니다. 브로드캐스트(또는 브로드캐스트) IPv6 주소가 없습니다. 이는 여러 유형의 브로드캐스트 주소(예: "제한된 브로드캐스트" 주소 6[RFC4])가 있는 IPv255.255.255.255와 IPv1122를 구별합니다.

그러나 "모든 노드 멀티캐스트" IPv6 주소가 있으므로 이를 사용하여 링크의 모든 IPv6 노드를 ping합니다. ("브로드캐스트" 주소는 실제로 모든 노드를 포함하는 멀티캐스트 그룹인 특별히 명명된 멀티캐스트 주소입니다. 예를 들어 "그룹" 또는 멀티캐스트 주소 비트는 링크 계층의 이더넷 브로드캐스트 주소에서 켜져 있습니다. ).

채널의 모든 노드 멀티캐스트 IPv6 주소: ff02::1. ff 멀티캐스트 IPv6 주소를 나타냅니다. 다음 0은 비트가 설정되지 않은 플래그의 일부입니다.

다음 2 멀티캐스트 그룹의 영역을 정의합니다. 멀티캐스트 IPv4 주소와 달리 멀티캐스트 IPv6 주소에는 범위가 있습니다. 범위 값은 멀티캐스트 패킷 전달이 허용되는 네트워크 부분을 나타냅니다. 패킷이 지정된 범위의 경계에 도달하면 홉 수 필드가 6이 아닌지 여부에 관계없이 패킷을 삭제해야 합니다. 물론, 지정된 멀티캐스트 그룹 경계에 도달하기 전에 홉 수가 XNUMX에 도달하는 경우에도 즉시 재설정됩니다. 다음은 IPvXNUMX 멀티캐스트 범위의 전체 목록입니다.

마지막으로, ::1 모든 노드 멀티캐스트 그룹을 지정합니다.

주소에 대해서 ff02::1 모호하다는 점에 유의해야합니다. 라우터 또는 멀티홈 호스트와 같은 다중 인터페이스가 있는 IPv6 호스트에서 주소 ff02::1 ICMPv6 에코 요청을 보낼 인터페이스나 도착 시 ICMPv6 에코 응답을 받을 것으로 예상하는 인터페이스를 지정할 수 있는 곳은 없습니다. ff02::1 유효하며 다중 인터페이스 노드에 연결된 모든 인터페이스 및 채널에서 사용할 수 있습니다.

따라서 링크의 모든 IPv6 노드를 핑할 때 유틸리티에도 알려야 합니다. ping IPv6의 경우 사용할 인터페이스입니다.

인터페이스 정의 - 명령줄 옵션

우리가 이미 본 것처럼 우리가 사용하려는 모든 노드 멀티캐스트 주소는 다음과 같습니다. ff02::1 - ICMPv6 에코 요청 및 에코 응답 패킷을 보내고 받는 인터페이스에 대한 정보를 제공하지 않습니다.

그렇다면 멀티캐스트 주소 공간이나 유니캐스트 링크-로컬 주소 공간에 사용할 인터페이스를 어떻게 지정합니까?

첫 번째이자 가장 확실한 방법은 이를 우리가 사용하는 애플리케이션에 매개변수로 제공하는 것입니다.

유틸리티용 ping 옵션을 통해 제공해드립니다 -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
 
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

이 모든 노드 멀티캐스트 핑을 사용하여 6개의 IPv6 노드로부터 응답을 받았습니다. 접두사로 시작하는 링크-로컬 IPv6 노드 주소에서 응답이 왔습니다. fe80::/10.

그 ping ICMPv6 에코 요청을 중단할 때까지 무기한 계속 보내지 않으므로 일반적으로 -c 옵션을 통해 보낼 패킷 수를 지정합니다. 그러나 이는 또한 멀티캐스트 ICMPv6 에코 요청을 보낼 때 ping이 둘 이상의 ICMPv6 에코 응답을 수락하고 표시하는 것을 방지합니다. 대신 -w 옵션을 사용하여 ICMPv1 에코 요청 또는 에코 응답 수에 관계없이 6초 후에 ping이 완료되어야 함을 지정했습니다.

또 주목해야 할 점은 (DUP!) 두 번째 이후의 답변에 대해 출력합니다. 이러한 패킷은 처음에 전송된 개별 ICMPv6 에코 요청과 동일한 ICMP 시퀀스 값을 갖기 때문에 중복 응답으로 식별됩니다. ICMPv6 멀티캐스트 에코 요청으로 인해 여러 개별 유니캐스트 응답이 발생하기 때문에 이러한 현상이 나타납니다. 중복 횟수는 통계 요약에도 표시됩니다.

인터페이스 정의 - 영역 ID

사용할 인터페이스를 노출하는 또 다른 방법은 IPv6 주소 매개변수의 일부로 사용하는 것입니다.

응답하는 IPv6 호스트의 주소에도 접미사가 붙는 ping 출력에서 ​​이에 대한 예를 볼 수 있습니다. %enp3s2예 :

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

인터페이스를 지정하는 이 방법은 [RFC4007], "IPv6 정의 주소 아키텍처"에 공식적으로 설명되어 있습니다. 일반적으로 운영 체제 인터페이스라고 부르지만 실제로는 "영역" 또는 "범위"와 같은 좀 더 일반적인 것을 정의합니다.

보다 일반적인 영역 또는 범위 영역을 갖는 이유는 [RFC4007]에서 언급한 것처럼 IPv6 노드가 동일한 채널에 연결된 여러 다른 IPv6 인터페이스를 가질 수 있기 때문입니다. 이러한 인터페이스는 동일한 영역의 구성원입니다.

운영 체제의 한 영역 내에서 여러 인터페이스를 그룹화하는 것이 가능해야 합니다. 현재 Linux에서 이것이 가능한지 또는 수행 방법을 모르겠습니다.

접미사 사용 %<zone_id>, 명령줄 옵션을 제거할 수 있습니다. -I ping.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

링크-로컬 주소 응답

이 모든 노드 멀티캐스트 ping에서 우리는 총 6개의 고유한 응답을 받았습니다.

이러한 응답은 유니캐스트 링크-로컬 IPv6 호스트 주소에서 나왔습니다. 예를 들어 첫 번째 답변은 다음과 같습니다.

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

모든 IPv6 지원 인터페이스에는 유니캐스트 링크-로컬 IPv6 주소가 필요합니다. [RFC4291], "IP 버전 6 주소 지정 아키텍처". 그 이유는 IPv6 노드가 항상 자동으로 유니캐스트 IPv6 주소를 갖게 되므로 최소한 직접 연결된 링크에서 다른 노드와 통신하는 데 사용할 수 있기 때문입니다. 여기에는 링크-로컬 호스트 주소를 통해 다른 호스트의 애플리케이션과 통신하는 것이 포함됩니다.

이는 IPv6 Neighbor Discovery 및 OSPFv3와 같은 프로토콜의 설계 및 구현을 단순화합니다. 또한 호스트의 최종 사용자 애플리케이션이 채널에 다른 IPv6 지원 인프라를 지원하지 않고도 채널을 통해 통신할 수 있도록 해줍니다. 연결된 IPv6 호스트 간의 직접 통신에는 연결 시 IPv6 라우터나 DHCPv6 서버가 필요하지 않습니다.

링크-로컬 주소는 10비트 접두사로 시작합니다. fe80, 그 뒤에 54개의 64비트, 그 다음에는 XNUMX비트 인터페이스 식별자(IID)가 옵니다. 위의 첫 번째 답변에서 2392:6213:a15b:66ff 64비트 IID입니다.

루프형 멀티캐스트

기본적으로 멀티캐스트 패킷은 패킷을 보낸 노드에 내부적으로 반환됩니다. 이는 IPv6 및 IPv4 주소 지정 모두에서 발생합니다.

이 기본 동작의 이유는 멀티캐스트 패킷이 전송될 때 전송 호스트 자체는 물론 네트워크 어딘가에서 실행 중인 수신 로컬 멀티캐스트 응용 프로그램도 있을 수 있기 때문입니다. 이 로컬 애플리케이션은 멀티캐스트 패킷도 수신해야 합니다.

ping 출력에서 ​​이 멀티캐스트 로컬 루프를 볼 수 있습니다.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...

첫 번째이자 가장 빠른 응답(0,106ms에 비해 0,453ms)은 인터페이스 자체에 구성된 링크-로컬 주소에서 나옵니다. enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

공익 사업 ping 매개변수를 사용하여 로컬 멀티캐스트 피드백을 억제하는 방법을 제공합니다. -L. 이 플래그와 함께 모든 노드 멀티캐스트 ping을 보내면 응답은 원격 노드로 제한됩니다. 송신 인터페이스의 링크-로컬 주소로부터 응답을 받지 못합니다.

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
 
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...

Ping 링크-로컬 주소

짐작할 수 있듯이 유니캐스트 링크-로컬 주소 자체는 주소에 도달하는 데 사용할 인터페이스를 나타내는 충분한 정보를 제공하지 않습니다. 모든 노드 멀티캐스트 핑과 마찬가지로 인터페이스를 명령줄 매개변수로 지정해야 합니다. ping 또는 링크-로컬 주소를 핑할 때 주소가 포함된 영역 ID.

이번에는 우리가 사용할 수 있습니다 -c보내고 받는 패킷 및 응답 수를 제한하려면 ping, 유니캐스트 핑을 수행하고 있기 때문입니다.

[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
 
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
 
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

다른 IPv6 주소를 (모두) ping하시겠습니까?

이 기사에서는 모든 노드 멀티캐스트 IPv6 주소를 사용하여 채널의 모든 IPv6 노드를 ping하는 방법을 살펴보았습니다. ff02::1. 또한 주소 자체로는 이 정보를 제공할 수 없기 때문에 모든 노드 멀티캐스트 IPv6 주소와 함께 사용할 인터페이스를 지정하는 방법도 살펴보았습니다. 우리는 명령줄 옵션 중 하나를 사용했습니다. ping또는 접미사를 사용하여 인터페이스를 지정했습니다. %<zone_id>.

그런 다음 모든 노드 멀티캐스트 ICMPv6 에코 요청에 응답하는 데 사용되는 주소인 유니캐스트 링크-로컬 주소에 대해 배웠습니다.

또한 멀티캐스트 패킷이 기본적으로 송신 노드로 반환되는 방법과 유틸리티에 대해 이를 비활성화하는 방법도 살펴보았습니다. ping.

마지막으로 접미사를 사용하여 단일 링크-로컬 주소를 ping했습니다. %<zone_id>, 링크-로컬 주소 자체도 나가는 인터페이스에 대한 정보를 제공하지 않기 때문입니다.

그렇다면 다른 모든 노드에 대해 ping을 실행하여 글로벌 유니캐스트 주소(GUA)(즉, 인터넷의 공개 주소) 또는 고유한 로컬 유니캐스트 주소(ULA)를 얻는 것은 어떨까요? 이에 대해서는 다음 블로그 포스팅에서 살펴보겠습니다.

그게 다야.

우리 과정에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 오픈 데이 노트.

출처 : habr.com