Några dagar återstår tills ett nytt flöde startar i takt från OTUS. I detta avseende skulle vi vilja dela med dig av en översättning av användbart material om ämnet.
En serie blogginlägg om tips och tricks för att felsöka IPv6-pingproblem (ICMPv6 Echo Request/Echo Reply)
Observera att jag använder Linux (speciellt Fedora 31), men ping-kommandosyntaxen för andra operativsystem bör förhoppningsvis vara mycket lika.
Pinga alla IPv6-noder på en kanal
Det första och enklaste tipset är att pinga alla IPv6-noder på länken.
IPv6 använder multicast-adresser för alla typer av en-till-många-kommunikation. Det finns inga sändnings- (eller sändnings-) IPv6-adresser. Detta skiljer IPv6 från IPv4, där det finns flera typer av sändningsadresser, till exempel "limited broadcast"-adressen 255.255.255.255 [RFC1122].
Det finns dock en "all-nodes multicast" IPv6-adress, så vi kommer att använda den för att pinga alla IPv6-noder på länken. (En "broadcast"-adress är egentligen bara en speciellt namngiven multicast-adress, vilket är en multicast-grupp som inkluderar alla noder. Observera att till exempel "group"- eller multicast-adressbiten är aktiverad i Ethernet-broadcast-adresser i länklagret ).
All-nodes multicast IPv6-adress för kanalen: ff02::1. ff anger en multicast IPv6-adress. Nästa nolla är den del av flaggan med oinställda bitar.
Nästa 2 definierar området för en multicast-grupp. Till skillnad från multicast IPv4-adresser har multicast IPv6-adresser en omfattning. Omfattningsvärdet indikerar den del av nätverket över vilken ett multicast-paket tillåts vidarebefordras. När ett paket når gränsen för det angivna omfånget måste paketet släppas, oavsett om dess Hop Count-fält inte är noll. Naturligtvis, om hoppräkningen når noll innan den når den specificerade multicast-gruppgränsen, återställs den också omedelbart. Här är en komplett lista över IPv6 multicast scope.
Slutligen ::1 anger en multicast-grupp med alla noder.
Om adressen ff02::1 Det bör noteras att det är tvetydigt. På en IPv6-värd med flera gränssnitt, till exempel en router eller multihomed-värd, adressen ff02::1 det finns inget där du kan specificera vilket gränssnitt du ska skicka ICMPv6-ekoförfrågningar till eller förvänta dig att få ICMPv6-ekosvar när de kommer. ff02::1 är giltig och kan användas på alla gränssnitt och kanaler som är kopplade till multi-interface noden.
Så när vi pingar alla IPv6-noder på en länk måste vi på något sätt också berätta för verktyget ping för IPv6, vilket gränssnitt som ska användas.
Definiera gränssnitt - Kommandoradsalternativ
Som vi redan har sett är multicastadressen för alla noder vi vill använda − ff02::1 - tillhandahåller ingen information om vilket gränssnitt som ska skickas och ta emot ICMPv6-ekobegäran och ekosvarspaket.
Så, hur anger vi gränssnittet som ska användas för multicast-adressutrymmet eller unicast Link-Local-adressutrymmet?
Det första och mest uppenbara sättet är att tillhandahålla det som en parameter till applikationen vi använder.
För nytta 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 ~]$Genom att använda denna multicast-ping med alla noder fick vi svar från 6 IPv6-noder. Svaren kom från Link-Local IPv6-nodadresser, som börjar med prefixet fe80::/10.
Att ping inte fortsätter att skicka ICMPv6-ekoförfrågningar på obestämd tid tills vi avbryter det, vi anger vanligtvis antalet paket som ska skickas via alternativet -c. Detta förhindrar dock också att ping accepterar och visar mer än ett ICMPv6-ekosvar när en multicast ICMPv6-ekobegäran skickas. Istället använde vi alternativet -w för att ange att ping ska slutföras efter 1 sekund, oavsett hur många ICMPv6-ekoförfrågningar eller ekosvar som skickades eller togs emot.
En annan sak att vara uppmärksam på är (DUP!) utdata på det andra och efterföljande svaren. Dessa paket identifieras som dubbletter av svar eftersom de har samma ICMP-sekvensvärde som de individuella ICMPv6-ekobegäranden som skickades från början. De visas eftersom en ICMPv6 multicast-ekobegäran resulterar i flera individuella unicast-svar. Antalet dubbletter anges 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-utgången, 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 msDenna metod för att specificera gränssnitt beskrivs formellt i [RFC4007], "IPv6 Defined Address Architecture." Även om de vanligtvis kallas för operativsystemets gränssnitt, definierar de faktiskt något mer generellt - en "zon" eller "omfattning".
Anledningen till att ha mer generella zoner eller scope-zoner är att, som nämnts i [RFC4007], en IPv6-nod kan ha flera olika IPv6-gränssnitt kopplade till samma kanal. Dessa gränssnitt är medlemmar i samma zon.
Det bör vara möjligt att gruppera flera gränssnitt inom en zon under operativsystemet; För närvarande vet jag inte om detta är möjligt under Linux eller hur man gör det.
Använder suffixet %<zone_id>, kan vi ta bort kommandoradsalternativet -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 ~]$Länk-lokal adresssvar
Från denna multicast-ping med alla noder fick vi totalt 6 unika svar.
Dessa svar kom från unicast Link-Local IPv6-värdadresser. Här är till exempel 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-aktiverade 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 åtminstone kan använda för att kommunicera med andra noder på sina direktanslutna länkar. Detta inkluderar kommunikation med applikationer på andra värdar via Link-Local värdadresser.
Detta förenklar designen och implementeringen av protokoll som IPv6 Neighbor Discovery och OSPFv3. Det tillåter också slutanvändarapplikationer på värdar att kommunicera över kanalen utan att kräva någon annan stödjande IPv6-infrastruktur på kanalen. Direkt kommunikation mellan anslutna IPv6-värdar kräver ingen IPv6-router eller DHCPv6-server på anslutningen.
Länk-lokala 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.
Slingad Multicast
Som standard returneras multicast-paket internt till noden som skickade 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å själva sändningsvärden, såväl som någonstans på nätverket. Denna lokala applikation måste också ta emot multicast-paket.
Vi kan se denna multicast-lokalslinga 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 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 -L. Om vi skickar en multicast-ping med alla noder med denna flagga, är svaren begränsade till fjärrnoder. Vi får inget svar från sändningsgränssnittets Link-Local-adress.
[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!)
...Pinga länk-lokala adresser
Som du kanske gissar ger unicast Link-Local-adresser i sig inte heller tillräckligt med information för att indikera vilket gränssnitt som ska användas för att nå dem. Som med all-nodes multicast-ping måste vi också ange gränssnittet som en kommandoradsparameter ping eller zon-ID med adress när man pingar Link-Local-adresser.
Den här tiden 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 en multicast-IPv6-adress med alla noder ff02::1. Vi såg också hur man anger vilket gränssnitt som ska användas med en all-nodes multicast IPv6-adress, eftersom adressen i sig inte kan ge denna information. Vi använde antingen kommandoradsalternativet ping, eller specificerade gränssnittet med suffixet %<zone_id>.
Sedan lärde vi oss om unicast Link-Local-adresser, som är adresser som används för att svara på multicast ICMPv6-ekoförfrågningar med alla noder.
Vi såg också hur multicast-paket returneras till sändningsnoden som standard och hur man inaktiverar detta för verktyget ping.
Slutligen pingade vi en enda Link-Local-adress med suffixet %<zone_id>, eftersom Link-Local-adresser i sig inte heller ger information om det utgående gränssnittet.
Så vad sägs om att pinga alla andra noder och få deras globala unicast-adresser (GUA) (det vill säga deras allmänna adresser på Internet) eller deras unika lokala unicast-adresser (ULA)? Vi ska titta på detta i nästa blogginlägg.
Det är allt.
Du kan läsa mer om vår kurs på.
Källa: will.com