Det är bara några dagar kvar tills en ny kursstart från OTUS. I detta avseende vill vi dela med oss av en översättning av användbart material i ämnet.
En serie blogginlägg om felsökningstips och tricks för IPv6 Ping (ICMPv6 Echo Request/Echo Reply)
Observera att jag använder Linux (specifikt Fedora 31), men ping-kommandosyntaxen för andra operativsystem borde förhoppningsvis vara väldigt likartad.
Pinga alla IPv6-noder på en kanal
Det första och enklaste tipset är att pinga alla IPv6-noder på kanalen.
IPv6 använder multicast-adresser för alla typer av en-till-många-kommunikation. Det finns inga broadcast-IPv6-adresser. Detta står i kontrast till IPv6, där det finns flera typer av broadcast-adresser, till exempel den "begränsade broadcast"-adressen 4 [RFC255.255.255.255].
Det finns dock en IPv6-adress för "all-nodes multicast", så vi kommer att använda den för att pinga alla IPv6-noder på länken. ("Broadcast"-adressen är egentligen bara en särskilt namngiven multicast-adress, vilket är en multicast-grupp som inkluderar alla noder. Observera att till exempel "group"- eller multicast-adressbiten är aktiverad på Ethernet-broadcast-adresser på datalänkslagret.)
All-nods multicast IPv6-adress för kanalen: ff02::1. ff betecknar en multicast-IPv6-adress. Följande 0 är den del av flaggan med obestämda bitar.
Nästa 2 definierar omfattningen för multicast-gruppen. Till skillnad från IPv4-multicastadresser har IPv6-multicastadresser ett omfång. Omfångsvärdet anger den del av nätverket över vilken multicast-paketet tillåts vidarebefordras. När ett paket når gränsen för det angivna omfånget måste paketet kasseras, oavsett om dess Hop Count-fält inte är noll. Om Hop Count når noll innan den angivna multicast-gruppgränsen når, kasseras det naturligtvis också omedelbart. Här är en komplett lista över IPv6-multicast-omfång.
Slutligen ::1 Anger en multicast-grupp med alla noder.
Om adressen ff02::1 Det bör noteras att det är tvetydigt. På en IPv6-nod med flera gränssnitt, såsom en router eller en multihomed-värd, är adressen ff02::1 Det finns inget som anger vilket gränssnitt ICMPv6-ekoförfrågningar ska skickas till eller att förvänta sig ICMPv6-ekosvar när de anländer. ff02::1 är giltig och kan användas på alla gränssnitt och kanaler som är anslutna till multigränssnittsnoden.
Så när vi pingar alla IPv6-noder på kanalen måste vi också på något sätt tala om för verktyget ping för IPv6, vilket gränssnitt som ska användas.
Definiera gränssnitt - kommandoradsalternativ
Som vi redan har sett är multicast-adressen för alla noder som vi vill använda ff02::1 - ger ingen information om vilket gränssnitt som ska skickas och tas emot ICMPv6-ekoförfrågningar och ekosvarspaket på.
Så hur specificerar vi vilket gränssnitt som ska användas för multicast-adressutrymmet eller unicast Link-Local-adresser?
Det första och mest uppenbara sättet är att ange det som en parameter till den applikation vi använder.
För nyttan ping vi tillhandahåller det genom alternativet -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 ~]$Med denna multicast-ping för alla noder fick vi svar från 6 IPv6-noder. Svaren kom från nodens länklokala IPv6-adresser, med början med prefixet fe80::/10.
Att ping För att förhindra att ping fortsätter att skicka ICMPv6-ekoförfrågningar på obestämd tid tills vi avbryter den, anger vi vanligtvis antalet paket som ska skickas via alternativet -c. Detta förhindrar dock också att ping tar emot och visar mer än ett ICMPv6-ekosvar när en ICMPv6-ekoförfrågning med multicast skickas. Istället använde vi alternativet -w för att ange att ping ska avslutas efter 1 sekund, oavsett hur många ICMPv6-ekoförfrågningar eller ekosvar som skickades eller togs emot.
En annan sak att notera är (DUP!) utdata på det andra och efterföljande svar. Dessa paket identifieras som dubbletter eftersom de har samma ICMP-sekvensvärde som de individuella ICMPv6-ekoförfrågningarna som skickades från första början. De uppstår eftersom en multicast-ICMPv6-ekoförfrågan resulterar i flera individuella unicast-svar. Antalet dubbletter rapporteras också i statistiksammanfattningen.
Definiera gränssnitt - Zon-ID
Ett annat sätt att exponera ett gränssnitt för användning är som en del av en IPv6-adressparameter.
Vi kan se ett exempel på detta i ping-utdata, där adresserna till de svarande IPv6-värdarna också har suffixet %enp3s2, till exempel:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDetta sätt att specificera gränssnitt beskrivs formellt i [RFC4007], "IPv6 Assigned Address Architecture". Även om de vanligtvis kallas ett operativsystemgränssnitt, definierar de faktiskt något mer generellt - en "zon" eller ett "omfång".
Anledningen till att ha mer generella zoner eller omfattningszoner är att, som nämnts i [RFC4007], kan en IPv6-nod ha flera olika IPv6-gränssnitt anslutna till samma länk. Dessa gränssnitt är medlemmar i samma zon.
Det borde vara möjligt att gruppera flera gränssnitt inom en zon under ett operativsystem; jag vet för närvarande inte om detta är möjligt under Linux eller hur man gör det.
Använda suffixet %<zone_id>, kan vi ta bort kommandoradsparametern -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 ~]$Svar på länklokala adresser
Från denna multicast-ping med alla noder fick vi totalt 6 unika svar.
Dessa svar kom från unicast-länklokala adresser för IPv6-noder. Till exempel, här är det första svaret:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresser krävs på alla IPv6-kompatibla gränssnitt [RFC4291], "IP Version 6 Addressing Architecture". Anledningen till detta är att en IPv6-nod alltid automatiskt har en unicast IPv6-adress som den kan använda för att åtminstone kommunicera med andra noder via sina direktanslutna länkar. Detta inkluderar kommunikation med applikationer på andra värdar via värdarnas Link-Local-adresser.
Detta förenklar designen och implementeringen av protokoll som IPv6 Neighbor Discovery och OSPFv3. Det gör det också möjligt för slutanvändarapplikationer på värdar att kommunicera över en länk utan att kräva någon annan IPv6-aktiverad infrastruktur på länken. Direkt kommunikation mellan anslutna IPv6-värdar kräver inte en IPv6-router eller DHCPv6-server i anslutningen.
Länklokala adresser börjar med ett 10-bitars prefix fe80, följt av 54 nollbitar och sedan en 64-bitars gränssnittsidentifierare (IID). I det första svaret ovan, 2392:6213:a15b:66ff — är ett 64-bitars IID.
Loopad multicast
Som standard returneras multicast-paket internt till noden som skickar dem. Detta händer för både IPv6- och IPv4-adressering.
Anledningen till detta standardbeteende är att när multicast-paket skickas kan det också finnas en lyssnande lokal multicast-applikation som körs på den sändande värden själv, såväl som någon annanstans i nätverket. Denna lokala applikation bör också ta emot multicast-paketen.
Vi kan se denna multicast-lokala loop i vår ping-utdata:
[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 den länklokala adressen som konfigurerats 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 multicast-feedback med hjälp av parametern -LOm vi skickar en ping-multicast för alla noder med denna flagga, är svaren begränsade till fjärrnoder. Vi får inget svar från den länklokala adressen i avsändargränssnittet.
[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-länklokala adresser
Som du kanske gissar ger inte heller unicast-länklokala adresser i sig tillräckligt med information för att ange vilket gränssnitt som ska användas för att nå dem. Precis som med multicast-ping för alla noder måste vi också ange gränssnittet som en kommandoradsparameter. ping eller zon-ID med adress vid ping av länklokala adresser.
Den här gången kan vi använda -cför att begränsa antalet paket och svar som skickas och tas emot 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 såg vi hur man pingar alla IPv6-noder på en kanal med hjälp av all-nodes multicast IPv6-adress. ff02::1Vi såg också hur man anger vilket gränssnitt som ska användas med en multicast-IPv6-adress för alla noder, eftersom själva adressen inte kan tillhandahålla denna information. Vi använde antingen kommandoradsalternativet ping, eller specificerade gränssnittet via ett suffix %<zone_id>.
Sedan lärde vi oss om unicast Link-Local-adresser, vilka är adresserna som används för att svara på ICMPv6 all-nodes multicast-ekoförfrågningar.
Vi såg också hur multicast-paket returneras till den sändande noden som standard och hur man inaktiverar detta för verktyget. ping.
Slutligen pingade vi en enda länklokal adress med suffixet %<zone_id>, eftersom länklokala adresser i sig inte heller ger information om det utgående gränssnittet.
Så hur är det med att pinga alla andra noder och hämta deras globala unicast-adresser (GUA:er) (dvs. deras offentligt tillgängliga adresser på internet) eller deras unika lokala unicast-adresser (ULA:er)? Vi tar upp det i nästa blogginlägg.
Det är allt.
Du kan läsa mer om vår kurs på.
Källa: will.com
