दो मालिक, एक पता: TAP ब्रिज पर डुप्लिकेट IP

एक Windows क्लाइंट 10.8.0.2 रखता है और तब तक काम करता है जब तक स्टार्टअप क्रम न बदले; फिर वही पता टकराव के रूप में सूचित होता है जबकि क्लाइंट में कुछ नहीं बदला। उसी ब्रिज्ड सेगमेंट पर दूसरा होस्ट उसी मान का दावा करता है, और जो मशीन कॉन्फ़िगरेशन सबसे बाद में पूरा करती है वही आमतौर पर हारती है। दोनों मानते हैं कि यह उनका है, और हारने वाला चुपचाप उस पते का उपयोग करना बंद कर देता है जिसे उसे उपयोग करने को कहा गया था। इसे समय की समस्या मानना ही इसे हर रीबूट पर दोहराने का कारण है।

ब्रिज को छूने से पहले टकराव के साक्ष्य पढ़ें

Windows दूसरे दावेदार के हार्डवेयर पते के साथ पता टकराव की सूचना देता है। वही हार्डवेयर पता उपयोगी तथ्य है, क्योंकि यह एक होस्ट पर एक इंटरफ़ेस से मेल खाता है, जबकि घटना का प्रदर्शित नाम डुप्लिकेट कहाँ है इसके बारे में कुछ नहीं बताता। कुछ भी बदलने से पहले हार्डवेयर पता लिख लें।

ARP-आधारित डुप्लिकेट पहचान पता उपयोग होने से पहले प्रतिस्पर्धी मालिकों की जाँच करती है और बाद में भी निगरानी रखती है। इसीलिए जो होस्ट नेटवर्क कॉन्फ़िगर करते समय अनुपस्थित था वह एक घंटे बाद भी टकराव पैदा कर सकता है। जाँच बूट पर एक बार होने वाली जाँच नहीं है। बाद में दिखने वाली मशीन पूरे दिन शांत उपयोग में रहा पता ले सकती है, इसलिए यह विफलता कॉन्फ़िगरेशन त्रुटि की तरह नहीं, दौड़ की तरह दिखती है।

टकराव की घटना अपने आप नहीं बताती कि दूसरा दावा किस कॉन्फ़िगरेशन ने बनाया, और प्रयोग के तौर पर पते मिटाना उस मैपिंग को नष्ट कर देता है जो आपको बताती। साक्ष्य का उद्देश्य हार्डवेयर पते को ऐसे इंटरफ़ेस में बदलना है जिसे आप जाँच सकें। मशीन के नाम से इन्वेंटरी खोजना आमतौर पर आपको गलत होस्ट पर भेजता है।

सेगमेंट पर हर दावे की सूची बनाएँ

ब्रिज्ड TAP सेटअप उन Ethernet सेगमेंट को जोड़ता है जो पहले अलग थे, इसलिए जो पते अपने नेटवर्क में अद्वितीय थे वे फ़्रेम के एक लिंक साझा करते ही टकरा सकते हैं। इसीलिए यह खराबी वर्ग VPN पर मौजूद है और उन रूटेड नेटवर्क पर नहीं जिन्हें इसने बदला। आपके पहले संदेह के बजाय हर संभावित मालिक की गणना करें।

सूची इस क्रम में देखें: हर ब्रिज डिवाइस और उसके सदस्य पोर्ट के पते, OpenVPN पूल और प्रति क्लाइंट कोई भी निश्चित आवंटन, और ब्रिज्ड सेगमेंट को कवर करने वाला कोई भी DHCP सर्वर। फिर टकराव रिपोर्ट के हार्डवेयर पते को आपने जो इंटरफ़ेस पाए उनसे मिलाएँ।

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

पूल और DHCP रेंज वे दो मालिक हैं जिन्हें लोग भूल जाते हैं। दोनों रेंज एक साथ छापें और कुछ और करने से पहले ओवरलैप खोजें। हाथ से दिया गया ब्रिज पता और वही मान बाँटने वाला पूल देर-सबेर टकराएँगे, और जब तक दोनों रेंज साथ-साथ न छपें टकराव अनियमित लगता है।

ब्रिज को केवल वहीं क्रमांक दें जहाँ उन्हें पहचान चाहिए

सामान्य होस्ट ब्रिज में ब्रिज डिवाइस होस्ट का तीसरी परत का कॉन्फ़िगरेशन रखता है और Ethernet तथा TAP सदस्य पोर्ट की तरह काम करते हैं। हर सदस्य को अपना पता देना, या पता बदले बिना एक सेटअप स्क्रिप्ट कई मशीनों पर कॉपी करना—इसी तरह एक सेगमेंट एक ही मान के तीन मालिकों तक पहुँचता है। फ़्रेम फ़ॉरवर्ड करने के लिए सदस्यों को अपनी पहचान की ज़रूरत नहीं। उन्हें प्रति होस्ट ठीक एक पहचान चाहिए जो उस सेगमेंट पर पहुँचने योग्य होना चाहिए।

जो ब्रिज केवल फ़्रेम स्विच करता है उसे उस सेगमेंट पर पते की ज़रूरत ही नहीं। उसे बिना क्रमांक छोड़ने से टकराव का पूरा वर्ग हट जाता है, बशर्ते होस्ट के पास आपका सत्यापित प्रबंधन मार्ग हो। पहले पहुँच की पुष्टि करें, दूसरे पता हटाएँ, और तीसरे पहुँचयोग्यता जाँचें।

यदि वह पता जिसे आप हटाने वाले हैं मशीन में जाने का एकमात्र रास्ता है, तो प्रयोग के तौर पर उसे हटाना निदान नहीं, स्वयं किया गया व्यवधान है। कुछ भी परखने से पहले आउट-ऑफ़-बैंड मार्ग सत्यापित करें।

सुधार को रीबूट में टिकने दें

चालू इंटरफ़ेस बदलना वर्तमान बूट को ठीक करता है और कुछ नहीं। स्टार्टअप पर पता फिर से बनाने वाला जो कुछ भी है वह अगले रीबूट पर टकराव लौटा देगा, और आप निष्कर्ष निकालेंगे कि सुधार काम नहीं आया, जबकि वास्तव में वह कभी स्थायी था ही नहीं। लिख लें कि आपने कौन-सी फ़ाइल बदली, ताकि अगला रीबूट आश्चर्य खोलने के बजाय निर्णय की पुष्टि करे।

उस कॉन्फ़िगरेशन का मालिक खोजें: नेटवर्क मैनेजर प्रोफ़ाइल, प्रति-इंटरफ़ेस फ़ाइल, कंटेनर या VM परिभाषा, या cloud-init टुकड़ा। उसे वहीं बदलें, फिर नया मान ही लौटता है यह पुष्टि करने के लिए जानबूझकर एक प्रभावित होस्ट रीबूट करें। रीबूट ही एकमात्र परीक्षण है जो स्थायित्व सिद्ध करता है।

DHCP रेंज के भीतर ब्रिज पतों को अपवर्जन के रूप में आरक्षित करें, या उन्हें बाहर ले जाएँ। जो आरक्षण केवल स्प्रेडशीट में है वह अपवर्जन नहीं है, और आवंटक उसे नहीं पढ़ेगा।

इसे हर क्लाइंट के ऑनलाइन रहते सिद्ध करें

एक सफल कनेक्शन कुछ सिद्ध नहीं करता, क्योंकि मूल लक्षण केवल तब दिखता था जब क्रम बदलता था। हर इच्छित क्लाइंट चालू करें, स्टार्टअप क्रम बदलें, और पुनः कनेक्ट के बाद दोहराएँ। फिर उस होस्ट को रीस्टार्ट करें जो पहले दौड़ हारता था और पुष्टि करें कि पता बचा रहता है।

सीधी पुष्टि के लिए, पता आवंटित करने से पहले डुप्लिकेट मालिक की जाँच करें और बाद में पड़ोसी तालिका पर नज़र रखें। यदि कुछ भी जाँच का उत्तर न दे और पूरे रीस्टार्ट चक्र में पता अद्वितीय रूप से धारित रहे, तो टकराव सुलझ गया है, केवल छिपा नहीं। नीचे दिए आदेश ब्रिज डिवाइस पर दोनों जाँचें करते हैं। RFC 5227 उस जाँच और घोषणा व्यवहार का वर्णन करता है जो ये उपकरण करते हैं, और जब कोई पहचान बंद करने का सुझाव दे तो यही उद्धृत करने का संदर्भ है।

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

जिस जाँच का कोई उत्तर न आए वह स्वच्छ सेगमेंट पर अपेक्षित परिणाम है। जो जाँच प्रतिक्रिया खींच लाए वह आपको शेष मालिक का हार्डवेयर पता देती है, वही साक्ष्य जो शुरू में Windows घटना ने दिया था। उस आउटपुट को परिवर्तन रिकॉर्ड के साथ रखें, क्योंकि पता अद्वितीय रूप से धारित है इसका वही एकमात्र प्रमाण है।