Queden uns dies per a l'inici d'un nou flux al ritme d'OTUS. En aquest sentit, ens agradaria compartir amb vosaltres una traducció de material útil sobre el tema.
Una sèrie de publicacions de bloc sobre consells i trucs per resoldre problemes de ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Tingueu en compte que estic fent servir Linux (específicament Fedora 31), però la sintaxi de l'ordre ping per a altres sistemes operatius hauria de ser molt semblant.
Feu ping a tots els nodes IPv6 d'un canal
El primer i més senzill consell és fer ping a tots els nodes IPv6 de l'enllaç.
IPv6 utilitza adreces de multidifusió per a tot tipus de comunicacions d'un a molts. No hi ha adreces IPv6 de difusió (o difusió). Això distingeix IPv6 d'IPv4, on hi ha diversos tipus d'adreces de difusió, per exemple, l'adreça de "difusió limitada" 255.255.255.255 [RFC1122].
Tanmateix, hi ha una adreça IPv6 de "multicast de tots els nodes", de manera que la farem servir per fer ping a tots els nodes IPv6 de l'enllaç. (Una adreça de "difusió" és en realitat només una adreça de multidifusió anomenada especialment, que és un grup de multidifusió que inclou tots els nodes. Tingueu en compte que, per exemple, el bit d'adreça de "grup" o multidifusió està activat a les adreces de difusió Ethernet a la capa d'enllaç. ).
Adreça IPv6 multicast de tots els nodes per al canal: ff02::1. ff indica una adreça IPv6 multicast. El següent 0 és la part de la bandera amb bits sense establir.
Addicional 2 defineix l'àrea d'un grup de multidifusió. A diferència de les adreces IPv4 multicast, les adreces IPv6 multicast tenen un abast. El valor d'abast indica la part de la xarxa a la qual es pot reenviar un paquet de multidifusió. Una vegada que un paquet arriba al límit de l'abast especificat, el paquet s'ha de deixar anar, independentment de si el seu camp Hop Count és diferent de zero. Per descomptat, si el recompte de salts arriba a zero abans d'arribar al límit del grup de multidifusió especificat, també es restableix immediatament. Aquí teniu una llista completa de l'àmbit de multidifusió IPv6.
Finalment ::1 especifica un grup de multidifusió de tots els nodes.
Sobre l'adreça ff02::1 Cal tenir en compte que és ambigu. En un host IPv6 amb múltiples interfícies, com ara un encaminador o un host multihomed, l'adreça ff02::1 no hi ha res on pugueu especificar a quina interfície enviar les sol·licituds d'eco ICMPv6 o esperar rebre respostes d'eco ICMPv6 quan arribin. ff02::1 és vàlid i es pot utilitzar en qualsevol de les interfícies i canals connectats al node multiinterfície.
Així, quan fem ping a tots els nodes IPv6 d'un enllaç, d'alguna manera també hem de dir-li a la utilitat ping per a IPv6, quina interfície utilitzar.
Definició d'interfícies - Opció de línia d'ordres
Com ja hem vist, l'adreça de multidifusió de tots els nodes que volem utilitzar és - ff02::1 - no proporciona cap informació sobre quina interfície enviar i rebre paquets de sol·licitud d'eco i resposta d'eco ICMPv6.
Aleshores, com especifiquem la interfície que s'utilitzarà per a l'espai d'adreces multicast o unicast Link-Local?
La primera i la més òbvia és proporcionar-lo com a paràmetre a l'aplicació que estem utilitzant.
Per utilitat ping ho proporcionem a través de l'opció -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 ~]$Utilitzant aquest ping multicast de tots els nodes, vam rebre respostes de 6 nodes IPv6. Les respostes provenien d'adreces de nodes IPv6 d'enllaç local, començant pel prefix fe80::/10.
Que ping no continua enviant peticions d'eco ICMPv6 indefinidament fins que l'interrompem, normalment especifiquem el nombre de paquets a enviar mitjançant l'opció -c. Tanmateix, això també evita que el ping accepti i mostri més d'una resposta d'eco ICMPv6 quan s'envia una sol·licitud d'eco ICMPv6 multicast. En comptes d'això, hem utilitzat l'opció -w per especificar que el ping s'hauria de completar al cap d'1 segon, sense importar quantes sol·licituds d'eco ICMPv6 o respostes d'eco s'hagin enviat o rebut.
Una altra cosa a la qual cal prestar atenció és (DUP!) sortida a la segona i posteriors respostes. Aquests paquets s'identifiquen com a respostes duplicades perquè tenen el mateix valor de seqüència ICMP que les sol·licituds d'eco ICMPv6 individuals que es van enviar en primer lloc. Apareixen perquè una sol·licitud d'eco multidifusió ICMPv6 dóna lloc a diverses respostes d'unidifusió individuals. El nombre de duplicats també s'indica al resum d'estadístiques.
Definició d'interfícies - ID de zona
Una altra manera d'exposar una interfície per utilitzar-la és com a part d'un paràmetre d'adreça IPv6.
Podem veure un exemple d'això a la sortida de ping, on les adreces dels hosts IPv6 que responen també tenen el sufix %enp3s2, per exemple:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msAquest mètode d'especificació d'interfícies es descriu formalment a [RFC4007], "Arquitectura d'adreces definides IPv6". Encara que se solen anomenar interfície del sistema operatiu, en realitat defineixen quelcom més general: una "zona" o "abast".
La raó de tenir zones més generals o zones d'abast és que, com s'esmenta a [RFC4007], un node IPv6 pot tenir diverses interfícies IPv6 diferents connectades al mateix canal. Aquestes interfícies són membres de la mateixa zona.
Hauria de ser possible agrupar múltiples interfícies dins d'una zona sota el sistema operatiu; Actualment no sé si això és possible amb Linux o com fer-ho.
Utilitzant el sufix %<zone_id>, podem eliminar l'opció de línia d'ordres -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 ~]$Enllaç-Respostes a l'adreça local
D'aquest ping multicast de tots els nodes hem rebut un total de 6 respostes úniques.
Aquestes respostes provenien d'adreces d'amfitrió IPv6 d'enllaç local unicast. Per exemple, aquí teniu la primera resposta:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msLes adreces IPv6 locals d'enllaç Unicast són necessàries a totes les interfícies habilitades per IPv6 [RFC4291], "Arquitectura d'adreçament IP versió 6". La raó d'això és que un node IPv6 sempre té automàticament una adreça IPv6 unicast, que almenys pot utilitzar per comunicar-se amb altres nodes als seus enllaços directament connectats. Això inclou la comunicació amb aplicacions d'altres amfitrions mitjançant adreces d'amfitrió d'enllaç local.
Això simplifica el disseny i la implementació de protocols com IPv6 Neighbor Discovery i OSPFv3. També permet que les aplicacions d'usuari final dels amfitrions es comuniquin a través del canal sense necessitat de cap altra infraestructura de suport IPv6 al canal. La comunicació directa entre hosts IPv6 connectats no requereix un encaminador IPv6 ni un servidor DHCPv6 a la connexió.
Les adreces d'enllaços locals comencen amb un prefix de 10 bits fe80, seguit de 54 bits zero i després un identificador d'interfície (IID) de 64 bits. A la primera resposta anterior 2392:6213:a15b:66ff és un IID de 64 bits.
Multicast en bucle
Per defecte, els paquets de multidifusió es retornen internament al node que els va enviar. Això passa amb l'adreçament IPv6 i IPv4.
El motiu d'aquest comportament predeterminat és que quan s'envien paquets de multidifusió, també pot haver-hi una aplicació de multidifusió local que s'executa al propi host d'enviament, així com en algun lloc de la xarxa. Aquesta aplicació local també ha de rebre paquets multicast.
Podem veure aquest bucle local multicast a la nostra sortida de 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!)
...La primera i més ràpida resposta (0,106 ms en comparació amb 0,453 ms) prové de l'adreça Link-Local configurada a la interfície mateixa enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilitat ping proporciona una manera de suprimir la retroalimentació de multidifusió local mitjançant el paràmetre -L. Si enviem un ping multicast de tots els nodes amb aquest senyalador, les respostes es limiten als nodes remots. No rebem cap resposta de l'adreça d'enllaç local de la interfície d'enviament.
[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-Adreces locals
Com podeu suposar, les adreces d'enllaç local d'unicast tampoc no proporcionen prou informació per indicar quina interfície s'ha d'utilitzar per arribar-hi. Igual que amb el ping multicast de tots els nodes, també hem d'especificar la interfície com a paràmetre de línia d'ordres ping o identificador de zona amb adreça quan feu ping a les adreces d'enllaç local.
Aquesta vegada podem utilitzar -cper limitar el nombre de paquets i respostes enviades i rebudes ping, ja que estem fent 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 ~]$Fer ping (a totes) les altres adreces IPv6?
En aquest article, vam veure com fer ping a tots els nodes IPv6 d'un canal mitjançant una adreça IPv6 multicast de tots els nodes ff02::1. També vam veure com especificar quina interfície utilitzar amb una adreça IPv6 multicast de tots els nodes, ja que la mateixa adreça no pot proporcionar aquesta informació. Hem utilitzat l'opció de línia d'ordres ping, o especificar la interfície amb el sufix %<zone_id>.
A continuació, vam conèixer les adreces d'enllaç local d'unicast, que són adreces que s'utilitzen per respondre a les sol·licituds d'eco ICMPv6 multicast de tots els nodes.
També vam veure com els paquets multicast es tornen al node d'enviament de manera predeterminada i com desactivar-ho per a la utilitat ping.
Finalment, vam fer ping a una única adreça d'enllaç local mitjançant el sufix %<zone_id>, ja que les adreces d'enllaç local tampoc no proporcionen informació sobre la interfície de sortida.
Aleshores, què passa amb fer ping a tots els altres nodes i obtenir les seves adreces globals unicast (GUA) (és a dir, les seves adreces públiques a Internet) o les seves adreces unicast local úniques (ULA)? Ho veurem a la propera entrada del blog.
Això és tot.
Podeu obtenir més informació sobre el nostre curs a.
Font: www.habr.com