💇🏿 👽 🧝🏼 NSX-V में VXLAN - परेशान अंडरले 🐰 ☮️ 👍

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

एक छोटा अस्वीकरण - लेखन के समय, मामले को पूरी तरह से हल नहीं किया गया है, लेकिन विक्रेताओं की प्रतिक्रिया की गति को देखते हुए, एक पूर्ण समाधान में महीनों लग सकते हैं, और मैं अभी अपने निष्कर्षों को साझा करना चाहता हूं। मुझे उम्मीद है, प्रिय पाठकों, आप मुझे इस जल्दबाजी को माफ कर देंगे। लेकिन पर्याप्त पानी - मामले के बारे में क्या?

पहला परिचयात्मक: एक कंपनी है (जहां मैं एक नेटवर्क इंजीनियर के रूप में काम करता हूं) जो VMWare के निजी क्लाउड में क्लाइंट समाधान होस्ट करता है। अधिकांश नए समाधान VXLAN खंडों से जुड़ते हैं जो NSX-V द्वारा नियंत्रित होते हैं - मैं मूल्यांकन नहीं करूँगा कि इस समाधान ने मुझे कितना समय दिया, संक्षेप में - बहुत कुछ। मैं भी अपने सहयोगियों को एनएसएक्स ईएसजी को कॉन्फ़िगर करने के लिए प्रशिक्षित करने में कामयाब रहा और छोटे ग्राहक समाधान मेरी भागीदारी के बिना तैनात किए गए हैं। एक महत्वपूर्ण नोट नियंत्रण विमान है जिसमें यूनिकास्ट प्रतिकृति है। Hypervisers दो इंटरफेस द्वारा अलग-अलग भौतिक जुनिपर QFX5100 स्विचेस (वर्चुअल चेसिस में इकट्ठे) और वर्चुअल पोर्ट की उत्पत्ति के आधार पर टाइमिंग पॉलिसी मार्ग से जुड़े हुए हैं।

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

जबकि हमने केवल वीएलएएन के साथ काम किया, सब कुछ काफी सामान्य था और अनुमानित रूप से एक घड़ी की तरह काम किया। कार्यान्वयन के बाद, NSX-V और VXLAN ने प्रश्न का सामना किया - क्या पुराने तरीके से निगरानी जारी रखना संभव है? इस प्रश्न के समय, सबसे तेज़ समाधान NSX ESG को तैनात करना और VXLAN ट्रंक इंटरफ़ेस को VTEP नेटवर्क से जोड़ना था। उद्धरणों में क्विक - क्लाइंट नेटवर्क को कॉन्फ़िगर करने के लिए GUI का उपयोग करने के बाद से, SNAT और फ़ायरवॉल नियम एक एकल vSphere इंटरफ़ेस में प्रबंधन को एकीकृत और एकीकृत कर सकते हैं, लेकिन मेरी राय में यह बोझिल है और अन्य बातों के अलावा, समस्या निवारण के लिए टूल के सेट को सीमित करता है। जिन लोगों ने NSX ESG को "वास्तविक" फ़ायरवॉल के विकल्प के रूप में इस्तेमाल किया, मुझे लगता है, वे सहमत होंगे। हालांकि, शायद, ऐसा समाधान अधिक स्थिर होगा - आखिरकार, सब कुछ एक विक्रेता के ढांचे के भीतर होता है।

एक अन्य समाधान है कि वीएलएएन और वीएलएलएएन के बीच पुल मोड में एनएसएक्स डीएलआर का उपयोग किया जाए। यहां, मुझे लगता है कि सब कुछ स्पष्ट है - VXLAN का उपयोग करने का लाभ कॉर्निया है - क्योंकि इस मामले में, आपको अभी भी निगरानी स्थापना के लिए VLAN को खींचना होगा। वैसे, इस समाधान को काम करने की प्रक्रिया में, मैं एक समस्या में भाग गया जब DLR पुल ने वर्चुअल मशीन के साथ पैकेट नहीं भेजे, जिसके साथ यह एक ही मेजबान पर था। मुझे पता है, मुझे पता है - एनएसएक्स-वी पर पुस्तकों और गाइडों में यह स्पष्ट रूप से कहा गया है कि एनएसएक्स एज के लिए एक अलग क्लस्टर आवंटित किया जाना चाहिए, लेकिन यह किताबों में है ... वैसे भी, समर्थन के साथ कुछ महीनों के बाद हमने समस्या का समाधान नहीं किया। सिद्धांत रूप में, मैंने कार्रवाई के तर्क को समझा - वीएलएलएएन एनकैप्सुलेशन के लिए जिम्मेदार हाइपरवाइज़र कोर मॉड्यूल सक्रिय नहीं था यदि डीएलआर और मॉनिटर किए गए सर्वर एक ही होस्ट पर थे, क्योंकि ट्रैफ़िक होस्ट को नहीं छोड़ता है और, तार्किक रूप से, इसे वीएक्सएलएएन सेगमेंट से जोड़ा जाना चाहिए - एनकैप्सुलेशन की आवश्यकता नहीं है।समर्थन के साथ, हम वर्चुअल इंटरफ़ेस vdrPort पर बस गए, जो तार्किक रूप से अपलिंक को जोड़ती है और यह ब्रिजिंग / इनकैप्सुलेशन भी करता है - वहाँ आने वाले ट्रैफ़िक में एक बेमेल देखा गया था, जिसे मैंने वर्तमान मामले में काम करने के लिए लिया था। लेकिन जैसा कि कहा गया था, मैंने इस मामले को अंत तक खत्म नहीं किया, क्योंकि यह एक अन्य परियोजना में स्थानांतरित हो गया था और शाखा शुरू में मृत-अंत थी और इसे विकसित करने की कोई विशेष इच्छा नहीं थी। अगर मैं गलत नहीं हूं, तो समस्या NSX और 6.1.4 और 6.2 संस्करण में देखी गई थी।चूंकि यह एक अन्य परियोजना में स्थानांतरित हो गया था और शाखा शुरू में मृत-अंत में थी और इसे विकसित करने की कोई विशेष इच्छा नहीं थी। अगर मैं गलत नहीं हूं, तो समस्या NSX और 6.1.4 और 6.2 संस्करण में देखी गई थी।चूंकि यह एक अन्य परियोजना में स्थानांतरित हो गया था और शाखा शुरू में मृत-अंत में थी और इसे विकसित करने की कोई विशेष इच्छा नहीं थी। अगर मैं गलत नहीं हूं, तो समस्या NSX और 6.1.4 और 6.2 संस्करण में देखी गई थी।

और यहाँ - बिंगो! फोर्टिनेट annonsiruet मूल समर्थन VXLAN । और न केवल पॉइंट-टू-पॉइंट या VXLAN-over-IPSec, न कि सॉफ्टवेयर-आधारित VLAN-VXLAN ब्रिजिंग - वे संस्करण 5.4 के बाद से यह सब लागू करना शुरू कर दिया (और अन्य विक्रेताओं द्वारा प्रस्तुत किया गया)), लेकिन यूनिकास्ट नियंत्रण विमान के लिए वास्तविक समर्थन। समाधान को लागू करते समय, मैं एक और समस्या में भाग गया - चेक किए गए सर्वर समय-समय पर "गायब" हो गए और कभी-कभी निगरानी में दिखाई दिए, हालांकि आभासी मशीन खुद भी जीवित थी। यह कारण निकला कि मैं VXLAN इंटरफ़ेस पर पिंग को सक्षम करना भूल गया। समूहों को पुनर्संतुलित करने की प्रक्रिया में, आभासी मशीनें चल पड़ीं और नए ESXI होस्ट को इंगित करने के लिए पिंग के साथ vMotion समाप्त हो गया, जिसमें मशीन चली गई। मेरी मूर्खता, लेकिन इस समस्या ने एक बार फिर समर्थन की विश्वसनीयता को कम कर दिया - इस मामले में फोर्टिनेट। मैं यह नहीं कह रहा हूँ कि VXLAN से जुड़ा प्रत्येक मामला इस सवाल से शुरू होता है कि "आपकी सेटिंग में VLAN-VXLAN सोफ्टस्विच कहाँ है?" इस बार मुझे MTU बदलने की सलाह दी गई - यह पिंग के लिए है, जो कि 32 बाइट्स है। फिर "प्ले चारों ओर" के साथ tcp-send-mss और tcp- प्राप्त- mss पॉलिसी में - VLLLAN के लिए,जो UDP में एनकैप्सुलेटेड है। फूफ, मुझे खेद है - यह उबल रहा है। सामान्य तौर पर, मैंने इस समस्या को अपने दम पर हल किया।

परीक्षण ट्रैफ़िक को सफलतापूर्वक वापस लाने के बाद, इस समाधान को लागू करने का निर्णय लिया गया। और उत्पादन में यह पता चला कि एक या दो दिन बाद, VXLAN के माध्यम से निगरानी की जाने वाली सब कुछ धीरे-धीरे पूरी तरह से गिर जाता है। इंटरफ़ेस को निष्क्रिय / सक्रिय करने में मदद की, लेकिन केवल अस्थायी रूप से। समर्थन की मंदी के कारण, मैंने अपने हिस्से के लिए समस्या निवारण करना शुरू कर दिया - अंत में, मेरी कंपनी, मेरा नेटवर्क मेरी जिम्मेदारी है।

स्पॉइलर के तहत समस्या निवारण का कोर्स है। कौन पत्रों और डींग से थक गया है - छोड़ें और पोस्टानैलिसिस पर जाएं।

समस्या निवारण

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

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

कल मुझे फोर्टिनेट तकनीकी सहायता से एक पत्र मिला - उन्होंने मेरे मामले में एक बग 615586 खोला है। मैं नहीं जानता कि कैसे आनन्द या शोक करना है: एक तरफ, समस्या सेटिंग्स में नहीं है, दूसरी तरफ, फ़र्क केवल फर्मवेयर के अपडेट के साथ आएगा, निम्न, सबसे अच्छा। एफएक्यू एक और बग को गर्म करता है जिसे मैंने पिछले महीने खोजा था, हालांकि उस समय एचटीएमएल 5 जीयूआई क्षेत्र में। खैर, विक्रेताओं का स्थानीय क्यूए विभाग प्रत्यक्ष है ...

मैं निम्नलिखित सुझाव देने के लिए उद्यम करूंगा:

1 - बहुस्तरीय नियंत्रण विमान सबसे अधिक संभावना है कि वर्णित समस्या से प्रभावित नहीं होगा - आखिरकार, वीटीईपी मैक पते उस समूह के आईपी पते से प्राप्त किए जाते हैं जिसमें इंटरफ़ेस सब्सक्राइब किया गया है।

2 - सबसे अधिक संभावना नेटवर्क प्रोसेसर (लगभग सीईएफ के अनुरूप) में ऑफलोड सत्रों में किले की समस्या है - यदि प्रत्येक पैकेट सीपीयू के माध्यम से पारित किया जाता है, तो सही जानकारी वाले तालिकाओं - कम से कम नेत्रहीन - का उपयोग किया जाएगा। इस धारणा के पक्ष में है कि इंटरफ़ेस को बंद / खोलने या थोड़ी देर प्रतीक्षा करने में मदद मिलती है - 5 मिनट से अधिक।

3 - टीमिंग नीति को बदलना, उदाहरण के लिए, स्पष्ट विफलता के लिए, या एलएजी को पेश करने से समस्या का समाधान नहीं होगा, क्योंकि एनएक्यूप्यूटेड पैकेट में मूल हाइपरवाइजर पर अटक मैक मनाया गया था।

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

ध्यान देने के लिए धन्यवाद! मुझे सवालों के जवाब देने और रचनात्मक आलोचना सुनने में खुशी होगी।

NSX-V में VXLAN - परेशान अंडरले

More articles: