Mancano solo pochi giorni all'inizio del nuovo corso da OTUS. A tal proposito, vogliamo condividere con voi la traduzione di materiale utile sull'argomento.
Serie di articoli del blog dedicati a consigli e raccomandazioni per la risoluzione di problemi relativi al ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Si prega di notare che sto utilizzando Linux (in particolare, Fedora 31), tuttavia il sintassi del comando ping dovrebbe essere molto simile su altri sistemi operativi.
Ping di tutti i nodi IPv6 sul canale
Il primo e il più semplice consiglio è di eseguire il ping di tutti i nodi IPv6 sul canale.
IPv6 utilizza indirizzi multicast per tutti i tipi di comunicazione «uno a molti». Non esistono indirizzi broadcast (o a diffusione) IPv6. Questo distingue IPv6 da IPv4, dove ci sono diversi tipi di indirizzi broadcast, come l'indirizzo «limited broadcast» 255.255.255.255 [RFC1122].
Tuttavia, esiste un indirizzo multicast IPv6 “all-nodes” (multicast generale), quindi lo useremo per eseguire il ping di tutti i nodi IPv6 nel canale. (L'indirizzo di broadcast è in realtà semplicemente un indirizzo multicast specificamente denominato, che è un gruppo di trasmissione multicast che include tutti i nodi. Si noti che, ad esempio, il bit "gruppo" o dell'indirizzo multicast è incluso negli indirizzi di broadcast Ethernet a livello di collegamento).
Indirizzo multicast IPv6 all-nodes per il canale: ff02::1. ff indica l'indirizzo multicast IPv6. Il successivo 0 è la parte del flag con bit non impostati.
Avanti 2 determina l'ambito del gruppo multicast. A differenza degli indirizzi multicast IPv4, gli indirizzi multicast IPv6 hanno un'area di visibilità. Il valore dell'ambito indica la parte della rete attraverso la quale è consentito inoltrare il pacchetto multicast. Una volta che il pacchetto raggiunge il confine dell'ambito specificato, deve essere scartato, indipendentemente dal fatto che il suo campo del contatore dei salti (Hop Count) sia diverso da zero. Naturalmente, se il contatore dei salti raggiunge zero prima di raggiungere il confine specificato del gruppo multicast, viene subito azzerato. Ecco l'elenco completo degli ambiti multicast IPv6.
Infine, ::1 indica il gruppo multicast di tutti i nodi.
Riguardo all'indirizzo ff02::1 si deve notare che è ambiguo. Su un nodo IPv6 con più interfacce, come un router o un host multiinterfaccia, nell'indirizzo ff02::1 non c'è nulla che indichi a quale interfaccia inviare le richieste di eco ICMPv6 o aspettare le risposte di eco ICMPv6 quando arrivano. ff02::1 è valido e può essere utilizzato su qualsiasi delle interfacce e canali collegati al nodo multiinterfaccia.
Pertanto, quando pinghiamo tutti i nodi IPv6 su un canale, dobbiamo anche in qualche modo comunicare l'utilità ping per IPv6, quale interfaccia utilizzare.
Definizione delle interfacce - parametro della riga di comando
Come abbiamo già visto, l'indirizzo multicast all-nodes che vogliamo utilizzare è ff02::1 non fornisce alcuna informazione su quale interfaccia inviare e ricevere pacchetti di richiesta e risposta ICMPv6.
Quindi, come possiamo specificare l'interfaccia che sarà utilizzata per lo spazio degli indirizzi multicast o per gli indirizzi Link-Local unicast?
Il primo e più ovvio modo è fornirlo come parametro per l'applicazione che stiamo usando.
Per l'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 ~]$Con questo ping multicast all-nodes abbiamo ricevuto risposte da 6 nodi IPv6. Le risposte sono arrivate da indirizzi IPv6 Link-Local, a partire dal prefisso fe80::/10.
Per creare un file di esportazione del database di gestione sul server di origine: ping non abbiamo continuato a inviare richieste di eco ICMPv6 all'infinito fino a quando non lo interrompiamo, di solito specifichiamo il numero di pacchetti da inviare tramite l'opzione -c. Tuttavia, ciò non consente a ping di accettare e visualizzare più di una risposta di eco ICMPv6 durante l'invio di una richiesta di eco multicast ICMPv6. Invece, abbiamo utilizzato il parametro -w per indicare che ping dovrebbe terminare dopo 1 secondo, indipendentemente da quanti richieste di eco o risposte ICMPv6 sono state inviate o ricevute.
Un'altra cosa a cui prestare attenzione è (DUP!) l'output sui secondi e successivi risposte. Questi pacchetti sono identificati come risposte duplicate poiché hanno lo stesso valore di sequenza ICMP di quelle singole risposte di eco ICMPv6 che sono state inviate per prime. Appaiono poiché una richiesta di eco multicast ICMPv6 porta a molteplici risposte unicast individuali. Il numero di duplicati è anche indicato nel riepilogo delle statistiche.
Definizione delle interfacce — Zone ID
Un altro modo per fornire un'interfaccia da utilizzare è una parte del parametro dell'indirizzo IPv6.
Possiamo osservare un esempio di questo nell'output del ping, dove gli indirizzi dei nodi IPv6 che rispondono hanno anche il suffisso %enp3s2, ad esempio:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msQuesto modo di specificare le interfacce è formalmente descritto in [RFC4007], "Architettura degli indirizzi IPv6 specificati". Anche se di solito vengono chiamate interfacce del sistema operativo, in realtà definiscono qualcosa di più generale: "zona" o "ambito".
Il motivo per cui esistono zone più generali o zone di ambito è che, come menzionato in [RFC4007], un nodo IPv6 può avere più interfacce IPv6 collegate alla stessa rete. Queste interfacce sono membri di una stessa zona.
Dovrebbe essere possibile raggruppare più interfacce all'interno di una zona sotto il sistema operativo; attualmente non so se questo sia possibile su Linux e come farlo.
Utilizzando il suffisso %, possiamo rimuovere il parametro 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 degli indirizzi Link-Local
Da questo ping multicast all-nodes abbiamo ricevuto in totale 6 risposte uniche.
Queste risposte sono arrivate dagli indirizzi Link-Local unicast dei nodi IPv6. Ecco la prima risposta:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msGli indirizzi IPv6 Link-Local unicast sono richiesti su tutte le interfacce che supportano IPv6 [RFC4291], "Architettura dell'indirizzamento IP versione 6". Questo è dovuto al fatto che un nodo IPv6 ha sempre automaticamente un indirizzo IPv6 unicast che può utilizzare, almeno per comunicare con altri nodi attraverso i propri canali direttamente connessi. Ciò include la comunicazione con le applicazioni di altri host attraverso indirizzi Link-Local degli host.
Questo semplifica lo sviluppo e l'implementazione di protocolli come IPv6 Neighbor Discovery e OSPFv3. Inoltre, consente alle applicazioni degli utenti finali sugli host di scambiare dati su un canale senza richiedere alcuna altra infrastruttura di supporto IPv6 sul canale. Per la comunicazione diretta tra host IPv6 non è necessario un router IPv6 o un server DHCPv6 nella connessione.
Gli indirizzi Link-Local iniziano con un prefisso di 10 bit fe80, seguito da 54 bit zero e poi un identificatore di interfaccia (IID) di 64 bit. Nella risposta sopra riportata 2392:6213:a15b:66ff — è l'IID di 64 bit.
Multicast in Loop
Per impostazione predefinita, i pacchetti multicast vengono restituiti internamente al nodo che li invia. Questo avviene sia per gli indirizzi IPv6 che IPv4.
La causa di questo comportamento predefinito è che, quando si inviano pacchetti multicast, può esserci un'applicazione multicast locale in ascolto che funziona anche sull'host mittente, così come in qualche altro punto della rete. Questa applicazione locale deve ricevere pacchetti multicast.
Possiamo vedere questo ciclo locale multicast nel nostro output ping:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 byte di dati
64 byte da fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 byte da 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 rispetto a 0.453 ms) proviene da un 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 ~]$Utility ping fornisce un modo per sopprimere il feedback locale del multicast utilizzando l'opzione -L. Se inviamo un ping multicast a tutti i nodi con questo flag, le risposte sono limitate ai nodi remoti. Non riceviamo risposta dall'indirizzo Link-Local dell'interfaccia mittente.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 byte di dati
64 byte da fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 byte da fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping dell'indirizzo Link-Local
Come puoi immaginare, gli indirizzi unicast Link-Local da soli non forniscono informazioni sufficienti per indicare quale interfaccia utilizzare per raggiungerli. Come nel caso del ping multicast a tutti i nodi, dobbiamo anche specificare l'interfaccia come parametro della riga di comando ping o l'ID della zona con l'indirizzo quando pinghiamo gli indirizzi Link-Local.
Questa volta possiamo utilizzare -c, per limitare il numero di pacchetti e risposte inviati e ricevuti ping, poiché stiamo effettuando un 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 byte di dati
64 byte da fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 statistiche del ping ---
1 pacchetti trasmessi, 1 ricevuti, 0% perdita di pacchetti, tempo 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Pingare (tutti) gli altri indirizzi IPv6?
In questo articolo abbiamo visto come effettuare ping a tutti i nodi IPv6 sulla rete, utilizzando l'indirizzo multicast all-nodes IPv6 ff02::1. Abbiamo anche visto come specificare quale interfaccia utilizzare con un indirizzo multicast IPv6 all-nodes, poiché l'indirizzo di per sé non può fornire queste informazioni. Abbiamo usato o un parametro della riga di comando ping, oppure abbiamo specificato l'interfaccia tramite suffisso %.
. Poi abbiamo appreso degli indirizzi Link-Local unicast, che sono gli indirizzi utilizzati per rispondere alle richieste echo multicast ICMPv6 all-nodes.
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 un suffisso %, poiché gli indirizzi Link-Local di per sé 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) (cioè i loro indirizzi pubblici su Internet) o i loro indirizzi unicast locali unici (ULA)? Ne parleremo nel prossimo articolo del blog.
Questo è tutto.
Per ulteriori informazioni sul nostro corso, visita il.
Fonte: habr.com
