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

المقدمة

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

أنفاق GRE

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

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

عادة، تظهر واجهة نفق GRE بمجرد تكوينها وتظل مستمرة طالما كان هناك عنوان مصدر نفق صالح أو واجهة قيد التشغيل. كما يجب أن يكون عنوان 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 (رغم أنه يمكن أن يكون بروتوكول آخر مثل Decnet، أو Internetwork Packet Exchange (IPX)، أو AppleTalk).

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

عنوان IP

رأس TCP

Telnet

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

رأس GRE IP

GRE

عنوان IP رأس TCP Telnet

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

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

طراز GRE Keepalives:

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

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

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

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

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

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

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

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

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

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

ملاحظة: بشكل عام، لا يمكن أن تعمل رسائل تنشيط الاتصال عبر النفق عند إستخدام VRF على واجهة النفق و fVRF ('tunnel vrf ...و iVRF ('ip vrf forwarding ...|على واجهة النفق) غير متطابقة. هذا مهم على نقطة نهاية النفق أن "يعكس" ال 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 بتنفيذ الخطوات التالية:

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

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

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

   رأس GRE IP		GRE	عنوان IP GRE المصدر:192.168.1.2 الوجهة:192.168.1.1  pt=0
   المصدر: 192-168-1-1	الوجهة: 192.168.1.2	pt=ip

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

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

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

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

ملاحظة: لا يقوم النفق بإعادة توجيه أو معالجة أي حركة مرور بيانات في حالة الارتفاع/الهبوط. ومع ذلك، فإنه يستمر في إرسال حزم 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 keepalives شكلت على النظير B، فإن أحداث التسلسل عندما يتم إنشاء keepalive هي كما يلي:

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