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 वर असतानाही असे होऊ शकते. तपासणी बिंदू स्पष्ट आहे आणि हाच या रचनेचा संपूर्ण युक्तिवाद आहे. खर्च म्हणजे फायरवॉलवरील ट्रान्झिट भार आणि आता तुम्हाला रचावे लागणारे केंद्रीय क्षमता व उपलब्धता अवलंबन.
बदल तुम्ही हेतू असलेल्या भाडेकरू गेटवेपर्यंत मर्यादित ठेवा. व्यवस्थापन, underlay आणि प्लॅटफॉर्म इंटरफेसची वेगळी कर्तव्ये असताना प्रत्येक VLAN पत्ता काढणे खूप व्यापक आहे. दुसरा सक्रिय गेटवेही तपासा, कारण जो अजूनही फायरवॉलभोवती राउट करतो तो रचना शांतपणे निष्क्रिय करतो.
हे मॉडेल लेखापरीक्षकाला समजावणे सोपे आहे. ते चालवणे आपोआप स्वस्त नाही.
वितरित 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 धोरणापेक्षा वेगळा निर्णय आहे आणि सामान्यतः दोन्हींपैकी एकच हेतू असतो. पूर्ण झालेली रचना प्रत्येक रहदारी वर्ग कुठे राउट होतो, कुठे तपासला जातो आणि तो तपासणी मार्ग उपलब्ध नसताना काय होते हे नाव देते.