3 सबनेट, 2 ओएसपीएफ क्षेत्र - क्या यह काम करेगा?


10

क्या कोई समस्या तब होगी जब मेरे पास एक टोपोलॉजी होगी जिसमें 3 सबनेट और दो ओएसपीएफ क्षेत्र होंगे जहां एक सबनेट एलईए 0 में है और अन्य दो सबनेट दोनों एलईए 1 में हैं?

उदाहरण के लिए:

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

तीन अलग-अलग राउटर? यदि हां, तो कृपया विवरण शामिल करें कि राउटर के बीच के लिंक किस क्षेत्र में हैं। OSPF एक ही क्षेत्र में लिंक डालता है, और क्षेत्रों को लिंक के दोनों किनारों पर मेल खाना चाहिए
माइक पेनिंगटन

@ माइक पेनिंगटन - क्या आप एबीआर में भी ओएसपीएफ नेटवर्क स्टेटमेंट की तलाश कर रहे हैं? मैं किसी भी वर्चुअल लिंक btw के बिना एक विन्यास के बारे में बात कर रहा हूँ।
DOCTOR

हां, इस प्रकार 3 अलग-अलग राउटर हैं: [क्षेत्र 1 नेटवर्क, सबनेट 1] --- [राउटर # 1] --- [क्षेत्र 0 नेटवर्क, सबनेट 2, एंड डिवाइस # 1] --- [राउटर # 2] --- (एक क्षेत्र 0 नेटवर्क, सबनेट 2, एंड डिवाइस # 2] --- [राउटर # 3] --- [क्षेत्र 1 नेटवर्क, सबनेट 3]
डॉक्‍टर

जवाबों:


7

रीढ़ की हड्डी के क्षेत्र के पीछे के क्षेत्र 1 के प्रश्न के बारे में (क्षेत्र 0):

[क्षेत्र 1, सबनेट 1] --- [एबीआर # 1] --- [क्षेत्र 0, सबनेट 2] --- [एबीआर # 2] --- [क्षेत्र 1, सबनेट 3]

[क्षेत्र 1, सबनेट 1] --- [रूटर # 1] --- [क्षेत्र ०, सबनेट २, एंड डिवाइस # 1] --- [राउटर # २] --- [क्षेत्र ०, सबनेट २, एंड डिवाइस # 2] --- [राउटर # 3] --- [क्षेत्र 1, सबनेट 3]

संक्षिप्त उत्तर: आपके प्रस्ताव में कोई समस्या नहीं है ...

लंबा जवाब:

यहां तक ​​कि पीटर का जवाब, जो तर्क देता है कि क्षेत्र संख्याओं का पुन: उपयोग करना बुरा डिजाइन है, कोई सबूत नहीं देता है कि यह एक बुरा डिजाइन है; यदि आप उनके द्वारा उपयोग किए गए हाइपरलिंक्स की जांच करते हैं, तो इस डिजाइन के लिए अवांछनीय परिणामों की कोई व्याख्या नहीं है। इसके अलावा, तर्क है कि आपको R1 और R3 को जोड़ने में समस्याएँ हो सकती हैं, क्योंकि R1 से R3 लिंक को वैध रूप से या तो एरिया 0 या एरिया 1 में कॉन्फ़िगर किया जा सकता है, यह निर्भर करता है कि आप इसे किस ट्रैफ़िक में ट्रांसफर करना चाहते हैं। वह जिन कठिनाइयों का उल्लेख करता है, वह एक झूठी दुविधा है।

में 2328 RFC, धारा 3.7 ओएसपीएफ स्पष्ट रूप से आप (नीचे जो "क्षेत्र विभाजन" कहा जाता है,) अनियमित गैर रीढ़ की हड्डी क्षेत्रों का उपयोग करने की अनुमति देता है:

    OSPF does not actively attempt to repair area partitions.  When
    an area becomes partitioned, each component simply becomes a
    separate area.  The backbone then performs routing between the
    new areas.  Some destinations reachable via intra-area routing
    before the partition will now require inter-area routing.
    ...  Also, the backbone itself must not partition.

इस प्रकार चाहे आप प्रस्तावित असंतोषी क्षेत्र 1 का उपयोग करें, यह सिर्फ स्वाद की बात है ... कुछ लोगों को आपके आरेख में कॉन्फ़िगरेशन का उपयोग करना अतार्किक लगता है; ये लोग सुझाव दे सकते हैं कि आप OSPF क्षेत्र संख्याओं को एक साथ रखते हैं ... इसलिए आपको राउटर # 3 पर [क्षेत्र 1, सबनेट 3] को [क्षेत्र 3, सबनेट 3] में बदलना होगा। अन्य लोगों को क्षेत्र 1 का पुन: उपयोग करने में कोई समस्या नहीं दिखाई देती है, क्योंकि OSPF क्षेत्र संख्या केवल स्थानीय रूप से महत्वपूर्ण है जो OSPF हेलोस को उत्पन्न करने वाले राउटर के लिए महत्वपूर्ण है।

किसी भी तरह से, हमें यह स्वीकार करना चाहिए कि ओएसपीएफ एक उल्लेखनीय लचीला प्रोटोकॉल है; इस बहस में एक पक्ष या दूसरे को चुनने की परवाह किए बिना।


1
FYI करें यह डिजाइन (असंतुष्ट क्षेत्र 1) कुछ सैन्य नेटवर्क में उत्पादन उपयोग में है। एक दूरस्थ साइट पर तैनाती करने वाली इकाई जो डीएमवीपीएन के माध्यम से हब साइट एबीआर पर वापस कनेक्ट हो जाएगी, एक मानक कॉन्फ़िगरेशन के साथ एक राउटर दिया जाता है। अधिकांश वे राउटर पर एक या दो आईपी पते बदल देंगे। यह संदिग्ध है कि क्या यह "सबसे अच्छा अभ्यास" है, लेकिन यह काम करता है और गैर-विशेषज्ञों के लिए इसे लागू करना आसान है।

@ user2668 उच्च स्तरीय सैन्य नीति उत्पादन नेटवर्क में इसे बढ़ावा नहीं देती है। यद्यपि "विशेष" संगठन (खरगोश के कानों पर ध्यान दें) वे जो करना चाहते हैं, करते हैं, जब वे चाहते हैं, तो यह निश्चित रूप से आदर्श नहीं है। मैं निश्चित रूप से कह सकता हूं कि area 0डिजाइन जटिलता को सीमित करने के लिए विशेष रूप से एकल ओएसपीएफ डिजाइन को बढ़ावा देने वाली शाखाएं हैं ।
रयान फोले

8

यह काम करेगा लेकिन यह एक खराब डिज़ाइन विकल्प (IMHO) होगा जब तक कि आपके पास ऐसा करने का कोई विशिष्ट कारण न हो।

यह चर्चा देखें: OSPF क्षेत्र IDs डुप्लिकेट करें

OSPF सर्वोत्तम अभ्यास

अनुशंसित OSPF कॉन्फ़िगरेशन सर्वोत्तम प्रथाओं (SSM उदाहरण का उपयोग करके)

OSPF क्षेत्र विन्यास सर्वोत्तम प्रथाओं

# 1 अपडेट करें :

पूर्णता के लिए, मैंने इस स्थिति का डाइनमिप्स का उपयोग करते हुए मजाक उड़ाया। मंच सिस्को 3725s था जो IOS ver 12.4 (15) T13 चला रहा था।

R1 (lo0 1.1.1.1, f0 / 0 10.12.0.1) <-> R2 (lo0 2.2.2.2, f0 / 0 10.12.0.2, f0 / 1 10.23.0.2) <-> R3 (lo03.3.3, f0 /) 0 10.23.0.3)।

R1 & R3 के लूपबैक इंटरफेस को क्षेत्र 1 में रखा गया था, अन्य सभी इंटरफेस क्षेत्र 0 में हैं।

पिंग तब किए गए थे (जैसे R1 # पिंग आईपी 1.1.1.1 स्रोत 3.3.3.3) R1 और R3 बॉक्स के बीच कनेक्टिविटी की पुष्टि करता है।

मेरी राय में मैं अभी भी इस वास्तुकला से दूर भागूंगा। माइक पूरी तरह से वैध अंक बनाता है (और परीक्षण पुष्टि करता है) कि यह काम करता है। OSPF क्षेत्र रूट प्रचार को नियंत्रित करने और राउटर के लिंक स्टेट डेटाबेस के आकार को कम करने के लिए उपयोगी उपकरण हैं - लेकिन वे यह भी काम करते हैं (मुझे कम से कम) यह दस्तावेज करने के लिए कि मैं "इस" नेटवर्क के हिस्से को "आर्किटेक्चरली" से अलग करने का इरादा रखता हूं। किसी कारण से नेटवर्क का हिस्सा।

यदि भविष्य में आप R1 को R3 से कनेक्ट करने का निर्णय लेते हैं और उसी क्षेत्र का उपयोग कर रहे हैं # तो आप किस्मत से बदल गए हैं और अपने आप को क्षेत्र संख्या बदलने या वर्चुअल लिंक का उपयोग करने के साथ बहुत सारे मुद्दों को सहेजने का समर्थन किया है। तो शायद यह हर जगह दो क्षेत्र आईडी (0 & 1) का उपयोग करने के पक्ष में एक तर्क है - लेकिन फिर आपने मूल रूप से आर 1 और आर 3 को सीधे संवाद करने में सक्षम होने का इरादा नहीं किया। कंधे उचकाने की क्रिया

यह शैली और व्यक्तिगत प्राथमिकता का मामला है - ऐसा प्रतीत होता है कि कोई तकनीकी कारण नहीं है कि यह काम क्यों न करे और मैंने कभी भी इसका प्रतिनिधित्व करने का इरादा नहीं किया।

अद्यतन # 2

कनेक्शनों के गैर-एससीआई कला आरेख को जोड़ना - रैखिक रूप से और एक त्रिकोण के रूप में खींचा गया। R1 और R3 के बीच क्या इरादा है? क्या क्षेत्र 1 को सन्निहित या अलग माना जाता है?

यहाँ छवि विवरण दर्ज करें


तर्क यह है कि एएसपी के विभिन्न हिस्सों के बीच होने वाले ओएसपीएफ ट्रैफिक की मात्रा को कम करना है। मैंने आपके सभी लिंक पर एक नज़र डाली और पता नहीं कि क्या मैंने कुछ याद किया है, लेकिन यह उस उद्देश्य के लिए एक खराब डिज़ाइन विकल्प क्यों है जिसका मैंने उल्लेख किया है?
DOCTOR

1
@Peter, रिचर्ड बर्ट के जवाब के अलावा , मुझे आपके लिंक में कुछ भी नहीं मिल रहा है जो बताता है कि असंगत गैर-रीढ़ की हड्डी वाले क्षेत्र एक समस्या हैं ... और रिचर्ड के जवाब को उसी प्रश्न के लिए रेज़ व्हाइट द्वारा जवाब दिया गया था । OSPF क्षेत्र विन्यास सर्वोत्तम प्रथाओं की ओर इशारा करते हुए आपके द्वारा उल्लेखित लिंक एक असमान क्षेत्र के बारे में कुछ नहीं कहता है जो मुझे मिल सकता है। क्या आप उत्तर के बारे में कुछ और बता सकते हैं?
माइक पेनिंगटन

@ माइक पेनिंगटन - ऐसा कोई तकनीकी कारण नहीं है कि आप OSPF क्षेत्रों को बंद नहीं कर सकते, लेकिन बहुत सारे व्यावहारिक हैं। अपने वातावरण को बनाए रखना और दूसरों के बीच समस्या निवारण करना। अपने कोड में टिप्पणियों की तरह, आवश्यक नहीं है लेकिन यह बाद में आपके जीवन को बहुत आसान बनाता है।
पीटर

1
@ पेटर, यह बिल्कुल सही बात है, आपने साबित कर दिया कि यह कम स्पष्ट है ... सिर्फ इसलिए कि आपको यह पसंद नहीं है कि यह दुनिया के बाकी हिस्सों के लिए एक समस्या नहीं है ... इस बिंदु पर, मैं सुनना शुरू कर रहा हूं आपके पास अपने तर्क का समर्थन करने के लिए कोई सबूत नहीं है
माइक पेनिंगटन

1
आप प्रसारण डोमेन को सीमित करने के लिए क्षेत्र करते हैं, यदि आप क्षेत्र 1 और क्षेत्र 1 अभाज्य आप एक भौतिक पृथक्करण पर निर्भर हैं, क्योंकि दोनों क्षेत्र 1s एक ही राउटर या बाढ़ डोमेन में नहीं रह सकते हैं। यदि आपके पास क्षेत्र 1 और क्षेत्र 2 है, तो आपके पास एक राउटर हो सकता है जिसमें दोनों क्षेत्र और क्षेत्र 0 हैं और अपने एसपीएफ़ डोमेन को दोगुना करें। आपके पास बस उसी संख्या का उपयोग न करके अधिक लचीलापन है। हो सकता है कि अधिक
मेगानेट

1

वैसे आपको सामान्य रूप से एक अलग गैर क्षेत्र 0 क्षेत्र के माध्यम से क्षेत्र 0 से बात करने के लिए आभासी लिंक का उपयोग करने की आवश्यकता है या आप गैर शून्य क्षेत्र के माध्यम से क्षेत्र 0 के 2 भागों को जोड़ते हैं। इसलिए वर्चुअल लिंक लागू नहीं होते हैं। आप एक गैर संक्रामक क्षेत्र हो सकते हैं यदि इसका क्षेत्र 0 नहीं है, लेकिन जैसा कि ऊपर संकेत दिया गया है, वास्तव में एक अच्छा विचार नहीं है। कहा जा रहा है कि आप प्रस्तावित टोपोलॉजी आभासी लिंक के बिना काम करेंगे।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.