Pinging av alle IPv6-noder på kanalen

Bare dager igjen til oppstart av det nye kurset «Nettverksingeniør» fra OTUS. I den forbindelse ønsker vi å dele en nyttig oversettelse av materiale om emnet med deg.

En serie blogginnlegg som er viet til tips og anbefalinger for feilsøking relatert til IPv6 ping (ICMPv6 Echo Request/Echo Reply)

Vennligst merk at jeg bruker Linux (spesielt Fedora 31), men syntaksen for ping-kommandoen burde være veldig lik på andre operativsystemer.

Pinging av alle IPv6-noder på kanalen

Det første og enkleste tipset er å pinge alle IPv6-noder på kanalen.

IPv6 bruker multicast-adresser for alle typer 'én til mange'-kommunikasjon. Det finnes ingen broadcast (eller bredbånds) IPv6-adresser. Dette skiller IPv6 fra IPv4, hvor det finnes flere typer broadcast-adresser, for eksempel 'limited broadcast' adresse 255.255.255.255 [RFC1122].

Det finnes imidlertid en 'all-nodes multicast' (felles multicast) IPv6-adresse, så vi vil bruke den for å pinge alle IPv6-noder på kanalen. ('Bredbånds'-adressen er faktisk bare en spesialnavnert multicast-adresse, som er en gruppe av multicast som omfatter alle noder. Vær oppmerksom på at for eksempel 'gruppe'-bit eller multicast-adressen er inkludert i bredbåndsadresser på Ethernet-nivå).

All-nodes multicast IPv6-adresse for kanalen: ff02::1. ff indikerer multicast IPv6-adressen. Det neste 0 er delen av flagget med ikke-innstilte biter.

Deretter 2 definerer området for multicast-gruppen. I motsetning til multicast IPv4-adresser har multicast IPv6-adresser scope (synlighetsområde). Verdien av scope viser hvilken del av nettverket som tillates å videresende multicast-pakken. Så snart pakken når grensen for det angitte scope, må pakken kastes, uavhengig av om dens hop-kontrollfelt (Hop Count) er null. Selvfølgelig, hvis hop-kontrollverdien når null før den når den angitte grensen for multicast-gruppen, vil den også umiddelbart bli kastet. Her er hele listen over multicast scope IPv6.

Til slutt, ::1 angir all-nodes multicast-gruppen.

Om adressen ff02::1 bør det bemerkes at den er tvetydig. På en IPv6-node med flere grensesnitt, som en ruter eller multi-interface vert, i adressen ff02::1 Det finnes ingenting som angir hvilken grensesnitt som skal brukes for å sende ICMPv6 ekkoforespørsel eller forvente å motta ICMPv6 ekko-svar når de ankommer. ff02::1 Den er gyldig og kan brukes på alle grensesnitt og kanaler som er knyttet til en flergrensesnittsnute.

Derfor, når vi pinger alle IPv6-noder på kanalen, må vi på en eller annen måte også informere verktøyet ping om hvilket grensesnitt som skal brukes for IPv6.

Grensesnittdefinisjon er en kommandolinjeparameter.

Som vi allerede har sett, er all-nodes multicast-adressen vi ønsker å bruke — ff02::1 — den gir ingen informasjon om hvilket grensesnitt som skal brukes for å sende og motta ICMPv6 ekkoforespørsel og ekko-svar.

Så hvordan kan vi spesifisere grensesnittet som skal brukes for multicast-adresser eller unicast Link-Local adresser?

Den første og mest åpenbare måten er å gi det som en parameter til applikasjonen vi bruker.

For verktøyet ping gir vi det gjennom alternativet -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Advarsel: kildeadresse kan bli valgt på en enhet annet enn: enp3s2
PING ff02::1(ff02::1) fra :: enp3s2: 56 data-byte
64 bytes fra fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tid=0.438 ms
64 bytes fra fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tid=0.589 ms (DUP!)
64 bytes fra fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 tid=5.15 ms (DUP!)
64 bytes fra fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 tid=58.0 ms (DUP!)
64 bytes fra fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 tid=62.3 ms (DUP!)
64 bytes fra fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 tid=62.8 ms (DUP!)

--- ff02::1 ping-statistikk ---
1 pakker sendt, 1 mottatt, +5 duplikater, 0% pakktap, tid 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

Ved hjelp av denne all-nodes multicast-pingen fikk vi svar fra 6 IPv6-noder. Responsene kom fra nodale Link-Local IPv6-adresser, som begynner med prefikset fe80::/10.

For å ping unngå å fortsette å sende ICMPv6 ekkoforespørsel uendelig til vi avbryter det, angir vi vanligvis antall pakker som skal sendes gjennom alternativet -c. Men dette lar heller ikke ping ta imot og vise mer enn ett ICMPv6 ekko-svar når vi sender multicast ekkoforespørsel. I stedet brukte vi parameteren -w for å indikere at ping skulle avsluttes etter 1 sekund, uavhengig av hvor mange ekkoforespørsel eller ICMPv6 ekko-svar som ble sendt eller mottatt.

En annen ting å merke seg er (DUP!) utdata på andre og påfølgende svar. Disse pakkene identifiseres som duplikater av svaret fordi de har samme ICMP sekvensverdi som de individuelle ICMPv6 ekkoforespørslene som først ble sendt. De vises fordi multicast ICMPv6 ekkoforespørsel fører til flere individuelle unicast svar. Antallet duplikater blir også angitt i statistikkoppsummeringen.

Definere grensesnitt — Zone ID

En annen måte å gi et grensesnitt til bruk på er å være en del av IPv6 adressens parameter.

Vi kan observere et eksempel på dette i ping-utdataene, der adressene til svarende IPv6-noder også har suffiks %enp3s2, for eksempel:

64 bytes fra fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tid=0.438 ms

Denne metoden for å spesifisere grensesnitt er formelt beskrevet i [RFC4007], «IPv6-adressearkitektur med spesifiserte adresser». Selv om de vanligvis omtales som operativsystemets grensesnitt, definerer de faktisk noe mer generelt — «sone» eller «område».

Grunnen til at det finnes mer generelle soner eller scope soner, er at, som nevnt i [RFC4007], kan en IPv6-node ha flere forskjellige IPv6-grensesnitt tilkoblet samme nettverk. Disse grensesnittene er medlemmer av samme sone.

Det bør være mulig å gruppere flere grensesnitt innenfor en sone under operativsystemet; jeg vet for øyeblikket ikke om dette er mulig under Linux, og hvordan det kan gjøres.

Ved å bruke suffikset %, kan vi fjerne kommandolinjeargumentet -I ping.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes fra fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tid=0.106 ms
64 bytes fra fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tid=0.453 ms (DUP!)
64 bytes fra fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tid=0.606 ms (DUP!)
64 bytes fra fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 tid=6.23 ms (DUP!)
64 bytes fra fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 tid=157 ms (DUP!)
64 bytes fra fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 tid=159 ms (DUP!)
64 bytes fra fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 tid=161 ms (DUP!)
64 bytes fra fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 tid=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping-statistikk ---
1 pakker sendt, 1 mottatt, +7 duplikater, 0% pakketap, tid 0ms
rtt min/avg/maks/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

Svar fra Link-Local adresser

Fra denne all-nodes multicast ping fikk vi totalt 6 unike svar.

Disse svarene kom fra unicast Link-Local adresser til IPv6-noder. For eksempel, her er det første svaret:

64 bytes fra fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tid=0.106 ms

Unicast Link-Local IPv6-adresser er nødvendig på alle grensesnitt med IPv6-støtte [RFC4291], "Arkitektur for IP-adressering versjon 6". Grunnen til dette er at et IPv6-nod alltid automatisk har en unicast IPv6-adresse som det kan bruke, i det minste for å kommunisere med andre noder over sine direkte tilkoblede kanaler. Dette inkluderer kommunikasjon med applikasjoner på andre verter via Link-Local adresser til vertene.

Dette gjør utviklingen og implementeringen av protokoller som IPv6 Neighbor Discovery og OSPFv3 enklere. Det lar også sluttbruker-applikasjoner på verter utveksle data over kanalen, uten å kreve noe annet som støtter IPv6-infrastruktur på kanalen. For direkte kommunikasjon mellom tilkoblede IPv6-verter er det ikke nødvendig med en IPv6-ruter eller DHCPv6-server i forbindelsen.

Link-Local adresser begynner med en 10-bits prefiks fe80, etterfulgt av 54 nullbiter, og deretter en 64-bits grensesnittidentifikator (IID). I det første svaret ovenfor 2392:6213:a15b:66ff — er dette 64-bits IID.

Looped Multicast

Som standard returneres multicast-pakkene internt til noden som sender dem. Dette gjelder både IPv6 og IPv4 adressering.

Årsaken til denne standardoppsettet er at når multicast-pakker sendes, kan det også være en lytteapplikasjon for lokal multicast som kjører på den sendende verten, i tillegg til et annet sted i nettverket. Denne lokale applikasjonen må også motta multicast-pakkene.

Vi kan se denne multicast-lokale sløyfen 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ørste og raskeste svaret (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 ~]$

Verktøy ping gir en måte å undertrykke lokal tilbakemelding av multicast-distribusjon ved hjelp av parameteren -L. Hvis vi sender en ping til all-nodes multicast med dette flagget, vil svarene begrenses til eksterne noder. Vi får ikke svar fra Link-Local adressen til senderens grensesnitt.

[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 gjette, gir unicast Link-Local adresser ikke nok informasjon om hvilken grensesnitt som skal brukes for å nå dem. Som med all-nodes multicast ping, må vi også angi grensesnittet som et kommandolinjeargument ping eller zone ID med adressen når vi pinger Link-Local adresser.

Denne gangen kan vi bruke -c, for å begrense antall pakker og svar som sendes og mottas ping, ettersom 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 statistikk ---
1 pakker sendt, 1 mottatt, 0% packet loss, tid 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

Pinge (alle) andre IPv6 adresser?

I denne artikkelen så vi hvordan vi kan pinge alle IPv6-noder i kanalen ved å bruke all-nodes multicast IPv6-adressen ff02::1. Vi så også hvordan vi angir hvilket grensesnitt som skal brukes med all-nodes multicast IPv6-adressen, ettersom selve adressen ikke kan gi denne informasjonen. Vi brukte enten kommandolinjeargumentet ping, eller spesifiserte grensesnittet gjennom suffikset %.

Deretter lærte vi om unicast Link-Local adresser som brukes til å svare på all-nodes multicast ICMPv6 echo forespørsel.

Vi så også hvordan multicast-pakker returneres til den sendende noden som standard, og hvordan vi kan deaktivere dette for verktøyet ping.

Til slutt pinget vi en enkelt Link-Local adresse ved å bruke suffikset %, ettersom Link-Local adresser også ikke gir informasjon om utgående grensesnitt.

Hva med å ping hele andre noder og hente deres globale unicast adresser (GUA) (det vil si deres offentlige adresser på internett) eller deres unike lokale unicast adresser (ULA)? Vi vil se på dette i neste blogginnlegg.

Det var alt.

Du kan lære mer om kurset vårt i opptak av åpen dag.

Kilde: habr.com