Der er kun få dage tilbage til starten af det nye hold på kurset fra OTUS. I den forbindelse ønsker vi at dele en nyttig oversættelse af materialet om emnet med jer.
En serie blogindlæg dedikeret til tips og anbefalinger til fejlfinding relateret til IPv6 ping (ICMPv6 Echo Request/Echo Reply)
Bemærk, at jeg bruger Linux (især Fedora 31), men syntaksen for ping-kommandoen burde være ret lignende på andre operativsystemer.
Ping af alle IPv6-noder på kanalen
Det første og mest grundlæggende råd er at pinge alle IPv6-noder på kanalen.
IPv6 bruger multicast-adresser til alle former for «one-to-many» kommunikation. Der er ikke 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].
Men der findes en “all-nodes multicast” (fælles multicast) IPv6-adresse, og vi vil bruge den til at pinge alle IPv6-noder på kanalen. («Broadcast» adressen er i virkeligheden blot en specielt navngivet multicast-adresse, som er en gruppe af multicast, der inkluderer alle noder. Bemærk, at for eksempel ‘gruppe’-bit eller multicast-adresse er inkluderet i broadcast-adresser på Ethernet-niveau).
All-nodes multicast IPv6-adresse for kanalen: ff02::1. ff angiver en multicast IPv6-adresse. Den næste 0 er en del af flaget med ikke-indstillede bits.
Næste 2 definerer omfanget af multicast-gruppen. I modsætning til multicast IPv4-adresser, har multicast IPv6-adresser scope (synlighedsområde). Værdien af scope angiver den del af netværket, hvor multicast-pakken må videresendes. Når pakken når grænsen for det angivne scope, skal pakken kastes, uanset om dens hop-tæller (Hop Count) er nul eller ej. Selvfølgelig, hvis hop-tælleren når nul, før den når den angivne grænse for multicast-gruppen, vil den også straks blive droppet. Her er den fulde liste over multicast scope IPv6.
Endelig, ::1 angiver all-nodes multicast gruppen.
Om adressen ff02::1 skal det bemærkes, at den er tvetydig. På en IPv6-node med flere interfaces, såsom en router eller en multinetværkshost, i adressen ff02::1 Der er ikke noget sted, hvor man kan angive, hvilken grænseflade der skal sendes ICMPv6 ekko-anmodninger til, eller hvor man skal forvente at modtage ICMPv6 ekko-svar, når de kommer. ff02::1 Det er gyldigt og kan bruges på enhver af de grænseflader og kanaler, der er knyttet til en multi-interface node.
Derfor, når vi pinger alle IPv6 noder på kanalen, skal vi på en eller anden måde også informere værktøjet ping for IPv6, hvilken grænseflade der skal bruges.
Angivelse af grænseflader er et kommandolinjeparameter.
Som vi allerede har set, er multicast adressen all-nodes, som vi ønsker at bruge — ff02::1 — ikke informativ, hvad angår, hvilken grænseflade der skal bruges til at sende og modtage ICMPv6 ekko-anmodninger og ekko-svar.
Så hvordan angiver vi grænsefladen, der skal bruges til multicast adresser eller unicast Link-Local adresser?
Den første og mest åbenlyse måde er at angive den som en parameter for den applikation, vi bruger.
For værktøjet ping giver vi den via indstillingen -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Advarsel: kildeadresse kan vælges på en anden enhed end: enp3s2
PING ff02::1(ff02::1) fra :: enp3s2: 56 data bytes
64 bytes fra fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes fra fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes fra fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes fra fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes fra fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes fra fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistikker ---
1 pakker sendt, 1 modtaget, +5 duplikater, 0% pakke tab, tid 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Med denne all-nodes multicast ping modtog vi svar fra 6 IPv6 noder. Svarene kom fra node-link-lokale IPv6 adresser, der starter med præfikset fe80::/10.
For at ping sendte ikke uendeligt ICMPv6 ekko-anmodninger, indtil vi stoppede den, normalt angiver vi antallet af pakker, der skal sendes via indstillingen -c. Men dette tillader heller ikke ping at acceptere og vise mere end et ICMPv6 ekko-svar, når der sendes en multicast ICMPv6 ekko-anmodning. I stedet brugte vi parameteren -w for at angive, at ping skulle afsluttes efter 1 sekund, uanset hvor mange ekko-anmodninger eller ICMPv6 ekko-svar der blev sendt eller modtaget.
En anden ting at bemærke er (DUP!) output on the second and subsequent responses. These packets are identified as duplicate responses because they have the same ICMP sequence number as individual ICMPv6 echo requests that were sent first. They appear because the multicast ICMPv6 echo request leads to several individual unicast responses. The number of duplicates is also indicated in the summary statistics.
Definition of interfaces - Zone ID
Another way to provide an interface for use is as part of the IPv6 address parameter.
We can observe an example of this in the ping output, where the addresses of responding IPv6 nodes also have a suffix %enp3s2, for eksempel:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msThis way of specifying interfaces is formally described in [RFC4007], "Architecture of IPv6 Scoped Addresses." Although they are usually referred to as the operating system's interface, they actually define something more general - a "zone" or "scope."
The reason for having more general zones or scope zones is that, as mentioned in [RFC4007], an IPv6 node can have several different IPv6 interfaces connected to the same link. These interfaces are members of one zone.
It should be possible to group multiple interfaces within a zone under the operating system; Currently, I do not know if this is possible under Linux and how to do it.
Using the suffix %, we can remove the command line parameter -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-Local address responses
From this all-nodes multicast ping, we received a total of 6 unique responses.
These responses came from the unicast Link-Local addresses of IPv6 nodes. For example, here is the first response:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresser kræves på alle interfaces, der understøtter IPv6 [RFC4291], "Arkitekturen af IP-adressering version 6". Årsagen hertil er, at en IPv6-node altid automatisk har en unicast IPv6-adresse, som den kan bruge, i det mindste til at kommunikere med andre noder over dens direkte tilsluttede forbindelser. Dette inkluderer kommunikation med applikationer fra andre værter via Link-Local adresser.
Det forenkler udviklingen og implementeringen af protokoller som IPv6 Neighbor Discovery og OSPFv3. Det muliggør også, at slutbrugerapplikationer på værter kan udveksle data over forbindelsen uden at kræve nogen anden understøttende infrastruktur for IPv6 på kanalen. For direkte forbindelse mellem tilsluttede værter kræves der ingen IPv6-router eller DHCPv6-server i forbindelsen.
Link-Local adresser begynder med en 10-bit præfiks fe80, efterfulgt af 54 nul-bits og derefter en 64-bit interface-id (IID). I det førnævnte første svar 2392:6213:a15b:66ff — er dette et 64-bit IID.
Looped Multicast
Som standard returneres multicast-pakker internt til den node, der sender dem. Dette gælder for både IPv6 og IPv4 adressering.
Årsagen til denne standardadfærd er, at når der sendes multicast-pakker, kan der også være en lytte-applikation til lokal multicast, der kører på den samme sendende værtsmaskine, ligesom et eller andet sted i netværket. Denne lokale applikation skal også modtage multicast-pakkerne.
Vi kan se denne multicast-lokale cyklus 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 Link-Local adressen, der er konfigureret på selve interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utility ping tilbyder en metode til at undertrykke lokal feedback på multicast-udsendelse ved hjælp af parameteren -L. Hvis vi sender pingen til all-nodes multicast med dette flag, begrænses svarene til fjerne noder. Vi modtager ikke svar fra Link-Local adressen på senderens interface.
[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 gætte, giver unicast Link-Local adresser i sig selv heller ikke nok oplysninger til at angive, hvilken grænseflade der skal bruges for at nå dem. Ligesom med all-nodes multicast ping, skal vi også angive grænsefladen som en kommandolinjeparameter. ping eller zone-ID med adressen, når vi pinger Link-Local adresser.
Denne gang kan vi bruge -c, for at 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 ~]$Pinge (alle) andre IPv6-adresser?
I denne artikel så vi, hvordan man pinger alle IPv6-noder på kanalen ved at bruge all-nodes multicast IPv6-adressen. ff02::1Vi så også, hvordan man angiver, hvilken grænseflade der skal bruges med all-nodes multicast IPv6-adressen, da selve adressen ikke kan give denne information. Vi brugte enten kommandolinjeparameteren ping, eller angav grænsefladen via suffikset %.
Derefter lærte vi om unicast Link-Local adresser, som er adresser, der bruges til at svare på all-nodes multicast echo-forespørgsler ICMPv6.
Vi så også, hvordan multicast-pakker returneres til den afsendende node som standard, og hvordan man deaktiverer dette for værktøjet ping.
Endelig pingede vi en enkelt Link-Local adresse ved at bruge suffikset %, da Link-Local adresser i sig selv heller ikke giver oplysninger om den udgående grænseflade.
Hvad med at pinge alle andre noder og få deres globale unicast adresser (GUA) (det vil sige deres offentlige adresser på internettet) eller deres unikke lokale unicast adresser (ULA)? Vi vil se på dette i næste blogartikel.
Det var alt for nu.
Du kan læse mere om vores kursus i.
Kilde: habr.com
