कोअरमध्ये VPNv4 ला MPLS हवे का? गरजेचे नाही
BGP VPNv4 मार्ग वितरण संदर्भावर बोलणी करते, अग्रेषण मार्गावर नाही। आयात, पुढील हॉपचे निराकरण आणि तुम्ही चालवू शकता असे एन्कॅप्स्युलेशन वेगळे करा।
दोन राउटरांमध्ये VPNv4 पत्ता-कुटुंब सुरू केल्याने केवळ मार्ग वितरण संदर्भ तयार होतो आणि त्याहून अधिक काही नाही। ते अग्रेषण मार्ग स्थापित करत नाही आणि ग्राहक पॅकेट दूरच्या अंतिम बिंदूपर्यंत कोणते एन्कॅप्स्युलेशन नेईल हे सांगत नाही। या दोन तथ्यांची विभागणी झाल्यावर, «कोअरमध्ये याला MPLS हवे का» हा प्रश्न प्लॅटफॉर्मने समर्थित डेटा प्लेनबद्दल अधिक संकुचित आणि उत्तर देण्यायोग्य प्रश्न बनतो।
पत्ता-कुटुंब प्रत्यक्षात कशावर बोलणी करते
मल्टीप्रोटोकॉल BGP AFI 1 आणि SAFI 128 अंतर्गत VPNv4 नेटवर्क-स्तराची पोहोचक्षमता माहिती वाहून नेते, आणि प्रत्येक नोंद मार्ग विभेदकाला उपसर्ग आणि लेबलशी जोडते। सत्र यावर बोलणी करते की दोन्ही बाजू ती माहिती एन्कोड आणि डिकोड करू शकतात। ज्यावर ते बोलणी करत नाही ते डेटा प्लेन आहे। या परिच्छेदानंतरचे सर्व अग्रेषणाशी संबंधित आहे, आणि त्यातील काहीही सत्र उभे राहण्याने ठरत नाही।
त्यामुळे यशस्वी सत्र हे नियंत्रण-प्लेन क्षमतेचा पुरावा आहे, अग्रेषणाचा नाही। राउटर हजारो VPNv4 नोंदी ठेवू शकतो आणि तरीही प्रत्येक ग्राहक पॅकेट टाकून देऊ शकतो, आणि यामुळेच दोन अपयश-वर्ग सुरुवातीलाच एकमेकांत मिसळतात।
NLRI मधील लेबलकडे लक्ष द्या। हे सेवा लेबल आहे, VRF मधील उपसर्गाशी बांधलेले आहे, आणि पॅकेट बाहेर जाणाऱ्या अंतिम बिंदूपर्यंत पोहोचल्यावर त्याची अग्रेषण भूमिका असते। कोणतेही संक्रमण उपकरण ते वाचते का, हा वेगळा रचना-निर्णय आहे।
स्वीकृती, आयात आणि अग्रेषण तीन टप्पे आहेत
मार्ग स्वीकारणे, तो वापरण्याची परवानगी असणे आणि त्याने अग्रेषित करू शकणे हे उपकरणाचे वेगवेगळे भाग करतात। BGP जे ऐकते ते साठवते; आयात धोरण आणि मार्ग-लक्ष्य जुळणी कोणते VRF त्याचा विचार करू शकते हे ठरवतात; नंतर अग्रेषण प्लेनला जाहीर केलेल्या पुढील हॉपचे अशा गोष्टीत निराकरण करावे लागते जी ते खरोखर तारेवर ढकलू शकते।
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
सर्वात आश्चर्यकारक अपयशे याच मधल्या टप्प्यात राहतात। मार्ग BGP तक्त्यात असू शकतो, वैध आणि अगदी सर्वोत्तम, तर VRF मार्ग तक्ता रिकामा राहतो कारण कोणतेही मार्ग-लक्ष्य आयात सूचीशी जुळले नाही। काहीही प्रोटोकॉल त्रुटी नोंदवत नाही, कारण प्रोटोकॉल त्रुटी झालीच नाही।
शेवटचा टप्पा म्हणजे प्लॅटफॉर्म समर्थन दिसण्याचे ठिकाण। अंडरलेमध्ये पोहोचण्यायोग्य पुढील हॉप आपोआप VPN सेवा वाहतूक म्हणून निराकरण होत नाही, आणि उपकरण विशिष्ट बोगदा प्रकार, विशिष्ट लेबल क्रिया किंवा दोन्हीची मागणी करू शकते। निराकरण स्थिती वाचणे मार्ग संख्या वाचण्यापेक्षा अधिक माहितीपूर्ण आहे।
IP कोअर असा स्टॅक वाहू शकते जो तो कधीही स्विच करत नाही
जतन करण्यायोग्य फरक «कोअर MPLS चालवत नाही» आणि «सेवेमध्ये कुठेही लेबल नाही» यात आहे। हे वेगवेगळे दावे आहेत, आणि फक्त पहिला संक्रमण उपकरणांबद्दल आहे। RFC 4023 IP किंवा GRE बोगद्यांद्वारे MPLS वाहून नेण्याची व्याख्या करते, आणि हाच यंत्रणा पूर्णपणे IP कोअरवर दुसरा दावा शक्य करते।
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningful
संक्रमण राउटर बाह्य IP गंतव्यस्थानानुसार अग्रेषित करतात आणि त्यांना ग्राहक उपसर्ग किंवा स्थानिक लेबल स्विचिंगची गरज नसते। दूरच्या टोकाला बाह्य बोगदा काढला जातो आणि सेवा लेबल त्याचे काम पुन्हा सुरू करते। कोअरने अपारदर्शक पेलोड हलवले, आणि IP नेटवर्क ज्यात चांगले आहे ते नेमके हेच आहे।
हे रचना तुम्हाला जे देत नाही ती सार्वत्रिक हमी आहे। प्रत्येक राउटर प्रत्येक VPNv4 पुढील हॉप कोणत्याही GRE इंटरफेसवर निराकरण करतो याचा हा पुरावा नाही, आणि कार्यरत स्थानिक MPLS संरचना हटवण्याचे कारणही नाही। हा सार्वत्रिक दाव्याविरुद्धचा प्रतिउदाहरण आहे, आणि व्यावहारिक प्रश्न प्लॅटफॉर्मपुरता स्थानिक राहतो। तो प्रश्न प्रोटोकॉल नियम म्हणून नाही, प्लॅटफॉर्म मर्यादा म्हणून नोंदवा।
बॉक्सवर साखळी तुटेपर्यंत चाला
स्वीकारलेल्या मार्गापासून सुरू करा आणि ज्या पहिल्या टप्प्यात अपयश येते तिथे थांबा, कारण आधीचा टप्पा तुटलेला असताना पुढील टप्प्यांचे निदान करता येत नाही। ठराविक अंमलबजावणीत चार आदेश त्यातील बहुतेक भाग व्यापतात।
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A
त्यांना चार स्वतंत्र तपासण्या म्हणून नाही, क्रम म्हणून वाचा। पहिला कुटुंब सक्रिय आहे आणि सहकारी मार्गांची देवाणघेवाण करत आहे याची खात्री देतो; दुसरा उपसर्ग उपयुक्त पुढील हॉपसह आला का हे दाखवतो; तिसरा आयात पात्रता सिद्ध करतो; चौथा अग्रेषण प्लेनने त्याला लेबल किंवा बोगदा जोडला का हे दाखवतो।
नंतर कामाचा भार मार्ग दोन्ही दिशांनी तपासा, एन्कॅप्स्युलेशन टिकून राहणाऱ्या MTU सह। GRE हेडर बाइट जोडते, आणि लहान प्रोबमधून जाणारा मार्ग केवळ एका दिशेने पूर्ण आकाराच्या पॅकेटवर अपयशी होऊ शकतो, जो वाहतूक दोषाऐवजी अनुप्रयोग दोषासारखा दिसतो।
दोन कार्यचालन टिपा चक्र बंद करतात। GRE एन्कॅप्स्युलेशन आहे, गोपनीयता नाही, त्यामुळे अविश्वासू संक्रमण नेटवर्कला गृहीतकाऐवजी वर समर्थित सुरक्षा व्यवस्था आवश्यक आहे। आणि रचना पुनरावलोकनापूर्वी प्लॅटफॉर्म प्रत्यक्षात कोणते एन्कॅप्स्युलेशन समर्थित करते ते नोंदवा, कारण तो एकच उत्तर केवळ-IP कोअर वैध पर्याय आहे की अग्रेषित करू न शकणारी योजना हे ठरवते।