تكوين المحاكاة الظاهرية للنقل المجمع باستخدام ASR 1000

خيارات التنزيل

  • PDF     (1.1 MB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (868.7 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (795.2 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:٣١ يوليو ٢٠٢٤
معرّف المستند:222266

لغة خالية من التحيز

تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.

حول هذه الترجمة

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

    المقدمة

    يصف هذا المستند مخططات شبكة المحاكاة الظاهرية للنقل (OTV) المدعومة على موجهات من السلسلة ASR1000 و Catalyst 8300/8500.

    المتطلبات الأساسية

    المتطلبات

    لا توجد متطلبات خاصة لهذا المستند.

    المكونات المستخدمة

    تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

    • ASR1000 وIOS® XE الإصدار 16.10.1a وما بعده
    • Catalyst 8300 وIOS® XE الإصدار 17.5.1a وما بعده
    • Catalyst 8500 وIOS® XE الإصدار 17.6.1a وما بعده

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

    معلومات أساسية 

    يدعم ASR1000 OTV منذ Cisco IOS® XE، الإصدار 3.5. يبدأ الموجه Catalyst 8300 series دعم مع IOS® XE17.5.1a ويبدأ مسار Catalyst 8500 series دعم مع IOS® XE الإصدار 17.6.1a.

    يوفر بروتوكول OTV اتصال الطبقة 2 بين مواقع الشبكة البعيدة من خلال التوجيه القائم على عنوان MAC وإعادة التوجيه المغلف عبر بروتوكول IP (MAC في IP) عبر شبكة النقل لتوفير الدعم للتطبيقات التي تتطلب تجاور الطبقة 2، مثل المجموعات والمحاكاة الافتراضية. يستخدم OTV بروتوكول مستوى التحكم في التراكب لمعرفة معلومات توجيه MAC ونشرها عبر الشبكة الترابية. يستخدم بروتوكول OTV Control-plane رسائل النظام الوسيط إلى النظام الوسيط (IS-IS) لبناء عمليات تجاور إلى المواقع البعيدة ولإرسال تحديثات مسار MAC إلى المواقع البعيدة. يبني بروتوكول OTV عمليات تجاور الطبقة 2 للمواقع البعيدة على الشبكة الفرعية من خلال الاكتشاف التلقائي لأجهزة OTV البعيدة.

    مزايا OTV لملحق الطبقة 2 تشمل:

    • لا يوجد متطلبات MPLS
    • لا يوجد تكوين معقد لتحويل التسمية متعدد البروتوكولات (EoMPLS) للشبكة العنكبوتية
    • لا يوجد نشر معقد لخدمات شبكة المنطقة المحلية الخاصة الظاهرية (VPLS) لملحقات الطبقة 2
    • عملية عزل الشجرة الممتدة الأصلية
      • لا حاجة لتكوين عوامل تصفية وحدة بروتوكول بيانات الجسر (BPDU) بشكل صريح
      • عملية عزل افتراضية لمشاكل الشجرة المتفرعة عن مركز بيانات محدد
    • عزل غمر أحادي للبث الأحادي غير معروف أصلي
      • لا تتم إعادة توجيه حزم MAC للبث الأحادي غير المعروفة
      • يسمح بدعم إعادة توجيه البث الأحادي لكل MAC غير المعروف
    • تحسين بروتوكول تحليل العنوان (ARP) باستخدام التخزين المؤقت ل OTV ARP
      • تقليل حركة المرور غير الضرورية عبر شبكة الاتصال واسعة النطاق (WAN)
    • إمداد مبسط لعزل بروتوكول تكرار الخطوة الأولى (FHRP)
    • إضافة مبسطة للمواقع
    • تكوين نسخ الاحتياطية مبسط
    • القدرة على الحصول على "جهاز إسقاط" لعمليات الترحيل عند الحاجة إلى خدمات مؤقتة

    المتطلبات

    العناصر التالية هي القواعد الأساسية التي يجب وضعها في الاعتبار عند تصميم نشر OTV.  في حالة الالتزام بهذه القواعد، سيتم تبسيط التصميم والنشر.

    • يمكن إستخدام واجهة واحدة فقط لإرسال حركة مرور OTV المغلفة، المعروفة باسم الواجهة المشتركة، لجميع واجهات تغشية OTV التي تم تكوينها
    • يمكن إستخدام واجهة واحدة فقط لتكوين مثيلات خدمة L2 لمركز البيانات لشبكة VLAN الخاصة بموقع OTV وشبكات VLAN الموسعة بين مراكز البيانات لجميع واجهات OTV التبليطية التي تم تكوينها
    • يمكن إستخدام قنوات المنفذ لتكرار الواجهة واتصالها بمحولات VSS أو VPC ويتم دعمها كواجهة "واحد فقط" للاتصال.
    • يجب أن تكون جميع موجهات OTV قابلة للتوصيل عبر الواجهة المشتركة
    • يجب تكوين الشجرة المتفرعة على موجه OTV الذي يشير إلى مركز البيانات
    • يجب تكوين التطفل على بروتوكول IGMP والاستعلام لإعادة توجيه حركة مرور البث المتعدد لمركز البيانات بشكل صحيح
    • يمكن تكوين مركز بيانات محدد باستخدام موجه OTV واحد أو موجهات OTV. باستخدام موجهين، يوزعون إعادة توجيه شبكة VLAN في طريقة فردية/زوجية استنادا إلى رقم شبكة VLAN.   يعمل كل موجه OTV في مركز البيانات كنسخة إحتياطية للآخر.
    • يجب تكوين أزواج متعددة المتجانسة باستخدام معرف موقع OTV نفسه
    • يمكن أن يشارك ASR1000/Catalyst 8300/Catalyst 8500 و Nexus 7000 في شبكة OTV نفسها
      • لا يدعم Nexus 7000 تجزئة أو تشفير OTV، لذلك لا يمكن إستخدام هذه الميزات في النشر "المختلط".

    هناك تصاميم معينة للاتصال من الخلف إلى الخلف، وهي مدعومة ولا تلتزم بالقواعد المنصوص عليها.  وعلى الرغم من أن هذه التكوينات مدعومة، إلا أنه لا يوصى بها.  ويمكن العثور على تفاصيل عن هذه العناصر في القسم التالي "طبولوجيا البث الأحادي للحالة الخاصة".

    لا يمكن التأكيد على أن برنامج OTV الحالي به قيد الواجهة "one and only one" عند تكوين واجهات الوصول من المستوى الثاني و OTV. يمكن إستخدام واجهة قناة المنفذ للتكرار.  يتم دعم اتصال قناة المنفذ ب Nexus 7000s في جهاز VPC.  كما يتم دعم اتصال قناة منفذ أساسي بمحول واحد.

    أنواع تنفيذ OTV

    يتطلب OTV واجهة ربط واحدة وواجهة L2 واحدة.  يمكن دعم واحد فقط من كل من هذه العناصر لكل موجه OTV.  يتطلب OTV أيضا أن يكون موقع VLAN شكلت لذلك أن يتعدد OTV مسحاج تخديد يستطيع اتصلت مع بعضهم بعضا من خلال الشبكة المحلية.  يجب أن تحتوي حتى موجهات OTV الأحادية الطرف على شبكة VLAN الخاصة بموقع OTV مكونة.  وبالإضافة إلى ذلك، يجب أن يكون لكل موقع أو مركز بيانات معرف موقع فريد تم تكوينه.  يجب أن تستخدم موجهات OTV المزدوجة التوجيه معرف الموقع نفسه وأن تكون قادرة على الاتصال عبر شبكة VLAN نفسها.

    يعطي التشكيل لاحق التشكيل أساسي أساسي ضروري ل OTV. ومع ذلك، ليس كامل بما أن ال unicast أو multicast لب تشكيل ينبغي كنت أضفت.  وترد هذه التفاصيل في الفروع التالية من هذه الوثيقة.

    otv site bridge-domain 100
    otv site-identifier 0000.0000.1111
    !
    interface Overlay1
      no ip address
      otv join-interface GigabitEthernet0/0/0
      service instance 99 ethernet
        encapsulation dot1q 99
        bridge-domain 99
      !
      service instance 90 ethernet
        encapsulation dot1q 90
        bridge-domain 90
    !
    interface GigabitEthernet1/0/1
      no ip address
      negotiation auto
      service instance 100 ethernet
        encapsulation dot1q 100
        bridge-domain 100
      !
      service instance 99 ethernet
        encapsulation dot1q 99
        bridge-domain 99
      !
      service instance 98 ethernet
        encapsulation dot1q 98 second-dot1q 1098
        rewrite ingress tag trans 2-to-1 dot1q 90 symmetric
        bridge-domain 90

    يتم إستخدام تكوين مثيل الخدمة لجميع تكوين واجهة L2 مع OTV. 

    يجب أن يكون كل مثيل خدمة على واجهة L2 مرتبطا بعملية كبسلة أحادية أو مزدوجة علامات التمييز. 

    وفي المقابل، يجب أن يكون كل مثيل من مثيلات الخدمة هذه مرتبطا بمجال جسر. 

    ويتم إستخدام مجال الجسر هذا على مثيل خدمة تم تكوينه على واجهة التغشية. 

    يمثل مجال الجسر اللصق الذي يربط مثيل خدمة التغشية بمثيل خدمة واجهة L2.

    يجب أن يتطابق تضمين حركة المرور على الواجهة المتغشية مع عملية كبسلة حركة المرور بعد إعادة كتابة المدخل على واجهة L2. 

    في المثال، تحتوي حركة المرور التي يتم جلبها على Gig1/0/1 service instance 99 على شبكة VLAN واحدة 802.1Q من 99 وجسر مجال 99. كما تم تكوين مثيل الخدمة المطابق مع Bridge-domain 99 على الواجهة التخطيطية لشبكة VLAN واحدة 802.1Q من 99. هذه الحالة هي الأكثر مباشرة.

    في المثال، تحتوي حركة المرور التي تدخل على Gig1/0/1 service instance 98 على شبكة VLAN مزدوجة من 802.1Q مقاس 99 و 1098 ومجال Bridge 90. تم تكوين مثيل الخدمة المطابق مع Bridge-Domain 90 على الواجهة الترويجية لشبكة VLAN واحدة بسرعة 802.1Q بنسبة 90. من الواضح أن هذه ليست نفسها.  يضمن أمر إعادة الكتابة مدخل أن علامات التمييز ترجمت بشكل صحيح بينما حركة مرور تنتقل عبر واجهة المدخل.  يتلقى حركة مرور أن يجمع ال L2 قارن ال 98/1098 802.1Q VLANs استبدلت ب VLAN وحيد VLAN 90. الكلمة المفتاح متماثل يضمن أن حركة مرور أن ينتج ال l2 قارن وحيد 802.1Q VLAN من 90 إستبدال مع 98/1098.

    أي خدمة مثال مع يتعدد 802.1Q VLANs أن يكون مددت ب OTV ينبغي استعملت ال rewrite مدخل أمر.  OTV يساند عملية كبسلة فقط VLAN معرف وحيد.  ولهذا السبب، يجب إعادة كتابة أي تكوين لشبكة VLAN مزدوجة على واجهات L2 إلى علامة واحدة على مثيل خدمة واجهة التغشية.  وهذا يحول دون دعم تكوينات VLAN الغامضة.

    لمزيد من التفاصيل حول إعادة كتابة علامة التمييز، راجع هذا المستند: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/command/ce-cr-book/ce-m1.html

    في هذا مثال، ال OTV موقع جسر-domain هو 100.

    • ال OTV موقع جسر-domain شكلت فقط على ال L2 قارن. 
    • يجب عدم تكوين مجال جسر موقع OTV أبدا على واجهة التغشية لأن هذا يجعل نشر OTV غير مستقر. 
    • ال OTV موقع VLAN ينبغي كنت ربطت فقط إلى ال OTV مسحاج تخديد ولا يحمل أي آخر معطيات مركز / مستعمل حركة مرور. 
    • ال OTV موقع VLAN ينبغي كنت على ال نفسه قارن طبيعي بما أن ال OTV موسع VLANs.

    متعدد المنازل

    يمكن توصيل مركز البيانات بمضيف OTV واحد أو ما يصل إلى 2 للتكرار، المعروف أيضا باسم Multihome.  يتم إستخدام Multihome للمرونة وموازنة الحمل. عندما يكون هناك أكثر من جهاز حافة واحد في موقع ما ويشارك كلاهما في نفس الشبكة التغشية، يعتبر الموقع متعدد المواقع. يقسم OTV Multihome شبكات VLAN بين موجهات OTV التي تنتمي إلى الموقع نفسه في طريقة فردية/زوجية مبنية على رقم شبكة VLAN. يتم إختيار جهاز حافة واحد كمعيار AED لجميع الشبكات المحلية الظاهرية (VLANs) الفردية، بينما يتم إختيار موجه OTV الآخر كموجه AED لجميع الشبكات المحلية الظاهرية (VLANs) الزوجية. كل AED أيضا إستعداد ل VLANs أن يكون نشط على الآخر مسحاج تخديد. في حالة فشل الارتباط أو العقدة في أحد AED، يصبح AED الاحتياطي نشطا لجميع شبكات VLAN.

    إذا تم توصيل نظامين من ASR1000s في مركز البيانات نفسه لإجراء Multihome، فلا حاجة إلى إرتباط مخصص بين نظامي ASR1000s. يستخدم OTV شبكة VLAN الخاصة بموقع OTV والتي يتم نشرها من خلال الواجهة الداخلية والاتصال من خلال الواجهة المشتركة لتحديد الموجهات المسؤولة عن شبكات VLAN الفردية والفردية.

    لا يمكن المزج بين ASR1000s و Nexus 7000s في مركز البيانات نفسه مع تكوين OTV على كلا الموجهين كنسخ إحتياطي للآخر. يتم دعم Multihome في مركز بيانات محدد للأنظمة الأساسية المتطابقة (ASR1000 أو Nexus 7000). يمكنك الحصول على ASR1000s في مركز بيانات واحد و Nexus 7000s في مركز بيانات آخر. تم إختبار ودعم قابلية التشغيل البيني بين هذين النظامين الأساسيين.  يمكن أن تكون بعض مراكز البيانات متعددة، بينما تكون مراكز البيانات الأخرى فردية.

    يجب أن تقوم أزواج موجهات ASR1000 متعددة المسارات بتشغيل نفس الإصدار من برنامج Cisco IOS® XE.

    إذا تم إستخدام Multihome، فمن المستحسن بشدة تمكين الشجرة المتفرعة على موجهات OTV حيث أن هذا يمكن موجه OTV من إرسال إعلام تغيير المخطط (TCN) الذي يتسبب في قيام جهاز محول L2 المجاور (مع المحولات الأخرى في الشجرة المتفرعة) بتقليل مؤقت العمر من الافتراضي إلى 15 ثانية.  وهذا يزيد من تقارب السرعة بشكل كبير عندما يكون هناك فشل أو إستعادة بين الزوج متعدد الأزواج. يمكن تمكين الشجرة المتفرعة لجميع مثيلات الخدمة التي تم تكوينها (المتصلة ب OTV أو خلاف ذلك) من خلال إضافة سطر subsequ إلى التكوين العام.

    spanning-tree mode [ pvst | rapid-pvst | mst ]

    لا يلزم توفر تكوين محدد لكل شبكة محلية ظاهرية (VLAN) أو لكل مثيل خدمة.

    مركز البث المتعدد

    تتطلب شبكة البث المتعدد اتصال شبكة كاملة عبر شبكة الاتصال واسعة النطاق. يجب توصيل جميع موجهات OTV معا من خلال الواجهة المشتركة.

    شكل 1. مخطط شبكة البث المتعدد المدعومة

    OTV-figure1

    يوضح هذا الشكل مثالا على مركزين للبيانات متصلين من خلال مركز في شبكة كاملة.  يتم تشغيل البث المتعدد المستقل (PIM) للبث المتعدد محدد المصدر (SSM) بين موجهات OTV وموجهات WAN الأساسية.  يتم دعم أي عدد من الموجهات الأساسية طالما أن هناك اتصال شبكة كامل.  لا يوجد متطلب زمن وصول أقصى صريح لاتصال OTV عبر مركز شبكة WAN.

    شكل 2. مخطط شبكة البث المتعدد غير معتمد

    OTV-Figure2

    نظرا لأن ASR1000/OTV يتوقع تلقي رسائل للبث المتعدد على واجهة إرتباط واحدة من جميع الأجهزة النظيرة، على سبيل المثال، فإن ذلك سيؤدي إلى نشر OTV غير مستقر. لنفترض أن الروابط بين الشرق والغرب باللون القرنفلي والأزرق تم تكوينها كواجهات وصل.  عند فشل الارتباط الوردي، لن يعود الموجه قادرا على تلقي تحديثات OTV على تلك الواجهة.  قد يكون المسار البديل عبر الارتباطات الخضراء أو الأرجوانية غير مقبول لأنه قد تم تكوين واجهة الربط بشكل صريح.  يجب تلقي التحديثات على هذه الواجهة.  غير مدعوم في هذا الوقت لاستخدام واجهات الاسترجاع كواجهة الربط.

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

    يجب أن تدعم شبكة النقل بين موجهات OTV وضع PIM المتناثر (أي مصدر multicast [ASM]) لمجموعة البث المتعدد للموفر و SSM لمجموعة التسليم.

    تتطلب مراكز البث المتعدد بعض التكوين المحدد على واجهة التغشية لمجموعة تحكم بالإضافة إلى مجموعة من مجموعات البث المتعدد للبيانات التي يتم إستخدامها لإعادة توجيه البيانات.

    ip multicast-routing distributed
    ip pim ssm default
    !
    interface Port-channel60
     encapsulation dot1Q 30
     ip address 10.0.0.1 255.255.255.0
     ip pim passive
     ip igmp version 3
    !
    interface Overlay99
     no ip address
     otv control-group 239.1.1.1
     otv data-group 232.192.1.0/24
     otv join-interface Port-ch60

    تتطلب عمليات نشر OTV للبث المتعدد تكوين واجهة الربط كواجهة خاملة ل PIM.  يمكن تكوين IGMP للإصدارات المختلفة حسب الحاجة.  يجب أن تحتوي واجهة التراكب على مجموعة تحكم ومجموعة بيانات تم تكوينها.  مجموعة التحكم هي مجموعة بث متعدد واحدة تستخدم لإدارة OTV.  مجموعة البيانات هي مجموعة من عناوين البث المتعدد المستخدمة لنقل بيانات المستخدم بين مراكز البيانات.  إذا لم تكن مجموعة البيانات في مساحة IP 232.0.0.0/8، فيجب تكوين الأمر الإضافي "ip pim ssm range" لتضمين النطاق المطلوب من قبل OTV.

    يجب أن تدعم شبكة النقل بين موجهات OTV وضع PIM النادر (أي مصدر multicast [ASM]) لمجموعة البث المتعدد للموفر والبث المتعدد محدد المصدر (SSM) لمجموعة التسليم.

    Unicast Core مع خوادم التجاور

    أضاف Cisco IOS® XE 3.9 دعم ل OTV مع مركز البث الأحادي.  يستمر دعم كل من مراكز البث الأحادي والبث المتعدد ل OTV لجميع أنظمة ASR1000 الأساسية والإصدارات المستقبلية من Cisco IOS® XE 3.9.

    شكل 3. مخطط شبكة البث الأحادي

    OTV-Figure3

    تتيح ميزة خادم التجاور OTV النقل أحادي البث فقط بين حافة OTV.  تحتفظ موجهات OTV التي تم تكوينها باستخدام دور خادم التجاور بقائمة بجميع موجهات OTV المعروفة. هم يزودون هذا قائمة إلى كل مسحاج تخديد OTV مسجل لذلك هم يتلقون قائمة ميلان إلى جانب الجهاز أن يتلقى يكرر بث و multicast حركة مرور.

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

     في نفس طريقة التفكير، يتم نسخ أي حركة مرور للبث المتعدد من مركز البيانات على موجه OTV المحلي ويتم إرسال نسخ متعددة إلى كل مركز بيانات بعيد.  وعلى الرغم من أن هذا أقل كفاءة من أن يكون مشروطا على مركز WAN لإجراء النسخ المتماثل، إلا أنه لا يلزم تكوين شبكة البث المتعدد الأساسية وإدارتها.  في حالة وجود كمية صغيرة فقط من حركة مرور البث المتعدد لمركز البيانات أو إذا كان هناك عدد قليل فقط من مواقع مركز البيانات (أربعة أو أقل)، يكون مركز البث الأحادي لإعادة توجيه توجيه الفيديو (OTV) هو الاختيار الأفضل عادة.  وبشكل عام، فإن التبسيط التشغيلي لنموذج البث الأحادي فقط يجعل خيار النشر المركزي للبث الأحادي واقعا مسبقا في السيناريوهات حيث يكون اتصال امتداد الشبكة المحلية (LAN) مطلوبا فقط بين أربعة مراكز بيانات أو أقل.  من المستحسن أن يتم تكوين خادمين تجاور على الأقل، أحدهما أساسي والآخر نسخ إحتياطي.  لا يوجد خيار لتكوين خادم التجاور النشط/النشط.

    يجب تكوين موجهات OTV وفقا لذلك لتحديد خادم التجاور المناسب والتسجيل به بشكل صحيح.

    خادم التجاور الأولي

    خادم التجاور الثانوي

    موجهات OTV الأخرى

    عنوان IP الخاص بواجهة OTV المشتركة

    10.0.0.1

    10.2.2.24

    عناوين IP الأخرى

    التكوين

    تغشية الواجهة 1
      OTV خادم التجاور أحادي البث فقط

    تغشية الواجهة 1
      OTV خادم التجاور أحادي البث فقط
      OTV use-neighbors-server 10.0.0.1 unicast فقط

    تغشية الواجهة 1
      OTV use-neighbors-server 10.0.0.1 10.2.2.24 unicast-only

    هناك تصميمات معينة للاتصال من الخلف إلى الخلف مدعومة بإعادة توجيه OTV للبث الأحادي والتي لا تلتزم بقواعد "الشبكة الكاملة".  ولا يوصى بإجراء هذه التكوينات على الرغم من دعمها.  يكون هذا النوع من النشر أكثر شيوعا عندما تكون مراكز البيانات متصلة عبر ألياف داكنة.  يمكن العثور على تفاصيل حول خيار التكوين هذا في القسم الأحدث "مخطط البث الأحادي للحالة الخاصة".

    OTV على العصا مقابل الخط الداخلي

    هناك طرازان لنشر OTV في مركز البيانات الخاص بك: على العصا وفي السطر. في سيناريوهات التصميم المعروضة سابقا، كانت موجهات OTV مضمنة بين مركز البيانات والشبكة الأساسية لمزودي الخدمة. مهما، أضفت من ال OTV مسحاج تخديد كجهاز أن هو ليس في النقل ممر من كل حركة مرور يستطيع كنت أكثر مرغوب. في بعض الأحيان، لا يتطلب الأمر تغيير المخطط الحالي للاتصال بمزود الخدمة من خلال المعدات الحالية (على سبيل المثال، نشر Brownfield باستخدام محول Catalyst 6000 switch أو أجهزة محول Nexus التي لا تدعم OTV). وبالتالي، يفضل نشر OTV على ASR1000 على عصا كجهاز OTV.

    شكل 4. الطوبولوجيا الداخلية مقابل على العصا

    OTV-figure4

    يوضح المخطط طرازي النشر اللذين يمكن أن يكونا جزءا من التغشية نفسها.  يتم تكوين الارتباطات الخضراء المتصلة بموجهات OTV كواجهات وصول L2 لقبول حركة مرور شبكات VLAN.  الارتباطات الزرقاء المتصلة بموجهات OTV هي الواجهات المشتركة التي تحمل حركة مرور OTV التي تغلف شبكة VLAN.

    هو يستطيع كنت ضروري أن يشكل سمة أن لا يساند مع OTV. على سبيل المثال، لا يمكن تكوين OTV و MPLS على نفس المربع. ونتيجة لذلك، يمكن أن يكون خيارا جيدا لاستخدام ASR1000/OTV على عصا، وتكوين MPLS على الموجه الذي يجلس أمام موجه OTV.

    قنوات المنفذ للطبقة 2 والطبقة 3 

    أضاف رمز Cisco IOS® XE 3.10 ل ASR1000 تكوين قناة المنفذ من الطبقة 2 والطبقة 3 مع OTV. يمكن إستخدام طبقة 2 Port-Channel كواجهة داخلية.  يجب أن تتكون قناة المنفذ من ما يصل إلى 4 واجهات مادية. طبقة 3 ميناء-channel يستطيع كنت استعملت كالقارن.

    شكل 5. قنوات المنفذ المستخدمة لاتصال L2

    OTV-figure5

    يبدي الرسم بياني سيناريو نموذجي ميناء-channel مع إثنان مفتاح في VSS (مادة حفازة 6000 sery) أو VPC (Nexus 7000 sery).  يوفر هذا النوع من التصميم إمكانية التكرار بفضل موجهات OTV المزدوجة وإمكانية الاتصال المزدوجة بالبنية الأساسية لمركز البيانات.  لا يلزم إجراء تكوين خاص ل OTV بخلاف تكوين قناة المنفذ الأساسي إذا تم إستخدام VSS أو VPC على معدات تحويل L2 المجاورة لموجهات OTV.

    البوابة الافتراضية

    طبقا للتعريف، يقوم OTV بإنشاء نفس الشبكة الفرعية L3 في مواقع متعددة.  هذا يتطلب بعض الاعتبارات الخاصة عند توجيه حركة مرور L3 إلى ومن شبكات VLAN الموسعة.  يمكن تكوين التوجيه L3 على موجهات OTV نفسها أو يمكن تكوينه على الأجهزة الأخرى المتصلة بشبكات VLAN الموسعة.  بالإضافة إلى ذلك، في كل سيناريو يمكن نشر بروتوكولات تكرار الخطوة الأولى (FHRP) مثل بروتوكول تكرار الاستعداد السريع (HSRP) أو بروتوكول تكرار الموجه الظاهري (VRRP) للتكرار.  يمكن تشغيل HSRP محليا إلى مركز بيانات محدد أو توسيعه بين مراكز البيانات (غير النموذجية).

    أفضل ممارسة لعمليات نشر OTV التي تستخدم FHRP، هي تشغيل مثيلات محلية ل FHRP في كل مركز بيانات.  تستخدم حالات FHRP تلك نفس عنوان MAC وعنوان IP الظاهري بحيث عندما تنتقل الأجهزة الظاهرية (VMs) بين مراكز البيانات يكون لها اتصال غير منقطع.  إذا تم تغيير عنوان MAC الخاص بالموجه الافتراضي بين مراكز البيانات، فلن تتمكن أجهزة VM من الاتصال بالشبكة الفرعية حتى تنتهي مهلة إدخال ARP للعبارة الافتراضية ل VM.

    لنشر بروتوكول FHRP بشكل صحيح مع OTV، من الضروري إعتبار ما يجب تصفية حركة مرور L2 و L3 وعزلها من OTV. على مستوى L2، يلزم الحفاظ على OTV من رؤية اللحاق لنفس MAC الظاهري من L2 المستخدم من قبل FHRP في مواقع متعددة.  يلزم توفر عوامل تصفية على المستوى L3 للحفاظ على عزل إعلانات HSRP و VRRP لكل مركز بيانات بحيث يتم ترجمة عملية الاختيار النشطة/المستمعة/الاحتياطية إلى كل مركز بيانات.

    بشكل افتراضي، يتم تمكين عوامل تصفية FHRP عند تمكين OTV.  يمكن تعطيلها إذا يتطلب التصميم توسيع FHRP بين مراكز البيانات.  لا يتم تمكين تصفية L2 لعناوين MAC الظاهرية بشكل افتراضي ويجب تكوينها يدويا.

    شكل 6. مثال على النشر الموصى به ل FHRP

    OTV-figure6

    في المثال، يتم إستخدام عنوان MAC الظاهري 0000.0c9f.f001 لعنوان IP 192.168.0.1 الذي يستضيف على شبكة VLAN الموسعة للاتصال خارج الشبكة الفرعية.  نظرا لاستخدام نفس عناوين التحكم في الوصول للوسائط (MAC) الافتراضية وبروتوكول الإنترنت (IP) في كل من مركزي البيانات، يتمتع المضيف بإمكانية اتصال سلسة خارج الشبكة الفرعية عند نقلها بين مراكز البيانات.

    لإبقاء عنوان MAC 0000.0c9f.001 مخفيا من OTV في مواقع متعددة، يجب نشر مرشح L2 مدخل (نقطة توقف حمراء في الرسم التخطيطي) لشبكة VLAN على كل من موجهات OTV، التي تخدم شبكة VLAN. من خلال تصفية قائمة التحكم بالوصول (ACL) التي تم تكوينها على مثيلات خدمة L2 للمدخل، يمكن إسقاط أي حزم تم الحصول عليها من MAC قبل عملية OTV على ASR1000 رؤيتها.  لذلك، لا يتعرف OTV على MAC ولا يقوم بالإعلان عنه لمراكز البيانات البعيدة. 

    يتم توفير التكوين الموصى به لتعقب جميع حركة مرور MAC الظاهرية ل FHRP المعروفة جيدا / الافتراضية هنا.

    mac access-list extended otv_filter_fhrp
     deny 0000.0c07.ac00 0000.0000.00ff any
     deny 0000.0c9f.f000 0000.0000.0fff any
     deny 0007.b400.0000 0000.0000.00ff any
     deny 0000.5e00.0100 0000.0000.00ff any
     permit any any

    تطابق قائمة التحكم في الوصول (ACL) هذه مساحات عنوان MAC المعروفة جيدا المقترنة بالإصدارات 1 و 2 من HSRP وبروتوكول موازنة حمل العبارة (GLBP) و VRRP (بهذا الترتيب). إذا تم تكوين MAC الظاهري لاستخدام قيمة غير قياسية لا تستند إلى رقم مجموعة FHRP، فيجب إضافته بشكل صريح إلى مثال قائمة التحكم في الوصول (ACL).  يجب إضافة قائمة التحكم في الوصول (ACL) إلى مثيل خدمة L2 (كما هو موضح هنا).

    interface Port-channel10
      description *** OTV internal interface ***
      no ip address
      no negotiation auto
    !
      service instance 800 ethernet
        encapsulation dot1q 800
        mac access-group otv_filter_fhrp in
        bridge-domain 800

    ومن الضروري أيضا إدارة الاتصال بين البلدان المضيفة في بروتوكول FHRP على المستوى L3 أيضا.  هناك أربعة موجهات FHRP تم تكوينها على شبكة فرعية موسعة واحدة في المخطط.  بدون درجة ما من مرشحات L3، يمكن أن ترى الموجهات الأربعة بعضها البعض وتنتخب جهاز نشط واحد ويكون لها 3 في حالات إستعداد مختلفة.  وبالتالي، سيكون لدى أحد مراكز البيانات موجهات FHRP احتياطيين محليين ولكن ليس لديه اتصال L2 بالموجه النشط البعيد بسبب عوامل تصفية L2 التي تمت مناقشتها مسبقا.

    تتمثل النتيجة المطلوبة في وجود موجه FHRP واحد نشط وآخر إحتياطي في كل مركز بيانات.  لا يمسك مرشح L2 المدخل الذي تمت مناقشته سابقا حركة مرور الانتخابات هذه لأن العملية الانتخابية تستخدم عناوين IP و MAC الفعلية للموجه.  بشكل افتراضي، يتم تطبيق قائمة التحكم بالوصول (ACL) subsequ كمخرج على واجهة التغشية.  سيكون مخرج لواجهة التغشية حركة مرور باتجاه مركز WAN.  لا تظهر قائمة التحكم في الوصول (ACL) في التكوين الجاري، ومع ذلك يمكن ملاحظتها باستخدام "show ip access-list".  هو يصفي ال FHRP انتخاب حركة مرور يؤسس على udp ميناء رقم.

    Extended IP access list otv_fhrp_filter_acl
        10 deny udp any any eq 1985 3222
        20 deny 112 any any
        30 permit ip any

    السبب الوحيد لتعطيل عامل التصفية هذا هو إذا كنت تريد أن تشارك جميع موجهات FHRP على شبكة VLAN، في نفس عملية الاختيار للوضع النشط.  لتعطيل عامل التصفية هذا، قم بتكوين "no otv filter-fhrp" على واجهة التغشية.

    حركة مرور بث موحد غير معروفة

    بشكل افتراضي، يتم إسقاط حركة مرور البث الأحادي المستلمة من الشبكة المحلية (LAN) بواسطة موجه OTV المحدد لعنوان MAC غير المعروف بوجوده في موقع OTV بعيد.  تعرف حركة المرور هذه باسم unicast غير معروف.  يذهب إجراء الإسقاط هذا إلى نواة WAN التي تحد من مقدار عرض النطاق الترددي المستهلك على شبكة WAN بواسطة حركة مرور البث.  تشير التوقعات العامة إلى أن جميع الأجهزة المضيفة الموجودة على الشبكة المحلية تصدر حركة مرور بيانات كافية للبث (ARPs، وبث البروتوكولات، وما إلى ذلك) يمكن رؤيتها دائما بواسطة موجه OTV، يتم الإعلان عنه، وبالتالي "معروف".

    تستفيد بعض التطبيقات من البيئات المضيفة الصامتة.  على تحويل بنية أساسية عادي هذا ليس مشكلة لأن بث L2 من مجهول unicast {upper}mac address على ال lan يسمح المضيف الصامت أن يرى الحركة مرور.  ومع ذلك، في بيئة OTV، يقوم موجه OTV بحظر حركة مرور البيانات بين مراكز البيانات.

    وللتعويض عن هذا، تم دمج ميزة تعرف باسم إعادة توجيه البث الأحادي الانتقائي في إصدارات Cisco IOS® XE 3.10.6 و XE3.13.3 و XE 3.14.1 و XE 3.14.1 و XE3.15 وجميع الإصدارات بعد الحصول على دعم لإعادة توجيه البث الأحادي الانتقائي. 

    يتم تكوينه بإضافة أمر واحد لكل عنوان MAC على واجهة التغشية.  على سبيل المثال:

    interface Overlay1
      service instance 100 ethernet
        encapsulation dot1q 100
        otv mac flood 0000.0000.0001
        bridge-domain 100

    أي حركة مرور موجهة ل 0000.0001.0001 يجب أن يتم فضت إلى كل موجهات OTV البعيدة مع VLAN 100 في هذا المثال.  يمكن ملاحظة ذلك من خلال أمر subsequant:

    OTV_router_1#show otv route
    Codes: BD - Bridge-Domain, AD - Admin-Distance,SI - Service Instance, * - Backup Route
    OTV Unicast MAC Routing Table for Overlay99
     Inst VLAN BD     MAC Address    AD    Owner  Next Hops(s)
    ----------------------------------------------------------
     0    100  100    0000.0000.0001 20    OTV    Flood

    إذا تم التعرف على عنوان MAC هذا في موقع بعيد، يجب إضافة إدخال إلى الجدول الأمامي الذي له الأولوية على إدخال التدفق.

    OTV_router_1#show otv route
    Codes: BD - Bridge-Domain, AD - Admin-Distance,SI - Service Instance, * - Backup Route
    OTV Unicast MAC Routing Table for Overlay99
     Inst VLAN BD     MAC Address    AD    Owner  Next Hops(s)
    ----------------------------------------------------------
     0    100  100    0000.0000.0001 20    OTV    Flood
     0    100  100    0000.0000.0001 50    ISIS   OTV_router_3

    بشكل عام، يجب تكوين إدخال تدفق لعنوان MAC محدد على جميع موجهات OTV مع شبكة VLAN هذه.

    مصادر البث المتعدد عن بعد

    لا يقوم موجه OTV ASR1000 بإعادة توجيه طلبات انضمام IGMP للبث المتعدد التي يتم استقبالها من الشبكة المحلية (LAN). ويفصل المخطط التالي المخطط المخطط الهيكلي حيث يمكن أن يكون هذا مشكلة.

    شكل 7. مصادر البث المتعدد عن بعد

    OTV-figure7

    عندما يتم إرسال انضمام IGMP للبث المتعدد بواسطة عميل البث المتعدد، فإن ASR1000 (موجه OTV B) يلاحظه ويعلن عن الاهتمام بمجموعة البث المتعدد.  يجب أن تقوم موجهات OTV البعيدة (OTV Router A) بإعادة توجيه أي حركة مرور إلى مجموعة البث المتعدد تلك التي تراها على مجال البث المحلي لها من المستوى الثاني.  لا يقوم موجه ASR1000 (OTV Router A) البعيد بإعادة إنشاء طلبات انضمام IGMP للبث المتعدد عند الإعلان عن الفائدة في مجموعة البث المتعدد من موجه OTV الخاص بالعميل (OTV Router B).

    عندما تكون مصادر البث المتعدد على مجال بث L2 نفسه الخاص بموجه OTV، فإن ذلك لا يمثل مشكلة.  يجب تكوين موجه OTV كمستعلم IGMP.  هذا يظهر في أي multicast حركة مرور حاضر على ال L2 بث مجال.  مهما، فقط PIM ربط طلب أن يسبب PIM مسحاج تخديد أن يرسل multicast مصدر من مختلف L2 بث مجال إلى ال L2 بث مجال ال OTV مسحاج تخديد يكون على.

    لم يتم إعادة توجيه طلب الانضمام إلى بروتوكول IGMP البعيد أو إعادة إنشاؤه. موجهات OTV ليست موجهات PIM أيضا.  لذلك فإن الطبقات ذات مصادر البث المتعدد ليست مباشرة على مجال بث L2 مع موجه OTV ليس لديها أي طريقة للدخول من موجهات PIM لإعادة توجيه حركة مرور المصدر عندما يكون هناك اهتمام من قبل عميل بعيد.

    هناك حلان لهذه المشكلة.  

    أولا، يمكن نشر عميل (عملاء) IGMP المحليين على مجال بث L2 المرفق بموجه OTV (OTV Router A). يجب على عميل IGMP هذا الاشتراك في أي مجموعات بث متعدد يمكن للعملاء البعيدين الاشتراك فيها.  وهذا قد يتسبب في قيام موجه PIM بإعادة توجيه حركة مرور البث المتعدد إلى مجال البث المتاخم لموجه OTV A.  تقوم استعلامات IGMP بعد ذلك بسحب أي حركة مرور للبث المتعدد ويتم إرسالها عبر التراكب. 

    ويتمثل الحل الآخر في تكوين "ip igmp static-join" لأي مجموعات يمكن للعملاء البعيدين الاشتراك فيها.  وهذا قد يتسبب أيضا في قيام موجه PIM بإعادة توجيه حركة مرور البث المتعدد إلى مجال البث المتاخم لموجه OTV A.

    هذا التحديد معروف وهو جزء من مواصفات التصميم.  لا يعد خطأ، ولكنه حد في المخطط المعتمد في هذا الوقت.

    اعتبارات جودة الخدمة

    بشكل افتراضي على ASR1000، يتم نسخ قيمة TOS في رأس OTV المضاف من وحدات بت 802.1p الخاصة بالحزمة L2.  إذا كانت حزمة L2 غير مميزة، فسيتم إستخدام قيمة مقدارها صفر.

    يحتوي Nexus 7000 على سلوك افتراضي مختلف في برنامج 5.2.1 والأحدث.  إذا كان السلوك المرغوب هو نسخ قيمة TOS للحزم الداخلية في الخارج، فيمكن لتكوين جودة الخدمة الإضافية تحقيق ذلك.  وهذا يعطي نفس السلوك الذي يعطيه برنامج Nexus 7000 الجديد.

    يكون التكوين لنسخ قيمة حزم L2 L3 TOS في الرأس الخارجي لحزمة OTV هو subsequ:

    class-map dscp-af11
     match dscp af11
    !
    class-map dscp-af21
     match dscp af21
    !
    class-map qos11
     match qos-group 11
    !
    class-map qos21
     match qos-group 21
    !
    policy-map in-mark
     class dscp-af11
      set qos-group 11
     class dscp-af21
      set qos-group 21
    !
    policy-map out-mark
     class qos11
      set dscp af11
     class qos21
      set dscp af21
    !
    interface Gig0/0/0
     ! L2 interface
     service instance 100 ethernet
      encapsulation dot1q 100
      service-policy in-mark
      bridge-domain 100
    !
    interface Gig0/0/1
     ! OTV join interface
     service-policy out-mark

    يجب أن يطابق التكوين المقدم حركة مرور قيم DSCP المختلفة على المدخل.  يتم إستخدام علامة مجموعة جودة الخدمة (QoS) المهمة محليا لوضع علامة داخليا على حركة المرور هذه أثناء العبور عبر الموجه.  في واجهة الخروج، تتم مطابقة مجموعة جودة الخدمة، ثم يتم تحديث بايت TOS الخارجي وفقا لذلك. 

    اعتبارات وحدة الحد الأقصى للنقل (MTU) لشبكة WAN / التجزئة

    يستخدم OTV بشكل أساسي رأس GRE لنقل حركة مرور L2 عبر شبكة WAN. رأس GRE هذا يبلغ حجمه 42 بايت.  في نشر شبكة مثالي، يجب أن يحتوي إرتباط WAN على وحدة إرسال (MTU) كحد أقصى تكون أكبر بمقدار 42 بايت على الأقل من أكبر الحزمة التي يتوقع أن يتعامل معها OTV.

    إذا كانت واجهة L2 تحتوي على وحدة الحد الأقصى للنقل (MTU) بمقدار 1500 بايت، فيجب أن تحتوي واجهة الربط على وحدة الحد الأقصى للنقل (MTU) بمقدار 1542 بايت أو أكثر.  إذا كانت واجهة L2 تحتوي على وحدة الحد الأقصى للنقل (MTU) بمقدار 2000 بايت، ولكن من المتوقع فقط معالجة الحزم التي يصل حجمها إلى 1500 بايت، فهذا يعني أن وحدة الحد الأقصى للنقل (MTU) لشبكة WAN بمقدار 1542 بايت كافية، ومع ذلك فإن الإضافة القياسية التي تبلغ 42 إلى 2000 ستكون مثالية.

    interface GigabitEthernet0/0/0
      mtu 1600
    !
    interface Overlay 1
      otv join-interface GigabitEthernet0/0/0
    !
    interface GigabitEthernet0/0/1
      mtu 1500
      service instance 100 ethernet
        encapsulation dot1q 100
        bridge-domain 100
      service instance 101 ethernet
        encapsulation dot1q 101
        bridge-domain 101

    يتعذر على بعض موفري الخدمة توفير قيم أكبر لوحدة الحد الأقصى للنقل (MTU) لدارات شبكة WAN الخاصة بهم.  إذا كان هذا هو الحال، فيمكن ل ASR1000 إجراء تجزئة للبيانات التي تم نقلها عبر بروتوكول OTV.  لا يحتوي Nexus 7000 على هذه الإمكانية.  شبكات ASR1000 و Nexus 7000 OTV المختلطة مع التجزئة التي تم تمكينها على ASR1000 غير مدعومة.

    تكوين تجزئة OTV هو:

    otv fragmentation join-interface GigabitEthernet0/0/0
    !
    interface Overlay 1
      otv join-interface GigabitEthernet0/0/0

    من المهم تكوين الأمر global level قبل أمر الواجهة overlay join-interface.  إذا تم تكوين أمر واجهة التغشية OTV join-interface أولا، فقم بإزالة أمر OTV join-interface من الواجهة التغشية، ثم قم بتكوين أمر تجزئة OTV join-interface ثم قم بتكوين أمر واجهة التغشية otv join-interface مرة أخرى.

    عندما لا يكون تجزئة OTV ممكنا، فإن كل حزم OTV التي تحمل بيانات L2 المغلفة يتم إرسالها مع مجموعة بت DF بحيث لا يتم تجزئتها أثناء النقل.  بمجرد إضافة أمر التجزئة، يتم تعيين وحدة بت DF على 0. ويمكن أن تتفتت موجهات OTV نفسها في الحزمة ويمكن تجزئتها أثناء العبور بواسطة موجهات أخرى.

    هناك كمية محدودة من المخازن المؤقتة لإعادة تجميع الحزم المتوفرة على أنظمة ASR1000 الأساسية، وبالتالي يجب تقسيم الأجزاء الأقل من الحزمة إلى لإرسالها بشكل أفضل.  وهذا من شأنه زيادة الكفاءة وتقليل إجمالي إستهلاك عرض النطاق الترددي عبر شبكة الاتصال واسعة النطاق إذا كانت هذه مشكلة.  هناك تأثيرات على الأداء لتمكين تجزئة OTV.  إذا كان التجزئة موجودا وكان من المتوقع معالجة أكثر من 1 جيجابت/ثانية لحركة مرور OTV، فيجب إجراء المزيد من التحقيق في أداء OTV.

    مخطط البث الأحادي للحالة الخاصة

    عادة ما تتضمن عمليات النشر الميدانية لبروتوكول OTV إتصالات ألياف مباشرة من الخلف إلى الخلف بين موجهات OTV في مركزين للبيانات. 

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

    ومع ذلك، إذا كان النشر يحتوي على موجهات OTV متعددة المسارات في مركزي البيانات، فهناك بعض الاعتبارات الخاصة.  يلزم توفر تكوين إضافي.

    في حالة مشاركة أكثر من مركزين للبيانات، لا ينطبق هذا التكوين الخاص. 

    للسيناريو الذي يحتوي على أكثر من مركزي بيانات مزودين بموجهات OTV أحادية أو متعددة المسارات، يجب إستخدام نشر OTV للبث الأحادي أو البث المتعدد. 

    لا يوجد بديل مدعوم آخر.

    شكل 8. البث الأحادي للحالة الخاصة

    OTV-figure8

    في المخطط المعروض، الروابط بالأخضر هي روابط الألياف الداكنة بين مركزي البيانات.  هذه الألياف الداكنة متصلة مباشرة بموجهات OTV.  يتم إستخدام الارتباطات الزرقاء بين موجهات OTV لإعادة توجيه حركة المرور غير الخاصة ب OTV في حالة فشل الارتباطات الخضراء.  إذا فشل الارتباط الأخضر العلوي (من A إلى C)، فسيتم توجيه حركة المرور غير المعتمدة على تقنية OTV التي تستخدم الموجهات الطرفية OTV كالمسار الافتراضي لها عبر الارتباطات الزرقاء من الشمال إلى الجنوب (من A إلى B ومن C إلى D) إلى الارتباط الأخضر الذي لا يزال قيد التشغيل بين زوج موجه OTV السفلي (من B إلى D).

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

    يجب أن يراقب BFD إرتباط WAN بين أزواج موجهات OTV من الشرق إلى الغرب (A / C و B / D). في حالة فقد الاتصال بالموجه البعيد، يتم إيقاف تشغيل واجهة تغشية OTV عبر برنامج IM النصي على زوج موجهات OTV من الشرق إلى الغرب.  وهذا يتسبب في قيام الموجه متعدد المنازل المقترن بفرض إعادة التوجيه لجميع شبكات VLAN.  عندما يكتشف BFD أن الرابط قد استرد، فإن برنامج IM النصي يعمل على إعادة تمكين واجهة التغشية.

    ومن المهم جدا إستخدام BFD لاكتشاف فشل الارتباط.  وذلك نظرا لأنه يجب إيقاف تشغيل واجهة التغشية على كل من الجانب "failed" بالإضافة إلى زوج الشرق والغرب.  والذي يتوقف على نوع الاتصال الذي يوفره مزود الخدمة، يمكن أن يتعطل إرتباط فعلي واحد (الواجهة الخضراء على موجه OTV A) بينما يمكن أن تظل واجهة زوج الموجهات الشرقي-الغربي المقابلة ثابتة (الواجهة الخضراء على موجه OTV C). يكتشف BFD فشل أي من الواجهات أو أي مشكلة أخرى في النقل ويقوم على الفور بإعلام كلا الزوجين في آن واحد.  وينطبق الأمر نفسه على الحالات التي يلزم فيها إعلام الموجهات بارتباط الاسترداد.

    يكون تكوين هذا النشر هو نفسه أي نشر آخر مع إضافة العناصر التالية:

    • تكوين BFD على واجهة WAN
    • نص IM اللاحق
    • OTV ISIS هوية أن تلاءم توزيع زوجي/فردي VLAN

    يتجاوز تكوين BFD على واجهة ربط OTV نطاق هذا المستند.  يمكن العثور على معلومات حول كيفية تكوين BFD على ASR1000 في:

    https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bfd/configuration/xe-3s/irb-xe-3s-book.html

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

    event manager environment _OverlayInt Overlay1
    !
    event manager applet WatchBFDdown
    description "Monitors BFD status, if it goes down, bring OVERLAY int down"
    event syslog pattern "BFD peer down notified" period 1
    action 1.0 cli command "enable"
    action 2.0 cli command "config t"
    action 2.1 syslog msg "EEM: WatchBFDdown will shut int $_OverlayInt"
    action 3.0 cli command "interface $_OverlayInt"
    action 4.0 cli command "shutdown"
    action 5.0 syslog msg "EEM WatchBFDdown COMPLETE ..."
    !
    event manager applet WatchBFDup
    description "Monitors BFD status, if it goes up, bring OVERLAY int up"
    event syslog pattern "new adjacency" period 1
    action 1.0 cli command "enable"
    action 2.0 cli command "config t"
    action 2.1 syslog msg "EEM: WatchBFDup bringing up int $_OverlayInt"
    action 3.0 cli command "interface $_OverlayInt"
    action 4.0 cli command "no shutdown"
    action 5.0 syslog msg "EEM WatchBFDup COMPLETE ..."
    !

    يتطلب هذا النوع من النشر أيضا أن تتطابق أزواج الموجهات من الشرق إلى الغرب (A/C و B/D) مع إعادة التوجيه الخاصة بشبكات VLAN الفردية والزوجية. 

    على سبيل المثال، يجب أن يقوم A و C بإعادة توجيه شبكات VLAN الزوجية بينما يقوم B و D بإعادة توجيه شبكات VLAN الفردية في عملية اسمية مستقرة في الحالة. 

    يتم تحديد التوزيع الفردي / الزوجي بواسطة الرقم الترتيبي OTV الذي يمكن ملاحظته بواسطة الأمر "show otv site". 

    يتم تحديد الرقم الترتيبي بين موجهات الموقع استنادا إلى المعرف الصافي ل OTV ISIS. 

    OTV_router_A#show otv site
    Site Adjacency Information (Site Bridge-Domain: 99)
    Overlay99 Site-Local Adjacencies (Count: 2)
      Hostname       System ID      Last Change Ordinal    AED Enabled Status
    * OTV_router_A   0021.D8D4.F200 19:32:02    0          site       overlay
      OTV_router_B   0026.CB0C.E200 19:32:46    1          site       overlay

    يجب تكوين معرف شبكة OTV ISIS على جميع موجهات OTV.  يجب توخي الحذر عند تكوين المعرف بحيث لا تزال جميع موجهات OTV تعرف بعضها البعض.

    OTV router A:
    otv isis Site
     net 49.0001.0001.0001.000a.00

    OTV router B:
    otv isis Site
     net 49.0001.0001.0001.000b.00

    OTV router C:
    otv isis Site
     net 49.0001.0001.0001.000c.00

    OTV router 
   
   D:
    otv isis Site
     net 49.0001.0001.0001.000d.00

    يجب أن تتطابق أجزاء المعرف بالأسود مع جميع موجهات OTV التي تشارك في التغشية.  يمكن تعديل جزء المعرف باللون الأحمر.  يحصل معرف الشبكة الأدنى في موقع ما على الرقم الترتيبي 0 وبالتالي إعادة توجيه شبكات VLAN المرقمة الزوجية.  يحصل أعلى معرف شبكة في موقع ما على الرقم الترتيبي 1 ويرسل الرقم الفردي لشبكات VLAN.

    أمثلة التكوين

    البث الأحادي 

    شكل 9. مثال تكوين البث الأحادي

    OTV-figure9

    تهيئة روما:

    !
    hostname Rome
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0001
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet1/0/0
     otv adjacency-server unicast-only
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    interface GigabitEthernet1/0/0
     ip address 172.16.0.1 255.255.255.0
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet1/0/1
     no ip address
     negotiation auto
     cdp enable
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !

    تهيئة البندقية:

    !
    hostname Venice
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0001
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet0/0/0
     otv adjacency-server unicast-only
     otv use-adjacency-server 172.16.0.1 unicast-only
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet0/0/0
     ip address 172.16.0.2 255.255.255.0
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet0/0/1
     no ip address
     negotiation auto
     cdp enable
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !

    تهيئة نابولي:

    !
    hostname Naples
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0002
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet0/0/0
     otv use-adjacency-server 172.16.0.1 172.16.0.2 unicast-only
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet0/0/0
     ip address 172.16.0.3 255.255.255.0
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet0/0/1
     no ip address
     negotiation auto
     cdp enable
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !

    تكوين ميلانو:

    !
    hostname Milan
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0002
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet0/0/0
     otv use-adjacency-server 172.16.0.1 172.16.0.2 unicast-only
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet0/0/0
     ip address 172.16.0.4 255.255.255.0
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet0/0/1
     no ip address
     negotiation auto
     cdp enable
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !

    البث المتعدد

    شكل 10. مثال تكوين البث المتعدد

    OTV-figure10

    تهيئة روما:

    !
    hostname Rome
    !
    ip multicast-routing distributed
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0001
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet1/0/0
     otv control-group 239.0.0.1
     otv data-group 238.1.2.0/24
    !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet1/0/0
     ip address 192.168.0.1 255.255.255.0
     ip pim passive
     ip igmp version 3
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet1/0/1
     no ip address
     negotiation auto
     cdp enable
    !
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !

    تهيئة البندقية:

    !
    hostname Venice
    !
    ip multicast-routing distributed
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0001
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet0/0/0
     otv control-group 239.0.0.1
     otv data-group 238.1.2.0/24
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet0/0/0
     ip address 172.17.0.1 255.255.255.0
     ip pim passive
     ip igmp version 3
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet0/0/1
     no ip address
     negotiation auto
     cdp enable
    !
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !

    تهيئة نابولي:

    !
    hostname Naples
    !
    ip multicast-routing distributed
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0002
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet0/0/0
     otv control-group 239.0.0.1
     otv data-group 238.1.2.0/24
    !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet0/0/0
     ip address 172.18.0.1 255.255.255.0
     ip pim passive
     ip igmp version 3
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet0/0/1
     no ip address
     negotiation auto
     cdp enable
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !

    تكوين ميلانو:

    !
    hostname Milan
    !
    ip multicast-routing distributed
    !
    ip igmp snooping querier version 3
    ip igmp snooping querier
    !
    otv site bridge-domain 99
    !
    otv site-identifier 0000.0000.0002
    !
    spanning-tree mode pvst
    !
    interface Overlay99
     no ip address
     otv join-interface GigabitEthernet0/0/0
    otv control-group 239.0.0.1
     otv data-group 238.1.2.0/24
    !
      service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !
    interface GigabitEthernet0/0/0
     ip address 172.19.0.1 255.255.255.0
     ip pim passive
     ip igmp version 3
     negotiation auto
     cdp enable
    !
    interface GigabitEthernet0/0/1
     no ip address
     negotiation auto
     cdp enable
     service instance 99 ethernet
      encapsulation dot1q 99
      bridge-domain 99
     !
     service instance 100 ethernet
      encapsulation dot1q 100
      bridge-domain 100
     !
     service instance 101 ethernet
      encapsulation dot1q 101
      bridge-domain 101
     !
    !

    الأسئلة المتكررة

    س) هل يتم دعم شبكات VLAN الخاصة بالاقتران مع OTV؟

    أ) نعم، التكوين الخاص مطلوب في OTV. في تكوين شبكة VLAN الخاصة، تأكد من تكوين منافذ المحول المتصلة بواجهة OTV L2 في الوضع المختلط.

    س) هل OTV معتمد مع تشفير IPSec؟

    أ) نعم، يتم دعم تكوين خريطة التشفير على الواجهة المشتركة.  لا يتطلب تكوين خاص ل OTV لدعم التشفير.  ومع ذلك، يضيف تكوين التشفير عبئا إضافيا ويجب التعويض عن ذلك بزيادة وحدة الحد الأقصى للنقل (MTU) لشبكة WAN مقابل وحدة الحد الأقصى للنقل (MTU) لشبكة LAN. إذا لم يكن ذلك ممكنا، يجب أن يكون تجزئة OTV مطلوبا.  يقتصر أداء OTV على أداء أجهزة IPSec.

    س) هل OTV مدعوم مع MACsec؟

    أ) نعم، يتضمن ASR1001-X دعم MACsec للواجهات المدمجة.  يعمل OTV مع MACsec الذي تم تكوينه على واجهات LAN و/أو WAN.  يقتصر أداء OTV على أداء أجهزة MACsec.

    س) هل يمكن إستخدام واجهة الاسترجاع كواجهة الربط؟

    أ) لا، يمكن إستخدام واجهات Ethernet أو PortChannels أو POS فقط كواجهات ربط OTV.  توجد واجهة الانضمام إلى OTV Loopback على خريطة الطريق ولكن لم يتم جدولتها حاليا لإصدار في هذا الوقت.

    Q) يمكن إستخدام واجهة النفق كواجهة الربط؟

    أ)لا يتم دعم أنفاق GRE أو أنفاق DMVPN أو أي نوع نفق آخر كواجهات مشتركة.  يمكن إستخدام واجهات Ethernet أو PortChannels أو POS فقط كواجهات ربط OTV. 

    س) هل يمكن أن تستخدم واجهات تغشية مختلفة الواجهات L2 و/أو وصلات وصل؟

    أ) يجب أن تشير جميع واجهات التغشية إلى نفس واجهة الوصل.  يجب ربط كافة التغشيات بنفس الواجهة المادية لاتصال L2 بمركز البيانات.

    q) يستطيع ال OTV موقع VLAN يكون على قارن طبيعي مختلف من ال OTV موسع VLANs؟

    أ) ال OTV موقع VLAN و VLANs موسع ينبغي كنت على ال نفسه قارن طبيعي.

    س) ما هي مجموعة الميزات المطلوبة ل OTV؟

    أ) خدمات IP المتقدمة (AIS) أو خدمات المؤسسات المتقدمة (AES) مطلوبة من أجل OTV.

    س) هل هناك حاجة إلى ترخيص منفصل من أجل OTV على منصات ذات تهيئة ثابتة؟

    أ) لا، طالما يتم تشغيل ASR1000 مع تكوين مستوى تمهيد الخدمات أو المغامرات، فإن OTV يتوفر.

    محفوظات المراجعة

    المراجعة تاريخ النشر التعليقات
    1.0
    31-Jul-2024
    الإصدار الأولي
    TAC Authored

    تمت المساهمة بواسطة مهندسو Cisco

    • David Langley
      Cisco TAC

    هل كان هذا المستند مفيدًا؟

    Feedbackالتعليقات

    اتصل بنا

    ينطبق هذا المستند على هذه المنتجات