تحسين توجيه ExpressRoute

  • مقالة

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

تحديد المسار ل Microsoft والتناظر العام

من المهم التأكد من أنه عند استخدام نظير Microsoft أو Public، تتدفق نسبة استخدام الشبكة عبر المسار المطلوب إذا كان لديك دائرة ExpressRoute واحدة أو أكثر. تحتاج أيضا إلى التأكد من أن المسارات إلى الإنترنت تستخدم Internet Exchange (IX) أو Internet Service Provider (ISP). يستخدم BGP أفضل خوارزمية تحديد المسار استنادا إلى العديد من العوامل بما في ذلك أطول تطابق بادئة (LPM). للتأكد من أن نسبة استخدام الشبكة الموجهة إلى Azure من خلال Microsoft أو النظير العام تعبر مسار ExpressRoute، يجب عليك تنفيذ سمة التفضيل المحلي . يضمن هذا الإعداد تفضيل المسار دائما على ExpressRoute.

ملاحظة

عادة ما يكون التفضيل المحلي الافتراضي هو 100. يُفضل التفضيلات المحلية الأعلى.

خذ بعين الاعتبار السيناريو المثال التالي:

رسم تخطيطي يوضح مشكلة حالة ExpressRoute الأولى - توجيه دون المستوى الأمثل من العميل إلى Microsoft

في المثال أعلاه، لتفضيل مسارات ExpressRoute، قم بتكوين التفضيلات المحلية على النحو التالي.

تكوين Cisco IOS-XE من منظور R1:

  • R1(config)#route-map prefer-ExR permit 10

  • R1(config-route-map)#set local-preference 150

  • R1(config)#router BGP 345

  • R1(config-router)#neighbor 1.1.1.2 remote-as 12076

  • R1(config-router)#neighbor 1.1.1.2 activate

  • R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

تكوين Junos من منظور R1:

  • user@R1# set protocols bgp group ibgp type internal
  • user@R1# set protocols bgp group ibgp local-preference 150

التوجيه دون المستوى الأمثل من العميل إلى Microsoft

دعنا نلقي نظرة فاحصة على مشكلة التوجيه من خلال مثال. تخيل أن لديك مكتبين في الولايات المتحدة، أحدهما في لوس أنجلوس وآخر في نيويورك. يتم توصيل مكاتبك على شبكة واسعة النطاق (WAN)، والتي يمكن أن تكون إما شبكتك الأساسية أو IP VPN لموفر الخدمة الخاص بك. لديك دائرتان ExpressRoute، واحدة في غرب الولايات المتحدة وواحدة في شرق الولايات المتحدة. كلاهما متصل أيضا على شبكة WAN. من الواضح أن لديك مساران للاتصال بشبكة Microsoft.

تخيل الآن أن لديك توزيع Azure، على سبيل المثال، Azure App Service في كل من غرب الولايات المتحدة وشرق الولايات المتحدة. نيتك هي توصيل المستخدمين في لوس أنجلوس ب Azure US West والمستخدمين في نيويورك ب Azure US East. والسبب في هذا الإعداد هو أن مسؤول الخدمة يعلن أن المستخدمين في كل مكتب يصلون إلى خدمات Azure القريبة للحصول على التجارب المثلى. تعمل الخطة بشكل جيد لمستخدمي الساحل الشرقي ولكن ليس لمستخدمي الساحل الغربي.

سبب المشكلة موجود في كل دائرة ExpressRoute، ونعلن محليا عن كل من البادئة في Azure US East 23.100.0.0/16 والبادئة في Azure US West 13.100.0.0/16. إذا كنت لا تعرف أي بادئة من أي منطقة، فلن تتمكن من التعامل معها بشكل مختلف. قد تعتقد شبكة WAN الخاصة بك أن كلتا البادئتين أقرب إلى شرق الولايات المتحدة من غرب الولايات المتحدة، وبالتالي تقوم بتوجيه مستخدمي المكتبين إلى دائرة ExpressRoute في شرق الولايات المتحدة. في النهاية، لديك العديد من المستخدمين غير سعداء في مكتب لوس أنجلوس.

مشكلة حالة ExpressRoute الأولى - توجيه دون المستوى الأمثل من العميل إلى Microsoft

الحل: استخدام مجتمعات BGP

لتحسين التوجيه لمستخدمي المكتبين، تحتاج إلى معرفة أي بادئة من Azure US West وأي بادئة من Azure US East. نقوم بترميز هذه المعلومات باستخدام قيم مجتمع BGP. لقد قمنا بتعيين قيمة مجتمع BGP فريدة لكل منطقة Azure، على سبيل المثال 12076:51004 لشرق الولايات المتحدة، 12076:51006 لغرب الولايات المتحدة. الآن بعد أن عرفت أي بادئة من أي منطقة Azure، يمكنك تكوين دائرة ExpressRoute التي يجب أن تكون مفضلة. نظرا لأننا نستخدم BGP لتبادل معلومات التوجيه، يمكنك استخدام التفضيل المحلي ل BGP للتأثير على التوجيه.

في مثالنا، يمكنك تعيين قيمة تفضيل محلي أعلى إلى 13.100.0.0/16 في غرب الولايات المتحدة عنها في شرق الولايات المتحدة، وبالمثل، قيمة تفضيل محلي أعلى إلى 23.100.0.0/16 في شرق الولايات المتحدة عنها في غرب الولايات المتحدة. يتأكد هذا التكوين من أنه عندما يتوفر كلا المسارين إلى Microsoft، يأخذ المستخدمون في لوس أنجلوس دائرة ExpressRoute في غرب الولايات المتحدة للاتصال ب Azure US West بينما يأخذ المستخدمون في نيويورك ExpressRoute في شرق الولايات المتحدة إلى Azure US East. تم تحسين التوجيه على كلا الجانبين.

حل حالة ExpressRoute الأولى - استخدام مجتمعات BGP

ملاحظة

يمكن تطبيق نفس الأسلوب، باستخدام التفضيل المحلي، على التوجيه من العميل إلى شبكة Azure الظاهرية عند استخدام التناظر الخاص. لا تضع Microsoft علامة على قيم مجتمع BGP إلى البادئات المُعلن عنها من Azure إلى شبكتك. ومع ذلك، ونظراً لأنك تعرف أياً من عمليات نشر الشبكة الظاهرية الخاصة بك قريبة من أي مكتب من مكتبك، يمكنك تكوين أجهزة التوجيه الخاصة بك وفقاً لذلك لتفضيل دائرة ExpressRoute على الأخرى.

التوجيه دون المستوى الأمثل من Microsoft إلى العميل

في هذا المثال، لدينا اتصالات من Microsoft تستغرق مسارا أطول للوصول إلى شبكتك. في هذه الحالة، يمكنك استخدام خوادم Exchange المحلية وExchange Online في بيئة مختلطة. مكاتبك متصلة بشبكة WAN. يمكنك الإعلان عن بادئات الخوادم المحلية في كلا المكتبين إلى Microsoft من خلال دائرتين ExpressRoute.

يبدأ Exchange Online الاتصالات بالخوادم المحلية في حالات مثل ترحيل علبة البريد. يتم توجيه الاتصال بمكتب لوس أنجلوس إلى دائرة ExpressRoute في شرق الولايات المتحدة قبل اجتياز القارة بأكملها مرة أخرى إلى الساحل الغربي. سبب المشكلة مشابهاً للمشكلة الأولى. دون أي تلميح، لا يمكن لشبكة Microsoft معرفة البادئة المحلية القريبة من شرق الولايات المتحدة وأي بادئة قريبة من غرب الولايات المتحدة. يحدث أن تختار المسار الخطأ إلى مكتبك في لوس أنجلوس.

حالة ExpressRoute الثانية - التوجيه دون المستوى الأمثل من Microsoft إلى العميل

الحل: استخدام إلحاق AS PATH

يوجد حلان للمشكلة. الأول هو ببساطة الإعلان عن البادئة المحلية الخاصة بك لمكتب لوس أنجلوس 177.2.0.0/31 على دائرة ExpressRoute في غرب الولايات المتحدة. ثم تقوم بالإعلان عن البادئة المحلية لمكتبك في نيويورك، 177.2.0.2/31 على دائرة ExpressRoute في شرق الولايات المتحدة. ونتيجة لذلك، لا يوجد سوى مسار واحد ل Microsoft للاتصال بكل مكتب من مكاتبك. لا يوجد غموض ويتم تحسين التوجيه. مع هذا التصميم، تحتاج إلى التفكير في استراتيجية تجاوز الفشل. إذا تعطل المسار إلى Microsoft من خلال ExpressRoute، فستحتاج إلى التأكد من أن Exchange Online لا يزال قادرا على الاتصال بالخوادم المحلية.

الحل الثاني هو أن تستمر في الإعلان عن كلتا البادئتين على دائرتي ExpressRoute، بالإضافة إلى تقديم تلميح عن البادئة القريبة من أي مكتب من مكاتبك. لأننا ندعم إلحاق BGP AS Path، يمكنك تكوين AS Path للبادئة للتأثير على التوجيه. في هذا المثال، يمكنك إطالة مسار AS ل 172.2.0.0/31 في شرق الولايات المتحدة بحيث نفضل دائرة ExpressRoute في غرب الولايات المتحدة لنسبة استخدام الشبكة الموجهة لهذه البادئة. وبالمثل يمكنك إطالة AS PATH ل 172.2.0.2/31 في غرب الولايات المتحدة بحيث نفضل دائرة ExpressRoute في شرق الولايات المتحدة. تم تحسين التوجيه لكلا المكتبين. مع هذا التصميم، إذا تعطلت إحدى دوائر ExpressRoute، فلا يزال بإمكان Exchange Online الوصول إليك عبر دائرة ExpressRoute أخرى وشبكة WAN الخاصة بك.

هام

نقوم بإزالة أرقام AS الخاصة في AS PATH للبادئات التي تم تلقيها على نظير Microsoft عند التناظر باستخدام رقم AS خاص. تحتاج إلى استخدام AS عام وإلحاق أرقام AS عامة في AS PATH للتأثير على التوجيه لتناظر Microsoft.

حل حالة ExpressRoute الثانية - استخدام إلحاق AS PATH

ملاحظة

في حين أن الأمثلة الواردة هنا خاصة بـ Microsoft ونظائر عامة، فإننا ندعم نفس الإمكانات للنظير الخاص. أيضاً، يعمل إلحاق AS Path ضمن دائرة ExpressRoute واحدة، للتأثير على اختيار المسارين الأساسي والثانوي.

التوجيه دون المستوى الأمثل بين الشبكات الظاهرية

مع ExpressRoute، يمكنك تمكين اتصال شبكة ظاهرية إلى شبكة ظاهرية (والذي يُعرف أيضاً باسم "NET.") عن طريق ربطها إلى دائرة ExpressRoute. عند ربطها بدوائر ExpressRoute متعددة، يمكن أن يحدث توجيه دون المستوى الأمثل بين NET.s. لننظر في مثالين. لديك دائرتان ExpressRoute، واحدة في غرب الولايات المتحدة وواحدة في شرق الولايات المتحدة. في كل منطقة، لديك اثنين من الشبكات الظاهرية. يتم نشر خوادم ويب الخاصة بك في شبكة ظاهرية وخوادم التطبيق في الأخرى. للتكرار، تربط الشبكتين الظاهريتين في كل منطقة بدائرة ExpressRoute المحلية ودائرة ExpressRoute البعيدة. كما هو موضح في الرسم التخطيطي التالي، من كل شبكة ظاهرية هناك مساران إلى الشبكة الظاهرية الأخرى. لا تعرف الشبكات الظاهرية أي دائرة ExpressRoute محلية وأي دائرة بعيدة. نظرا لأن توجيه Equal-Cost-Multi-Path (ECMP) يستخدم لموازنة تحميل نسبة استخدام الشبكة بين VNet، فإن بعض تدفقات نسبة استخدام الشبكة تأخذ المسار الأطول ويتم توجيهها في دائرة ExpressRoute البعيدة.

حالة ExpressRoute الثالثة - التوجيه دون المستوى الأمثل بين الشبكات الظاهرية

الحل: تعيين وزن مرتفع للاتصال المحلي

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

حل حالة ExpressRoute الثالثة - تعيين وزن مرتفع للاتصال المحلي

ملاحظة

يمكنك أيضا التأثير على التوجيه من VNet إلى شبكتك المحلية، إذا كان لديك دوائر ExpressRoute متعددة، عن طريق تكوين وزن الاتصال بدلا من تطبيق إلحاق AS PATH، وهي تقنية موصوفة في السيناريو الثاني. لكل بادئة، سننظر دائماً إلى وزن الاتصال قبل طول AS Path عند تحديد كيفية إرسال نسبة استخدام الشبكة.

الخطوات التالية