Rimangono pochi giorni prima dell'inizio di un nuovo flusso al ritmo da OTUS. A questo proposito desideriamo condividere con voi la traduzione di materiale utile sull'argomento.
Una serie di post di blog su suggerimenti e trucchi per la risoluzione dei problemi di ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Tieni presente che sto utilizzando Linux (in particolare Fedora 31), tuttavia si spera che la sintassi del comando ping per altri sistemi operativi dovrebbe essere molto simile.
Effettua il ping di tutti i nodi IPv6 su un canale
Il primo e più semplice suggerimento è eseguire il ping di tutti i nodi IPv6 sul collegamento.
IPv6 utilizza indirizzi multicast per tutti i tipi di comunicazioni uno-a-molti. Non esistono indirizzi IPv6 broadcast (o broadcast). Ciò distingue IPv6 da IPv4, dove esistono diversi tipi di indirizzi di trasmissione, ad esempio l'indirizzo di “trasmissione limitata” 255.255.255.255 [RFC1122].
Tuttavia, esiste un indirizzo IPv6 "multicast di tutti i nodi", quindi lo utilizzeremo per eseguire il ping di tutti i nodi IPv6 sul collegamento. (Un indirizzo "broadcast" è in realtà solo un indirizzo multicast con un nome speciale, che è un gruppo multicast che include tutti i nodi. Si noti che, ad esempio, il bit "gruppo" o indirizzo multicast è attivato negli indirizzi broadcast Ethernet al livello di collegamento ).
Indirizzo IPv6 multicast di tutti i nodi per il canale: ff02::1. ff denota un indirizzo IPv6 multicast. Lo 0 successivo è la parte del flag con i bit non impostati.
Avanti 2 definisce l'area di un gruppo multicast. A differenza degli indirizzi IPv4 multicast, gli indirizzi IPv6 multicast hanno un ambito. Il valore dell'ambito indica la parte della rete su cui è consentito inoltrare un pacchetto multicast. Una volta che un pacchetto raggiunge il limite dell'ambito specificato, il pacchetto deve essere scartato, indipendentemente dal fatto che il suo campo Hop Count sia diverso da zero. Naturalmente, se il conteggio degli hop raggiunge lo zero prima di raggiungere il limite del gruppo multicast specificato, viene immediatamente reimpostato. Ecco un elenco completo dell'ambito multicast IPv6.
Infine, l' ::1 specifica un gruppo multicast composto da tutti i nodi.
Circa l'indirizzo ff02::1 Va notato che è ambiguo. Su un host IPv6 con più interfacce, come un router o un host multihomed, l'indirizzo ff02::1 non è possibile specificare a quale interfaccia inviare le richieste echo ICMPv6 o aspettarsi di ricevere risposte echo ICMPv6 quando arrivano. ff02::1 è valido e può essere utilizzato su qualsiasi interfaccia e canale collegato al nodo multi-interfaccia.
Pertanto, quando eseguiamo il ping di tutti i nodi IPv6 su un collegamento, dobbiamo in qualche modo comunicarlo anche all'utilità ping per IPv6, quale interfaccia utilizzare.
Definizione delle interfacce: opzione della riga di comando
Come abbiamo già visto, l'indirizzo multicast su tutti i nodi che vogliamo utilizzare è − ff02::1 - non fornisce alcuna informazione su quale interfaccia inviare e ricevere i pacchetti di richiesta echo e di risposta echo ICMPv6.
Quindi, come specifichiamo l'interfaccia da utilizzare per lo spazio degli indirizzi multicast o lo spazio degli indirizzi Link-Local unicast?
Il primo e più ovvio modo è fornirlo come parametro all'applicazione che stiamo utilizzando.
Per utilità ping lo forniamo tramite l'opzione -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 ~]$Utilizzando questo ping multicast su tutti i nodi, abbiamo ricevuto risposte da 6 nodi IPv6. Le risposte provenivano dagli indirizzi dei nodi IPv6 Link-Local, iniziando con il prefisso fe80::/10.
Che ping non continua a inviare richieste echo ICMPv6 indefinitamente finché non lo interrompiamo, solitamente specifichiamo il numero di pacchetti da inviare tramite l'opzione -c. Tuttavia, ciò impedisce anche al ping di accettare e visualizzare più di una risposta echo ICMPv6 quando si invia una richiesta echo ICMPv6 multicast. Abbiamo invece utilizzato l'opzione -w per specificare che il ping dovrebbe essere completato dopo 1 secondo, indipendentemente dal numero di richieste echo o risposte echo ICMPv6 inviate o ricevute.
Un'altra cosa a cui prestare attenzione è (DUP!) output sulla seconda risposta e su quelle successive. Questi pacchetti vengono identificati come risposte duplicate perché hanno lo stesso valore di sequenza ICMP delle singole richieste echo ICMPv6 inviate per prime. Appaiono perché una richiesta echo multicast ICMPv6 genera più risposte unicast individuali. Il numero di duplicati è indicato anche nel riepilogo statistico.
Definizione delle interfacce: ID zona
Un altro modo per esporre un'interfaccia per l'uso è come parte di un parametro di indirizzo IPv6.
Possiamo vederne un esempio nell'output del ping, dove anche gli indirizzi degli host IPv6 che rispondono hanno il suffisso %enp3s2, ad esempio:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msQuesto metodo per specificare le interfacce è formalmente descritto in [RFC4007], "IPv6 Defined Address Architecture." Sebbene siano solitamente chiamate interfaccia del sistema operativo, in realtà definiscono qualcosa di più generale: una “zona” o un “ambito”.
La ragione per avere zone più generali o zone di ambito è che, come menzionato in [RFC4007], un nodo IPv6 può avere diverse interfacce IPv6 collegate allo stesso canale. Queste interfacce sono membri della stessa zona.
Dovrebbe essere possibile raggruppare più interfacce all'interno di una zona sotto il sistema operativo; Attualmente non so se questo sia possibile sotto Linux o come farlo.
Utilizzando il suffisso %<zone_id>, possiamo rimuovere l'opzione della riga di comando -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 ~]$Risposte all'indirizzo link-locale
Da questo ping multicast su tutti i nodi abbiamo ricevuto un totale di 6 risposte uniche.
Queste risposte provenivano da indirizzi host IPv6 Link-Local unicast. Ad esempio, ecco la prima risposta:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msGli indirizzi IPv6 Unicast Link-Local sono richiesti su tutte le interfacce abilitate per IPv6 [RFC4291], "Architettura di indirizzamento IP versione 6". Il motivo è che un nodo IPv6 dispone sempre automaticamente di un indirizzo IPv6 unicast, che può almeno utilizzare per comunicare con altri nodi sui suoi collegamenti direttamente collegati. Ciò include la comunicazione con applicazioni su altri host tramite indirizzi host Link-Local.
Ciò semplifica la progettazione e l'implementazione di protocolli come IPv6 Neighbor Discovery e OSPFv3. Consente inoltre alle applicazioni dell'utente finale sugli host di comunicare sul canale senza richiedere altre infrastrutture IPv6 di supporto sul canale. La comunicazione diretta tra host IPv6 connessi non richiede un router IPv6 o un server DHCPv6 sulla connessione.
Gli indirizzi Link-Local iniziano con un prefisso a 10 bit fe80, seguito da 54 bit zero e quindi un identificatore di interfaccia (IID) a 64 bit. Nella prima risposta sopra 2392:6213:a15b:66ff è un IID a 64 bit.
Multicast in loop
Per impostazione predefinita, i pacchetti multicast vengono restituiti internamente al nodo che li ha inviati. Ciò accade sia per l'indirizzamento IPv6 che per quello IPv4.
Il motivo di questo comportamento predefinito è che quando vengono inviati i pacchetti multicast, potrebbe esserci anche un'applicazione multicast locale in ascolto in esecuzione sull'host mittente stesso, nonché da qualche parte sulla rete. Questa applicazione locale deve ricevere anche pacchetti multicast.
Possiamo vedere questo loop locale multicast nel nostro output 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 prima e più rapida risposta (0,106 ms contro 0,453 ms) arriva dall'indirizzo Link-Local configurato sull'interfaccia stessa enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilità ping fornisce un modo per sopprimere il feedback multicast locale utilizzando il parametro -L. Se inviamo un ping multicast a tutti i nodi con questo flag, le risposte sono limitate ai nodi remoti. Non riceviamo una risposta dall'indirizzo Link-Local dell'interfaccia di invio.
[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-Indirizzi locali
Come puoi immaginare, anche gli indirizzi Link-Local unicast da soli non forniscono informazioni sufficienti per indicare quale interfaccia utilizzare per raggiungerli. Come con il ping multicast su tutti i nodi, dobbiamo anche specificare l'interfaccia come parametro della riga di comando ping o ID zona con indirizzo durante il ping degli indirizzi Link-Local.
Questa volta possiamo usare -cper limitare il numero di pacchetti e risposte inviati e ricevuti ping, poiché stiamo eseguendo il 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 ~]$Eseguire il ping di (tutti) gli altri indirizzi IPv6?
In questo articolo abbiamo visto come eseguire il ping di tutti i nodi IPv6 su un canale utilizzando un indirizzo IPv6 multicast su tutti i nodi ff02::1. Abbiamo anche visto come specificare quale interfaccia utilizzare con un indirizzo IPv6 multicast su tutti i nodi, poiché l'indirizzo stesso non può fornire questa informazione. Abbiamo utilizzato l'opzione della riga di comando pingo specificato l'interfaccia utilizzando il suffisso %<zone_id>.
Successivamente abbiamo appreso degli indirizzi Link-Local unicast, che sono indirizzi utilizzati per rispondere alle richieste echo multicast ICMPv6 su tutti i nodi.
Abbiamo anche visto come i pacchetti multicast vengono restituiti al nodo mittente per impostazione predefinita e come disabilitarlo per l'utilità ping.
Infine, abbiamo eseguito il ping di un singolo indirizzo Link-Local utilizzando il suffisso %<zone_id>, poiché anche gli stessi indirizzi Link-Local non forniscono informazioni sull'interfaccia in uscita.
Che ne dici di eseguire il ping di tutti gli altri nodi e ottenere i loro indirizzi unicast globali (GUA) (ovvero i loro indirizzi pubblici su Internet) o i loro indirizzi unicast locali univoci (ULA)? Lo vedremo nel prossimo post del blog.
Questo è tutto.
Puoi scoprire di più sul nostro corso su.
Fonte: habr.com