दो इमारतें, एक पॉइंट-टू-पॉइंट रेडियो और एक इंटरनेट VPN जो दूसरा रास्ता बन सकता है। बैकअप के स्वचालित होने से पहले एक सवाल बाकी लगभग सब कुछ तय करता है: क्या बचना चाहिए — अलग सबनेट के बीच IP पहुँच या एक साझा ईथरनेट सेगमेंट? रेडियो का केबल जैसा व्यवहार करना इस बात का तर्क नहीं है कि हर ब्रॉडकास्ट फ्रेम इंटरनेट पर भेजा जाए। पहले इस सवाल का जवाब दें, क्योंकि दोनों जवाब अलग लूप नियंत्रण, अलग स्वास्थ्य जाँच और रिकवरी के अर्थ की अलग समझ मांगते हैं।

तय करें कि व्यवधान में क्या बचना चाहिए

उन एप्लिकेशन की सूची बनाएँ जिन्हें काम करते रहना है और नोट करें कि वे Layer 3 पहुँच पर निर्भर हैं या Layer 2 निकटता पर। फ़ाइल साझाकरण, डेटाबेस कनेक्शन और वेब सेवाएँ आमतौर पर सिर्फ़ रूट की परवाह करती हैं; डिस्कवरी प्रोटोकॉल, कुछ क्लस्टर उत्पाद और हर वह चीज़ जो एक ही ब्रॉडकास्ट डोमेन की अपेक्षा करती है, निकटता की परवाह करती है। गलत तरह की पहुँच बहाल करने वाला बैकअप ऐसी साइट बनाता है जो तकनीकी रूप से जुड़ी और व्यवहार में बेकार है।

उस सूची को लिख लें और डिज़ाइन के साथ जोड़ें, क्योंकि पहला एप्लिकेशन स्वामी नए लिंक के बारे में सुनते ही जवाब आमतौर पर खिसक जाता है।

राउटेड फेलओवर: दो प्रीफ़िक्स, एक पसंदीदा रास्ता

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

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

दूसरी के साथ तीसरी कमांड भी पढ़ें: नीति नियम, दूसरी तालिका या स्रोत-आधारित निर्णय एक सबनेट का ट्रैफ़िक दूसरे से अलग भेज सकते हैं, और एक ही डिफ़ॉल्ट लुकअप उसे छिपा देता है।

ब्रिज्ड फेलओवर: एक सेगमेंट, एक अवरोधक रास्ता

अगर निकटता सचमुच ज़रूरी है, तो बैकअप को ईथरनेट फ्रेम ले जाने होंगे, जो राउटेड IP टनल नहीं करता। कुछ प्लेटफ़ॉर्म VPN इंटरफ़ेस को स्थानीय सेगमेंट में ब्रिज करने का समर्थन करते हैं, और वे इंटरफ़ेस तब संबंधित परिणामों के साथ ब्रिज सदस्य बन जाते हैं। एक साथ फ़ॉरवर्ड करने वाले दो Layer 2 रास्ते लूप बनाते हैं, इसलिए डिज़ाइन को दोनों साइटों को कवर करने वाला स्पैनिंग ट्री और यह स्पष्ट कथन चाहिए कि कौन-सा रास्ता अवरोधित होना चाहिए।

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

जो सीमा मायने रखती है उसकी निगरानी करें

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

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

जाँच को सस्ता और सीमित रखें: छोटा अंतराल, कम गिनती और एप्लिकेशन की सहनशीलता से मेल खाता टाइमआउट। जो मॉनिटर खुद उसी रास्ते पर निर्भर है जिसे वह जाँचता है, वह कुछ भी बताना बंद करने तक सफलता बताता रहेगा।

भार के तहत दोनों दिशाओं का अभ्यास करें

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

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

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

संबंधित लेख