एक चैनल पर सभी IPv6 नोड्स को पिंग करें

दर पर नया प्रवाह शुरू होने में कुछ दिन शेष हैं "नेटवर्क इंजीनियर" OTUS से. इस संबंध में, हम आपके साथ विषय पर उपयोगी सामग्री का अनुवाद साझा करना चाहेंगे।

IPv6 पिंग समस्याओं के निवारण के लिए युक्तियों और युक्तियों पर ब्लॉग पोस्ट की एक श्रृंखला (ICMPv6 इको अनुरोध/इको रिप्लाई)

कृपया ध्यान दें कि मैं लिनक्स (विशेष रूप से फेडोरा 31) का उपयोग कर रहा हूं, हालांकि उम्मीद है कि अन्य ऑपरेटिंग सिस्टम के लिए पिंग कमांड सिंटैक्स बहुत समान होना चाहिए।

एक चैनल पर सभी IPv6 नोड्स को पिंग करें

पहली और सरल युक्ति लिंक पर सभी IPv6 नोड्स को पिंग करना है।

IPv6 सभी प्रकार के एक-से-अनेक संचार के लिए मल्टीकास्ट पतों का उपयोग करता है। कोई प्रसारण (या प्रसारण) IPv6 पते नहीं हैं। यह IPv6 को IPv4 से अलग करता है, जहां कई प्रकार के प्रसारण पते होते हैं, उदाहरण के लिए, "सीमित प्रसारण" पता 255.255.255.255 [RFC1122]।

हालाँकि, एक "ऑल-नोड्स मल्टीकास्ट" IPv6 पता है, इसलिए हम लिंक पर सभी IPv6 नोड्स को पिंग करने के लिए इसका उपयोग करेंगे। (एक "प्रसारण" पता वास्तव में केवल एक विशेष रूप से नामित मल्टीकास्ट पता है, जो एक मल्टीकास्ट समूह है जिसमें सभी नोड्स शामिल हैं। ध्यान दें, उदाहरण के लिए, लिंक परत पर ईथरनेट प्रसारण पते में "समूह" या मल्टीकास्ट पता बिट चालू है ).

चैनल के लिए ऑल-नोड्स मल्टीकास्ट IPv6 पता: ff02::1. ff एक मल्टीकास्ट IPv6 पते को दर्शाता है। अगला 0 ध्वज का अनसेट बिट्स वाला भाग है।

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

अंत में, ::1 एक ऑल-नोड्स मल्टीकास्ट समूह निर्दिष्ट करता है।

पते के बारे में ff02::1 यह ध्यान दिया जाना चाहिए कि यह अस्पष्ट है। एकाधिक इंटरफ़ेस वाले IPv6 होस्ट पर, जैसे कि राउटर या मल्टीहोम होस्ट, पता ff02::1 ऐसा कुछ भी नहीं है जहां आप यह निर्दिष्ट कर सकें कि किस इंटरफ़ेस को ICMPv6 इको अनुरोध भेजना है या 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 नोड्स से प्रतिक्रियाएँ प्राप्त हुईं। प्रतिक्रियाएं लिंक-लोकल आईपीवी6 नोड पतों से आईं, जो उपसर्ग से शुरू होती हैं fe80::/10.

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

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

इंटरफेस परिभाषित करना - जोन आईडी

किसी इंटरफ़ेस को उपयोग के लिए उजागर करने का दूसरा तरीका IPv6 एड्रेस पैरामीटर का हिस्सा है।

हम इसका एक उदाहरण पिंग आउटपुट में देख सकते हैं, जहां प्रतिक्रिया देने वाले IPv6 होस्ट के पते में भी प्रत्यय होता है %enp3s2, उदाहरण के लिए:

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

इंटरफ़ेस निर्दिष्ट करने की यह विधि औपचारिक रूप से [आरएफसी4007], "आईपीवी6 डिफाइंड एड्रेस आर्किटेक्चर" में वर्णित है। हालाँकि उन्हें आमतौर पर ऑपरेटिंग सिस्टम इंटरफ़ेस कहा जाता है, वे वास्तव में कुछ अधिक सामान्य परिभाषित करते हैं - एक "ज़ोन" या "स्कोप"।

अधिक सामान्य ज़ोन या स्कोप ज़ोन होने का कारण यह है कि, जैसा कि [आरएफसी4007] में बताया गया है, एक आईपीवी6 नोड में एक ही चैनल से जुड़े कई अलग-अलग आईपीवी6 इंटरफेस हो सकते हैं। ये इंटरफ़ेस एक ही क्षेत्र के सदस्य हैं।

ऑपरेटिंग सिस्टम के अंतर्गत एक ज़ोन के भीतर एकाधिक इंटरफ़ेस को समूहित करना संभव होना चाहिए; फ़िलहाल मुझे नहीं पता कि क्या लिनक्स के तहत यह संभव है या इसे कैसे किया जाए।

प्रत्यय का प्रयोग %<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 अद्वितीय प्रतिक्रियाएँ प्राप्त हुईं।

ये प्रतिक्रियाएँ यूनिकास्ट लिंक-लोकल IPv6 होस्ट पतों से आईं। उदाहरण के लिए, यहाँ पहला उत्तर है:

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

यूनिकैस्ट लिंक-लोकल आईपीवी6 पते सभी आईपीवी6-सक्षम इंटरफेस [आरएफसी4291], "आईपी संस्करण 6 एड्रेसिंग आर्किटेक्चर" पर आवश्यक हैं। इसका कारण यह है कि एक IPv6 नोड में हमेशा स्वचालित रूप से एक यूनिकास्ट IPv6 पता होता है, जिसका उपयोग वह कम से कम अपने सीधे जुड़े लिंक पर अन्य नोड्स के साथ संचार करने के लिए कर सकता है। इसमें लिंक-लोकल होस्ट पते के माध्यम से अन्य होस्ट पर एप्लिकेशन के साथ संचार करना शामिल है।

यह IPv6 नेबर डिस्कवरी और OSPFv3 जैसे प्रोटोकॉल के डिज़ाइन और कार्यान्वयन को सरल बनाता है। यह मेजबानों पर अंतिम-उपयोगकर्ता अनुप्रयोगों को चैनल पर किसी अन्य सहायक आईपीवी6 बुनियादी ढांचे की आवश्यकता के बिना चैनल पर संचार करने की अनुमति देता है। कनेक्टेड IPv6 होस्ट के बीच सीधे संचार के लिए कनेक्शन पर IPv6 राउटर या DHCPv6 सर्वर की आवश्यकता नहीं होती है।

लिंक-स्थानीय पते 10-बिट उपसर्ग से शुरू होते हैं fe80, उसके बाद 54 शून्य बिट और फिर 64-बिट इंटरफ़ेस पहचानकर्ता (आईआईडी)। उपरोक्त प्रथम उत्तर में 2392:6213:a15b:66ff एक 64-बिट 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 एमएस की तुलना में 0,453 एमएस) इंटरफ़ेस पर कॉन्फ़िगर किए गए लिंक-स्थानीय पते से आती है 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 या लिंक-स्थानीय पते को पिंग करते समय पते के साथ ज़ोन आईडी।

इस बार हम उपयोग कर सकते हैं -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 ~]$

अन्य IPv6 पते (सभी) पिंग करें?

इस लेख में, हमने देखा कि ऑल-नोड्स मल्टीकास्ट IPv6 एड्रेस का उपयोग करके एक चैनल पर सभी IPv6 नोड्स को कैसे पिंग किया जाए ff02::1. हमने यह भी देखा कि कैसे निर्दिष्ट किया जाए कि ऑल-नोड्स मल्टीकास्ट IPv6 पते के साथ किस इंटरफ़ेस का उपयोग किया जाए, क्योंकि पता स्वयं यह जानकारी प्रदान नहीं कर सकता है। हमने या तो कमांड लाइन विकल्प का उपयोग किया ping, या प्रत्यय का उपयोग करके इंटरफ़ेस निर्दिष्ट करें %<zone_id>.

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

हमने यह भी देखा कि मल्टीकास्ट पैकेट डिफ़ॉल्ट रूप से भेजने वाले नोड पर कैसे लौटाए जाते हैं और उपयोगिता के लिए इसे कैसे अक्षम किया जाए ping.

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

तो अन्य सभी नोड्स को पिंग करने और उनके वैश्विक यूनिकास्ट पते (जीयूए) (यानी, इंटरनेट पर उनके सार्वजनिक पते) या उनके अद्वितीय स्थानीय यूनिकास्ट पते (यूएलए) प्राप्त करने के बारे में क्या? हम इसे अगले ब्लॉग पोस्ट में देखेंगे।

बस इतना ही।

आप हमारे पाठ्यक्रम के बारे में अधिक जानकारी यहां पा सकते हैं खुले दिन के नोट्स.

स्रोत: www.habr.com