Der er et par dage tilbage til starten af et nyt flow på hastigheden fra OTUS. I denne forbindelse vil vi gerne dele en oversættelse af nyttigt materiale om emnet med dig.
En række blogindlæg om tips og tricks til fejlfinding af IPv6 ping-problemer (ICMPv6 Echo Request/Echo Reply)
Bemærk venligst, at jeg bruger Linux (specifikt Fedora 31), men ping-kommandosyntaksen for andre operativsystemer skulle forhåbentlig være meget ens.
Ping alle IPv6-noder på en kanal
Det første og enkleste tip er at pinge alle IPv6-noder på linket.
IPv6 bruger multicast-adresser til alle typer en-til-mange-kommunikation. Der er ingen broadcast (eller broadcast) IPv6-adresser. Dette adskiller IPv6 fra IPv4, hvor der er flere typer broadcast-adresser, for eksempel "limited broadcast"-adressen 255.255.255.255 [RFC1122].
Der er dog en "all-nodes multicast" IPv6-adresse, så den vil vi bruge til at pinge alle IPv6-noder på linket. (En "broadcast"-adresse er faktisk bare en specielt navngivet multicast-adresse, som er en multicast-gruppe, der omfatter alle noder. Bemærk, at f.eks. "gruppe" eller multicast-adressebit er slået til i Ethernet-broadcast-adresser på linklaget ).
All-nodes multicast IPv6-adresse for kanalen: ff02::1. ff angiver en multicast IPv6-adresse. Den næste 0 er den del af flaget med unset bits.
Næste 2 definerer området for en multicast-gruppe. I modsætning til multicast IPv4-adresser har multicast IPv6-adresser et omfang. Omfangsværdien angiver den del af netværket, som en multicast-pakke må videresendes over. Når en pakke når grænsen for det angivne omfang, skal pakken droppes, uanset om dens Hop Count-felt ikke er nul. Selvfølgelig, hvis hoptællingen når nul, før den når den specificerede multicast-gruppegrænse, nulstilles den også straks. Her er en komplet liste over IPv6 multicast-omfang.
Endelig ::1 angiver en multicast-gruppe med alle noder.
Om adressen ff02::1 Det skal bemærkes, at det er tvetydigt. På en IPv6-vært med flere grænseflader, såsom en router eller multihomed-vært, er adressen ff02::1 der er intet, hvor du kan angive, hvilken grænseflade du skal sende ICMPv6 ekko-anmodninger til eller forvente at modtage ICMPv6 ekkosvar, når de ankommer. ff02::1 er gyldig og kan bruges på alle de grænseflader og kanaler, der er knyttet til multi-interface noden.
Så når vi pinger alle IPv6-noder på et link, skal vi på en eller anden måde også fortælle værktøjet ping til IPv6, hvilket interface der skal bruges.
Definition af grænseflader - Kommandolinjevalg
Som vi allerede har set, er all-nodes multicast-adressen, vi ønsker at bruge − ff02::1 - giver ingen information om, hvilken grænseflade der skal sende og modtage ICMPv6 ekkoanmodnings- og ekkosvarpakker.
Så hvordan specificerer vi den grænseflade, der skal bruges til multicast-adresserummet eller unicast Link-Local-adresserummet?
Den første og mest oplagte måde er at give det som en parameter til den applikation, vi bruger.
Til nytte ping vi giver det gennem muligheden -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 ~]$Ved at bruge dette multicast-ping med alle noder modtog vi svar fra 6 IPv6-noder. Svar kom fra Link-Local IPv6-nodeadresser, startende med præfikset fe80::/10.
Det ping fortsætter ikke med at sende ICMPv6 ekko-anmodninger på ubestemt tid, indtil vi afbryder det, angiver vi normalt antallet af pakker, der skal sendes via -c-indstillingen. Dette forhindrer dog også ping i at acceptere og vise mere end ét ICMPv6 ekkosvar, når der sendes en multicast ICMPv6 ekkoanmodning. I stedet brugte vi muligheden -w til at specificere, at ping skulle fuldføres efter 1 sekund, uanset hvor mange ICMPv6 ekko-anmodninger eller ekkosvar, der blev sendt eller modtaget.
En anden ting at være opmærksom på er (DUP!) output på det andet og efterfølgende svar. Disse pakker identificeres som duplikerede svar, fordi de har den samme ICMP-sekvensværdi som de individuelle ICMPv6-ekkoanmodninger, der blev sendt i første omgang. De vises, fordi en ICMPv6 multicast ekkoanmodning resulterer i flere individuelle unicast-svar. Antallet af dubletter er også angivet i statistikoversigten.
Definition af grænseflader - Zone ID
En anden måde at eksponere en grænseflade til brug på er som en del af en IPv6-adresseparameter.
Vi kan se et eksempel på dette i ping-outputtet, hvor adresserne på de reagerende IPv6-værter også har suffikset %enp3s2, for eksempel:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDenne metode til at specificere grænseflader er formelt beskrevet i [RFC4007], "IPv6 Defined Address Architecture." Selvom de normalt kaldes operativsystemgrænsefladen, definerer de faktisk noget mere generelt - en "zone" eller "omfang".
Grunden til at have mere generelle zoner eller scope-zoner er, at som nævnt i [RFC4007], kan en IPv6-node have flere forskellige IPv6-grænseflader forbundet til den samme kanal. Disse grænseflader er medlemmer af samme zone.
Det bør være muligt at gruppere flere grænseflader inden for en zone under operativsystemet; I øjeblikket ved jeg ikke, om dette er muligt under Linux, eller hvordan man gør det.
Brug af suffikset %<zone_id>, kan vi fjerne kommandolinjeindstillingen -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 ~]$Link-lokale adressesvar
Fra dette all-nodes multicast-ping modtog vi i alt 6 unikke svar.
Disse svar kom fra unicast Link-Local IPv6-værtsadresser. For eksempel, her er det første svar:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresser er påkrævet på alle IPv6-aktiverede grænseflader [RFC4291], "IP Version 6 Addressing Architecture". Grunden til dette er, at en IPv6-node altid automatisk har en unicast IPv6-adresse, som den i det mindste kan bruge til at kommunikere med andre noder på sine direkte forbundne links. Dette inkluderer kommunikation med applikationer på andre værter via Link-Local værtsadresser.
Dette forenkler designet og implementeringen af protokoller som IPv6 Neighbour Discovery og OSPFv3. Det giver også slutbrugerapplikationer på værter mulighed for at kommunikere over kanalen uden at kræve anden understøttende IPv6-infrastruktur på kanalen. Direkte kommunikation mellem tilsluttede IPv6-værter kræver ikke en IPv6-router eller DHCPv6-server på forbindelsen.
Link-Local-adresser starter med et 10-bit præfiks fe80, efterfulgt af 54 nul bit og derefter en 64-bit interface identifier (IID). I ovenstående første svar 2392:6213:a15b:66ff er et 64-bit IID.
Looped Multicast
Som standard returneres multicast-pakker internt til den node, der sendte dem. Dette sker for både IPv6- og IPv4-adressering.
Årsagen til denne standardadfærd er, at når multicast-pakker sendes, kan der også være en lyttende lokal multicast-applikation, der kører på selve afsenderværten såvel som et sted på netværket. Denne lokale applikation skal også modtage multicast-pakker.
Vi kan se denne multicast-lokalløkke i vores ping-output:
[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ørste og hurtigste svar (0,106 ms sammenlignet med 0,453 ms) kommer fra den Link-Local-adresse, der er konfigureret på selve grænsefladen enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Hjælpeprogram ping giver en måde at undertrykke lokal multicast-feedback ved hjælp af parameteren -L. Hvis vi sender et multicast-ping med alle noder med dette flag, er svar begrænset til fjernknuder. Vi modtager ikke et svar fra Link-Local-adressen på afsendergrænsefladen.
[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-lokale adresser
Som du måske kan gætte, giver unicast Link-Local-adresser i sig selv heller ikke nok information til at angive, hvilken grænseflade der skal bruges til at nå dem. Som med all-nodes multicast-ping, skal vi også angive grænsefladen som en kommandolinjeparameter ping eller zone-id med adresse ved ping af Link-Local-adresser.
Denne gang kan vi bruge -cat begrænse antallet af pakker og svar, der sendes og modtages ping, da vi udfører 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 ~]$Ping (alle) andre IPv6-adresser?
I denne artikel så vi, hvordan man pinger alle IPv6-noder på en kanal ved hjælp af en all-nodes multicast IPv6-adresse ff02::1. Vi så også, hvordan man specificerer, hvilken grænseflade der skal bruges med en all-nodes multicast IPv6-adresse, da adressen i sig selv ikke kan give disse oplysninger. Vi brugte enten kommandolinjeindstillingen ping, eller specificerede grænsefladen ved hjælp af suffikset %<zone_id>.
Derefter lærte vi om unicast Link-Local-adresser, som er adresser, der bruges til at svare på multicast ICMPv6-ekko-anmodninger med alle noder.
Vi så også, hvordan multicast-pakker returneres til afsendernoden som standard, og hvordan man deaktiverer dette for værktøjet ping.
Til sidst pingede vi en enkelt Link-Local-adresse ved hjælp af suffikset %<zone_id>, da Link-Local-adresser heller ikke selv giver information om den udgående grænseflade.
Så hvad med at pinge alle de andre noder og få deres globale unicast-adresser (GUA'er) (det vil sige deres offentlige adresser på internettet) eller deres unikke lokale unicast-adresser (ULA'er)? Det vil vi se på i næste blogindlæg.
Det er alt sammen.
Du kan læse mere om vores kursus på.
Kilde: www.habr.com