Ping nodes IPv6 ທັງໝົດຢູ່ໃນຊ່ອງໃດໜຶ່ງ

ສອງສາມມື້ຍັງຄົງຢູ່ຈົນກ່ວາການເລີ່ມຕົ້ນຂອງການໄຫຼໃຫມ່ໃນອັດຕາ "ວິສະວະກອນເຄືອຂ່າຍ" ຈາກ OTUS. ໃນເລື່ອງນີ້, ພວກເຮົາຢາກແບ່ງປັນໃຫ້ທ່ານມີການແປພາສາຂອງອຸປະກອນທີ່ເປັນປະໂຫຍດໃນຫົວຂໍ້.

ຊຸດຂອງບົດຄວາມ blog ກ່ຽວກັບຄໍາແນະນໍາແລະຄໍາແນະນໍາສໍາລັບການແກ້ໄຂບັນຫາ IPv6 ping (ICMPv6 Echo Request / Echo Reply)

ກະລຸນາຮັບຊາບວ່າຂ້ອຍກໍາລັງໃຊ້ Linux (ໂດຍສະເພາະ Fedora 31), ແນວໃດກໍ່ຕາມ syntax ຄໍາສັ່ງ ping ສໍາລັບລະບົບປະຕິບັດການອື່ນໆຫວັງວ່າຈະຄ້າຍຄືກັນຫຼາຍ.

Ping nodes IPv6 ທັງໝົດຢູ່ໃນຊ່ອງໃດໜຶ່ງ

ຄໍາແນະນໍາທໍາອິດແລະງ່າຍດາຍທີ່ສຸດແມ່ນການ ping nodes IPv6 ທັງຫມົດໃນການເຊື່ອມຕໍ່.

IPv6 ໃຊ້ທີ່ຢູ່ multicast ສໍາລັບທຸກປະເພດຂອງການສື່ສານຫນຶ່ງຫາຫຼາຍ. ບໍ່ມີທີ່ຢູ່ IPv6 ອອກອາກາດ (ຫຼືອອກອາກາດ). ນີ້ຈໍາແນກ IPv6 ຈາກ IPv4, ບ່ອນທີ່ມີຫຼາຍປະເພດຂອງທີ່ຢູ່ອອກອາກາດ, ຕົວຢ່າງ, ທີ່ຢູ່ "ອອກອາກາດຈໍາກັດ" 255.255.255.255 [RFC1122].

ຢ່າງໃດກໍຕາມ, ມີທີ່ຢູ່ IPv6 "ທຸກ nodes multicast", ດັ່ງນັ້ນພວກເຮົາຈະໃຊ້ມັນເພື່ອ ping nodes IPv6 ທັງຫມົດໃນການເຊື່ອມຕໍ່. (ຕົວຈິງແລ້ວທີ່ຢູ່ "ການອອກອາກາດ" ແມ່ນພຽງແຕ່ເປັນທີ່ຢູ່ multicast ທີ່ມີຊື່ພິເສດ, ເຊິ່ງເປັນກຸ່ມ multicast ທີ່ປະກອບມີ nodes ທັງຫມົດ. ໃຫ້ສັງເກດວ່າ, ຕົວຢ່າງ, ທີ່ຢູ່ "ກຸ່ມ" ຫຼື multicast ຈະຖືກເປີດຢູ່ໃນທີ່ຢູ່ອອກອາກາດ Ethernet ຢູ່ຊັ້ນເຊື່ອມຕໍ່. ).

All-nodes multicast IPv6 ທີ່ຢູ່ສໍາລັບຊ່ອງ: ff02::1. ff ໝາຍເຖິງທີ່ຢູ່ IPv6 multicast. 0 ຕໍ່ໄປແມ່ນສ່ວນຂອງທຸງທີ່ມີບິດທີ່ບໍ່ໄດ້ຕັ້ງ.

ເພີ່ມເຕີມ 2 ກໍານົດພື້ນທີ່ຂອງກຸ່ມ multicast. ບໍ່ເຫມືອນກັບທີ່ຢູ່ IPv4 multicast, ທີ່ຢູ່ multicast IPv6 ມີຂອບເຂດ. ຄ່າຂອບເຂດຊີ້ບອກເຖິງພາກສ່ວນຂອງເຄືອຂ່າຍທີ່ແພັກເກັດ multicast ຖືກອະນຸຍາດໃຫ້ສົ່ງຕໍ່. ເມື່ອແພັກເກັດໄປຮອດຂອບເຂດຂອງຂອບເຂດທີ່ກຳນົດໄວ້, ແພັກເກັດຕ້ອງຖືກຫຼຸດລົງ, ໂດຍບໍ່ຄໍານຶງວ່າຊ່ອງ Hop Count ຂອງມັນຈະບໍ່ເປັນສູນ. ແນ່ນອນ, ຖ້າການນັບ hop ຮອດສູນກ່ອນທີ່ຈະເຖິງຂອບເຂດຂອງກຸ່ມ multicast ທີ່ລະບຸ, ມັນຍັງຖືກຕັ້ງຄ່າຄືນໃຫມ່ໃນທັນທີ. ນີ້ແມ່ນບັນຊີລາຍຊື່ຄົບຖ້ວນຂອງຂອບເຂດ IPv6 multicast.

ສຸດທ້າຍ ::1 ລະບຸກຸ່ມ multicast ທັງໝົດ nodes.

ກ່ຽວກັບທີ່ຢູ່ ff02::1 ມັນຄວນຈະສັງເກດເຫັນວ່າມັນບໍ່ຊັດເຈນ. ໃນ IPv6 host ທີ່ມີການໂຕ້ຕອບຫຼາຍ, ເຊັ່ນ router ຫຼື multihomed host, ທີ່ຢູ່ ff02::1 ບໍ່ມີຫຍັງທີ່ທ່ານສາມາດລະບຸວ່າການໂຕ້ຕອບໃດທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍ ICMPv6 echo ໄປຫາຫຼືຄາດວ່າຈະໄດ້ຮັບການຕອບກັບ ICMPv6 echo ເມື່ອພວກເຂົາມາຮອດ. ff02::1 ແມ່ນຖືກຕ້ອງ ແລະສາມາດນຳໃຊ້ໄດ້ກັບອິນເຕີເຟດ ແລະຊ່ອງໃດນຶ່ງທີ່ຕິດຢູ່ກັບໂຫນດຫຼາຍການໂຕ້ຕອບ.

ດັ່ງນັ້ນ, ເມື່ອພວກເຮົາ ping nodes IPv6 ທັງຫມົດໃນການເຊື່ອມຕໍ່, ພວກເຮົາຈໍາເປັນຕ້ອງ somehow ຍັງບອກຜົນປະໂຫຍດ ping ສໍາລັບ IPv6, ການໂຕ້ຕອບທີ່ຈະໃຊ້.

ການກໍານົດການໂຕ້ຕອບ - ທາງເລືອກແຖວຄໍາສັ່ງ

ດັ່ງທີ່ພວກເຮົາໄດ້ເຫັນແລ້ວ, ທີ່ຢູ່ all-nodes multicast ທີ່ພວກເຮົາຕ້ອງການໃຊ້ແມ່ນ − ff02::1 - ບໍ່​ໄດ້​ໃຫ້​ຂໍ້​ມູນ​ໃດໆ​ກ່ຽວ​ກັບ​ການ​ໂຕ້​ຕອບ​ທີ່​ຈະ​ສົ່ງ​ແລະ​ໄດ້​ຮັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ ICMPv6 echo ແລະ​ຊອງ​ການ​ຕອບ​ຄືນ​ສຽງ​.

ດັ່ງນັ້ນ, ພວກເຮົາກໍານົດການໂຕ້ຕອບທີ່ຈະນໍາໃຊ້ສໍາລັບພື້ນທີ່ທີ່ຢູ່ multicast ຫຼື unicast Link-Local address space ແນວໃດ?

ວິທີທໍາອິດແລະຊັດເຈນທີ່ສຸດແມ່ນການສະຫນອງມັນເປັນພາລາມິເຕີກັບຄໍາຮ້ອງສະຫມັກທີ່ພວກເຮົາກໍາລັງໃຊ້.

ສໍາລັບຜົນປະໂຫຍດ ping ພວກເຮົາສະຫນອງມັນໂດຍຜ່ານທາງເລືອກ -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 ~]$

ການນໍາໃຊ້ ping multicast ທັງຫມົດນີ້, ພວກເຮົາໄດ້ຮັບການຕອບສະຫນອງຈາກ 6 IPv6 nodes. ຄໍາຕອບມາຈາກທີ່ຢູ່ຂອງ Link-Local IPv6 node, ເລີ່ມຕົ້ນດ້ວຍຄໍານໍາຫນ້າ fe80::/10.

ທີ່ ping ບໍ່ໄດ້ສືບຕໍ່ສົ່ງຄໍາຮ້ອງຂໍ ICMPv6 echo ໂດຍບໍ່ມີກໍານົດຈົນກ່ວາພວກເຮົາຂັດຂວາງມັນ, ພວກເຮົາມັກຈະລະບຸຈໍານວນແພັກເກັດທີ່ຈະສົ່ງຜ່ານທາງເລືອກ -c. ຢ່າງໃດກໍຕາມ, ນີ້ຍັງປ້ອງກັນບໍ່ໃຫ້ ping ຍອມຮັບແລະສະແດງຫຼາຍກ່ວາຫນຶ່ງ ICMPv6 echo ຕອບເມື່ອສົ່ງຄໍາຮ້ອງຂໍ multicast ICMPv6 echo. ແທນທີ່ຈະ, ພວກເຮົາໄດ້ໃຊ້ທາງເລືອກ -w ເພື່ອລະບຸວ່າ ping ຄວນສໍາເລັດຫຼັງຈາກ 1 ວິນາທີ, ບໍ່ວ່າຄໍາຮ້ອງຂໍ ICMPv6 echo ຫຼືການຕອບຄືນຂອງສຽງສະທ້ອນຖືກສົ່ງຫຼືໄດ້ຮັບ.

ສິ່ງອື່ນທີ່ຄວນເອົາໃຈໃສ່ແມ່ນ (DUP!) ຜົນໄດ້ຮັບໃນຄໍາຕອບທີສອງແລະຕໍ່ມາ. ແພັກເກັດເຫຼົ່ານີ້ຖືກລະບຸວ່າເປັນການຕອບສະຫນອງທີ່ຊ້ໍາກັນເພາະວ່າພວກເຂົາມີມູນຄ່າລໍາດັບ ICMP ດຽວກັນກັບການຮ້ອງຂໍ ICMPv6 echo ສ່ວນບຸກຄົນທີ່ຖືກສົ່ງໃນສະຖານທີ່ທໍາອິດ. ພວກມັນປາກົດຍ້ອນວ່າຄໍາຮ້ອງຂໍ ICMPv6 multicast echo ສົ່ງຜົນໃຫ້ມີຄໍາຕອບ unicast ສ່ວນບຸກຄົນຫຼາຍອັນ. ຈໍານວນການຊໍ້າກັນຍັງຖືກສະແດງຢູ່ໃນສະຫຼຸບສະຖິຕິ.

ການກໍານົດການໂຕ້ຕອບ - ID ເຂດ

ອີກວິທີຫນຶ່ງທີ່ຈະເປີດເຜີຍການໂຕ້ຕອບສໍາລັບການນໍາໃຊ້ແມ່ນເປັນສ່ວນຫນຶ່ງຂອງພາລາມິເຕີທີ່ຢູ່ IPv6.

ພວກເຮົາສາມາດເຫັນຕົວຢ່າງຂອງສິ່ງນີ້ໃນຜົນຜະລິດ ping, ບ່ອນທີ່ທີ່ຢູ່ຂອງເຈົ້າພາບ IPv6 ທີ່ຕອບສະຫນອງຍັງມີຄໍາຕໍ່ທ້າຍ. %enp3s2ຕົວຢ່າງ:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

ວິທີການກໍານົດການໂຕ້ຕອບນີ້ແມ່ນໄດ້ຖືກອະທິບາຍຢ່າງເປັນທາງການໃນ [RFC4007], "IPv6 Defined Address Architecture." ເຖິງແມ່ນວ່າພວກເຂົາມັກຈະເອີ້ນວ່າການໂຕ້ຕອບຂອງລະບົບປະຕິບັດການ, ຕົວຈິງແລ້ວພວກເຂົາກໍານົດບາງສິ່ງບາງຢ່າງທົ່ວໄປກວ່າ - "ເຂດ" ຫຼື "ຂອບເຂດ."

ເຫດຜົນສໍາລັບການມີເຂດທົ່ວໄປຫຼາຍຫຼືເຂດຂອບເຂດແມ່ນວ່າ, ດັ່ງທີ່ໄດ້ກ່າວໄວ້ໃນ [RFC4007], ໂຫນດ IPv6 ສາມາດມີການໂຕ້ຕອບ IPv6 ທີ່ແຕກຕ່າງກັນຫຼາຍທີ່ເຊື່ອມຕໍ່ກັບຊ່ອງທາງດຽວກັນ. ການໂຕ້ຕອບເຫຼົ່ານີ້ແມ່ນສະມາຊິກຂອງເຂດດຽວກັນ.

ມັນຄວນຈະເປັນໄປໄດ້ທີ່ຈະຈັດກຸ່ມການໂຕ້ຕອບຫຼາຍພາຍໃນເຂດພາຍໃຕ້ລະບົບປະຕິບັດການ; ໃນປັດຈຸບັນຂ້າພະເຈົ້າບໍ່ຮູ້ວ່ານີ້ແມ່ນເປັນໄປໄດ້ພາຍໃຕ້ Linux ຫຼືເຮັດແນວໃດມັນ.

ການໃຊ້ຄຳຕໍ່ທ້າຍ %<zone_id>, ພວກເຮົາສາມາດເອົາຕົວເລືອກເສັ້ນຄໍາສັ່ງ -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 ຕອບ

ຈາກ ping multicast ທັງໝົດນີ້, ພວກເຮົາໄດ້ຮັບການຕອບສະໜອງທັງໝົດ 6 ອັນ.

ຄໍາຕອບເຫຼົ່ານີ້ມາຈາກ unicast Link-Local IPv6 host addresses. ຕົວຢ່າງ, ນີ້ແມ່ນຄໍາຕອບທໍາອິດ:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

ທີ່ຢູ່ Unicast Link-Local IPv6 ແມ່ນຕ້ອງການຢູ່ໃນທຸກອິນເຕີເຟດທີ່ເປີດໃຊ້ IPv6 [RFC4291], "IP Version 6 Addressing Architecture". ເຫດຜົນສໍາລັບການນີ້ແມ່ນວ່າ node IPv6 ສະເຫມີມີທີ່ຢູ່ unicast IPv6 ອັດຕະໂນມັດ, ເຊິ່ງຢ່າງຫນ້ອຍມັນສາມາດນໍາໃຊ້ເພື່ອຕິດຕໍ່ສື່ສານກັບ nodes ອື່ນໆໃນການເຊື່ອມຕໍ່ໂດຍກົງຂອງມັນ. ນີ້ຮວມເຖິງການຕິດຕໍ່ສື່ສານກັບແອັບພລິເຄຊັນໃນໂຮສອື່ນຜ່ານທີ່ຢູ່ໂຮສ Link-Local.

ນີ້ເຮັດໃຫ້ການອອກແບບ ແລະການປະຕິບັດໂປຣໂຕຄໍງ່າຍເຊັ່ນ: IPv6 Neighbor Discovery ແລະ OSPFv3. ມັນຍັງອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນຜູ້ໃຊ້ສຸດທ້າຍຢູ່ໃນໂຮດເພື່ອຕິດຕໍ່ສື່ສານຜ່ານຊ່ອງທາງໂດຍບໍ່ຈໍາເປັນຕ້ອງມີໂຄງສ້າງພື້ນຖານ IPv6 ທີ່ສະຫນັບສະຫນູນອື່ນໆໃນຊ່ອງທາງ. ການສື່ສານໂດຍກົງລະຫວ່າງແມ່ຂ່າຍ IPv6 ທີ່ເຊື່ອມຕໍ່ແລ້ວບໍ່ຈໍາເປັນຕ້ອງມີ router IPv6 ຫຼືເຄື່ອງແມ່ຂ່າຍ DHCPv6 ໃນການເຊື່ອມຕໍ່.

ທີ່ຢູ່ Link-Local ເລີ່ມຕົ້ນດ້ວຍ 10-bit prefix fe80, ຕິດຕາມດ້ວຍ 54 zero bits ແລະຫຼັງຈາກນັ້ນ 64-bit interface identifier (IID). ໃນຄໍາຕອບທໍາອິດຂ້າງເທິງ 2392:6213:a15b:66ff ເປັນ IID 64-ບິດ.

Looped Multicast

ໂດຍຄ່າເລີ່ມຕົ້ນ, ແພັກເກັດ multicast ຈະຖືກສົ່ງຄືນພາຍໃນກັບ node ທີ່ສົ່ງພວກມັນ. ນີ້ເກີດຂຶ້ນສໍາລັບທັງ IPv6 ແລະ IPv4 ທີ່ຢູ່.

ເຫດຜົນສໍາລັບພຶດຕິກໍາການເລີ່ມຕົ້ນນີ້ແມ່ນວ່າເມື່ອແພັກເກັດ multicast ຖືກສົ່ງ, ອາດຈະມີຄໍາຮ້ອງສະຫມັກ multicast ທ້ອງຖິ່ນທີ່ຟັງຢູ່ໃນເຈົ້າພາບສົ່ງຕົວມັນເອງ, ເຊັ່ນດຽວກັນກັບບາງບ່ອນໃນເຄືອຂ່າຍ. ແອັບພລິເຄຊັນທ້ອງຖິ່ນນີ້ຕ້ອງໄດ້ຮັບແພັກເກັດ multicast.

ພວກ​ເຮົາ​ສາ​ມາດ​ເບິ່ງ multicast ໃນ​ທ້ອງ​ຖິ່ນ loop ໃນ​ຜົນ​ຜະ​ລິດ 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!)
...

ການຕອບສະຫນອງຄັ້ງທໍາອິດແລະໄວທີ່ສຸດ (0,106 ms ທຽບກັບ 0,453 ms) ແມ່ນມາຈາກທີ່ຢູ່ Link-Local ທີ່ຖືກຕັ້ງຄ່າໃນການໂຕ້ຕອບຕົວມັນເອງ enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

ປະໂຫຍດ ping ສະໜອງວິທີການສະກັດກັ້ນການຕິຊົມ multicast ໃນທ້ອງຖິ່ນໂດຍໃຊ້ພາລາມິເຕີ -L. ຖ້າພວກເຮົາສົ່ງ ping multicast ທັງໝົດດ້ວຍທຸງນີ້, ຄໍາຕອບຈະຖືກຈໍາກັດຢູ່ໃນ nodes ຫ່າງໄກສອກຫຼີກ. ພວກເຮົາບໍ່ໄດ້ຮັບການຕອບສະຫນອງຈາກທີ່ຢູ່ Link-Local ຂອງການໂຕ້ຕອບການສົ່ງ.

[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-ທີ່ຢູ່ທ້ອງຖິ່ນ

ດັ່ງທີ່ເຈົ້າອາດຈະເດົາໄດ້, unicast Link-Local addresses ດ້ວຍຕົນເອງບໍ່ໄດ້ໃຫ້ຂໍ້ມູນພຽງພໍເພື່ອຊີ້ບອກວ່າຈະໃຊ້ອິນເຕີເຟດໃດເພື່ອເຂົ້າຫາພວກມັນ. ເຊັ່ນດຽວກັນກັບທຸກ nodes multicast ping, ພວກເຮົາຍັງຈໍາເປັນຕ້ອງລະບຸການໂຕ້ຕອບເປັນພາລາມິເຕີເສັ້ນຄໍາສັ່ງ ping ຫຼື ID ເຂດທີ່ມີທີ່ຢູ່ໃນເວລາທີ່ pinging Link-Local addresses.

ເວລານີ້ພວກເຮົາສາມາດໃຊ້ໄດ້ -cເພື່ອຈໍາກັດຈໍານວນແພັກເກັດແລະຄໍາຕອບທີ່ສົ່ງແລະໄດ້ຮັບ ping, ນັບຕັ້ງແຕ່ພວກເຮົາກໍາລັງປະຕິບັດ 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 ~]$

Ping (ທັງໝົດ) ທີ່ຢູ່ IPv6 ອື່ນບໍ?

ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ເຫັນວິທີການ ping nodes IPv6 ທັງໝົດໃນຊ່ອງໃດໜຶ່ງໂດຍໃຊ້ທີ່ຢູ່ IPv6 multicast ທັງໝົດ. ff02::1. ພວກເຮົາຍັງໄດ້ເຫັນວິທີການລະບຸວ່າອິນເຕີເຟດໃດທີ່ຈະໃຊ້ກັບທີ່ຢູ່ IPv6 multicast ທັງໝົດ, ເນື່ອງຈາກທີ່ຢູ່ຂອງມັນເອງບໍ່ສາມາດສະໜອງຂໍ້ມູນນີ້ໄດ້. ພວກເຮົາໄດ້ໃຊ້ທາງເລືອກແຖວຄໍາສັ່ງ ping, ຫຼືລະບຸການໂຕ້ຕອບໂດຍໃຊ້ suffix %<zone_id>.

ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ຮຽນຮູ້ກ່ຽວກັບ unicast Link-Local addresses, ເຊິ່ງເປັນທີ່ຢູ່ທີ່ໃຊ້ເພື່ອຕອບສະໜອງຕໍ່ການຮ້ອງຂໍ echo multicast ICMPv6 ທັງໝົດ.

ພວກເຮົາຍັງໄດ້ເຫັນວ່າແພັກເກັດ multicast ຖືກສົ່ງກັບໄປຫາຈຸດສົ່ງໂດຍຄ່າເລີ່ມຕົ້ນແລະວິທີການປິດການໃຊ້ງານນີ້ສໍາລັບຜົນປະໂຫຍດ. ping.

ສຸດທ້າຍ, ພວກເຮົາ pinged ທີ່ຢູ່ Link-Local ດຽວໂດຍໃຊ້ຄໍາຕໍ່ທ້າຍ %<zone_id>, ນັບຕັ້ງແຕ່ທີ່ຢູ່ Link-Local ຕົວເອງບໍ່ໄດ້ສະຫນອງຂໍ້ມູນກ່ຽວກັບການໂຕ້ຕອບຂາອອກ.

ດັ່ງນັ້ນ, ແມ່ນຫຍັງກ່ຽວກັບ ping nodes ອື່ນໆທັງຫມົດແລະໄດ້ຮັບທີ່ຢູ່ unicast ທົ່ວໂລກຂອງພວກເຂົາ (GUAs) (ນັ້ນແມ່ນ, ທີ່ຢູ່ສາທາລະນະຂອງພວກເຂົາໃນອິນເຕີເນັດ) ຫຼືທີ່ຢູ່ unicast ທ້ອງຖິ່ນທີ່ເປັນເອກະລັກ (ULAs)? ພວກເຮົາຈະເບິ່ງນີ້ຢູ່ໃນບົດຄວາມ blog ຕໍ່ໄປ.

ນັ້ນແມ່ນທັງ ໝົດ.

ທ່ານສາມາດຊອກຮູ້ເພີ່ມເຕີມກ່ຽວກັບຫຼັກສູດຂອງພວກເຮົາໄດ້ທີ່ ບັນທຶກມື້ເປີດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com