مصنع 🥇VxLAN. الجزء الأول

أهلا هبر. أنا على وشك الانتهاء من سلسلة من المقالات، مخصصة لإطلاق الدورة "مهندس الشبكة" من أوتوسباستخدام تقنية VxLAN EVPN للتوجيه داخل النسيج واستخدام جدار الحماية لتقييد الوصول بين الخدمات الداخلية

الأجزاء السابقة من السلسلة تجدونها على الروابط التالية:

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

دعونا نفكر في خيارين للتوجيه بين VRFs:

التوجيه دون ترك نسيج VxLAN؛
التوجيه على المعدات الخارجية.

لنبدأ بمنطق التوجيه بين VRFs. هناك عدد معين من VRFs. للتوجيه بين VRFs، تحتاج إلى تحديد جهاز في الشبكة يمكنه التعرف على جميع VRFs (أو الأجزاء التي يلزم التوجيه بينها). يمكن أن يكون هذا الجهاز، على سبيل المثال، أحد مفاتيح Leaf (أو كلها مرة واحدة) . ستبدو هذه الطوبولوجيا كما يلي:

ما هي عيوب هذه الطوبولوجيا؟

هذا صحيح، كل ورقة تحتاج إلى معرفة جميع VRFs (وجميع المعلومات الموجودة فيها) على الشبكة، مما يؤدي إلى فقدان الذاكرة وزيادة حمل الشبكة. بعد كل شيء، في كثير من الأحيان، لا يحتاج كل محول Leaf إلى معرفة كل ما هو موجود على الشبكة.

ومع ذلك، دعونا نفكر في هذه الطريقة بمزيد من التفصيل، نظرًا لأن هذا الخيار مناسب تمامًا للشبكات الصغيرة (إذا لم تكن هناك متطلبات عمل محددة)

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

والإجابة تكمن في وظائف مثل تصدير واستيراد معلومات التوجيه (تم النظر في إعداد هذه التكنولوجيا في ثان أجزاء الدورة). اسمحوا لي أن أكرر بإيجاز:

عند ضبط VRF في التركيز البؤري التلقائي، يجب عليك تحديد ذلك route-target للحصول على معلومات توجيه الاستيراد والتصدير. يمكنك تحديده تلقائيًا. ثم ستتضمن القيمة ASN BGP وL3 VNI المرتبطة بـ VRF. يعد هذا مناسبًا عندما يكون لديك ASN واحد فقط في المصنع الخاص بك:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

ومع ذلك، إذا كان لديك أكثر من ASN واحد وتحتاج إلى نقل المسارات بينهم، فسيكون التكوين اليدوي خيارًا أكثر ملاءمة وقابلية للتوسع route-target. التوصية بالإعداد اليدوي هي الرقم الأول، استخدم الرقم الذي يناسبك، على سبيل المثال، 9999.
يجب ضبط الثاني ليكون مساويًا لـ VNI لذلك VRF.

لنقم بتكوينه على النحو التالي:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

كيف يبدو في جدول التوجيه:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

لنفكر في الخيار الثاني للتوجيه بين VRFs - من خلال المعدات الخارجية، على سبيل المثال جدار الحماية.

هناك عدة خيارات للعمل من خلال جهاز خارجي:

يعرف الجهاز ما هو VxLAN ويمكننا إضافته إلى جزء من القماش؛
الجهاز لا يعرف شيئا عن VxLAN.

لن نتوقف عند الخيار الأول، حيث أن المنطق سيكون هو نفسه تقريبًا كما هو موضح أعلاه - فنحن نحضر جميع VRFs إلى جدار الحماية ونقوم بتكوين التوجيه بين VRFs عليه.

لنفكر في الخيار الثاني، عندما لا يعرف جدار الحماية لدينا شيئًا عن VxLAN (الآن، بالطبع، تظهر المعدات التي تدعم VxLAN. على سبيل المثال، أعلنت Checkpoint عن دعمها في الإصدار R81. يمكنك أن تقرأ عنها هنالكن هذا كله في مرحلة الاختبار وليس هناك ثقة في استقرار التشغيل).

عند توصيل جهاز خارجي نحصل على المخطط التالي:

كما ترون من الرسم البياني، يظهر عنق الزجاجة في الواجهة مع جدار الحماية. يجب أن يؤخذ ذلك في الاعتبار في المستقبل عند تخطيط الشبكة وتحسين حركة مرور الشبكة.

ومع ذلك، دعونا نعود إلى المشكلة الأصلية المتمثلة في التوجيه بين VRFs. نتيجة لإضافة جدار الحماية، توصلنا إلى نتيجة مفادها أن جدار الحماية يجب أن يكون على علم بجميع VRFs. للقيام بذلك، يجب أيضًا تكوين جميع VRFs على الحدود Leafs، ويجب توصيل جدار الحماية بكل VRF برابط منفصل.

ونتيجة لذلك، فإن المخطط مع جدار الحماية:

أي أنك تحتاج في جدار الحماية إلى تكوين واجهة لكل VRF موجود على الشبكة. بشكل عام، لا يبدو المنطق معقدًا والشيء الوحيد الذي لا يعجبني هنا هو العدد الهائل من الواجهات الموجودة على جدار الحماية، ولكن هنا حان الوقت للتفكير في الأتمتة.

بخير. لقد قمنا بتوصيل جدار الحماية وأضفناه إلى جميع وحدات VRF. ولكن كيف يمكننا الآن إجبار حركة المرور من كل ورقة على المرور عبر جدار الحماية هذا؟

على الورقة المتصلة بجدار الحماية، لن تنشأ أي مشاكل، نظرًا لأن جميع المسارات محلية:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

ومع ذلك، ماذا عن أوراق النائية؟ كيفية تمرير لهم الطريق الخارجي الافتراضي؟

هذا صحيح، من خلال طريق EVPN من النوع 5، مثل أي بادئة أخرى عبر نسيج VxLAN. ومع ذلك، فإن الأمر ليس بهذه البساطة (إذا كنا نتحدث عن Cisco، فأنا لم أتحقق من البائعين الآخرين)

يجب الإعلان عن المسار الافتراضي من الصفحة التي يتصل بها جدار الحماية. ومع ذلك، لنقل المسار، يجب أن تعرفه الورقة بنفسها. وهنا تنشأ مشكلة معينة (ربما بالنسبة لي فقط)، يجب تسجيل المسار بشكل ثابت في VRF حيث تريد الإعلان عن مثل هذا المسار:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

بعد ذلك، في تكوين BGP، قم بتعيين هذا المسار في AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

ومع ذلك، هذا ليس كل شيء. بهذه الطريقة لن يتم تضمين المسار الافتراضي في العائلة l2vpn evpn. بالإضافة إلى ذلك، تحتاج إلى تكوين إعادة التوزيع:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

نشير إلى البادئات التي ستدخل إلى BGP من خلال إعادة التوزيع

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

الآن البادئة 0.0.0.0/0 يقع ضمن مسار EVPN من النوع 5 ويتم نقله إلى بقية الورقة:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

في جدول BGP يمكننا أيضًا ملاحظة نوع المسار 5 الناتج باستخدام المسار الافتراضي عبر 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

وبهذا تنتهي سلسلة المقالات المخصصة لـ EVPN. في المستقبل، سأحاول النظر في تشغيل VxLAN بالتزامن مع البث المتعدد، حيث تعتبر هذه الطريقة أكثر قابلية للتطوير (في الوقت الحالي بيان مثير للجدل)

إذا كان لا يزال لديك أسئلة/اقتراحات حول هذا الموضوع، ففكر في أي وظيفة لـ EVPN - اكتب، وسننظر فيها أكثر.

المصدر: www.habr.com

مصنع VxLAN. الجزء 3

إضافة تعليق إلغاء الرد