🥇 च्यानलमा सबै IPv6 नोडहरू पिङ गर्दै

दरमा नयाँ प्रवाह सुरु हुन केही दिन बाँकी छ "नेटवर्क इन्जिनियर" OTUS बाट। यस सन्दर्भमा, हामी तपाईंलाई यस विषयमा उपयोगी सामग्रीको अनुवाद साझेदारी गर्न चाहन्छौं।

IPv6 ping समस्याहरू (ICMPv6 इको अनुरोध/इको जवाफ) समस्या निवारणका लागि सुझाव र चालहरूमा ब्लग पोष्टहरूको श्रृंखला

कृपया ध्यान दिनुहोस् कि म लिनक्स (विशेष गरी Fedora 31) प्रयोग गर्दैछु, यद्यपि अन्य अपरेटिङ सिस्टमहरूको लागि पिंग आदेश सिन्ट्याक्स धेरै समान हुनुपर्छ।

च्यानलमा सबै IPv6 नोडहरू पिङ गर्नुहोस्

पहिलो र सरल टिप लिङ्कमा सबै IPv6 नोडहरू पिङ गर्नु हो।

IPv6 ले सबै प्रकारका एक-देखि-धेरै सञ्चारका लागि मल्टिकास्ट ठेगानाहरू प्रयोग गर्दछ। त्यहाँ कुनै प्रसारण (वा प्रसारण) IPv6 ठेगानाहरू छैनन्। यसले IPv6 लाई IPv4 बाट अलग गर्छ, जहाँ धेरै प्रकारका प्रसारण ठेगानाहरू छन्, उदाहरणका लागि, "सीमित प्रसारण" ठेगाना २५५.२५५.२५५.२५५ [RFC255.255.255.255]।

यद्यपि, त्यहाँ "सबै-नोड्स मल्टिकास्ट" IPv6 ठेगाना छ, त्यसैले हामी यसलाई लिङ्कमा सबै IPv6 नोडहरू पिङ गर्न प्रयोग गर्नेछौं। (एउटा "प्रसारण" ठेगाना वास्तवमा एक विशेष नाम दिइएको मल्टिकास्ट ठेगाना हो, जुन सबै नोडहरू समावेश गर्ने मल्टकास्ट समूह हो। नोट गर्नुहोस् कि, उदाहरणका लागि, लिङ्क तहमा रहेको इथरनेट प्रसारण ठेगानाहरूमा "समूह" वा मल्टिकास्ट ठेगाना बिट अन गरिएको छ। )।

च्यानलका लागि सबै-नोडहरू मल्टिकास्ट IPv6 ठेगाना: ff02::1. ff मल्टीकास्ट IPv6 ठेगाना जनाउँछ। अर्को ० सेट नगरिएको बिट्सको साथ झण्डाको भाग हो।

थप 2 मल्टीकास्ट समूहको क्षेत्र परिभाषित गर्दछ। मल्टिकास्ट IPv4 ठेगानाहरूको विपरीत, मल्टिकास्ट IPv6 ठेगानाहरूको दायरा हुन्छ। स्कोप मानले नेटवर्कको भागलाई संकेत गर्छ जसमा मल्टीकास्ट प्याकेटलाई फर्वार्ड गर्न अनुमति दिइएको छ। एक पटक प्याकेट निर्दिष्ट दायराको सीमामा पुगेपछि, प्याकेट छोड्नु पर्छ, चाहे यसको हप काउन्ट फिल्ड शून्य होस्। निस्सन्देह, यदि हप गणना निर्दिष्ट मल्टिकास्ट समूह सीमामा पुग्नु अघि शून्य पुग्छ, यो पनि तुरुन्तै रिसेट हुन्छ। यहाँ IPv6 मल्टिकास्ट स्कोपको पूर्ण सूची छ।

अन्ततः, ::1 सबै-नोड बहुकास्ट समूह निर्दिष्ट गर्दछ।

ठेगाना बारे ff02::1 यो अस्पष्ट छ भनेर ध्यान दिनुपर्छ। एक IPv6 होस्टमा बहु इन्टरफेसहरू, जस्तै राउटर वा बहुमुखी होस्ट, ठेगाना ff02::1 ICMPv6 echo अनुरोधहरू पठाउने वा तिनीहरू आइपुग्दा ICMPv6 प्रतिध्वनि जवाफहरू प्राप्त गर्ने अपेक्षा गर्ने कुन इन्टरफेसले निर्दिष्ट गर्न सक्नुहुन्छ भन्ने कुनै पनि ठाउँ छैन। ff02::1 मान्य छ र बहु-इन्टरफेस नोडमा संलग्न कुनै पनि इन्टरफेस र च्यानलहरूमा प्रयोग गर्न सकिन्छ।

त्यसोभए जब हामी सबै IPv6 नोडहरू लिङ्कमा पिंग गर्छौं, हामीले कुनै न कुनै रूपमा उपयोगितालाई पनि बताउन आवश्यक छ ping IPv6 को लागि, कुन इन्टरफेस प्रयोग गर्न।

इन्टरफेस परिभाषित गर्दै - कमाण्ड लाइन विकल्प

हामीले पहिले नै देखेका छौं, हामीले प्रयोग गर्न चाहने सबै-नोड्स मल्टिकास्ट ठेगाना - हो ff02::1 - कुन इन्टरफेस पठाउने र ICMPv6 इको अनुरोध र इको जवाफ प्याकेटहरू प्राप्त गर्ने बारे कुनै जानकारी प्रदान गर्दैन।

त्यसोभए, हामी मल्टिकास्ट ठेगाना स्पेस वा युनिकास्ट लिङ्क-स्थानीय ठेगाना स्पेसको लागि प्रयोग गरिने इन्टरफेस कसरी निर्दिष्ट गर्छौं?

पहिलो र सबैभन्दा स्पष्ट तरिका हामीले प्रयोग गरिरहेको अनुप्रयोगमा प्यारामिटरको रूपमा प्रदान गर्नु हो।

उपयोगिता को लागी 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 ~]$

यो सबै-नोड्स मल्टिकास्ट पिंग प्रयोग गरेर, हामीले 6 IPv6 नोडहरूबाट प्रतिक्रियाहरू प्राप्त गर्यौं। जवाफहरू Link-Local IPv6 नोड ठेगानाहरूबाट आएका थिए, उपसर्गबाट सुरु हुँदै fe80::/10.

कि ping हामीले यसलाई अवरोध नगरेसम्म ICMPv6 प्रतिध्वनि अनुरोधहरू पठाउन जारी राख्दैन, हामी सामान्यतया -c विकल्प मार्फत पठाउन प्याकेटहरूको संख्या निर्दिष्ट गर्छौं। यद्यपि, यसले पिङलाई मल्टिकास्ट ICMPv6 इको अनुरोध पठाउँदा एकभन्दा बढी ICMPv6 इको जवाफ स्वीकार गर्न र प्रदर्शन गर्नबाट रोक्छ। यसको सट्टा, हामीले 1 सेकेन्ड पछि पिंग पूरा गर्नुपर्छ भनेर निर्दिष्ट गर्न -w विकल्प प्रयोग गर्यौं, जतिसुकै ICMPv6 प्रतिध्वनि अनुरोधहरू वा प्रतिध्वनि जवाफहरू पठाइयो वा प्राप्त गरियो।

ध्यान दिनुपर्ने अर्को कुरा हो (DUP!) दोस्रो र पछिल्लो उत्तरहरूमा आउटपुट। यी प्याकेटहरूलाई डुप्लिकेट प्रतिक्रियाहरूको रूपमा पहिचान गरिएको छ किनभने तिनीहरूसँग पहिलो स्थानमा पठाइएका व्यक्तिगत ICMPv6 प्रतिध्वनि अनुरोधहरू जस्तै ICMP अनुक्रम मान छ। तिनीहरू देखा पर्छन् किनभने ICMPv6 मल्टिकास्ट इको अनुरोधले धेरै व्यक्तिगत युनिकास्ट प्रतिक्रियाहरूमा परिणाम दिन्छ। डुप्लिकेटहरूको संख्या तथ्याङ्क सारांशमा पनि संकेत गरिएको छ।

इन्टरफेसहरू परिभाषित गर्दै - क्षेत्र ID

प्रयोगको लागि इन्टरफेस उजागर गर्ने अर्को तरिका IPv6 ठेगाना प्यारामिटरको भागको रूपमा हो।

हामी पिंग आउटपुटमा यसको उदाहरण देख्न सक्छौं, जहाँ प्रतिक्रिया दिने IPv6 होस्टहरूको ठेगानाहरूमा पनि प्रत्यय हुन्छ। %enp3s2, उदाहरणका लागि:

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

इन्टरफेसहरू निर्दिष्ट गर्ने यो विधि औपचारिक रूपमा [RFC4007] मा वर्णन गरिएको छ, "IPv6 परिभाषित ठेगाना आर्किटेक्चर।" यद्यपि तिनीहरूलाई सामान्यतया अपरेटिङ सिस्टम इन्टरफेस भनिन्छ, तिनीहरूले वास्तवमा केहि सामान्य परिभाषित गर्दछ - एक "जोन" वा "स्कोप।"

धेरै सामान्य क्षेत्रहरू वा स्कोप जोनहरू हुनुको कारण यो हो कि, [RFC4007] मा उल्लेख गरिए अनुसार, एक IPv6 नोडमा एउटै च्यानलमा जोडिएका धेरै फरक IPv6 इन्टरफेसहरू हुन सक्छन्। यी इन्टरफेसहरू एउटै क्षेत्रका सदस्यहरू हुन्।

अपरेटिङ सिस्टम अन्तर्गत एक क्षेत्र भित्र धेरै इन्टरफेसहरू समूहबद्ध गर्न सम्भव हुनुपर्छ; हाल मलाई थाहा छैन कि यो लिनक्स अन्तर्गत सम्भव छ वा यो कसरी गर्ने।

प्रत्यय प्रयोग गर्दै %<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 ~]$

लिङ्क-स्थानीय ठेगाना प्रतिक्रियाहरू

यस सबै-नोड्स मल्टिकास्ट पिंगबाट हामीले कुल 6 अद्वितीय प्रतिक्रियाहरू प्राप्त गर्यौं।

यी प्रतिक्रियाहरू unicast Link-Local IPv6 होस्ट ठेगानाहरूबाट आएका हुन्। उदाहरण को लागी, यहाँ पहिलो जवाफ छ:

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

युनिकास्ट लिङ्क-स्थानीय IPv6 ठेगानाहरू सबै IPv6-सक्षम इन्टरफेसहरूमा आवश्यक छ [RFC4291], "IP संस्करण 6 ठेगाना आर्किटेक्चर"। यसको कारण यो हो कि एक IPv6 नोडमा सधैं स्वचालित रूपमा एक युनिकास्ट IPv6 ठेगाना हुन्छ, जुन यसले कम्तिमा यसको प्रत्यक्ष जडान लिङ्कहरूमा अन्य नोडहरूसँग सञ्चार गर्न प्रयोग गर्न सक्छ। यसमा लिङ्क-स्थानीय होस्ट ठेगानाहरू मार्फत अन्य होस्टहरूमा अनुप्रयोगहरूसँग सञ्चार गर्ने समावेश छ।

यसले IPv6 Neighbour Discovery र OSPFv3 जस्ता प्रोटोकलहरूको डिजाइन र कार्यान्वयनलाई सरल बनाउँछ। यसले च्यानलमा कुनै पनि अन्य समर्थन IPv6 पूर्वाधारको आवश्यकता बिना नै च्यानलमा सञ्चार गर्न होस्टहरूमा अन्त-प्रयोगकर्ता अनुप्रयोगहरूलाई अनुमति दिन्छ। जडान गरिएका IPv6 होस्टहरू बीचको प्रत्यक्ष सञ्चारलाई जडानमा IPv6 राउटर वा DHCPv6 सर्भरको आवश्यकता पर्दैन।

लिङ्क-स्थानीय ठेगानाहरू 10-बिट उपसर्गबाट सुरु हुन्छ fe80, त्यसपछि 54 शून्य बिट र त्यसपछि 64-बिट इन्टरफेस पहिचानकर्ता (IID)। माथिको पहिलो उत्तरमा 2392:6213:a15b:66ff 64-bit IID हो।

लूप गरिएको मल्टीकास्ट

पूर्वनिर्धारित रूपमा, मल्टिकास्ट प्याकेटहरू नोडमा आन्तरिक रूपमा फर्काइन्छ जसले तिनीहरूलाई पठाएको थियो। यो दुबै IPv6 र IPv4 ठेगानाको लागि हुन्छ।

यस पूर्वनिर्धारित व्यवहारको कारण यो हो कि जब मल्टिकास्ट प्याकेटहरू पठाइन्छ, त्यहाँ पठाउने होस्टमा चलिरहेको सुन्ने स्थानीय मल्टिकास्ट अनुप्रयोग पनि हुन सक्छ, साथै नेटवर्कमा कतै। यो स्थानीय अनुप्रयोगले मल्टिकास्ट प्याकेटहरू पनि प्राप्त गर्नुपर्छ।

हामी हाम्रो पिंग आउटपुटमा यो मल्टिकास्ट स्थानीय लूप देख्न सक्छौं:

[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 प्यारामिटर प्रयोग गरेर स्थानीय मल्टिकास्ट प्रतिक्रिया दबाउन एक तरिका प्रदान गर्दछ -L। यदि हामीले यो फ्ल्यागको साथ सबै-नोडहरू मल्टिकास्ट पिङ पठायौं भने, प्रतिक्रियाहरू रिमोट नोडहरूमा सीमित हुन्छन्। हामीले पठाउने इन्टरफेसको लिङ्क-स्थानीय ठेगानाबाट प्रतिक्रिया प्राप्त गर्दैनौं।

[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 वा लिङ्क-स्थानीय ठेगानाहरू पिङ गर्दा ठेगानाको साथ क्षेत्र ID।

यस पटक हामी प्रयोग गर्न सक्छौं -cपठाइएको र प्राप्त प्याकेट र प्रतिक्रियाहरूको संख्या सीमित गर्न 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 ~]$

Ping (सबै) अन्य IPv6 ठेगानाहरू?

यस लेखमा, हामीले कसरी सबै-नोडहरू मल्टिकास्ट IPv6 ठेगाना प्रयोग गरेर च्यानलमा सबै IPv6 नोडहरू पिंग गर्ने देख्यौं। ff02::1। हामीले सबै-नोड्स मल्टिकास्ट IPv6 ठेगानासँग कुन इन्टरफेस प्रयोग गर्ने भनेर कसरी निर्दिष्ट गर्ने भनेर पनि देख्यौं, किनकि ठेगानाले यो जानकारी प्रदान गर्न सक्दैन। हामीले या त कमांड लाइन विकल्प प्रयोग गर्यौं ping, वा प्रत्यय प्रयोग गरेर इन्टरफेस निर्दिष्ट गर्नुहोस् %<zone_id>.

त्यसपछि हामीले युनिकास्ट लिङ्क-स्थानीय ठेगानाहरू बारे जान्यौं, जुन सबै-नोडहरू मल्टिकास्ट ICMPv6 इको अनुरोधहरूमा प्रतिक्रिया दिन प्रयोग गरिएका ठेगानाहरू हुन्।

हामीले यो पनि देख्यौं कि कसरी मल्टिकास्ट प्याकेटहरू पूर्वनिर्धारित रूपमा पठाउने नोडमा फर्काइन्छ र यसलाई उपयोगिताको लागि कसरी असक्षम गर्ने। ping.

अन्तमा, हामीले प्रत्यय प्रयोग गरेर एकल लिङ्क-स्थानीय ठेगाना पिङ गर्यौं %<zone_id>, किनकि लिङ्क-स्थानीय ठेगानाहरूले आफैंले बाहिर जाने इन्टरफेसको बारेमा जानकारी प्रदान गर्दैन।

त्यसोभए अन्य सबै नोडहरू पिंग गर्ने र तिनीहरूको विश्वव्यापी युनिकास्ट ठेगानाहरू (GUAs) (अर्थात, इन्टरनेटमा तिनीहरूको सार्वजनिक ठेगानाहरू) वा तिनीहरूको अद्वितीय स्थानीय युनिकास्ट ठेगानाहरू (ULAs) प्राप्त गर्ने बारे के हुन्छ? हामी यसलाई अर्को ब्लग पोस्टमा हेर्नेछौं।

यति नै।

तपाईले हाम्रो पाठ्यक्रम बारे थप जान्न सक्नुहुन्छ खुला दिन नोटहरू.

स्रोत: www.habr.com

च्यानलमा सबै IPv6 नोडहरू पिङ गर्नुहोस्

च्यानलमा सबै IPv6 नोडहरू पिङ गर्नुहोस्

इन्टरफेस परिभाषित गर्दै - कमाण्ड लाइन विकल्प

इन्टरफेसहरू परिभाषित गर्दै - क्षेत्र ID

लिङ्क-स्थानीय ठेगाना प्रतिक्रियाहरू

लूप गरिएको मल्टीकास्ट

पिङ लिङ्क-स्थानीय ठेगानाहरू

Ping (सबै) अन्य IPv6 ठेगानाहरू?

एक टिप्पणी थप्न Отменить ответ