Ilang araw ang natitira hanggang sa magsimula ang isang bagong daloy sa rate mula sa OTUS. Kaugnay nito, nais naming ibahagi sa iyo ang isang pagsasalin ng kapaki-pakinabang na materyal sa paksa.
Isang serye ng mga post sa blog sa mga tip at trick para sa pag-troubleshoot ng mga isyu sa IPv6 ping (ICMPv6 Echo Request/Echo Reply)
Pakitandaan na gumagamit ako ng Linux (partikular ang Fedora 31), gayunpaman ang ping command syntax para sa iba pang mga operating system ay dapat sana ay magkatulad.
I-ping ang lahat ng IPv6 node sa isang channel
Ang una at pinakasimpleng tip ay i-ping ang lahat ng IPv6 node sa link.
Gumagamit ang IPv6 ng mga multicast na address para sa lahat ng uri ng isa-sa-maraming komunikasyon. Walang mga broadcast (o broadcast) na IPv6 address. Tinutukoy nito ang pagkakaiba ng IPv6 sa IPv4, kung saan mayroong ilang uri ng mga address ng broadcast, halimbawa, ang address na "limitadong broadcast" na 255.255.255.255 [RFC1122].
Gayunpaman, mayroong "all-nodes multicast" IPv6 address, kaya gagamitin namin iyon upang i-ping ang lahat ng IPv6 node sa link. (Ang isang "broadcast" address ay talagang isang espesyal na pinangalanang multicast address, na isang multicast na grupo na kinabibilangan ng lahat ng node. Tandaan na, halimbawa, ang "grupo" o multicast address bit ay naka-on sa Ethernet broadcast address sa link layer ).
All-nodes multicast IPv6 address para sa channel: ff02::1. ff nagsasaad ng multicast IPv6 address. Ang susunod na 0 ay ang bahagi ng bandila na may hindi nakatakdang mga piraso.
Pa 2 tumutukoy sa lugar ng isang multicast na grupo. Hindi tulad ng mga multicast IPv4 address, ang mga multicast IPv6 address ay may saklaw. Ang halaga ng saklaw ay nagpapahiwatig ng bahagi ng network kung saan ang isang multicast packet ay pinapayagang maipasa. Sa sandaling maabot ng isang packet ang hangganan ng tinukoy na saklaw, dapat i-drop ang packet, hindi alintana kung ang field ng Hop Count nito ay nonzero. Siyempre, kung ang bilang ng hop ay umabot sa zero bago maabot ang tinukoy na hangganan ng multicast group, agad din itong ni-reset. Narito ang kumpletong listahan ng IPv6 multicast scope.
Sa wakas ::1 tumutukoy ng all-nodes multicast na grupo.
Tungkol sa address ff02::1 Dapat tandaan na ito ay hindi maliwanag. Sa isang IPv6 host na may maraming interface, gaya ng router o multihomed host, ang address ff02::1 walang anuman kung saan maaari mong tukuyin kung aling interface ang padadalhan ng ICMPv6 echo request o inaasahan na makatanggap ng ICMPv6 echo replies pagdating nila. ff02::1 ay wasto at maaaring gamitin sa alinman sa mga interface at channel na naka-attach sa multi-interface node.
Kaya kapag na-ping namin ang lahat ng IPv6 node sa isang link, kailangan din naming sabihin sa utility ping para sa IPv6, kung aling interface ang gagamitin.
Pagtukoy ng Mga Interface - Pagpipilian sa Command Line
Gaya ng nakita na natin, ang all-nodes multicast address na gusto nating gamitin ay − ff02::1 - hindi nagbibigay ng anumang impormasyon tungkol sa kung aling interface ang ipapadala at tatanggap ng ICMPv6 echo request at echo reply packet.
Kaya, paano natin tutukuyin ang interface na gagamitin para sa multicast address space o unicast Link-Local address space?
Ang una at pinaka-halatang paraan ay ang ibigay ito bilang parameter sa application na ginagamit namin.
Para sa utility ping ibinibigay namin ito sa pamamagitan ng opsyon -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 ~]$Gamit ang all-nodes multicast ping na ito, nakatanggap kami ng mga tugon mula sa 6 na IPv6 node. Ang mga tugon ay nagmula sa Link-Local IPv6 node address, simula sa prefix fe80::/10.
Na ping ay hindi patuloy na nagpapadala ng ICMPv6 echo request nang walang katiyakan hanggang sa maabala namin ito, karaniwan naming tinutukoy ang bilang ng mga packet na ipapadala sa pamamagitan ng -c na opsyon. Gayunpaman, pinipigilan din nito ang ping sa pagtanggap at pagpapakita ng higit sa isang ICMPv6 echo reply kapag nagpapadala ng multicast ICMPv6 echo request. Sa halip, ginamit namin ang -w na opsyon upang tukuyin na ang ping ay dapat makumpleto pagkatapos ng 1 segundo, gaano man karaming ICMPv6 echo request o echo replies ang ipinadala o natanggap.
Ang isa pang bagay na dapat bigyang pansin ay (DUP!) output sa pangalawa at kasunod na mga sagot. Ang mga packet na ito ay kinilala bilang mga duplicate na tugon dahil mayroon silang parehong halaga ng sequence ng ICMP gaya ng mga indibidwal na ICMPv6 echo request na ipinadala sa unang lugar. Lumilitaw ang mga ito dahil ang isang ICMPv6 multicast echo request ay nagreresulta sa maraming indibidwal na unicast na tugon. Ang bilang ng mga duplicate ay ipinahiwatig din sa buod ng mga istatistika.
Pagtukoy ng Mga Interface - Zone ID
Ang isa pang paraan upang ilantad ang isang interface para sa paggamit ay bilang bahagi ng isang parameter ng IPv6 address.
Makakakita tayo ng halimbawa nito sa ping output, kung saan ang mga address ng tumutugon na IPv6 host ay mayroon ding suffix %enp3s2, halimbawa:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msAng pamamaraang ito ng pagtukoy ng mga interface ay pormal na inilalarawan sa [RFC4007], "Iv6 Defined Address Architecture." Bagama't ang mga ito ay karaniwang tinatawag na interface ng operating system, aktwal na tinukoy nila ang isang bagay na mas pangkalahatan—isang "zone" o "saklaw."
Ang dahilan ng pagkakaroon ng mas pangkalahatang mga zone o saklaw na zone ay, tulad ng nabanggit sa [RFC4007], ang isang IPv6 node ay maaaring magkaroon ng ilang magkakaibang mga interface ng IPv6 na konektado sa parehong channel. Ang mga interface na ito ay mga miyembro ng parehong zone.
Posibleng mag-grupo ng maraming interface sa loob ng isang zone sa ilalim ng operating system; Sa kasalukuyan ay hindi ko alam kung posible ito sa ilalim ng Linux o kung paano ito gagawin.
Gamit ang panlapi %<zone_id>, maaari nating alisin ang opsyon sa command line -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 ~]$Link-Local Address na Mga Tugon
Mula sa all-nodes multicast ping na ito nakatanggap kami ng kabuuang 6 na natatanging tugon.
Ang mga tugon na ito ay nagmula sa mga unicast na Link-Local IPv6 host address. Halimbawa, narito ang unang sagot:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msAng Unicast Link-Local IPv6 address ay kinakailangan sa lahat ng IPv6-enabled na interface [RFC4291], “IP Version 6 Addressing Architecture”. Ang dahilan nito ay ang isang IPv6 node ay palaging awtomatikong mayroong unicast na IPv6 address, na maaari nitong gamitin upang makipag-usap sa iba pang mga node sa mga direktang konektadong link nito. Kabilang dito ang pakikipag-ugnayan sa mga application sa ibang mga host sa pamamagitan ng Link-Local host address.
Pinapasimple nito ang disenyo at pagpapatupad ng mga protocol tulad ng IPv6 Neighbor Discovery at OSPFv3. Pinapayagan din nito ang mga application ng end-user sa mga host na makipag-usap sa channel nang hindi nangangailangan ng anumang iba pang sumusuportang imprastraktura ng IPv6 sa channel. Ang direktang komunikasyon sa pagitan ng mga nakakonektang IPv6 host ay hindi nangangailangan ng IPv6 router o DHCPv6 server sa koneksyon.
Ang Link-Local na mga address ay nagsisimula sa isang 10-bit na prefix fe80, na sinusundan ng 54 zero bits at pagkatapos ay isang 64-bit na interface identifier (IID). Sa unang sagot sa itaas 2392:6213:a15b:66ff ay isang 64-bit na IID.
Naka-loop na Multicast
Bilang default, ang mga multicast packet ay ibinalik sa loob sa node na nagpadala sa kanila. Nangyayari ito para sa parehong IPv6 at IPv4 addressing.
Ang dahilan para sa default na pag-uugali na ito ay kapag ang mga multicast packet ay ipinadala, maaaring mayroon ding nakikinig na lokal na multicast application na tumatakbo sa mismong nagpapadalang host, gayundin sa isang lugar sa network. Ang lokal na application na ito ay dapat ding makatanggap ng mga multicast packet.
Makikita natin itong multicast local loop sa ating ping output:
[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!)
...Ang una at pinakamabilis na tugon (0,106 ms kumpara sa 0,453 ms) ay mula sa Link-Local na address na na-configure sa mismong interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Kagamitan ping nagbibigay ng paraan upang sugpuin ang lokal na multicast na feedback gamit ang parameter -L. Kung magpapadala kami ng all-node multicast ping na may ganitong flag, ang mga tugon ay limitado sa mga malalayong node. Hindi kami nakakatanggap ng tugon mula sa Link-Local na address ng interface ng pagpapadala.
[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-Mga Lokal na Address
Tulad ng maaari mong hulaan, ang mga unicast na Link-Local na address sa kanilang sarili ay hindi rin nagbibigay ng sapat na impormasyon upang ipahiwatig kung aling interface ang gagamitin upang maabot ang mga ito. Tulad ng all-nodes multicast ping, kailangan din nating tukuyin ang interface bilang parameter ng command line ping o zone ID na may address kapag pini-ping ang Link-Local na mga address.
This time magagamit na natin -cupang limitahan ang bilang ng mga packet at mga tugon na ipinadala at natanggap ping, dahil gumaganap kami ng unicast ping.
[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 ~]$I-ping (lahat) ang iba pang mga IPv6 address?
Sa artikulong ito, nakita namin kung paano i-ping ang lahat ng IPv6 node sa isang channel gamit ang isang all-nodes multicast IPv6 address ff02::1. Nakita rin namin kung paano tukuyin kung aling interface ang gagamitin sa isang all-node multicast IPv6 address, dahil ang address mismo ay hindi makakapagbigay ng impormasyong ito. Ginamit namin ang alinman sa command line na opsyon ping, o tinukoy ang interface gamit ang suffix %<zone_id>.
Pagkatapos ay natutunan namin ang tungkol sa mga unicast na Link-Local na address, na mga address na ginagamit upang tumugon sa mga all-node na multicast ICMPv6 echo request.
Nakita rin namin kung paano ibinalik ang mga multicast packet sa pagpapadala ng node bilang default at kung paano ito i-disable para sa utility ping.
Sa wakas, nag-ping kami ng iisang Link-Local address gamit ang suffix %<zone_id>, dahil ang Link-Local na mga address mismo ay hindi rin nagbibigay ng impormasyon tungkol sa papalabas na interface.
Kaya't paano ang pag-ping sa lahat ng iba pang mga node at kunin ang kanilang mga pandaigdigang unicast address (GUA) (iyon ay, ang kanilang mga pampublikong address sa Internet) o ang kanilang mga natatanging lokal na unicast address (ULAs)? Titingnan natin ito sa susunod na post sa blog.
Iyon lang.
Maaari mong malaman ang higit pa tungkol sa aming kurso sa.
Pinagmulan: www.habr.com