💮 🐴 🤞🏾 VXLAN في NSX-V - طبقة سفلية مضطربة 💶 📅 🚼

تحية طيبة وأولا كلمات صغيرة. أحسد الزملاء أحيانًا على العمل عن بُعد - من الرائع أن أكون قادرًا على العمل من أي مكان في العالم متصل بالإنترنت ، والعطلات في أي وقت ، والمسؤولية عن المشاريع والمواعيد النهائية ، وعدم التواجد في المكتب من 8 إلى 17. يستبعد عملي ومسؤولياتي عمليًا إمكانية الغياب الطويل في مركز البيانات. ومع ذلك - تحدث حالات مثيرة للاهتمام مثل الحالة الموضحة أدناه من حين لآخر ، وأنا أفهم أن هناك مواقف قليلة حيث يوجد مثل هذا النطاق للتعبير الإبداعي عن أداة حل المشكلات الداخلية.

إخلاء مسؤولية صغير - في وقت كتابة هذا التقرير ، لم يتم حل القضية تمامًا ، ولكن نظرًا لسرعة استجابة البائعين ، فقد يستغرق الحل الكامل أشهرًا ، وأريد مشاركة نتائجي الآن. آمل ، أيها القراء الأعزاء ، أن تغفر لي هذا التسرع. لكن ما يكفي من الماء - ماذا عن الحالة؟

المقدمة الأولى: هناك شركة (حيث أعمل كمهندس شبكات) تستضيف حلول العميل في السحابة الخاصة لـ VMWare. تتصل معظم الحلول الجديدة بقطاعات VXLAN التي يتم التحكم فيها بواسطة NSX-V - لن أقوم بتقييم مقدار الوقت الذي منحني إياه هذا الحل ، باختصار - كثيرًا. حتى أنني تمكنت من تدريب زملائي على تكوين NSX ESG ويتم نشر حلول العملاء الصغيرة دون مشاركتي. ملاحظة مهمة هي مستوى التحكم مع النسخ المتماثل أحادي الإرسال. يتم توصيل Hypervisors بشكل كبير من خلال واجهتين بمبدلات Juniper QFX5100 المادية المختلفة (مجمعة في الهيكل الظاهري) ومسار سياسة التوقيت المستند إلى المنفذ الظاهري الأصلي هو من أجل الاكتمال.

حلول العميل غير متجانسة للغاية: من Windows IIS ، حيث يتم تثبيت جميع مكونات خادم الويب على جهاز واحد إلى الأجهزة الكبيرة جدًا - على سبيل المثال ، واجهات الويب Apache متوازنة التحميل + LB MariaDB في Galera + بالونات الخادم المتزامنة باستخدام GlusterFS. يحتاج كل خادم تقريبًا إلى المراقبة بشكل منفصل ، ولا تحتوي جميع المكونات على عناوين عامة - إذا واجهت هذه المشكلة ولديك حل أكثر أناقة ، فسوف يسعدني تقديم المشورة.
يتكون حل المراقبة الخاص بي من "ربط" جدار الحماية (Fortigate) بكل شبكة عميل داخلية (+ SNAT ، وبالطبع ، قيود صارمة على نوع حركة المرور المسموح بها) ومراقبة العناوين الداخلية - وبهذه الطريقة يتم تحقيق توحيد وتبسيط معين للمراقبة. تأتي المراقبة نفسها من مجموعة من خوادم PRTG. مخطط المراقبة شيء من هذا القبيل:

بينما كنا نعمل فقط مع VLAN ، كان كل شيء معتادًا وعمل بشكل متوقع مثل الساعة. بعد التنفيذ ، واجهت NSX-V و VXLAN السؤال - هل من الممكن مواصلة المراقبة بالطريقة القديمة؟ في وقت هذا السؤال ، كان الحل الأسرع هو نشر NSX ESG وربط واجهة صندوق VXLAN بشبكة VTEP. سريع في الاقتباسات - نظرًا لاستخدام واجهة المستخدم الرسومية لتكوين شبكات العملاء ، يمكن لقواعد SNAT وجدار الحماية أن توحد الإدارة وتوحدها في واجهة vSphere واحدة ، ولكنها في رأيي معقدة إلى حد ما ، وتحد من مجموعة من الأدوات لاستكشاف الأخطاء وإصلاحها. أعتقد أن أولئك الذين استخدموا NSX ESG كبديل لجدار حماية "حقيقي" سيوافقون. على الرغم من أن هذا الحل ، على الأرجح ، سيكون أكثر استقرارًا - بعد كل شيء ، يحدث كل شيء في إطار بائع واحد.

حل آخر هو استخدام NSX DLR في وضع الجسر بين VLAN و VXLAN. هنا ، أعتقد أن كل شيء واضح - فائدة استخدام VXLAN متقلبة - لأنه في هذه الحالة ، لا يزال عليك سحب VLAN إلى تثبيت المراقبة. بالمناسبة ، في عملية حل هذا الحل ، واجهت مشكلة عندما لم يرسل جسر DLR حزمًا إلى الجهاز الظاهري الذي كان عليه على نفس المضيف. أعلم ، أعلم - في الكتب والأدلة على NSX-V ، يُذكر صراحة أنه يجب تخصيص مجموعة منفصلة لـ NSX Edge ، ولكن هذا في الكتب ... على أي حال ، بعد شهرين من الدعم لم نحل المشكلة. من حيث المبدأ ، فهمت منطق الإجراء - لم يتم تنشيط الوحدة الأساسية لبرنامج Hypervisor المسؤول عن تغليف VXLAN إذا كان DLR والخادم الذي تم مراقبته على نفس المضيف ، نظرًا لأن حركة المرور لا تغادر المضيف ، ومن المنطقي ، يجب أن تكون متصلة بجزء VXLAN - لا حاجة إلى التغليف.مع الدعم ، استقرنا على الواجهة الظاهرية vdrPort ، التي تجمع منطقيًا الروابط الصاعدة وتقوم أيضًا بعمل الجسور / التغليف - هناك لوحظ عدم تطابق في حركة المرور الواردة ، والتي أخذتها لحلها في الحالة الحالية. ولكن كما قيل ، لم أنهي هذه القضية حتى النهاية ، حيث تم نقلها إلى مشروع آخر وكان الفرع في البداية مسدودًا ولم تكن هناك رغبة خاصة في تطويره. إذا لم أكن مخطئًا ، فقد لوحظت المشكلة في الإصدارات NSX و 6.1.4 و 6.2.حيث تم تحويله إلى مشروع آخر وكان الفرع في البداية مسدودًا ولم تكن هناك رغبة خاصة في تطويره. إذا لم أكن مخطئًا ، فقد لوحظت المشكلة في الإصدارات NSX و 6.1.4 و 6.2.حيث تم تحويله إلى مشروع آخر وكان الفرع في البداية مسدودًا ولم تكن هناك رغبة خاصة في تطويره. إذا لم أكن مخطئًا ، فقد لوحظت المشكلة في الإصدارات NSX و 6.1.4 و 6.2.

وهنا - بنغو! دعم الأصلي Fortinet annonsiruet VXLAN . وليس فقط من نقطة إلى نقطة أو VXLAN over-IPSec ، وليس جسر VLAN-VXLAN المستند إلى البرامج - فقد بدأوا في تنفيذ كل هذا منذ الإصدار 5.4 (ويقدمه بائعون آخرون) ، ولكن دعم حقيقي لمستوى تحكم أحادي الإرسال. عند تنفيذ الحل ، واجهت مشكلة أخرى - فقد "اختفت" الخوادم التي تم فحصها بشكل دوري أو ظهرت في المراقبة ، على الرغم من أن الجهاز الافتراضي نفسه كان لا يزال على قيد الحياة. والسبب في ذلك هو أنني نسيت تمكين Ping على واجهة VXLAN. في عملية إعادة توازن المجموعات ، انتقلت الأجهزة الافتراضية ، وانتهت vMotion بـ Ping للإشارة إلى مضيف ESXI الجديد الذي انتقلت إليه الآلة. غبي ، ولكن هذه المشكلة مرة أخرى قوضت مصداقية الدعم - في هذه الحالة Fortinet. أنا لا أقول أن كل حالة تتعلق بشبكة VXLAN تبدأ بالسؤال "أين VLAN-VXLAN سوفت سويتش في إعداداتك؟" هذه المرة نصحت بتغيير MTU - هذا لـ Ping ، وهو 32 بايت. ثم "العب حول" باستخدام tcp-send-mss و tcp-receiver-mss في السياسة - لـ VXLAN ،وهو مغلف في 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

لذا ، ماذا لدينا في النهاية - بعد ترحيل الجهاز الافتراضي ، يحاول الحصن إرسال حركة المرور إلى VTEP من VXLAN FDB (الصحيح) ، ولكنه يستخدم MAC DST خاطئ ومن المتوقع أن يتم تجاهل حركة المرور من خلال واجهة المتلقي المتلقي. علاوة على ذلك ، في حالة واحدة من أصل أربعة ، ينتمي MAC هذا إلى برنامج مراقبة الأجهزة الافتراضية الأصلي ، الذي بدأ منه ترحيل الجهاز.

تلقيت أمس رسالة من الدعم الفني Fortinet - فتحوا خطأ 615586 في حالتي. لا أعرف كيف أفرح أو أحزن: من ناحية ، المشكلة ليست في الإعدادات ، من ناحية أخرى ، سيأتي الإصلاح فقط مع تحديث البرنامج الثابت ، التالي ، في أفضل الأحوال. تساهم الأسئلة الشائعة أيضًا في تسريع خطأ آخر اكتشفته الشهر الماضي ، على الرغم من ذلك في ذلك الوقت في HTML5 GUI vSphere. حسنًا ، قسم ضمان الجودة المحلي للبائعين مباشر ...

سأجرؤ على اقتراح ما يلي:

1 - على الأرجح لن تخضع طائرة التحكم في الإرسال المتعدد للمشكلة الموصوفة - بعد كل شيء ، يتم الحصول على عناوين MAC VTEP من عنوان IP للمجموعة التي تشترك فيها الواجهة.

2 - على الأرجح مشكلة العيوب في جلسات التفريغ على معالج الشبكة (مماثل تقريبًا لـ CEF) - إذا تم تمرير كل حزمة من خلال وحدة المعالجة المركزية ، فسيتم استخدام الجداول التي تحتوي على المعلومات الصحيحة - على الأقل بصريًا -. لصالح هذا الافتراض هو ما يساعد على إغلاق / فتح الواجهة أو الانتظار لفترة - أكثر من 5 دقائق.

3 - لن يؤدي تغيير سياسة الفريق ، على سبيل المثال ، إلى تجاوز الفشل الواضح ، أو إدخال LAG إلى حل المشكلة ، نظرًا لأن MAC عالق في برنامج Hypervisor الأصلي في الحزم المغلفة.

في ضوء ذلك ، يمكنني مشاركة ما اكتشفته مؤخرًا مدونةحيث ورد في إحدى المقالات أن جدران الحماية الثابتة والأساليب المخبأة لنقل البيانات هي عكازات. حسنًا ، لست من ذوي الخبرة في مجال تكنولوجيا المعلومات لأقول ذلك ، ولا أتفق مع جميع العبارات في مقالات المدونة. ومع ذلك ، يخبرني شيء ما أن هناك بعض الحقيقة في كلمات إيفان.

شكرآ لك على أهتمامك! سأكون سعيدًا للإجابة على الأسئلة وسماع النقد البناء.

VXLAN في NSX-V - طبقة سفلية مضطربة

More articles: