क्या आप स्थैतिक रूटिंग को अच्छी तरह से जानते हैं?

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

अस्वीकरण। विषय लिखते समय, मैं मानता हूं कि पाठक रूटिंग की अवधारणा से परिचित है, स्थिर मार्ग बनाना जानता है, और शब्द "एआरपी" को अपमानजनक नहीं मानता है। हालांकि, यहां तक ​​कि अनुभवी सिग्नलमैन निश्चित रूप से यहां कुछ नया पाएंगे।
सभी उदाहरणों का परीक्षण iOS 15.2M लाइन पर किया गया है। अन्य ऑपरेटिंग सिस्टम का व्यवहार भिन्न हो सकता है।
और यहां कोई डायनेमिक रूटिंग नहीं होगी।

हम निम्नलिखित टोपोलॉजी के साथ काम करते हैं:

एक स्थिर मार्ग कैसे प्रकट होता है?

शुरू करने के लिए, हम उस कमांड को निष्पादित करेंगे जो सभी को पता है, और डिबग के साथ देखें कि क्या होता है:

R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 

 IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.3 RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state IP ARP: creating incomplete entry for IP address: 10.0.0.3 interface GigabitEthernet0/1 IP ARP: sent req src 10.0.0.1 30e4.db16.7791, dst 10.0.0.3 0000.0000.0000 GigabitEthernet0/1 IP ARP: rcvd rep src 10.0.0.3 0019.aad6.ae10, dst 10.0.0.1 GigabitEthernet0/1 

IOS ने एक मार्ग बनाया और तुरंत अगले हॉप की तलाश में एक arp रिक्वेस्ट भेजी, जो हमारे पास 10.0.0.3 है। और तुरंत सवाल: राउटर को कैसे पता चला कि अनुरोध को Gi0 / 1 इंटरफ़ेस में भेजा जाना चाहिए? निश्चित रूप से कोई "स्थानीय इंटरफेस की सूची से" कहेगा और एक भयानक गलती करेगा। रूटिंग उस तरह काम नहीं करता है। वास्तव में, iOS ने राउटिंग टेबल पर एक पुनरावर्ती क्वेरी बनाई ताकि यह पता लगाया जा सके कि अगले हॉप को कैसे प्राप्त करें:

 R00#show ip route 10.0.0.3 Routing entry for 10.0.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1 

और यहाँ यह है, हमारे Gi0 / 1। आईओएस को पता है कि आरआईबी के लिए पुनरावर्ती अनुरोधों के साथ, जैसे ही यह "सीधे जुड़ा हुआ" ध्वज के साथ एक मार्ग पाता है, आपको समाप्त करने की आवश्यकता है। लेकिन क्या होगा यदि, 10.0.0.3 के प्रारंभिक अनुरोध के जवाब में, वापस लौटा मार्ग बिल्कुल जुड़ा नहीं है, लेकिन एक मध्यवर्ती एक, एक और अगले हॉप का जिक्र है? हम इस पर थोड़ा बाद में लौटेंगे, लेकिन अब यह याद रखें कि सीईएफ क्या है।

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

वापस हमारे स्थिर मार्ग पर। यहाँ राउटिंग टेबल में प्रविष्टि है:

 R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3 Route metric is 0, traffic share count is 1 

पैकेज कहां भेजें? 10.0.0.3 की तलाश कहाँ करें? यह स्पष्ट नहीं है। हमें राउटिंग टेबल को फिर से क्वेरी करने की आवश्यकता है, इस बार 10.0.0.3 के बारे में, और, यदि आवश्यक हो, तो कुछ और पुनरावृत्तियों का प्रदर्शन करें जब तक कि हम कनेक्टेड इंटरफ़ेस का पता नहीं लगा लेते। और इस तरह से, हम वास्तव में कई बार राउटर के प्रदर्शन को कम करते हैं।

और यहाँ CEF कहते हैं:

 R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 attached to GigabitEthernet0/1 

सरल और संक्षिप्त। एक इंटरफ़ेस है, अगला हॉप है, जिसमें आपको एक पैकेट भेजने की आवश्यकता है। बगल की मेज के बारे में उन्होंने क्या कहा?

 R00#show adjacency 10.0.0.3 detail Protocol Interface Address IP GigabitEthernet0/1 10.0.0.3(10) 0 packets, 0 bytes epoch 0 sourced in sev-epoch 2 Encap length 14 0019AAD6AE1030E4DB1677910800 ARP 

आइए, कुछ लंबी सीक्वेंस पर ध्यान दें। यह कुछ याद दिलाता है ... हम मैक 10.0.0.3 देखते हैं:

 R00#show arp | in 10.0.0.3 Internet 10.0.0.3 1 0019.aad6.ae10 ARPA GigabitEthernet0/1 

हम gi0 / 1 पर अपने मैक पते को देखते हैं:

 R00#show int gi0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is CN Gigabit Ethernet, address is 30e4.db16.7791 (bia 30e4.db16.7791) 

हाँ। वह डरावनी रेखा केवल दो पॉपपीज़ हैं जिन्हें एनकैप्सुलेशन के चरण में ईथरनेट हेडर में प्रतिस्थापित किया जाना है, और ईथरप्रिक्स 0x0800, अर्थात्। आम आईपीवी 4। और दो CEF तालिकाओं में पूरी तरह से सभी जानकारी है जो सफलतापूर्वक एक पैकेट को श्रृंखला के नीचे भेजने के लिए आवश्यक है।

यदि किसी के पास सवाल है, तो लोहे के टुकड़े को एक के बजाय एक ही बार में दो टेबल क्यों रखनी चाहिए, तो मैं स्पष्ट जवाब दूंगा: आमतौर पर एक राउटर में कुछ इंटरफेस (और एक ही समय में पड़ोसी) और कई मार्ग होते हैं। FIB में समान पॉपपीज़ के हजारों बार नकल करने का क्या मतलब है? विशेष रूप से हार्डवेयर प्लेटफ़ॉर्म पर बहुत अधिक मेमोरी नहीं होती है, चाहे वह ASRs का नया रूप हो या उत्प्रेरक लाइन का L3 स्विच। पैकेट ट्रांसमिट करते समय सभी CEF का उपयोग करते हैं।

और वैसे, आइए एक पल के लिए मूल डीबग पर वापस जाएं। कोई IP cef कमांड के साथ CEF अक्षम करें (ऐसा कभी न करें) और परिणाम की तुलना करें:

 IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.100 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.100 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.100 RT: add 3.1.1.0/24 via 10.0.0.100, static metric [1/0], add succeed, active state 

मार्ग जोड़ा गया। अर्पित अनुरोध नहीं था। और ठीक ही तो - आरआईबी ने मैक पते पर आत्मसमर्पण क्यों किया? यदि आप उदाहरण के लिए, 3.1.1.1 को पिंग करते हैं, तो सबसे अधिक संभावना है कि यह इस तरह होगा:

 R00#ping 3.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.1.1.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms 

पहला पैकेट छोड़ दिया गया है, और राउटर मैक पते को खोजने के लिए एक arp अनुरोध भेजता है 10.0.0.3 अगर यह पहले से ज्ञात नहीं था। सीईएफ हमेशा अगले हॉप के मैक पते को पहले से जानता है।

हमने इसका पता लगा लिया। अब इस सवाल पर लौटते हैं कि अगर सीधे जुड़े हुए इंटरफ़ेस पर स्थिर मार्ग की अगली आशा बिल्कुल नहीं है तो क्या होगा। हम बस आगे बढ़ते हैं:

 R00(config)#ip route 10.0.0.3 255.255.255.255 100.100.100.101 

जहाँ Gi0 / 2 का पता 100.100.100.100/24 ​​है।

 R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2 

यह सब कितना बुरा है ... लेकिन क्या होगा अगर हमारे पास पूरे सुपरनेट का मार्ग है?

 R00(config)#no ip route 10.0.0.3 255.255.255.255 100.100.100.101 R00(config)#ip route 10.0.0.0 255.0.0.0 100.100.100.101 R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 attached to GigabitEthernet0/1 

अब हमारा रूटिंग टेबल इस तरह दिखता है:

 R00#show ip route 10.0.0.0/8 is variably subnetted, 2 subnets, 3 masks S 10.0.0.0/8 [1/0] via 100.100.100.101 C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 L 10.0.0.1/32 is directly connected, GigabitEthernet0/1 100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 100.100.100.0/24 is directly connected, GigabitEthernet0/2 L 100.100.100.100/32 is directly connected, GigabitEthernet0/2 

यह अच्छा लगता है। 100.100.100.101 पर नया मार्ग 10.0.0.3 पर लागू नहीं होता है, क्योंकि इसका मास्क / 8 कनेक्टेड इंटरफेस पर / 24 से बहुत कम है। लेकिन अचानक Gi0 / 1, जिसमें 3.1.1.0/24 के लिए अगला हॉप था, किसी अज्ञात कारण से नीचे चला गया, और इसका जुड़ा मार्ग RIB से गायब हो गया।

 %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down RT: interface GigabitEthernet0/1 removed from routing table RT: del 10.0.0.0 via 0.0.0.0, connected metric [0/0] RT: delete subnet route to 10.0.0.0/24 RT: del 10.0.0.1 via 0.0.0.0, connected metric [0/0] RT: delete subnet route to 10.0.0.1/32 IP-ST(default): updating GigabitEthernet0/1 

यहाँ क्या हुआ:

 R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 recursive via 10.0.0.0/8 recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2 

ओह। अब नेटवर्क 3.1.1.0/24 पर पैकेट कहीं गलत है। मैं एक ऐसे परिदृश्य की कल्पना नहीं कर सकता जहाँ एक स्थिर मार्ग का अपेक्षित व्यवहार दूसरे इंटरफ़ेस पर स्विच करना हो। यदि उस इंटरफ़ेस के पीछे एक बैकअप पथ है, तो आपको अभी भी एक और स्थिर मार्ग बनाने की आवश्यकता है ...

क्या करें? मार्ग में तुरंत इंटरफ़ेस इंगित करें। मार्ग फिर से बनाएं:

 R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 

Gi0 / 1 उठाएँ। हम देखते हैं कि मार्ग अब 3.1.1.0/24 की ओर जाता है:

 R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1 

इंटरफ़ेस पहले से ही यहां इंगित किया गया है। इसलिए, राउटिंग टेबल पर कोई पुनरावर्ती प्रश्न नहीं होंगे। FIB की जाँच:

 R00#show ip cef 3.1.1.0 3.1.1.0/24 nexthop 10.0.0.3 GigabitEthernet0/1 

हां, कोई "पुनरावर्ती" नहीं। और अगर आप फिर से gi0 / 1 का भुगतान करते हैं? मार्ग गायब हो गया है।

 R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 0.0.0.0/0 no route 

और इस तथ्य के बावजूद कि 10.0.0.3 का मार्ग अभी भी था:

 R00#show ip cef 10.0.0.3 10.0.0.0/8 nexthop 100.100.100.101 GigabitEthernet0/2 

लेकिन क्या होता है यदि अगले हॉप के लिए रास्ता डिफ़ॉल्ट मार्ग देता है, और 3.1.1.0/24 को मार्ग इंटरफ़ेस को संदर्भित नहीं करता है?

 R00(config)#no ip route 10.0.0.0 255.0.0.0 100.100.100.101 R00(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.101 R00(config)#no ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 detail 0.0.0.0/0, epoch 0, flags default route recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2 

कृपया ध्यान दें कि "शो आईपी सीफ" के बाद की पहली पंक्ति "0.0.0.0/0" है और "3.1.1.0/24" नहीं है। इस तथ्य के बावजूद कि एक औपचारिक अगली उम्मीद है, वास्तव में मतदान तालिका के सभी पुनरावृत्तियों (पहले को छोड़कर) डिफ़ॉल्ट मार्ग को अनदेखा करते हैं, जो तार्किक है, अन्यथा मार्ग तालिका में किसी भी क्वेरी को लगभग हमेशा हल किया जाएगा ("हल") जिसमें इंटरफ़ेस मिल रहा है पैकेज भेजने की जरूरत है)। इसलिए, हमारा स्थिर मार्ग गायब है, लेकिन पैकेट अभी भी Gi0 / 2 के लिए उड़ान भरते हैं। सब कुछ एक स्पष्ट इंटरफ़ेस के बिना ही लगता है? वास्तव में नहीं। मान लीजिए कि राउटिंग प्रोटोकॉल को "रीडिस्ट्रिब्यूट स्टैटिक" कहा गया था। यदि स्थिर मार्ग चला गया है, तो घोषणा भी प्रतिक्रिया देती है। और यदि नहीं, तो राउटर सभी को "मेरे माध्यम से वहां जाने" के लिए कहता रहेगा, और यह निश्चित रूप से उपसर्ग 3.1.1.0/24 के लिए एक एल 3 रिंग में बदल जाएगा, जो कहीं और से सुलभ हो सकता है। लेकिन रुकिए, हम इस बात पर सहमत हुए कि डायनेमिक रूटिंग को न छूएं ...

लेकिन क्या होगा यदि आप एक स्थिर मार्ग में एक इंटरफ़ेस निर्दिष्ट करते हैं, लेकिन अगले हॉप के आईपी पते को निर्दिष्ट नहीं करते हैं? उत्तर: ईथरनेट के मामले में, अगर प्रॉक्सी हॉप को अगले हॉप पर अक्षम नहीं किया गया है, तो कनेक्शन टूट नहीं जाएगा, लेकिन राउटर बहुत खराब हो सकता है। अधिक जानकारी । अगर हम कहते हैं, "आईपी मार्ग 3.1.1.0 255.255.255.0 gi0 / 1", तो कुछ भी भयानक नहीं होगा, यहां तक ​​कि आरपी टेबल में सौ प्रविष्टियों में से कोई भी किसी भी राउटर द्वारा पचा जाएगा (और वर्कअराउंड स्क्रिप्ट हैं जिसमें ऐसी बैसाखी इष्टतम समाधान है ), लेकिन यहाँ "राउटर 0.0.0.0 0.0.0.0 gi0 / 1" बॉर्डर राउटर पर संभवतः उसे मार देगा। इसलिए, सामान्य नियम को याद रखें: यदि ईथरनेट इंटरफेस पर अगले हॉप के साथ एक स्थिर मार्ग बनाया जाता है, तो इसका आईपी पता हमेशा संकेत दिया जाना चाहिए। अपवाद केवल तब होते हैं जब आपके पास बहुत अच्छा विचार होता है कि आप क्या कर रहे हैं, आप क्यों कर रहे हैं और आप अन्यथा क्यों नहीं कर सकते हैं।

और अंत में, हम एक बहुत बुरा काम करेंगे।

 R00(config)# ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00(config)#ip route 10.0.0.3 255.255.255.255 3.1.1.1 

पहला मार्ग ठीक है, सौ बार परीक्षण किया गया। लेकिन दूसरा अजीब है - यह पहले के माध्यम से होता है। और पहले अब दूसरे को संदर्भित करता है, और हमारे पास अनंत पुनरावृत्ति है। यहाँ क्या हुआ:

 IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.3 RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state IP-ST(default): updating same distance on 10.0.0.3/32 IP-ST(default): 10.0.0.3/32 [1], 3.1.1.1 Path = 8, no change, not active state IP-ST(default): 10.0.0.3/32 [1], 3.1.1.1 Path = 2 3 7 RT: updating static 10.0.0.3/32 (0x0): via 3.1.1.1 RT: add 10.0.0.3/32 via 3.1.1.1, static metric [1/0], add succeed, active state 

सफलतापूर्वक जोड़ा गया। लेकिन तब इसे डीबग में हाइलाइट किया गया था:

 RT: recursion error routing 3.1.1.1 - probable routing loop RT: recursion error routing 10.0.0.3 - probable routing loop 

और गंभीरता 3 के साथ एक लॉग प्रविष्टि थी:

 %IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIB 

 R00#show ip cef 10.0.0.3 detail 10.0.0.3/32, epoch 0 Adj source: IP adj out of GigabitEthernet0/1, addr 10.0.0.3 359503C0 Dependent covered prefix type adjfib cover 10.0.0.0/24 1 RR source [no flags] recursive via 3.1.1.1, unresolved recursive-looped R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0, flags cover dependents Covered dependent prefixes: 1 notify cover updated: 1 recursive via 10.0.0.3, unresolved recursive-looped 

हालांकि, आरआईबी कोई अपराध नहीं देखता है:

 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3 Route metric is 0, traffic share count is 1 R00#show ip route 10.0.0.3 Routing entry for 10.0.0.3/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 3.1.1.1 Route metric is 0, traffic share count is 1 

निष्कर्ष - ऐसा कभी न करें।

रूटिंग टेबल में एक स्थिर मार्ग क्यों नहीं मिल सकता है?

किसी भी नेटवर्क को आईओएस में मार्गों के किसी भी स्रोत के बारे में स्पष्टीकरण में से एक को तुरंत देना चाहिए: एक ही उपसर्ग का एक और मार्ग है, लेकिन कम एडी के साथ (सभी को प्रशासनिक दूरी याद है?)। एक मार्ग जिसका स्रोत "जुड़ा हुआ" हमेशा AD = 0 है, और कोई अन्य मार्ग स्रोत "1" से कम कुछ भी नहीं ला सकता है, यहां तक ​​कि एक स्पष्ट इंटरफ़ेस वाला एक स्थिर मार्ग भी। उदाहरण जुड़ा:

 R00# show ip route C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 

यानी जब तक Gi0 / 1 इंटरफ़ेस अप स्थिति में है और सबनेट 10.0.0.0/24 से इसका एक पता है, इस उपसर्ग का कोई स्थिर मार्ग रूटिंग टेबल में दिखाई नहीं देगा।

विकल्प भी है "विभिन्न मार्ग स्रोत समान AD के साथ एक ही उपसर्ग के लिए मार्ग जोड़ते हैं"। इस मामले में IOS के व्यवहार का दस्तावेजीकरण नहीं किया गया है, सामान्य अनुशंसा "ऐसा कभी नहीं" है।

लेकिन चलो अन्य, कम स्पष्ट उदाहरण देखें। उदाहरण के लिए, स्थैतिक मार्गों को "स्थायी" शब्द के साथ बनाया जा सकता है, जो "स्थायी" के रूप में अनुवाद होता है, और फिर वे हमेशा रूटिंग टेबल में लटकाएंगे। है न? नहीं।

इसे जोड़ें और देखें:

 R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent R00#show ip cef 3.1.1.0 3.1.1.0/24 nexthop 10.0.0.3 GigabitEthernet0/1 

Gi0 / 1 डालें, और देखें:

 R00#show ip cef 3.1.1.0 3.1.1.0/24 unresolved via 10.0.0.3 

यह RIB में मौजूद है, और अन्य रूटिंग प्रोटोकॉल इसका उपयोग कर सकते हैं:

 R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3, permanent Route metric is 0, traffic share count is 1 

और अब, Gi0 / 1 को बढ़ाए बिना:

 R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent 

उन्होंने कुछ भी बदले बिना इसे फिर से बनाया। और यहाँ क्या हुआ:

 IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): cannot delete, PERMANENT R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 0.0.0.0/0 no route 

स्थायी, बोलो? नहीं। एक छोटी सी बारीकियों है: हमेशा के लिए राउटिंग टेबल में फिट होने के लिए एक स्थायी मार्ग के लिए, इसे कम से कम एक विभाजित सेकंड के लिए हल करने की आवश्यकता है। हालाँकि और क्या है "हमेशा के लिए"? जब यह बिना हल किए इंटरफ़ेस में हवा में लटका रहता है, तो यह "स्पष्ट आईपी मार्ग *" या इससे भी अधिक "पुनः लोड" कहने के लिए पर्याप्त है ताकि यह आरआईबी से गायब हो जाए।

लेकिन चलो जारी रखें। आइए इसे ऐसे करें:

 R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 R00(config)#ip route 3.1.1.10 255.255.255.255 3.1.1.1 

यह सामान्य मार्गों की तरह लगता है। क्या होगा? दूसरे के साथ - बिल्कुल कुछ भी नहीं।

 IP-ST(default): 3.1.1.10/32 [1], 3.1.1.1 Path = 8, no change, not active state IP-ST(default): 3.1.1.10/32 [1], 3.1.1.1 Path = 2 3 6 8, no change, not active state 

बात यह है। मान लीजिए कि YYYY के माध्यम से XXXX के लिए एक मार्ग है। हम X2.X2.X2.X2 के माध्यम से X1.X1.X1.X1 (यह उपसर्ग पूरी तरह से XXXX द्वारा कवर किया गया है) के लिए एक मार्ग जोड़ते हैं (और यह भी XXXX द्वारा कवर किया गया है)। IOS एक तार्किक निष्कर्ष बनाता है: दूसरा मार्ग कोई नई जानकारी नहीं रखता है और पूरी तरह से बेकार है, इसलिए इसे RIB में स्थापित नहीं किया जा सकता है।

और अब सामंत कान।

 R00(config)#no ip route 3.1.1.10 255.255.255.255 3.1.1.1 R00(config)#ip route 3.1.1.10 255.255.255.255 Gi0/1 3.1.1.1 IP-ST(default): updating same distance on 3.1.1.10/32 IP-ST(default): 3.1.1.10/32 [1], GigabitEthernet0/1 Path = 1 RT: updating static 3.1.1.10/32 (0x0): via 3.1.1.1 Gi0/1 RT: network 3.0.0.0 is now variably masked RT: add 3.1.1.10/32 via 3.1.1.1, static metric [1/0], add succeed, active state IP ARP: creating incomplete entry for IP address: 3.1.1.1 interface GigabitEthernet0/1 IP ARP: sent req src 10.0.0.1 30e4.db16.7791, dst 3.1.1.1 0000.0000.0000 GigabitEthernet0/1 R00#show ip cef 3.1.1.10 3.1.1.10/32 nexthop 3.1.1.1 GigabitEthernet0/1 

और यह हमें एक और महत्वपूर्ण बिंदु पर लाता है। एक स्थिर मार्ग में एक इंटरफ़ेस निर्दिष्ट करना आपको कई चेक को बायपास करने की अनुमति देता है, क्योंकि एक स्थैतिक मार्ग को अब अगले हॉप के लिए एक मार्ग की तलाश में RIB को पुनरावर्ती प्रश्न करने की आवश्यकता नहीं है, और जब इसे जोड़ा जाता है, तो यह अन्य मार्गों पर ट्रिगर को प्रभावित नहीं करेगा। लेकिन यह मुख्य आवश्यकता को नकारता नहीं है: अगले हॉप को एक विशिष्ट इंटरफ़ेस को हल करना होगा, और उस इंटरफ़ेस को ऊपर रखना होगा। तथ्य यह है कि आरआईबी के लिए अधिक पुनरावर्ती अनुरोध नहीं होंगे इसका मतलब है कि अगले हॉप का आईपी पता इंटरफ़ेस के ठीक पीछे है, और यह संभवतः आरपी अनुरोध (राउटर के दृष्टिकोण से) का जवाब देगा। यदि Gi0 / 1 से सटे राउटर पर प्रॉक्सी arp को सक्षम किया जाता है, तो यह संभवतः arp के जवाब में अपना मैक एड्रेस लौटा देगा, और सब कुछ ठीक हो जाएगा। है कि आर्क तालिका में एक अतिरिक्त प्रविष्टि ...

लेकिन फिर भी, आपको ऐसा नहीं करना चाहिए।

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

आप सत्यापन अंतराल को बदल सकते हैं, उदाहरण के लिए, कमांड का उपयोग करके 10 सेकंड:

 ip route static adjust-time 10