Ping toate nodurile IPv6 de pe un canal

Au mai rămas câteva zile până la începerea unui nou flux la ritm "Inginer de retea" de la OTUS. În acest sens, am dori să vă împărtășim o traducere a materialului util pe această temă.

Ping toate nodurile IPv6 de pe un canal

O serie de postări pe blog despre sfaturi și trucuri pentru depanarea problemelor de ping IPv6 (ICMPv6 Echo Request/Echo Reply)

Vă rugăm să rețineți că folosesc Linux (în special Fedora 31), totuși sintaxa comenzii ping pentru alte sisteme de operare ar trebui să fie foarte asemănătoare.

Ping toate nodurile IPv6 de pe un canal

Primul și cel mai simplu sfat este să faceți ping la toate nodurile IPv6 de pe link.

IPv6 utilizează adrese multicast pentru toate tipurile de comunicații unu-la-mai multe. Nu există adrese IPv6 de difuzare (sau difuzare). Acest lucru distinge IPv6 de IPv4, unde există mai multe tipuri de adrese de difuzare, de exemplu, adresa de „difuzare limitată” 255.255.255.255 [RFC1122].

Cu toate acestea, există o adresă IPv6 „toate nodurile multicast”, așa că o vom folosi pentru a trimite ping la toate nodurile IPv6 de pe legătură. (O adresă de „difuzare” este de fapt doar o adresă multicast numită special, care este un grup de multicast care include toate nodurile. Rețineți că, de exemplu, bitul de adresă „grup” sau multicast este activat în adresele de difuzare Ethernet la nivelul de legătură. ).

Adresă IPv6 multicast pentru toate nodurile pentru canal: ff02::1. ff denotă o adresă IPv6 multicast. Următorul 0 este partea din steag cu biți nesetati.

Mai departe 2 definește aria unui grup multicast. Spre deosebire de adresele IPv4 multicast, adresele IPv6 multicast au un domeniu de aplicare. Valoarea domeniului de aplicare indică partea rețelei prin care un pachet multicast poate fi transmis. Odată ce un pachet ajunge la limita domeniului de aplicare specificat, pachetul trebuie abandonat, indiferent dacă câmpul său Hop Count este diferit de zero. Desigur, dacă numărul de hop ajunge la zero înainte de a ajunge la limita specificată a grupului multicast, este de asemenea resetat imediat. Iată o listă completă a domeniului de aplicare multicast IPv6.

În cele din urmă, ::1 specifică un grup multicast cu toate nodurile.

Despre adresa ff02::1 Trebuie remarcat faptul că este ambiguu. Pe o gazdă IPv6 cu interfețe multiple, cum ar fi un router sau o gazdă multihomed, adresa ff02::1 nu există nimic în care să puteți specifica ce interfață să trimiteți cererile de eco ICMPv6 sau să vă așteptați să primiți răspunsuri de ecou ICMPv6 când sosesc. ff02::1 este valid și poate fi utilizat pe oricare dintre interfețele și canalele atașate la nodul multi-interfață.

Deci, atunci când trimitem ping la toate nodurile IPv6 de pe o legătură, trebuie să spunem cumva și utilitarului ping pentru IPv6, ce interfață să utilizați.

Definirea interfețelor - Opțiunea liniei de comandă

După cum am văzut deja, adresa multicast pentru toate nodurile pe care dorim să o folosim este - ff02::1 - nu furnizează nicio informație cu privire la ce interfață să trimită și să primească pachetele de solicitare ecou și răspuns ecou ICMPv6.

Deci, cum specificăm interfața care va fi utilizată pentru spațiul de adrese multicast sau spațiul de adrese unicast Link-Local?

Prima și cea mai evidentă modalitate este de a-l oferi ca parametru aplicației pe care o folosim.

Pentru utilitate ping îl oferim prin opțiune -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 ~]$

Folosind acest ping multicast cu toate nodurile, am primit răspunsuri de la 6 noduri IPv6. Răspunsurile au venit de la adresele nodurilor IPv6 Link-Local, începând cu prefixul fe80::/10.

ping nu continuă să trimită cereri de ecou ICMPv6 la nesfârșit până când îl întrerupem, de obicei specificăm numărul de pachete de trimis prin opțiunea -c. Totuși, acest lucru împiedică, de asemenea, ping-ul să accepte și să afișeze mai mult de un răspuns ecou ICMPv6 atunci când trimite o cerere de ecou ICMPv6 multicast. În schimb, am folosit opțiunea -w pentru a specifica că ping-ul ar trebui să se finalizeze după 1 secundă, indiferent de câte solicitări de eco ICMPv6 sau răspunsuri de eco au fost trimise sau primite.

Un alt lucru la care trebuie să acordați atenție este (DUP!) rezultate pentru al doilea și următoarele răspunsuri. Aceste pachete sunt identificate ca răspunsuri duplicate deoarece au aceeași valoare a secvenței ICMP ca și cererile individuale de eco ICMPv6 care au fost trimise în primul rând. Acestea apar deoarece o solicitare de ecou multicast ICMPv6 are ca rezultat mai multe răspunsuri individuale unicast. Numărul de duplicate este, de asemenea, indicat în rezumatul statisticilor.

Definirea interfețelor - ID zone

O altă modalitate de a expune o interfață pentru utilizare este ca parte a unui parametru de adresă IPv6.

Putem vedea un exemplu în acest sens în ieșirea ping, unde adresele gazdelor IPv6 care răspund au și sufixul %enp3s2, de exemplu:

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

Această metodă de specificare a interfețelor este descrisă oficial în [RFC4007], „Arhitectura de adrese definite IPv6”. Deși sunt de obicei numite interfața sistemului de operare, ele definesc de fapt ceva mai general - o „zonă” sau „domeniu”.

Motivul pentru care există zone mai generale sau zone de domeniu este că, așa cum se menționează în [RFC4007], un nod IPv6 poate avea mai multe interfețe IPv6 diferite conectate la același canal. Aceste interfețe sunt membre ale aceleiași zone.

Ar trebui să fie posibilă gruparea mai multor interfețe într-o zonă sub sistemul de operare; În prezent, nu știu dacă acest lucru este posibil sub Linux sau cum să o fac.

Folosind sufixul %<zone_id>, putem elimina opțiunea de linie de comandă -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-Răspunsuri la adresa locală

Din acest ping multicast cu toate nodurile, am primit un total de 6 răspunsuri unice.

Aceste răspunsuri au venit de la adrese de gazdă unicast Link-Local IPv6. De exemplu, iată primul răspuns:

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

Adresele IPv6 Unicast Link-Local sunt necesare pe toate interfețele compatibile cu IPv6 [RFC4291], „Arhitectura de adresare IP Versiunea 6”. Motivul pentru aceasta este că un nod IPv6 are întotdeauna automat o adresă IPv6 unicast, pe care o poate folosi cel puțin pentru a comunica cu alte noduri de pe legăturile sale direct conectate. Aceasta include comunicarea cu aplicațiile de pe alte gazde prin adrese de gazdă Link-Local.

Acest lucru simplifică proiectarea și implementarea protocoalelor precum IPv6 Neighbor Discovery și OSPFv3. De asemenea, permite aplicațiilor utilizatorilor finali de pe gazde să comunice prin canal fără a necesita orice altă infrastructură IPv6 compatibilă pe canal. Comunicarea directă între gazdele IPv6 conectate nu necesită un router IPv6 sau un server DHCPv6 la conexiune.

Adresele Link-Local încep cu un prefix de 10 biți fe80, urmat de 54 de biți zero și apoi de un identificator de interfață (IID) pe 64 de biți. În primul răspuns de mai sus 2392:6213:a15b:66ff este un IID pe 64 de biți.

Multicast în buclă

În mod implicit, pachetele multicast sunt returnate intern la nodul care le-a trimis. Acest lucru se întâmplă atât pentru adresarea IPv6, cât și pentru IPv4.

Motivul pentru acest comportament implicit este că atunci când sunt trimise pachete multicast, poate exista și o aplicație multicast locală care rulează pe gazda de trimitere, precum și undeva în rețea. Această aplicație locală trebuie să primească și pachete multicast.

Putem vedea această buclă locală multicast în ieșirea noastră 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!)
...

Primul și cel mai rapid răspuns (0,106 ms față de 0,453 ms) vine de la adresa Link-Local configurată pe interfața însăși enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

Utilitate ping oferă o modalitate de a suprima feedback-ul local multicast folosind parametrul -L. Dacă trimitem un ping multicast pentru toate nodurile cu acest indicator, atunci răspunsurile sunt limitate la nodurile de la distanță. Nu primim un răspuns de la adresa Link-Local a interfeței de trimitere.

[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-Adrese locale

După cum ați putea ghici, adresele unicast Link-Local, de asemenea, nu oferă suficiente informații pentru a indica ce interfață să utilizați pentru a le ajunge. Ca și în cazul ping-ului multicast cu toate nodurile, trebuie de asemenea să specificăm interfața ca parametru de linie de comandă ping sau ID-ul zonei cu adresa atunci când trimiteți ping la adresele Link-Local.

De data asta putem folosi -cpentru a limita numărul de pachete și răspunsuri trimise și primite ping, deoarece efectuăm ping unicast.

[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 (toate) celelalte adrese IPv6?

În acest articol, am văzut cum să facem ping la toate nodurile IPv6 de pe un canal folosind o adresă IPv6 multicast pentru toate nodurile ff02::1. Am văzut, de asemenea, cum să specificăm ce interfață să folosim cu o adresă IPv6 multicast cu toate nodurile, deoarece adresa în sine nu poate furniza aceste informații. Am folosit fie opțiunea de linie de comandă ping, sau a specificat interfața folosind sufixul %<zone_id>.

Apoi am aflat despre adresele unicast Link-Local, care sunt adrese utilizate pentru a răspunde la cererile de eco ICMPv6 multicast pentru toate nodurile.

Am văzut, de asemenea, cum pachetele multicast sunt returnate la nodul de trimitere în mod implicit și cum să dezactivăm acest lucru pentru utilitar. ping.

În cele din urmă, am făcut ping la o singură adresă Link-Local folosind sufixul %<zone_id>, deoarece adresele Link-Local în sine nu oferă informații despre interfața de ieșire.

Deci, ce zici de ping-ul tuturor celorlalte noduri și de a obține adresele lor globale unicast (GUA) (adică adresele lor publice pe Internet) sau adresele lor unice locale unicast (ULA)? Ne vom uita la asta în următoarea postare pe blog.

Asta e tot.

Puteți afla mai multe despre cursul nostru la notele zilei deschise.

Sursa: www.habr.com

Adauga un comentariu