'n Paar dae bly oor tot die begin van 'n nuwe vloei teen die tempo van OTUS. In hierdie verband wil ons graag 'n vertaling van nuttige materiaal oor die onderwerp met u deel.
'n Reeks blogplasings oor wenke en truuks vir die oplos van IPv6-pingprobleme (ICMPv6 Echo Request/Echo Reply)
Neem asseblief kennis dat ek Linux gebruik (spesifiek Fedora 31), maar die ping-opdragsintaksis vir ander bedryfstelsels behoort hopelik baie soortgelyk te wees.
Ping alle IPv6 nodusse op 'n kanaal
Die eerste en eenvoudigste wenk is om alle IPv6-nodusse op die skakel te ping.
IPv6 gebruik multicast-adresse vir alle soorte een-tot-vee kommunikasie. Daar is geen uitsaai- (of uitsaai-) IPv6-adresse nie. Dit onderskei IPv6 van IPv4, waar daar verskeie tipes uitsaaiadresse is, byvoorbeeld die "beperkte uitsending"-adres 255.255.255.255 [RFC1122].
Daar is egter 'n "all-nodes multicast" IPv6-adres, so ons sal dit gebruik om alle IPv6-nodes op die skakel te ping. ('n "uitsaai"-adres is eintlik net 'n spesiaal-benoemde multi-uitsending-adres, wat 'n multi-uitsending-groep is wat alle nodusse insluit. Let daarop dat, byvoorbeeld, die "groep" of multi-uitsending-adresbis aangeskakel is in Ethernet-uitsaaiadresse by die skakellaag ).
All-nodes multicast IPv6-adres vir die kanaal: ff02::1. ff dui 'n multicast IPv6-adres aan. Die volgende 0 is die deel van die vlag met ongestelde stukkies.
Verdere 2 definieer die area van 'n multicast-groep. In teenstelling met multicast IPv4-adresse, het multicast IPv6-adresse 'n omvang. Die omvangwaarde dui die deel van die netwerk aan waaroor 'n multicast-pakkie toegelaat word om aangestuur te word. Sodra 'n pakkie die grens van die gespesifiseerde omvang bereik, moet die pakkie laat vaar word, ongeag of sy Hop Count-veld nie nul is nie. Natuurlik, as die hop-telling nul bereik voordat die gespesifiseerde multicast-groepgrens bereik word, word dit ook onmiddellik teruggestel. Hier is 'n volledige lys van IPv6 multicast-omvang.
uiteindelik, ::1 spesifiseer 'n all-nodes multicast groep.
Oor die adres ff02::1 Daar moet kennis geneem word dat dit dubbelsinnig is. Op 'n IPv6-gasheer met veelvuldige koppelvlakke, soos 'n router of multihome-gasheer, die adres ff02::1 daar is niks waar jy kan spesifiseer na watter koppelvlak ICMPv6 eggo-versoeke moet stuur of verwag om ICMPv6 eggo-antwoorde te ontvang wanneer hulle aankom nie. ff02::1 is geldig en kan gebruik word op enige van die koppelvlakke en kanale verbonde aan die multi-koppelvlak nodus.
So wanneer ons alle IPv6-nodusse op 'n skakel ping, moet ons op een of ander manier ook die hulpprogram vertel ping vir IPv6, watter koppelvlak om te gebruik.
Definieer koppelvlakke - Command Line Opsie
Soos ons reeds gesien het, is die all-nodes multicast adres wat ons wil gebruik − ff02::1 - verskaf geen inligting oor watter koppelvlak om ICMPv6 eggo versoek en eggo antwoord pakkies te stuur en te ontvang nie.
So, hoe spesifiseer ons die koppelvlak wat gebruik moet word vir die multicast-adresruimte of unicast Link-Local-adresruimte?
Die eerste en mees voor die hand liggende manier is om dit as 'n parameter te verskaf aan die toepassing wat ons gebruik.
Vir nut ping ons verskaf dit deur die opsie -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 ~]$Deur hierdie all-nodes multicast-ping te gebruik, het ons antwoorde van 6 IPv6-nodes ontvang. Antwoorde het gekom van Link-Local IPv6-nodusadresse, begin met die voorvoegsel fe80::/10.
Wat ping nie aanhou om ICMPv6 eggo-versoeke onbepaald te stuur totdat ons dit onderbreek nie, spesifiseer ons gewoonlik die aantal pakkies om via die -c opsie te stuur. Dit verhoed egter ook dat ping meer as een ICMPv6 eggo-antwoord aanvaar en vertoon wanneer 'n multicast ICMPv6 eggo-versoek gestuur word. In plaas daarvan het ons die -w opsie gebruik om te spesifiseer dat ping na 1 sekonde moet voltooi, maak nie saak hoeveel ICMPv6 eggo versoeke of eggo antwoorde gestuur of ontvang is nie.
Nog iets om op te let is (DUP!) uitvoer op die tweede en daaropvolgende antwoorde. Hierdie pakkies word as duplikaatantwoorde geïdentifiseer omdat hulle dieselfde ICMP-volgordewaarde het as die individuele ICMPv6 eggo-versoeke wat in die eerste plek gestuur is. Hulle verskyn omdat 'n ICMPv6 multicast eggo versoek lei tot verskeie individuele unicast antwoorde. Die aantal duplikate word ook in die statistiekopsomming aangedui.
Definieer koppelvlakke - Sone ID
Nog 'n manier om 'n koppelvlak vir gebruik bloot te stel, is as deel van 'n IPv6-adresparameter.
Ons kan 'n voorbeeld hiervan in die ping-uitvoer sien, waar die adresse van die reageer IPv6-gashere ook die agtervoegsel het %enp3s2, byvoorbeeld:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msHierdie metode om koppelvlakke te spesifiseer, word formeel beskryf in [RFC4007], "IPv6 Defined Address Architecture." Alhoewel hulle gewoonlik die bedryfstelsel-koppelvlak genoem word, definieer hulle eintlik iets meer algemeen - 'n "sone" of "omvang."
Die rede vir meer algemene sones of omvangsones is dat, soos genoem in [RFC4007], 'n IPv6-nodus verskeie verskillende IPv6-koppelvlakke kan hê wat aan dieselfde kanaal gekoppel is. Hierdie koppelvlakke is lede van dieselfde sone.
Dit behoort moontlik te wees om verskeie koppelvlakke binne 'n sone onder die bedryfstelsel te groepeer; Tans weet ek nie of dit moontlik is onder Linux of hoe om dit te doen nie.
Gebruik die agtervoegsel %<zone_id>, kan ons die opdragreëlopsie verwyder -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 ~]$Skakel-plaaslike adres antwoorde
Van hierdie all-nodes multicast ping het ons 'n totaal van 6 unieke antwoorde ontvang.
Hierdie antwoorde het gekom van unicast Link-Local IPv6-gasheeradresse. Hier is byvoorbeeld die eerste antwoord:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresse word vereis op alle IPv6-geaktiveerde koppelvlakke [RFC4291], "IP Weergawe 6 Addressing Architecture". Die rede hiervoor is dat 'n IPv6-nodus altyd outomaties 'n unicast IPv6-adres het, wat dit ten minste kan gebruik om met ander nodusse op sy direk gekoppelde skakels te kommunikeer. Dit sluit in kommunikasie met toepassings op ander gashere via Link-Local gasheeradresse.
Dit vergemaklik die ontwerp en implementering van protokolle soos IPv6 Neighbour Discovery en OSPFv3. Dit laat ook eindgebruikertoepassings op gashere toe om oor die kanaal te kommunikeer sonder om enige ander ondersteunende IPv6-infrastruktuur op die kanaal te vereis. Direkte kommunikasie tussen gekoppelde IPv6-gashere vereis nie 'n IPv6-roeteerder of DHCPv6-bediener op die verbinding nie.
Skakel-plaaslike adresse begin met 'n 10-bis voorvoegsel fe80, gevolg deur 54 nul bisse en dan 'n 64-bis koppelvlak identifiseerder (IID). In bogenoemde eerste antwoord 2392:6213:a15b:66ff is 'n 64-bis IID.
Gelusde Multicast
By verstek word multicast-pakkies intern teruggestuur na die nodus wat dit gestuur het. Dit gebeur vir beide IPv6- en IPv4-adressering.
Die rede vir hierdie verstekgedrag is dat wanneer multicast-pakkies gestuur word, daar ook 'n luisterende plaaslike multicast-toepassing op die stuurgasheer self kan wees, sowel as iewers op die netwerk. Hierdie plaaslike toepassing moet ook multicast-pakkies ontvang.
Ons kan hierdie multicast plaaslike lus in ons ping-uitvoer sien:
[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!)
...Die eerste en vinnigste reaksie (0,106 ms in vergelyking met 0,453 ms) kom van die Link-Local-adres wat op die koppelvlak self opgestel is enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Nuts ping bied 'n manier om plaaslike multicast-terugvoer met behulp van die parameter te onderdruk -L. As ons 'n all-nodes multicast-ping met hierdie vlag stuur, dan is antwoorde beperk tot afgeleë nodusse. Ons ontvang nie 'n antwoord vanaf die Link-Local-adres van die stuurkoppelvlak nie.
[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 skakel-plaaslike adresse
Soos jy dalk kan raai, verskaf unicast Link-Local-adresse op sigself ook nie genoeg inligting om aan te dui watter koppelvlak om te gebruik om hulle te bereik nie. Soos met all-nodes multicast ping, moet ons ook die koppelvlak as 'n command line parameter spesifiseer ping of sone-ID met adres wanneer skakel-plaaslike adresse geping word.
Hierdie tyd kan ons gebruik -com die aantal pakkies en antwoorde wat gestuur en ontvang word te beperk ping, aangesien ons unicast-ping uitvoer.
[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 (alle) ander IPv6-adresse?
In hierdie artikel het ons gesien hoe om alle IPv6-nodusse op 'n kanaal te ping met 'n multicast-IPv6-adres van alle nodes ff02::1. Ons het ook gesien hoe om te spesifiseer watter koppelvlak om te gebruik met 'n all-nodes multicast IPv6 adres, aangesien die adres self nie hierdie inligting kan verskaf nie. Ons het óf die opdragreëlopsie gebruik ping, of die koppelvlak gespesifiseer met die agtervoegsel %<zone_id>.
Toe het ons geleer van unicast Link-Local-adresse, wat adresse is wat gebruik word om te reageer op alle-nodes multicast ICMPv6 eggo-versoeke.
Ons het ook gesien hoe multicast-pakkies by verstek na die stuurnodus teruggestuur word en hoe om dit vir die nut te deaktiveer ping.
Uiteindelik het ons 'n enkele skakel-plaaslike adres met die agtervoegsel geping %<zone_id>, aangesien Link-Local-adresse self ook nie inligting oor die uitgaande koppelvlak verskaf nie.
So wat van ping al die ander nodusse en kry hul globale unicast-adresse (GUA's) (dit wil sê hul publieke adresse op die internet) of hul unieke plaaslike unicast-adresse (ULA's)? Ons sal hierna kyk in die volgende blogpos.
Dit is alles.
Jy kan meer uitvind oor ons kursus by.
Bron: will.com