तीन हजार शाखा राउटिङ समस्याजस्तो सुनिन्छ, तर व्यवहार लेखा समस्याजस्तो हुन्छ। प्रिफिक्सको कुल संख्या दस मिनेटमा निकालिन्छ, र दुखाउने संख्या त्यो विरलै हुन्छ। दुखाउने भनेको प्रत्येक सत्रको काम, कुनै साझा घटक विफल हुँदा अपडेटको लहर, र फर्वार्डिङ नयाँ टोपोलोजीसँग फेरि मिल्न लाग्ने समय हो।

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

चार बजेट, एउटा होइन

प्रत्येक बजेट फरक प्रश्नको उत्तर दिन्छ, र प्रत्येक फरक प्लेटफर्ममा बाध्यकारी सीमा हुन सक्छ। तिनीहरूलाई छुट्टाछुट्टै लेख्दा एउटा ठूलो प्रिफिक्स संख्याले सम्पूर्ण डिजाइनको ठाउँ लिन सक्दैन।

BudgetWhat you are really counting
SessionsPeers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count
PrefixesAlternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see
ChurnUpdates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event
RecoveryTime to detect, reselect, reinstall and restore the application, measured end to end rather than per box

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

चारैभित्र प्लेटफर्मको प्रश्न पनि लुकेको छ: इन्क्रिप्शन, फर्वार्डिङ र राउटिङ एउटै CPU साझा गर्छन् कि छुट्टै बाटा छन्। एउटै रुट क्षमता भएका दुई उपकरण लहरमा धेरै फरक व्यवहार गर्न सक्छन्, र डेटाशीटले तपाईं कुन किन्दै हुनुहुन्छ भन्ने विरलै भन्छ।

आफ्नै संख्याले गणित गर्नुहोस्

एउटा काल्पनिक डिजाइन लिनुहोस्: 3,000 शाखा, एकत्रीकरण अघि प्रत्येकमा तीन प्रिफिक्स, र रिडन्डन्सीका लागि प्रति शाखा दुई हब। हब जोडीले सारांश अघि करिब 9,000 शाखा प्रिफिक्स राख्नुपर्छ, र प्रत्येक शाखा दुवैसँग पियर गरे डिजाइनले 6,000 शाखा-देखि-हब सत्र जनाउँछ।

अब प्रिफिक्स नभएका भागहरू थप्नुहोस्। प्रत्येक सत्रले केही नबदले पनि अवस्था र आवधिक सन्देश बोक्छ। छिटो परिवर्तन अपेक्षित भए प्रत्येक हबले प्रति प्रिफिक्स एकभन्दा बढी मार्ग राख्न सक्छ, त्यसैले विकल्पको संख्या छानिएकाको संख्याभन्दा बढी हुन सक्छ। र प्रत्येक स्पोकको दृष्टि छुट्टै नीति-निर्णय हो: प्रत्येक शाखालाई अरू सबैका रुट दिँदा काम यसरी गुणन हुन्छ जो हब-पक्षको गणनाले देखाउँदैन।

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

BGP ले तपाईंलाई के दिन्छ, र IGP ले के दिन्छ

BGP ले राउटरले के पायो, के छान्यो र के घोषणा गर्छ भन्ने अलग गर्छ, र तीमध्ये प्रत्येक नीतिले नियन्त्रित हुन्छ। शाखा-नेटवर्कलाई ठ्याक्कै त्यही चाहिन्छ, किनभने स्पोकले सामान्यतया डिफल्ट रुट, केन्द्रीय सेवा र धेरै थोरै मात्र अरू देख्नुपर्छ। केवल अन्तिम तालिका गन्दा विकल्प र घोषणा लुक्छन्, र रिडन्डन्सी थप्दा बढ्ने भागहरू ठ्याक्कै ती हुन्।

IGP आफैंमा गलत हुँदैन। जब टोपोलोजी, क्षेत्र-संरचना र छिमेकी-मोडेल सेवासँग मिल्छ, लिङ्क-स्टेट प्रोटोकल छिटो एकत्रित हुन्छ र कम नीति-संरचना चाहिन्छ। जाल यो हो कि यसले BGP जस्तै प्रति-छिमेकी निर्यात नियन्त्रण व्यक्त गर्न सक्छ भनी ठान्नु: OSPF क्षेत्र बाढी-सीमा हो, एउटा शाखामा झुन्ड्याउन सकिने फिल्टर होइन।

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

लहरको परीक्षण गर्नुहोस्, स्थिर अवस्थाको होइन

तपाईंले साँच्चै अपेक्षा गर्नुभएको विफलताको वरिपरि तुलना बनाउनुहोस्: हब डाउन, क्षेत्रीय WAN घटना, वा आधा साइट एकैचोटि अफलाइन बनाउने मर्मत-झ्याल। शाखाको दृष्टिकोणबाट पुनःप्राप्ति मापन गर्नुहोस्, अनुप्रयोगसहित, किनभने सेकेन्डमा एकत्रित हुने नियन्त्रण-तलले सेसन पुनः स्थापना गर्न मिनेट लाग्छ भने थोरै मात्र अर्थ राख्छ।

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

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

सम्बन्धित लेखहरू