Det gjenstår noen dager til starten av en ny strømning med hastigheten fra OTUS. I denne forbindelse vil vi gjerne dele med deg en oversettelse av nyttig materiale om emnet.
En serie blogginnlegg om tips og triks for feilsøking av IPv6-pingproblemer (ICMPv6 Echo Request/Echo Reply)
Vær oppmerksom på at jeg bruker Linux (spesielt Fedora 31), men ping-kommandosyntaksen for andre operativsystemer bør forhåpentligvis være veldig lik.
Ping alle IPv6-noder på en kanal
Det første og enkleste tipset er å pinge alle IPv6-noder på lenken.
IPv6 bruker multicast-adresser for alle typer en-til-mange-kommunikasjon. Det er ingen kringkasting (eller kringkasting) IPv6-adresser. Dette skiller IPv6 fra IPv4, hvor det finnes flere typer kringkastingsadresser, for eksempel "limited broadcast"-adressen 255.255.255.255 [RFC1122].
Imidlertid er det en "all-nodes multicast" IPv6-adresse, så vi vil bruke den til å pinge alle IPv6-noder på lenken. (En "broadcast"-adresse er egentlig bare en spesielt navngitt multicast-adresse, som er en multicast-gruppe som inkluderer alle noder. Merk at for eksempel "gruppe"- eller multicast-adressebiten er slått på i Ethernet-kringkastingsadresser på lenkelaget ).
All-nodes multicast IPv6-adresse for kanalen: ff02::1. ff angir en multicast IPv6-adresse. Den neste 0-en er delen av flagget med ikke-innstilte biter.
Neste 2 definerer området til en multicast-gruppe. I motsetning til multicast IPv4-adresser, har multicast IPv6-adresser et omfang. Omfangsverdien angir den delen av nettverket som en multicast-pakke tillates videresendt over. Når en pakke når grensen til det spesifiserte omfanget, må pakken droppes, uavhengig av om dens Hop Count-felt ikke er null. Selvfølgelig, hvis hopptellingen når null før den når den spesifiserte multicast-gruppegrensen, tilbakestilles den også umiddelbart. Her er en komplett liste over IPv6 multicast-omfang.
Til slutt, den ::1 spesifiserer en multicast-gruppe med alle noder.
Om adressen ff02::1 Det skal bemerkes at det er tvetydig. På en IPv6-vert med flere grensesnitt, for eksempel en ruter eller multihomed vert, adressen ff02::1 det er ingenting der du kan spesifisere hvilket grensesnitt du skal sende ICMPv6 ekkoforespørsler til eller forvente å motta ICMPv6 ekkosvar når de kommer. ff02::1 er gyldig og kan brukes på alle grensesnittene og kanalene som er knyttet til multigrensesnittnoden.
Så når vi pinger alle IPv6-noder på en lenke, må vi på en eller annen måte også fortelle verktøyet ping for IPv6, hvilket grensesnitt som skal brukes.
Definere grensesnitt - Kommandolinjealternativ
Som vi allerede har sett, er all-nodes multicast-adressen vi ønsker å bruke − ff02::1 - gir ingen informasjon om hvilket grensesnitt som skal sende og motta ICMPv6 ekkoforespørsel og ekkosvarpakker.
Så hvordan spesifiserer vi grensesnittet som skal brukes for multicast-adresseområdet eller unicast Link-Local-adresseområdet?
Den første og mest åpenbare måten er å gi den som en parameter til applikasjonen vi bruker.
For nytte ping vi gir det gjennom 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 ~]$Ved å bruke dette multicast-pinget med alle noder, mottok vi svar fra 6 IPv6-noder. Svarene kom fra Link-Local IPv6-nodeadresser, som starter med prefikset fe80::/10.
At ping fortsetter ikke å sende ICMPv6 ekkoforespørsler på ubestemt tid før vi avbryter det, spesifiserer vi vanligvis antall pakker som skal sendes via -c-alternativet. Dette forhindrer imidlertid også at ping godtar og viser mer enn ett ICMPv6 ekkosvar når du sender en multicast ICMPv6 ekkoforespørsel. I stedet brukte vi alternativet -w for å spesifisere at ping skal fullføres etter 1 sekund, uansett hvor mange ICMPv6 ekkoforespørsler eller ekkosvar som ble sendt eller mottatt.
En annen ting å være oppmerksom på er (DUP!) utgang på andre og påfølgende svar. Disse pakkene identifiseres som dupliserte svar fordi de har samme ICMP-sekvensverdi som de individuelle ICMPv6-ekkoforespørslene som ble sendt i utgangspunktet. De vises fordi en ICMPv6 multicast ekkoforespørsel resulterer i flere individuelle unicast-svar. Antall duplikater er også angitt i statistikksammendraget.
Definere grensesnitt - Sone ID
En annen måte å eksponere et grensesnitt for bruk på er som en del av en IPv6-adresseparameter.
Vi kan se et eksempel på dette i ping-utgangen, der adressene til de svare IPv6-vertene også har suffikset %enp3s2, for eksempel:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDenne metoden for å spesifisere grensesnitt er formelt beskrevet i [RFC4007], "IPv6 Defined Address Architecture." Selv om de vanligvis kalles operativsystemgrensesnittet, definerer de faktisk noe mer generelt - en "sone" eller "omfang".
Grunnen til å ha mer generelle soner eller scope-soner er at, som nevnt i [RFC4007], kan en IPv6-node ha flere forskjellige IPv6-grensesnitt koblet til samme kanal. Disse grensesnittene er medlemmer av samme sone.
Det skal være mulig å gruppere flere grensesnitt innenfor en sone under operativsystemet; Foreløpig vet jeg ikke om dette er mulig under Linux eller hvordan man gjør det.
Bruker suffikset %<zone_id>, kan vi fjerne kommandolinjealternativet -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-lokal adresse-svar
Fra denne all-nodes multicast ping mottok vi totalt 6 unike svar.
Disse svarene kom fra unicast Link-Local IPv6-vertsadresser. For eksempel, her er det første svaret:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresser kreves på alle IPv6-aktiverte grensesnitt [RFC4291], "IP Version 6 Addressing Architecture". Grunnen til dette er at en IPv6-node alltid automatisk har en unicast IPv6-adresse, som den i det minste kan bruke til å kommunisere med andre noder på sine direkte tilkoblede lenker. Dette inkluderer kommunikasjon med applikasjoner på andre verter via Link-Local vertsadresser.
Dette forenkler utformingen og implementeringen av protokoller som IPv6 Neighbour Discovery og OSPFv3. Det lar også sluttbrukerapplikasjoner på verter kommunisere over kanalen uten å kreve annen støttende IPv6-infrastruktur på kanalen. Direkte kommunikasjon mellom tilkoblede IPv6-verter krever ikke en IPv6-ruter eller DHCPv6-server på tilkoblingen.
Link-Local-adresser starter med et 10-biters prefiks fe80, etterfulgt av 54 null biter og deretter en 64-bits grensesnittidentifikator (IID). I det første svaret ovenfor 2392:6213:a15b:66ff er en 64-bits IID.
Looped Multicast
Som standard returneres multicast-pakker internt til noden som sendte dem. Dette skjer for både IPv6- og IPv4-adressering.
Årsaken til denne standardoppførselen er at når multicast-pakker sendes, kan det også være en lyttende lokal multicast-applikasjon som kjører på selve avsenderverten, så vel som et sted på nettverket. Denne lokale applikasjonen må også motta multicast-pakker.
Vi kan se denne multicast-lokalsløyfen i pingutgangen vår:
[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!)
...Den første og raskeste responsen (0,106 ms sammenlignet med 0,453 ms) kommer fra Link-Local-adressen som er konfigurert på selve grensesnittet enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Nytte ping gir en måte å undertrykke lokal multicast-tilbakemelding ved å bruke parameteren -L. Hvis vi sender et multicast-ping med alle noder med dette flagget, er svarene begrenset til eksterne noder. Vi mottar ikke svar fra Link-Local-adressen til sendergrensesnittet.
[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-lenke-lokale adresser
Som du kanskje gjetter, gir unicast Link-Local-adresser i seg selv heller ikke nok informasjon til å indikere hvilket grensesnitt som skal brukes for å nå dem. Som med all-nodes multicast ping, må vi også spesifisere grensesnittet som en kommandolinjeparameter ping eller sone-ID med adresse ved pinging av Link-Local-adresser.
Denne gangen kan vi bruke -cfor å begrense antall pakker og svar som sendes og mottas ping, siden vi utfø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 artikkelen så vi hvordan du pinger alle IPv6-noder på en kanal ved å bruke en multicast-IPv6-adresse for alle noder ff02::1. Vi så også hvordan man spesifiserer hvilket grensesnitt som skal brukes med en all-nodes multicast IPv6-adresse, siden adressen i seg selv ikke kan gi denne informasjonen. Vi brukte enten kommandolinjealternativet ping, eller spesifisert grensesnittet ved hjelp av suffikset %<zone_id>.
Så lærte vi om unicast Link-Local-adresser, som er adresser som brukes til å svare på multicast ICMPv6-ekkoforespørsler med alle noder.
Vi så også hvordan multicast-pakker returneres til sendernoden som standard, og hvordan du deaktiverer dette for verktøyet ping.
Til slutt pinget vi en enkelt Link-Local-adresse ved å bruke suffikset %<zone_id>, siden Link-Local-adresser i seg selv heller ikke gir informasjon om det utgående grensesnittet.
Så hva med å pinge alle de andre nodene og få deres globale unicast-adresser (GUAer) (det vil si deres offentlige adresser på Internett) eller deres unike lokale unicast-adresser (ULA)? Vi skal se på dette i neste blogginnlegg.
Det er alt.
Du kan finne ut mer om kurset vårt på.
Kilde: www.habr.com