Mancano solo pochi giorni all'inizio di un nuovo ciclo del corso di OTUS. In questo contesto, vogliamo condividere con voi la traduzione di materiale utile sull'argomento.
Una serie di articoli sul blog dedicati a consigli e raccomandazioni per la risoluzione dei problemi relativi al ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Si noti che sto usando Linux (in particolare, Fedora 31), tuttavia la sintassi del comando ping per altri sistemi operativi dovrebbe essere molto simile.
Ping di tutti i nodi IPv6 sul canale
Il primo e più semplice consiglio è quello di pingare tutti i nodi IPv6 sul canale.
L'IPv6 utilizza indirizzi multicast per tutti i tipi di comunicazione «uno a molti». Non ci sono indirizzi broadcast (o a diffusione) IPv6. Questo distingue l'IPv6 dall'IPv4, dove esistono diversi tipi di indirizzi broadcast, come l'indirizzo «limited broadcast» 255.255.255.255 [RFC1122].
Tuttavia, esiste un indirizzo multicast IPv6 “all-nodes” (multicast per tutti i nodi), quindi lo utilizzeremo per pingare tutti i nodi IPv6 sul canale. (L'indirizzo «broadcast» è in realtà semplicemente un indirizzo multicast con nome specifico che è un gruppo di multicast che include tutti i nodi. Si noti che, ad esempio, il bit «di gruppo» o dell'indirizzo multicast è incluso negli indirizzi broadcast Ethernet a livello di collegamento).
L'indirizzo multicast IPv6 all-nodes per il canale: ff02::1. ff indica l'indirizzo multicast IPv6. Il successivo 0 è parte della flag con i bit non impostati.
Successivamente 2 definisce la regione del gruppo multicast. A differenza degli indirizzi multicast IPv4, gli indirizzi multicast IPv6 hanno uno scope (area di visibilità). Il valore dello scope indica la parte della rete su cui è consentito inoltrare il pacchetto multicast. Una volta che il pacchetto raggiunge il confine dello scope specificato, il pacchetto deve essere scartato, indipendentemente dal fatto che il suo campo conteggio salti (Hop Count) sia non nullo. Naturalmente, se il conteggio salti raggiunge zero prima di raggiungere il confine del gruppo multicast specificato, viene anche immediatamente scartato. Ecco l'elenco completo dei multicast scope IPv6.
Infine, ::1 indica il gruppo multicast all-nodes.
Riguardo all'indirizzo ff02::1 si deve notare che è ambiguo. Su un nodo IPv6 con più interfacce, come un router o un host multi-rete, nell'indirizzo ff02::1 Non c'è nulla dove si possa specificare a quale interfaccia inviare le richieste di eco ICMPv6 o aspettarsi di ricevere le risposte di eco ICMPv6 quando arrivano. ff02::1 È valido e può essere utilizzato su una qualsiasi delle interfacce e canali collegati a un nodo multi-interfaccia.
Quindi, quando facciamo ping a tutti i nodi IPv6 sul canale, dobbiamo in qualche modo comunicare all'utility ping per IPv6, quale interfaccia utilizzare.
La definizione delle interfacce è un parametro della riga di comando
Come abbiamo già visto, l'indirizzo multicast all-nodes che vogliamo utilizzare è ff02::1 non fornisce alcuna informazione riguardo a quale interfaccia inviare e ricevere pacchetti di richiesta di eco e risposta di eco ICMPv6.
Quindi, come possiamo specificare l'interfaccia che verrà utilizzata per lo spazio degli indirizzi multicast o per gli indirizzi unicast Link-Local?
Il primo e più ovvio modo è fornire il parametro per l'applicazione che stiamo utilizzando.
Per l'utility 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 inizio con il prefisso fe80::/10.
Per ping non ha continuato a inviare richieste di eco ICMPv6 fino a quando non lo interrompiamo, di solito specifichiamo il numero di pacchetti da inviare tramite l'opzione -c. Tuttavia, questo non consente nemmeno a ping di ricevere e visualizzare più di una risposta di eco ICMPv6 quando si invia una richiesta di eco multicast ICMPv6. Invece, abbiamo utilizzato il parametro -w per indicare che ping dovrebbe completarsi dopo 1 secondo, indipendentemente da quante richieste di eco o risposte di eco ICMPv6 sono state inviate o ricevute.
Un'altra cosa da tenere a mente è (DUP!) output nei secondi e nei successivi riscontri. Questi pacchetti vengono identificati come duplicati di risposta poiché hanno lo stesso valore di sequenza ICMP di singole richieste ICMPv6, che sono state inviate per prime. Appaiono perché la richiesta ICMPv6 multicast genera più risposte unicast individuali. Il numero di duplicati è anche indicato nel riepilogo delle statistiche.
Definizione delle interfacce — ID Zona
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 un suffisso %enp3s2, per esempio:
64 bytes da fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msQuesto modo di definire le interfacce è formalmente descritto in [RFC4007], "Architettura con indirizzi IPv6 definiti". Sebbene di solito vengano chiamati interfaccia del sistema operativo, in realtà definiscono qualcosa di più generale — "zona" o "ambito".
La ragione della presenza di zone più generali o zone di ambito è che, come riportato in [RFC4007], un nodo IPv6 può avere più interfacce IPv6 collegate allo stesso tunnel. 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 ciò 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 byte di dati
64 bytes da fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes da fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes da fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes da fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes da fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes da fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes da fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes da fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- statistiche ping ff02::1%enp3s2 ---
1 pacchetti trasmessi, 1 ricevuti, +7 duplicati, 0% perdita di pacchetti, tempo 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 da indirizzi Link-Local unicast dei nodi IPv6. Ad esempio, ecco la prima risposta:
64 bytes da fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msGli indirizzi IPv6 Link-Local sono richiesti su tutte le interfacce che supportano IPv6 [RFC4291], "Architettura degli indirizzi IP versione 6". Questo accade perché un nodo IPv6 ha sempre automaticamente un indirizzo IPv6 unicast che può utilizzare, almeno per comunicare con altri nodi tramite i propri canali direttamente connessi. Ciò include la comunicazione con le applicazioni di altri host tramite indirizzi Link-Local degli host.
Questo semplifica lo sviluppo e l'implementazione di protocolli come IPv6 Neighbor Discovery e OSPFv3. Consente anche alle applicazioni di utenti finali sugli host di scambiare dati tramite il canale, senza richiedere alcuna altra infrastruttura di supporto IPv6 sul canale. Per la comunicazione diretta tra host connessi, 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 da un identificatore di interfaccia a 64 bit (IID). Nella prima risposta precedente, 2392:6213:a15b:66ff è il IID a 64 bit.
Multicast Looped
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 vengono inviati pacchetti multicast, potrebbe anche esserci un'applicazione multicast locale in ascolto in esecuzione sullo stesso host mittente, così come in qualche parte della rete. Questa applicazione locale deve ricevere i pacchetti multicast.
Possiamo vedere questo ciclo multicast locale nella nostra 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 dall'indirizzo Link-Local configurato sull'interfaccia 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 l'eco locale della multicast utilizzando l'opzione -L. Se inviamo un ping multicast di tutti i nodi con questo flag, le risposte sono limitate ai nodi remoti. Non otteniamo 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 Link-Local unicast non forniscono da soli informazioni sufficienti per indicare quale interfaccia utilizzare per raggiungerli. Come nel caso del ping multicast all-nodes, dobbiamo anche specificare l'interfaccia come parametro della riga di comando. ping o l'ID della zona con l'indirizzo durante il ping degli indirizzi Link-Local.
Questa volta possiamo usare -c, per limitare il numero di pacchetti e risposte inviati e ricevuti ping, poiché stiamo eseguendo 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 ricevuto, 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 eseguire il ping di tutti i nodi IPv6 sulla rete utilizzando l'indirizzo multicast IPv6 all-nodes. ff02::1Abbiamo anche visto come specificare quale interfaccia utilizzare con l'indirizzo multicast IPv6 all-nodes, poiché l'indirizzo da solo non può fornire queste informazioni. Abbiamo utilizzato o il parametro della riga di comando ping, o specificato l'interfaccia tramite il suffisso %.
Successivamente, abbiamo appreso degli indirizzi Link-Local unicast, che sono gli indirizzi utilizzati per rispondere alle richieste echo ICMPv6 multicast all-nodes.
Abbiamo anche visto come i pacchetti multicast ritornano al nodo mittente per impostazione predefinita e come disabilitare ciò per l'utilità. ping.
Infine, abbiamo eseguito il ping di un singolo indirizzo Link-Local, utilizzando il suffisso %, poiché gli indirizzi Link-Local da soli non forniscono informazioni sull'interfaccia in uscita.
Che ne dici di eseguire il ping di tutti gli altri nodi e ricevere 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.
Scopri di più sul nostro corso nella.
Fonte: habr.com
