Pinga alla noder i IPv6 över kanalen

Det är bara några dagar kvar till starten av den nya kursen «Nätverksingenjör» från OTUS. I samband med detta vill vi dela med oss av en översättning av användbart material i ämnet.

En serie artiklar i bloggen, dedikerade till tips och rekommendationer för att åtgärda problem relaterade till IPv6-ping (ICMPv6 Echo Request/Echo Reply)

Observera att jag använder Linux (särskilt Fedora 31), men syntaxen för ping-kommandot bör, hoppas jag, vara mycket liknande för andra operativsystem.

Pinga alla noder i IPv6 över kanalen

Det första och enklaste rådet är att pinga alla IPv6-noder på kanalen.

IPv6 använder multicast-adresser för alla typer av samband "en till många". Det finns inga broadcast-alternativ (eller sändande) IPv6-adresser. Detta skiljer IPv6 från IPv4, där det finns flera typer av broadcast-adresser, till exempel den "begränsade broadcast"-adressen 255.255.255.255 [RFC1122].

Det finns dock en “all-nodes multicast” (gemensam multicast) IPv6-adress, så vi kommer att använda den för att pinga alla IPv6-noder i kanalen. (Den "sändande" adressen är faktiskt bara en specialnamn för en multicastadress som omfattar alla noder. Observera att till exempel biten "grupp" eller multicast-adressen ingår i broadcast-adresser på Ethernet-nivå).

All-nodes multicast IPv6-adress för kanalen: ff02::1. ff representerar multicast IPv6-adressen. Det följande 0:et är en del av flaggan med icke-inställda bitar.

Nästa 2 definierar området för multicast-gruppen. Till skillnad från multicast IPv4-adresser har multicast IPv6-adresser scope (synlighetsområde). Scope-värdet anger den del av nätverket som multicast-paketet får vidarebefordras över. Så snart paketet når gränsen för det angivna scope, måste paketet kasseras, oavsett om dess hopcount-fält är noll. Om hopcount når noll innan den angivna gränsen för multicast-gruppen nås, kasseras det också omedelbart. Här är hela listan över multicast scope IPv6.

Slutligen, ::1 indikerar all-nodes multicast-gruppen.

Om adressen ff02::1 bör det noteras att den är tvetydig. På en IPv6-nod med flera gränssnitt, som en router eller multihoming-värd, i adressen ff02::1 Det finns inget ställe där man kan ange vilken gränssnitt som ICMPv6-eko-förfrågningar ska skickas till eller vänta på att ta emot ICMPv6-eko-svar när de kommer. ff02::1 Är giltig och kan användas på något av de gränssnitt och kanaler som är kopplade till en multigränssnittsnod.

Därför, när vi pinger alla IPv6-noder på kanalen, måste vi också på något sätt informera verktyget ping för IPv6, vilket gränssnitt som ska användas.

Definition av gränssnitt är en kommandoradsparameter.

Som vi redan har sett, all-nodes multicast-adressen som vi vill använda — ff02::1 — ger ingen information om vilket gränssnitt som ska användas för att skicka och ta emot ICMPv6-eko-förfrågningar och -svar.

Så hur anger vi det gränssnitt som ska användas för multicast-adresser eller unicast Link-Local-adresser?

Det första och mest uppenbara sättet är att tillhandahålla det som en parameter för applikationen vi använder.

För verktyget ping tillhandahåller vi det via alternativet -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Varning: källadress kan väljas på en annan enhet än: enp3s2
PING ff02::1(ff02::1) från :: enp3s2: 56 databyte
64 byte från fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tid 0.438 ms
64 byte från fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tid 0.589 ms (DUP!)
64 byte från fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 tid 5.15 ms (DUP!)
64 byte från fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 tid 58.0 ms (DUP!)
64 byte från fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 tid 62.3 ms (DUP!)
64 byte från fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 tid 62.8 ms (DUP!)
 
--- ff02::1 ping-statistik ---
1 paket skickat, 1 mottaget, +5 dubbletter, 0% paketförlust, tid 0 ms
rtt min/medel/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

Med den här all-nodes multicast-pingen fick vi svar från 6 IPv6-noder. Svaren kom från noder med Link-Local IPv6-adresser som börjar med prefixet fe80::/10.

För att ping fortsatte inte att skicka ICMPv6-eko-förfrågningar oändligt tills vi avbröt den, vanligtvis anger vi antalet paket som ska skickas via alternativet -c. Men detta möjliggör inte heller att ping tar emot och visar mer än ett ICMPv6-eko-svar vid sändning av multicasts ICMPv6-eko-förfrågningar. Istället använde vi alternativet -w för att ange att ping skulle avslutas efter 1 sekund, oavsett hur många ICMPv6-eko-förfrågningar eller -svar som har skickats eller tagits emot.

En annan sak att notera är (DUP!) visning på andra och efterföljande svar. Dessa paket identifieras som dubbletter av svaret, eftersom de har samma ICMP-sekvensvärde som de individuella ICMPv6-echo-förfrågningar som skickades först. De visas eftersom multicast-echo-förfrågningar ICMPv6 resulterar i flera individuella unicast-svar. Antalet dubbletter anges också i sammanställningen av statistiken.

Definiera gränssnitt – Zon-ID

Ett annat sätt att tillhandahålla ett gränssnitt för användning är som en del av parameteradressen IPv6.

Vi kan observera ett exempel på detta i pingresultatet, där adresserna från svarande IPv6-noder också har suffix %enp3s2, till exempel:

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

Detta sätt att definiera gränssnitt beskrivs formellt i [RFC4007], "Arkitektur med angivna IPv6-adresser". Även om de vanligtvis kallas operativsystemets gränssnitt, definierar de faktiskt något mer generellt – en "zon" eller "räckvidd".

Anledningen till att det finns mer allmänna zoner eller räckviddszoner är att, som nämns i [RFC4007], kan en IPv6-nod ha flera olika IPv6-gränssnitt anslutna till samma nätverk. Dessa gränssnitt är medlemmar av samma zon.

Det bör vara möjligt att gruppera flera gränssnitt inom zonen under operativsystemet; just nu vet jag inte om detta är möjligt under Linux och hur man gör det.

Genom att använda suffixet %, kan vi ta bort kommandoradsparametern -I ping.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 databytes
64 bytes från fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes från fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes från fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes från fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes från fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes från fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes från fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes från fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
 
--- ff02::1%enp3s2 pingstatistik ---
1 paket skickade, 1 mottagen, +7 dubbletter, 0% paketförlust, tid 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

Svar från Link-Local adresser

Från denna multicast-ping till alla noder fick vi totalt 6 unika svar.

Dessa svar kom från unicast Link-Local adresser på IPv6-noder. Till exempel, här är det första svaret:

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

Unicast Link-Local IPv6-adresser behövs på alla gränssnitt som stöder IPv6 [RFC4291], "Arkitektur för IP-version 6-adressering". Anledningen till detta är att en IPv6-nod alltid automatiskt har en unicast IPv6-adress som den kan använda, åtminstone för att kommunicera med andra noder över sina direkt anslutna kanaler. Detta inkluderar kommunikation med andra värdas applikationer via Link-Local-adresser.

Detta förenklar utveckling och implementering av protokoll som IPv6 Neighbor Discovery och OSPFv3. Det gör det också möjligt för slutanvändarapplikationer på värdar att byta data över kanalen utan att behöva någon annan stödjande infrastruktur för IPv6. För direkt kommunikation mellan anslutna IPv6-värdar krävs ingen IPv6-router eller DHCPv6-server i anslutningen.

Link-Local-adresser börjar med en 10-bitars prefix fe80, följt av 54 nollbitar och sedan en 64-bitars identifierare för gränssnittet (IID). I det första svaret ovan 2392:6213:a15b:66ff — är det 64-bitars IID.

Looped Multicast

Som standard skickas multicast-paket tillbaka internt till noden som skickar dem. Detta gäller både för IPv6- och IPv4-adressering.

Anledningen till detta standardbeteende är att när multicast-paket skickas kan det också förekomma en lyssnande lokal multicast-applikation som körs på samma sändande värd, såväl som någonstans i nätverket. Denna lokala applikation måste också ta emot multicast-paketen.

Vi kan se denna multicast-lokala cykel i vår ping-utgång:

[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!)
...

Det första och snabbaste svaret (0,106 ms jämfört med 0,453 ms) kommer från Link-Local-adressen som är inställd på själva gränssnittet enp3s2.

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

Verktyg ping ger ett sätt att undertrycka lokal återkoppling av multicastutskick med hjälp av parametern -L. Om vi skickar ett ping till alla noder multicast med denna flagga, begränsas svaren till avlägsna noder. Vi får inget svar från Link-Local-adressen för avsändarens gränssnitt.

[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 Link-Local Adresser

Som du kan gissa, erbjuder unicast Link-Local-adresser i sig inte tillräcklig information för att ange vilken gränssnitt som ska användas för att nå dem. Precis som med all-nodes multicast-ping behöver vi också ange gränssnittet som en kommandoradsparameter. ping eller zone ID med adressen när vi pingar Link-Local-adresser.

Den här gången kan vi använda -c, för att begränsa antalet paket och svar som skickas och mottas ping, eftersom vi utför unicast-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 ~]$

Pinga (alla) andra IPv6-adresser?

I den här artikeln har vi sett hur man pingar alla IPv6-noder i kanalen med hjälp av all-nodes multicast IPv6-adressen. ff02::1Vi har också sett hur man anger vilket gränssnitt som ska användas med all-nodes multicast IPv6-adressen, eftersom adressen i sig inte kan ge denna information. Vi använde antingen kommandoradsparametern ping, eller angav gränssnittet via suffixet %.

Sedan lärde vi oss om unicast Link-Local-adresser, som är adresser som används för att svara på all-nodes multicast ekonfrågor ICMPv6.

Vi har också sett hur multicast-paket återvänder till den sändande noden som standard och hur man stänger av detta för verktyget. ping.

Till slut pingade vi enstaka Link-Local-adress med suffixet %, eftersom Link-Local-adresser i sig inte heller ger information om den utgående gränssnittet.

Vad sägs om att pinga alla andra noder och få deras globala unicastadresser (GUA) (det vill säga deras publika adresser på Internet) eller deras unika lokala unicastadresser (ULA)? Vi kommer att behandla detta i nästa bloggartikel.

Det är allt.

Läs mer om vår kurs i öppen dag inspelning.

Källa: habr.com