فهم رسائل تنشيط الاتصال عبر نفق GRE

المقدمة

يصف هذا وثيقة ما هو تضمين التوجيه العام (GRE) keepalives وكيف تعمل.

أنفاق GRE

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

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

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

قبل تنفيذ حزم GRE keepalives، كانت هناك طرق فقط لتحديد المشاكل المحلية على الموجه وليس هناك طريقة لتحديد المشاكل في شبكة النقل. على سبيل المثال، الحالة التي يتم فيها إعادة توجيه حزم GRE النفقي بنجاح، ولكنها تفقد قبل الوصول إلى الطرف الآخر من النفق. ومن شأن مثل هذه السيناريوهات أن تجعل حزم البيانات التي تمر عبر نفق GRE "محجوزة بالأبيض والأسود"، حتى وإن كان هناك طريق بديل يستخدم PBR أو مسار ثابت عائم عبر واجهة أخرى متاحا. يتم إستخدام رسائل Keepalives على واجهة نفق GRE لحل هذه المشكلة بنفس الطريقة التي يتم بها إستخدام رسائل keepalives على الواجهات المادية.

ملاحظة: لا يتم دعم رسائل تنشيط الاتصال GRE مع حماية نفق IPsec تحت أي ظروف. يناقش هذا المستند هذه المسألة.

كيفية عمل رسائل تنشيط الاتصال عبر النفق

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

الحِزمة العادية:

الحزم النفقي:

• IP هو بروتوكول النقل.
• GRE بمثابة بروتوكول التضمين.
• بروتوكول الإنترنت هو بروتوكول الركاب.

هنا مثال على حزمة keepalive التي تنشأ من الموجه A ويتم توجيهها إلى الموجه B. توجد إستجابة Keepalive التي يقوم الموجه B بإرجاعها إلى الموجه A بالفعل داخل رأس IP الداخلي. يكسر الموجه B ببساطة الحزمة keepalive ويرسلها مرة أخرى إلى الواجهة المادية (S2). إنه يعالج الحزمة keepalive ل GRE تماما مثل أي حزمة بيانات GRE IP أخرى.

مجموعة شرائح Keepalives:

تتسبب هذه الآلية في إعادة توجيه إستجابة keepalive من الواجهة المادية بدلا من واجهة النفق. وهذا يعني أن حزمة إستجابة GRE keepalive لا تتأثر بأي ميزات إخراج على واجهة النفق، مثل "حماية النفق ..." جودة الخدمة والتوجيه الظاهري وإعادة التوجيه (VRF) وما إلى ذلك.

ملاحظة: إذا تم تكوين قائمة التحكم في الوصول الواردة (ACL) على واجهة نفق GRE، فيجب السماح بالحزمة keepalive لنفق GRE التي يرسلها الجهاز المعاكس. وإذا لم تكن هناك مساحة، فإن نفق GRE الخاص بالجهاز المعاكس يصبح معطلا. (يسمح قائمة الوصول <number> لمضيف الشبكة <tunnel-source> لمضيف <tunnel-destination>)

هناك سمة أخرى لرسائل تنشيط الاتصال عبر نفق GRE وهي أن وحدات توقيت رسائل تنشيط الاتصال على كل جانب مستقلة ولا يجب أن تتطابق، على غرار رسائل تنشيط الاتصال عبر بروتوكول PPP.

تلميح: المشكلة مع تكوين رسائل keepalives فقط على جانب واحد من النفق هي أن الموجه الذي يحتوي على رسائل keepalives تم تكوينها يعلم واجهة النفق الخاصة به كالتالي إذا انتهت صلاحية مؤقت keepalive. وتظل واجهة نفق GRE على الجانب الآخر، حيث لم يتم تكوين رسائل تنشيط الاتصال، قيد التشغيل حتى إذا كان الجانب الآخر من النفق معطلا. يمكن أن يصبح النفق ثقبا أسود للحزم الموجهة إلى النفق من الجانب الذي لم يتم تكوين رسائل تنشيط الاتصال به.

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

رسائل تنشيط اتصال نفق GRE

باستخدام برنامج Cisco IOS^® الإصدار 12.2(8)T، من الممكن تكوين رسائل تنشيط الاتصال على واجهة نفق GRE من نقطة إلى نقطة. مع هذا التغيير، النفق قارن يعطل ديناميكيا إن يفشل ال keepalives لفترة معينة من الوقت.

أحلت ل كثير معلومة على كيف آخر شكل من keepalives يعمل، نظرة عامة من keepalive آلية على cisco ios.

ملاحظة: يتم دعم رسائل تنشيط الاتصال الخاصة بنفق GRE فقط على أنفاق GRE من نقطة إلى نقطة. تكون رسائل تنشيط الاتصال عبر النفق قابلة للتكوين على أنفاق GRE متعددة النقاط (mGRE) ولكن ليس لها تأثير.

ملاحظة: بشكل عام، لا يمكن أن تعمل رسائل keepalives النفق عندما يتم إستخدام VRF على واجهة النفق ولا تتطابق مع fVRF (النفق vrf ...) و iVRF (إعادة توجيه ip vrf .. على واجهة النفق). هذا مهم على نقطة نهاية النفق أن يعكس keepalive إلى الطالب. عندما يتم تلقي طلب keepalive، يتم إستلامه في fVRF وتجزئته. وهذا يكشف عن رد keepalive الذي تم إنشاؤه مسبقا، والذي يجب إعادة توجيهه بعد ذلك إلى المرسل، ولكن إعادة التوجيه هذه موجودة في سياق iVRF على واجهة النفق. لذلك، إذا لم تتطابق iVRF و fVRF، فلن تتم إعادة توجيه حزمة الرد keepalive مرة أخرى إلى المرسل. وهذا صحيح حتى إذا قمت باستبدال iVRF و/أو fVRF ب global.

يبدي هذا إنتاج الأمر أنت تستعمل in order to شكلت keepalives على GRE نفق.

Router#configure terminal
Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].

!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.

من أجل فهم كيفية عمل آلية رسائل تنشيط النفق بشكل أفضل، ضع في الاعتبار هذا المثال على مخطط النفق وتكوينه:

الموجه A:

interface loopback 0
  ip address 192.168.1.1 255.255.255.255
interface tunnel 0
  ip address 10.10.10.1 255.255.255.252
  tunnel source loopback0
  tunnel destination 192.168.1.2
  keepalive 5 4

الموجه B:

interface loopback 0
  ip address 192.168.1.2 255.255.255.255
interface tunnel 0
  ip address 10.10.10.2 255.255.255.252
  tunnel source loopback0
  tunnel destination 192.168.1.1
  keepalive 5 4 

في هذا السيناريو، يقوم الموجه A بتنفيذ الخطوات التالية:

• • يتم تعيين المصدر على أنه وجهة النفق المحلية، والتي تكون 192.168.1.2
  • تم تعيين الوجهة كمصدر النفق المحلي، وهو 192.168.1.1، و 
  • يبني رأس IP الداخلي كل خمس ثوان حيث تتم إضافة رأس GRE بنوع بروتوكول (PT) مقداره 0.
  
  الحزمة التي تم إنشاؤها بواسطة الموجه A ولكن لم يتم إرسالها:
  

  عنوان IP		GRE
  المصدر:192.168.1.2	الوجهة:192.168.1.1	pt=0

  
  
  

يرسل أن ربط من النفق قارن، أي ينتج في عملية كبسلة من الربط مع العنوان خارجي حيث:

• يتم تعيين المصدر على أنه مصدر النفق المحلي، وهو 192.168.1.1
• تم تعيين الوجهة على أنها وجهة النفق المحلي، وهي 192.168.1.2، و
• تتم إضافة رأس GRE مع pt = ip.
  
  الحزمة المرسلة من الموجه A إلى الموجه B:

• زيادة عداد رسائل تنشيط النفق بمقدار واحد.
• بافتراض وجود طريقة للوصول إلى نقطة نهاية النفق للنهاية البعيدة وعدم تعطل بروتوكول خط النفق بسبب أسباب أخرى، تصل الحزمة إلى الموجه B. وبعد ذلك تتم مطابقتها مقابل النفق 0، وتصبح مفككة، ويتم إعادة توجيهها إلى IP الوجهة الذي هو عنوان IP لمصدر النفق على الموجه A.
  
  تم الإرسال من الموجه B إلى الموجه A:
  

  عنوان IP		GRE
  المصدر:192.168.1.2	الوجهة:192.168.1.1	pt=0

  
  
  
• عند الوصول إلى الموجه A، تصبح الحزمة غير مبطنة وينتج التحقق من النقطة pt في 0. وهذا يعني أن هذه حزمة keepalive. يتم بعد ذلك إعادة تعيين عداد رسائل تنشيط النفق على 0 ويتم تجاهل الحزمة.

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

ملاحظة: في حالة up/down، لا يقوم النفق بإعادة توجيه أي حركة مرور بيانات أو معالجتها. ومع ذلك، فإنه يستمر في إرسال حزم keepalive. في إستقبال إستجابة keepalive، مع الإيحاء بأن نقطة نهاية النفق يمكن الوصول إليها مرة أخرى، تتم إعادة تعيين عداد keepalive النفق إلى 0، ويصدر بروتوكول الخط على النفق.

لتمكين نفق تصحيح الأخطاء وdebug tunnel keepalive لعرض رسائل تنشيط رسائل تنشيط الاتصال.

نموذج تصحيح الأخطاء من الموجه A:

debug tunnel keepalive
        Tunnel keepalive debugging is on
        01:19:16.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=15
        01:19:21.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=16
        01:19:26.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=17

إعادة توجيه المسار العكسي للبث الأحادي و GRE Keepalives

إعادة توجيه المسار العكسي (RPF) للبث الأحادي (إعادة توجيه المسار العكسي للبث الأحادي) هي ميزة أمان تساعد على اكتشاف حركة مرور IP المنتحلة وإسقاطها مع التحقق من صحة عنوان مصدر الحزمة مقابل جدول التوجيه. عند تشغيل إعادة توجيه المسار العكسي (RPF) للبث الأحادي في الوضع المقيد (ip verify unicast source reachable-via rx)، يجب إستلام الحزمة على الواجهة التي سيستخدمها الموجه لإعادة توجيه الحزمة المرتجعة. إذا تم تمكين إعادة توجيه المسار العكسي (RPF) للبث الأحادي في الوضع غير المحكم على واجهة النفق الخاصة بالموجه الذي يستقبل حزم GRE keepalive، حينئذ يتم إسقاط حزم keepalives بواسطة RPF بعد إزالة كبسلة النفق نظرا لأن المسار إلى عنوان المصدر للحزمة (عنوان مصدر النفق الخاص بالموجه) لا يتم من خلال واجهة النفق. يمكن ملاحظة عمليات إسقاط حزمة RPF في إخراج حركة مرور IP كما يلي:

Router#show ip traffic | section Drop 
 Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
 0 no route, 156 unicast RPF, 0 forced drop
 0 options denied 

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

رسائل تنشيط الاتصال عبر بروتوكول IPsec و GRE

أنفاق GRE مع IPsec

يتم أحيانا دمج أنفاق GRE مع IPsec لأن IPsec لا يدعم حزم بث IP المتعدد. ولهذا السبب، لا يمكن تشغيل بروتوكولات التوجيه الديناميكية بنجاح عبر شبكة VPN ل IPsec. ونظرا لأن أنفاق GRE تدعم بث IP المتعدد، يمكن تشغيل بروتوكول توجيه ديناميكي عبر نفق GRE. يمكن تشفير حزم البث الأحادي ل GRE IP التي ينتج عنها بواسطة IPsec.

هناك طريقتان مختلفتان يمكن أن يقوم IPsec بتشفير حزم GRE:

• إحدى الطرق هي إستخدام خريطة التشفير. عند إستخدام خريطة تشفير، يتم تطبيقها على الواجهة (الواجهات) المادية الصادرة لحزم نفق GRE. وفي هذه الحالة، يكون تسلسل الخطوات كما يلي:
  
  
  1. تصل الحزمة المشفرة إلى الواجهة المادية.
  2. يتم فك تشفير الحزمة وإعادة توجيهها إلى واجهة النفق.
  3. يتم فك كبسلة الحزمة ثم إعادة توجيهها إلى وجهة IP في نص واضح.
  
  
  
• الطريقة الأخرى هي إستخدام حماية النفق. عند إستخدام حماية النفق، يتم تكوينها على واجهة نفق GRE. أصبح أمر حماية النفق متاحا في برنامج Cisco IOS، الإصدار 12.2(13)T. وفي هذه الحالة، يكون تسلسل الخطوات كما يلي:
  
  
  1. تصل الحزمة المشفرة إلى الواجهة المادية.
  2. تتم إعادة توجيه الحزمة إلى واجهة النفق.
  3. يتم فك تشفير الحزمة وفك تشفيرها ثم إعادة توجيهها إلى وجهة IP في نص واضح.

تحدد كلتا الطريقتين أنه يتم إجراء تشفير IPsec بعد إضافة تضمين GRE. هناك اختلافان رئيسيان بين عند إستخدام خريطة تشفير وعند إستخدام حماية النفق:

• يتم ربط خريطة تشفير IPsec بالواجهة المادية ويتم فحصها حيث يتم إعادة توجيه الحزم خارج الواجهة المادية. قام نفق GRE بتضمين الحزمة بالفعل بواسطة هذه النقطة.
• تقوم حماية النفق بربط وظيفة التشفير بنفق GRE ويتم التحقق منها بعد تضمين الحزمة في GRE ولكن قبل تسليم الحزمة إلى الواجهة المادية.

مشكلات رسائل تنشيط الاتصال عند دمج IPsec و GRE

بافتراض الطريقتين لإضافة تشفير إلى أنفاق GRE، هناك ثلاث طرق منفصلة لإعداد نفق GRE مشفر:

1. يحتوي النظير A على حماية النفق التي تم تكوينها على واجهة النفق بينما يحتوي النظير B على خريطة تشفير تم تكوينها على الواجهة المادية.
2. يحتوي النظير A على خريطة تشفير تم تكوينها على الواجهة المادية بينما يحتوي النظير B على حماية النفق التي تم تكوينها على واجهة النفق.
3. يتمتع كلا النظرين بحماية النفق التي تم تكوينها على واجهة النفق.

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

ضع في الاعتبار كل سيناريو من هذه السيناريوهات مع تمكين GRE keepalives على النظير B(يتحدث) وحيث يتم إستخدام وضع النفق للتشفير.

السيناريو 1

التكوين:

• يستخدم النظير A حماية النفق.
• يستخدم النظير B خرائط التشفير.
• يتم تمكين رسائل تنشيط الاتصال على النظير B.
• يتم تشفير IPsec في وضع النفق.

في هذا السيناريو، نظرا لتكوين رسائل تنشيط الاتصال GRE على النظير B، تكون أحداث التسلسل عند إنشاء رسالة تنشيط الاتصال كما يلي:

1. يقوم النظير B بتوليد حزمة keepalive والتي تكون GRE مضمنة ثم تتم إعادة توجيهها إلى الواجهة العرقية حيث يتم تشفيرها وإرسالها إلى وجهة النفق، النظير A.
   
   الحزمة المرسلة من النظير B إلى النظير A:
   

   عنوان IP	رأس ESP	رأس GRE IP		رأس GRE	عنوان IP GRE المصدر أ DestinationB pt=0	مقطورة ESP
   المصدر B	الوجهة A	المصدر B	الوجهة A	pt=ip

   
   
   
2. يتم في النظير A فك تشفير GRE keepalive:
   

   رأس GRE IP		GRE	عنوان IP GRE المصدر أ DestinationB  pt=0
   المصدر B	الوجهة A	pt=ip

   
   
   مزيل الكبريت:
   

   عنوان IP		GRE
   المصدر أ	DestinationB	pt=0

   
   
   ثم يتم توجيه حزمة الاستجابة الداخلية ل GRE keepalive استنادا إلى عنوان الوجهة الخاص بها والذي هو النظير B. هذا يعني في النظير A، يتم توجيه الحزمة على الفور إلى خارج الواجهة المادية إلى النظير B. نظرا لأن النظير A يستخدم حماية النفق على واجهة النفق، فإن حزمة keepalive لا يتم تشفيرها.
   
   لذلك، الربط يرسل من النظير A إلى النظير B:
   

   عنوان IP		GRE
   المصدر أ	DestinationB	pt=0

   
   

   ملاحظة: لم يتم تشفير رسالة تنشيط الاتصال.

3. يتلقى النظير B الآن إستجابة GRE keepalive التي لا يتم تشفيرها على الواجهة المادية، ولكن بسبب خريطة التشفير التي تم تكوينها على الواجهة المادية، فإنها تتوقع حزمة مشفرة وبالتالي تقوم بإسقاطها.

لذلك، على الرغم من أن النظير A يستجيب إلى رسائل keepailves والموجه B يستلم الإجابات، فإنه لا يعالجها أبدا ويغير في نهاية المطاف بروتوكول الخط لواجهة النفق إلى حالة أسفل.

النتيجة:

تتسبب رسائل Keepalives الممكنة على النظير B في تغيير حالة النفق على النظير B إلى أعلى/أسفل.

السيناريو 2

التكوين:

• يستخدم النظير A خرائط التشفير.
• يستخدم النظير B حماية النفق.
• يتم تمكين رسائل تنشيط الاتصال على النظير B.
• يتم تشفير IPsec في وضع النفق.

في هذا السيناريو، نظرا لتكوين رسائل تنشيط الاتصال GRE على النظير B، تكون أحداث التسلسل عند إنشاء رسالة تنشيط الاتصال كما يلي:

1. يقوم النظير B بإنشاء حزمة keepalive تكون GRE مضمنة ثم مشفرة بواسطة حماية النفق على واجهة النفق ثم تمت إعادة توجيهها إلى الواجهة المادية.
   
   الحزمة المرسلة من النظير B إلى النظير A:
   

   عنوان IP	رأس ESP	رأس GRE IP	رأس GRE	عنوان IP GRE المصدر أ DestinationB pt=0	مقطورة ESP
   المصدر B	الوجهة A	المصدر B	الوجهة A	pt=ip

   
   
   
2. يتم في النظير A فك تشفير GRE keepalive:
   

   رأس GRE IP		GRE	عنوان IP GRE المصدر أ DestinationB  pt=0
   المصدر B	الوجهة A	pt=ip

   
   
   مزيل الكبريت:
   

   عنوان IP		GRE
   المصدر أ	DestinationB	pt=0

   
   
   ثم يتم توجيه حزمة الاستجابة الداخلية ل GRE keepalive استنادا إلى عنوان الوجهة الخاص بها والذي هو النظير B. وهذا يعني في النظير A، تتم إعادة توجيه الحزمة على الفور خارج الواجهة المادية إلى النظير B. ونظرا لأن النظير A يستخدم خرائط التشفير على الواجهة المادية، فإنه يقوم أولا بتشفير هذه الحزمة قبل إعادة توجيهها إليها.
   
   لذلك، الربط يرسل من النظير A إلى النظير B:
   

   عنوان IP		رأس ESP	عنوان IP GRE المصدر أ DestinationB pt=0	مقطورة ESP
   المصدر B	الوجهة A

   
   

   ملاحظة: يتم تشفير إستجابة keepalive.

3. يتلقى النظير B الآن إستجابة GRE keepalive مشفرة يتم إعادة توجيه الوجهة إلى واجهة النفق حيث يتم فك تشفيرها:
   

   عنوان IP		GRE
   المصدر أ	DestinationB	pt=0

   
   بما أن النموذج الأولي مضبوط على 0، فإن النظير ب يعرف أن هذه إستجابة بسيطة ويعالجها على هذا النحو.

النتيجة:

تحدد رسائل Keepalives الممكنة على النظير B بنجاح ما يمكن أن تكون حالة النفق بناء على توفر وجهة النفق.

السيناريو 3

التكوين:

• يستخدم كلا النظرين حماية النفق.
• يتم تمكين رسائل تنشيط الاتصال على النظير B.
• يتم تشفير IPsec في وضع النفق.

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

النتيجة:

تتسبب رسائل Keepalives الممكنة على النظير B في تغيير حالة النفق على النظير B إلى أعلى/أسفل.

الحل

في مثل هذه الحالات التي يجب فيها تشفير حزم GRE، هناك ثلاثة حلول ممكنة:

1. أستخدم خريطة تشفير على النظير A، وحماية النفق على النظير B، وتمكين رسائل keepalive على النظير B.
   
   ونظرا لأن هذا النوع من التكوين يتم إستخدامه في الغالب في مجموعات المحوري وري والمتكلم ونظرا لأنه في هذه المجموعات من المهم أن يكون المتحدثون على دراية بمراكز الوصول، فإن الحل هو إستخدام خريطة تشفير ديناميكية على المحوري (النظير A) وحماية النفق على المحوري (النظير B) وتمكين رسائل keepalive الخاصة بمجموعة GRE على المحولات. بهذه الطريقة، وعلى الرغم من أن واجهة نفق GRE على لوحة الوصل لا تزال قيد التشغيل، إلا أنه يتم فقد جار التوجيه والطرق عبر النفق ويمكن إنشاء المسار البديل. في مكبر الصوت، أن واقع أن النفق سقطت قارن يستطيع أطلقت هو أن يجلب مصل قارن ويستدعي مرة أخرى إلى الصرة (أو مسحاج تخديد آخر في الصرة)، بعد ذلك يؤسس توصيل جديد.
   
   
2. أستخدم شيئا آخر غير رسائل تنشيط الاتصال GRE لتحديد إمكانية وصول النظير.
   
   إذا تم تكوين كلا الموجهين باستخدام حماية النفق، فلا يمكن إستخدام محولات كبلات نفق GRE في أي من الاتجاهين. في هذه الحالة، يكون الخيار الوحيد هو إستخدام بروتوكول التوجيه أو آلية أخرى، مثل عامل ضمان الخدمة، لاكتشاف ما إذا كان النظير يمكن الوصول إليه أم لا.
   
   
3. إستخدام خرائط التشفير على النظير A والشريك B.
   
   إذا تم تكوين كلا الموجهين باستخدام خرائط التشفير، يمكن لرسائل keepalives للنفق المرور في كلا الاتجاهين ويمكن إيقاف واجهات نفق GRE في أي من الاتجاهين أو كليهما وتشغيل اتصال نسخ إحتياطي ليتم إجراؤه. هذا هو الخيار الأكثر مرونة.

معلومات ذات صلة

• RFC 1701، تضمين الموجّه العام (GRE)
• RFC 2890، امتدادات المفتاح ورقم التسلسل إلى GRE
• رسالة تنشيط اتصال نفق تضمين التوجيه العام (GRE)
• تجزئة IP وPMTUD
• نظرة عامة على آليات Keepalive على Cisco IOS
• الدعم الفني - Cisco Systems