EVPN फ़ायरवॉल नीति: केंद्रीकृत गेटवे बनाम वितरित IRB
केंद्रीकृत गेटवे किरायेदार का ट्रैफ़िक फ़ायरवॉल से गुज़ारते हैं, वितरित IRB नहीं। देखें कि कौन कहाँ निरीक्षण करता है और तेज़ पथ को क्या जोड़ना पड़ता है।
दो EVPN डिज़ाइन किरायेदार के गेटवे को अलग-अलग जगहों पर रखते हैं, और फ़ायरवॉल को हरेक में अलग ट्रैफ़िक दिखता है। केंद्रीकृत गेटवे के साथ, सबनेट के बीच का ट्रैफ़िक फ़ायरवॉल तक पहुँचता है क्योंकि राउटिंग वहीं होती है। वितरित IRB के साथ, leaf स्विच स्थानीय रूप से राउट करते हैं और फ़ायरवॉल को कुछ नहीं दिखता, जब तक आप उसे जानबूझकर वहाँ न डालें। कोई भी मॉडल ग़लत नहीं है। ग़लत यह है कि सीमा पर फ़ायरवॉल जोड़कर यह मान लिया जाए कि fabric ट्रैफ़िक उस तक पहुँचा देगा।
दो मॉडल, दो अलग निरीक्षण बिंदु
पहले उन फ़्लो के नाम बताएँ जिन्हें निरीक्षण चाहिए, क्योंकि दोनों मॉडल उन्हें अलग तरह से संभालते हैं।
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
एक ही सबनेट का ट्रैफ़िक वह पंक्ति है जिसे लोग भूल जाते हैं। एक VLAN पर दो होस्ट ब्रिजिंग से बात करते हैं, और उस पथ में कोई राउटेड फ़ायरवॉल नहीं होता, जब तक कोई अलग लेयर 2 निरीक्षण डिज़ाइन उसे रोक न ले। यह दोनों मॉडलों में सच है, इसलिए यह डिज़ाइन की कमी है, उनके बीच तुलना नहीं।
बाकी तीन पंक्तियाँ वह जगह हैं जहाँ मॉडल वास्तव में अलग होते हैं।
केंद्रीकृत गेटवे: सरल निरीक्षण, वास्तविक ट्रांज़िट लागत
किरायेदार के VLAN को लेयर 2 सेवाएँ के रूप में रखें और उनके राउटिंग गेटवे फ़ायरवॉल पर रखें। सबनेट के बीच का ट्रैफ़िक तब उस गेटवे तक जाता है और वापस आता है, संभवतः तब भी जब दोनों होस्ट एक ही leaf पर हों। निरीक्षण बिंदु स्पष्ट है, और यही इस डिज़ाइन का पूरा तर्क है। लागत फ़ायरवॉल पर ट्रांज़िट भार और एक केंद्रीय क्षमता व उपलब्धता निर्भरता है जिसे अब आपको इंजीनियर करना है।
बदलाव को उन किरायेदार गेटवे तक सीमित रखें जिनका आप इरादा रखते हैं। हर VLAN पता हटाना बहुत व्यापक है जब प्रबंधन, underlay और प्लेटफ़ॉर्म इंटरफ़ेस के अलग कर्तव्य हों। दूसरा सक्रिय गेटवे भी जाँचें, क्योंकि जो अब भी फ़ायरवॉल के चारों ओर राउट करता है वह डिज़ाइन को चुपचाप विफल कर देता है।
यह मॉडल लेखा परीक्षक को समझाना आसान है। यह अपने आप चलाने में सस्ता नहीं है।
वितरित IRB: तेज़ पथ, डिफ़ॉल्ट रूप से कोई निरीक्षण नहीं
वितरित anycast गेटवे के साथ, हर leaf किरायेदार का ट्रैफ़िक स्थानीय रूप से राउट करता है, और RFC 9135 बताता है कि ऐसा क्यों केंद्रीकृत गेटवे के बैकहॉल से बचता है। लाभ वास्तविक है, और इसका सीधा परिणाम है: निरीक्षण का अनुमान इससे नहीं लगाया जा सकता कि फ़ायरवॉल कहाँ लगा है। सीमा leaf से जुड़ा फ़ायरवॉल बाहरी ट्रैफ़िक और वह सब देखता है जो आप स्पष्ट रूप से उसकी ओर भेजते हैं।
सेवा को उस तंत्र से डालें जिसे प्लेटफ़ॉर्म वास्तव में समर्थित करता है: नीति-आधारित रीडायरेक्शन, सेवा नोड, या फ़ायरवॉल के माध्यम से नियंत्रित VRF-अंतर राउटिंग। इच्छित ट्रैफ़िक को उसके वास्तविक प्रवेश बिंदु पर मिलाएँ। होस्ट की ओर के इंटरफ़ेस पर लिखी नीति overlay से आने वाले पैकेट को नहीं ढकती।
इच्छित डिफ़ॉल्ट के बजाय स्थापित रूट पढ़ें। सीधे आयातित अधिक विशिष्ट किरायेदार प्रीफ़िक्स फ़ायरवॉल की ओर इंगित डिफ़ॉल्ट रूट को बायपास कर सकता है, और कॉन्फ़िगरेशन में कुछ भी ग़लत नहीं दिखेगा।
समरूपता राउटिंग का गुण है, निरीक्षण की गारंटी नहीं
सममित IRB बताता है कि प्रवेश और निर्गम provider edge नोड किसी फ़्लो के लिए राउटिंग और ब्रिजिंग कैसे संभालते हैं। यह नहीं बताता कि दोनों दिशाएँ एक ही stateful डिवाइस तक पहुँचती हैं या नहीं। ECMP, anycast और फ़ायरवॉल की उच्च उपलब्धता सभी इस पर असर डालते हैं कि कौन सा नोड वापसी ट्रैफ़िक देखता है, और क्लस्टर का समर्थित स्थिति मॉडल तय करता है कि यह स्वीकार्य है या नहीं।
आपके लिए महत्वपूर्ण हर फ़्लो के लिए वापसी पथ का स्पष्ट रूप से पालन करें। NAT उस काम का सार्वभौमिक विकल्प नहीं है, और उस पर निर्भर डिज़ाइन आमतौर पर कमी निर्माण के दौरान नहीं बल्कि failover के दौरान पाते हैं।
डिज़ाइन मंज़ूर करने से पहले एक आवश्यक फ़्लो और एक जानबूझकर बाहर रखा गया फ़्लो दोनों दिशाओं में चलकर देखें।
कैसे चुनें, और हर हाल में क्या परखें
केंद्रीकृत गेटवे चुनें जब निरीक्षण कवरेज ट्रांज़िट क्षमता से अधिक मायने रखता हो और आप केंद्रीय निर्भरता वहन कर सकें। वितरित IRB चुनें जब स्थानीय राउटिंग मुख्य बात हो, और मान लेने के बजाय स्पष्ट सेवा-प्रवेश के लिए बजट रखें।
फिर उस राउटिंग को परखें जो आपने वास्तव में स्थापित की, क्योंकि दोनों डिज़ाइन वहीं सबसे अधिक अलग होते हैं:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixपरीक्षण में सेवा नोड की विफलता और पुनर्प्राप्ति शामिल करें। जो फ़ॉलबैक रूट चुपचाप निरीक्षण को बायपास करता है वह नियोजित fail-open नीति से अलग निर्णय है, और आमतौर पर दोनों में से केवल एक ही इच्छित होता है। तैयार डिज़ाइन बताता है कि हर ट्रैफ़िक वर्ग कहाँ राउट होता है, कहाँ निरीक्षण होता है, और जब वह निरीक्षण पथ उपलब्ध न हो तो क्या होता है।