In pear dagen bliuwe oant it begjin fan in nije stream op it taryf fan OTUS. Yn dit ferbân wolle wy in oersetting mei jo diele fan brûkber materiaal oer it ûnderwerp.
In searje blogposten oer tips en trúkjes foar it oplossen fan problemen mei IPv6 ping (ICMPv6 Echo Request / Echo Reply)
Tink derom dat ik Linux brûke (spesifyk Fedora 31), lykwols soe de ping-kommandosyntaksis foar oare bestjoeringssystemen hooplik heul ferlykber wêze moatte.
Ping alle IPv6-knooppunten op in kanaal
De earste en ienfâldichste tip is om alle IPv6-knooppunten op 'e keppeling te pingjen.
IPv6 brûkt multicast-adressen foar alle soarten ien-op-in protte kommunikaasje. D'r binne gjin útstjoerings (of útstjoeren) IPv6-adressen. Dit ûnderskiedt IPv6 fan IPv4, wêr't ferskate soarten útstjoeradressen binne, bygelyks it "beheinde útstjoering" adres 255.255.255.255 [RFC1122].
D'r is lykwols in "all-nodes multicast" IPv6-adres, dus wy sille dat brûke om alle IPv6-knooppunten op 'e keppeling te pingjen. (In "útstjoering"-adres is eins gewoan in spesjaal neamd multicast-adres, dat is in multicast-groep dy't alle knooppunten omfettet. Tink derom dat bygelyks de "groep" of multicast-adresbit yn Ethernet-útstjoeradressen ynskeakele is by de linklaach ).
All-nodes multicast IPv6-adres foar it kanaal: ff02::1. ff jout in multicast IPv6-adres oan. De folgjende 0 is it diel fan 'e flagge mei net ynstelde bits.
fierder 2 definiearret it gebiet fan in multicast-groep. Oars as multicast IPv4-adressen, hawwe multicast IPv6-adressen in omfang. De omfangwearde jout it diel fan it netwurk oan wêrby't in multicast-pakket trochstjoerd wurdt. Sadree't in pakket de grins fan 'e opjûne omfang berikt, moat it pakket falle wurde, nettsjinsteande oft it Hop Count-fjild net nul is. Fansels, as de hop count nul berikt foar it berikken fan de oantsjutte multicast groep grins, it wurdt ek fuortendaliks weromsette. Hjir is in folsleine list mei IPv6 multicast-omfang.
Einlings ::1 spesifisearret in all-nodes multicast groep.
Oer it adres ff02::1 Dêrby moat opmurken wurde dat it is dûbelsinnich. Op in IPv6 host mei meardere ynterfaces, lykas in router of multihomed host, it adres ff02::1 d'r is neat wêr't jo kinne oantsjutte hokker ynterface jo ICMPv6-echo-fersiken moatte stjoere of ferwachtsje om ICMPv6-echo-antwurden te ûntfangen as se oankomme. ff02::1 is jildich en kin brûkt wurde op ien fan de ynterfaces en kanalen ferbûn oan de multi-interface node.
Dus as wy alle IPv6-knooppunten op in keppeling pingen, moatte wy op ien of oare manier ek it nut fertelle ping foar IPv6, hokker ynterface te brûken.
Defining Interfaces - Kommandorigelopsje
Lykas wy al sjoen hawwe, is it multicast-adres foar all-nodes dat wy wolle brûke - ff02::1 - jout gjin ynformaasje oangeande hokker ynterface te ferstjoeren en ûntfange ICMPv6 echo fersyk en echo antwurd pakketten.
Dat, hoe spesifisearje wy de ynterface dy't brûkt wurdt foar de multicast-adresromte as unicast Link-Lokale adresromte?
De earste en meast foar de hân lizzende manier is om it as parameter te leverjen oan 'e applikaasje dy't wy brûke.
Foar nut ping wy jouwe it troch de opsje -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 ~]$Mei dizze all-nodes multicast-ping krigen wy antwurden fan 6 IPv6-knooppunten. Antwurden kamen fan Link-Local IPv6-knooppuntadressen, begjinnend mei it foarheaksel fe80::/10.
dat ping net trochgean mei it ferstjoeren fan ICMPv6 echo-oanfragen foar ûnbepaalde tiid oant wy it ûnderbrekke, spesifisearje wy normaal it oantal pakketten om te ferstjoeren fia de -c-opsje. Dit foarkomt lykwols ek dat ping mear dan ien ICMPv6 echo antwurd akseptearret en werjaan by it ferstjoeren fan in multicast ICMPv6 echo fersyk. Ynstee dêrfan brûkten wy de -w-opsje om oan te jaan dat ping nei 1 sekonde foltôge moat, nettsjinsteande hoefolle ICMPv6-echo-oanfragen as echo-antwurden ferstjoerd of ûntfongen binne.
In oar ding om omtinken te jaan is (DUP!) útfier op de twadde en folgjende antwurden. Dizze pakketten wurde identifisearre as dûbele antwurden, om't se deselde ICMP-sekwinsjewearde hawwe as de yndividuele ICMPv6 echo-oanfragen dy't yn it earste plak waarden stjoerd. Se ferskine om't in ICMPv6 multicast echo-fersyk resultearret yn meardere yndividuele unicast-antwurden. It oantal duplikaten wurdt ek oanjûn yn 'e statistyk gearfetting.
Defining Schnittstellen - Zone ID
In oare manier om in ynterface te eksposearjen foar gebrûk is as ûnderdiel fan in IPv6-adresparameter.
Wy kinne in foarbyld hjirfan sjen yn 'e ping-útfier, wêr't de adressen fan' e reagearjende IPv6-hosts ek it efterheaksel hawwe %enp3s2bygelyks:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDizze metoade foar it opjaan fan ynterfaces wurdt formeel beskreaun yn [RFC4007], "IPv6 Defined Address Architecture." Hoewol se normaal de ynterface fan it bestjoeringssysteem wurde neamd, definiearje se eins wat algemiener - in "sône" of "berik."
De reden foar it hawwen fan mear algemiene sônes of omfang sônes is dat, lykas neamd yn [RFC4007], in IPv6 knooppunt kin hawwe ferskate ferskillende IPv6 ynterfaces ferbûn mei itselde kanaal. Dizze ynterfaces binne leden fan deselde sône.
It moat mooglik wêze om meardere ynterfaces binnen in sône ûnder it bestjoeringssysteem te groepearjen; Op it stuit wit ik net oft dit mooglik is ûnder Linux of hoe it te dwaan.
Mei help fan it efterheaksel %<zone_id>, kinne wy de kommandorigelopsje fuortsmite -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-Lokaal adres Responses
Fan dizze all-nodes multicast-ping krigen wy yn totaal 6 unike antwurden.
Dizze antwurden kamen fan unicast Link-Lokale IPv6-hostadressen. Hjir is bygelyks it earste antwurd:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Lokale IPv6-adressen binne ferplicht op alle IPv6-ynskeakele ynterfaces [RFC4291], "IP Ferzje 6-adresarsjitektuer". De reden hjirfoar is dat in IPv6-knooppunt altyd automatysk in unicast IPv6-adres hat, dat it op syn minst kin brûke om te kommunisearjen mei oare knopen op syn direkt ferbûne keppelings. Dit omfettet kommunikaasje mei applikaasjes op oare hosts fia Link-Lokale hostadressen.
Dit simplifies it ûntwerp en ymplemintaasje fan protokollen lykas IPv6 Neighbor Discovery en OSPFv3. It lit ek applikaasjes fan ein-brûkers op hosts oer it kanaal kommunisearje sûnder dat in oare stypjende IPv6-ynfrastruktuer op it kanaal nedich is. Direkte kommunikaasje tusken ferbûne IPv6-hosts fereasket gjin IPv6-router of DHCPv6-tsjinner op 'e ferbining.
Link-Lokale adressen begjinne mei in 10-bit prefix fe80, folge troch 54 nul bits en dan in 64-bit ynterface identifier (IID). Yn it boppesteande earste antwurd 2392:6213:a15b:66ff is in 64-bit IID.
Looped Multicast
Standert wurde multicast-pakketten yntern weromjûn nei it knooppunt dat se stjoerd hat. Dit bart foar sawol IPv6- as IPv4-adressering.
De reden foar dit standertgedrach is dat wannear't multicast-pakketten ferstjoerd wurde, d'r kin ek in harkjende lokale multicast-applikaasje rinne op 'e stjoerende host sels, lykas ek earne op it netwurk. Dizze lokale applikaasje moat ek multicast-pakketten ûntfange.
Wy kinne dizze multicast lokale lus sjen yn ús ping-útfier:
[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!)
...It earste en rapste antwurd (0,106 ms fergelike mei 0,453 ms) komt fan it Link-Lokaal adres dat is konfigureare op de ynterface sels enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utility ping jout in manier om lokale multicast-feedback te ûnderdrukken mei de parameter -L. As wy in all-nodes multicast-ping stjoere mei dizze flagge, dan binne antwurden beheind ta knooppunten op ôfstân. Wy krije gjin antwurd fan it Link-Lokaal adres fan de ferstjoerende ynterface.
[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 adressen
Lykas jo miskien riede, jouwe unicast Link-Local-adressen sels ek net genôch ynformaasje om oan te jaan hokker ynterface jo moatte brûke om se te berikken. Lykas by all-nodes multicast-ping, moatte wy ek de ynterface spesifisearje as in kommandorigelparameter ping of sône-ID mei adres by it pingen fan Link-Lokale adressen.
Dizze kear kinne wy brûke -com it oantal pakketten en antwurden te beheinen dat ferstjoerd en ûntfongen is ping, om't wy unicast-ping útfiere.
[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) oare IPv6-adressen?
Yn dit artikel seagen wy hoe't jo alle IPv6-knooppunten op in kanaal kinne pinge mei in multicast-IPv6-adres mei all-nodes ff02::1. Wy hawwe ek sjoen hoe't jo kinne opjaan hokker ynterface te brûken mei in all-nodes multicast IPv6-adres, om't it adres sels dizze ynformaasje net kin leverje. Wy brûkten of de kommandorigelopsje ping, of spesifisearre de ynterface mei it efterheaksel %<zone_id>.
Doe learden wy oer unicast Link-Lokale adressen, dat binne adressen dy't wurde brûkt om te reagearjen op multicast ICMPv6 echo-oanfragen mei alle nodes.
Wy hawwe ek sjoen hoe't multicast-pakketten standert wurde weromjûn nei it ferstjoerknooppunt en hoe't jo dit útskeakelje kinne foar it hulpprogramma ping.
Uteinlik pingen wy in inkeld Link-Lokaal adres mei it efterheaksel %<zone_id>, om't Link-Lokale adressen sels ek gjin ynformaasje jouwe oer de útgeande ynterface.
Dus hoe sit it mei ping alle oare knopen en krije har globale unicast-adressen (GUA's) (dat is, har iepenbiere adressen op it ynternet) of har unike lokale unicast-adressen (ULA's)? Wy sille dit sjen yn 'e folgjende blogpost.
Da's alles.
Jo kinne mear útfine oer ús kursus op.
Boarne: www.habr.com