كيفية عمل رسائل تنشيط الاتصال GRE
المحتويات
المقدمة
يقدم هذا المستند نظرة عامة على كيفية عمل تضمين التوجيه العام (GRE) keepalive.
المتطلبات الأساسية
المتطلبات
يجب أن يكون لدى قراء هذا المستند معرفة بالمواضيع التالية:
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
-
موجّه Cisco 7505
-
برنامج Cisco IOS®الذي يدعم GRE عبر IPSec
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.
الاصطلاحات
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
معلومات أساسية
تتيح ميزة GRE keepalive أمر الواجهة keepalive للأنفاق، وتسمح لك بتكوين رسائل keepalive لأنفاق GRE من نقطة إلى نقطة. أنت يستطيع شكلت keepalives مع ال keepalive أمر، واختياريا مع هو جديد امتداد.
توفر أنفاق GRE طريقة لتضمين الحزم العشوائية داخل بروتوكول النقل. كما أنها توفر بنية مصممة لتوفير الخدمات المطلوبة لتنفيذ أي مخطط تضمين قياسي من نقطة إلى نقطة. فيما يلي بعض ميزات أنفاق GRE:
-
تعمل أنفاق بروتوكول GRE على توفير شبكات محلية متعددة البروتوكولات عبر بنية أساسية أحادية البروتوكول.
-
توفر أنفاق GRE حلولا للشبكات التي تحتوي على بروتوكولات ذات عدد نقلات محدود.
-
تتصل أنفاق بروتوكول GRE بالشبكات الفرعية المتقطعة.
-
تتيح أنفاق GRE الشبكات الخاصة الظاهرية (VPN) عبر شبكات WAN.
ومع ذلك، في التنفيذ الحالي لأنفاق GRE، لا يتمتع النفق الذي تم تكوينه بالقدرة على إسقاط بروتوكول الخط لأي من نقطة نهاية النفق، إذا كان الطرف البعيد يتعذر الوصول إليه. وهكذا تكون حركة المرور المرسلة من النفق محصورة في حجرة سوداء، ولا يمكنها اتباع مسارات بديلة لأن النفق يبقى دائما صامدا.
هذا الموقف صحيح للأنفاق التي تعتمد على المسارات الثابتة أو بروتوكولات التوجيه التي تجمع المسارات للعثور على مسار إلى وجهة النفق. كما أنها صحيحة في الحالات التي تتبع فيها البيانات في مستوى التحكم مسارا مختلفا عن البيانات في مستوى البيانات.
آلية رسائل تنشيط النفق
يوفر هذا القسم وصفا وظيفيا لآلية رسائل تنشيط النفق بمساعدة مثال. يسرد هذا القسم أيضا عناصر البرامج التي تقوم هذه الميزة بتعديلها، ويناقش التأثير على الذاكرة والأداء.
الوصف الوظيفي
تتيح آلية رسائل تنشيط النفق الأمر الخاص بواجهات النفق وتمديده وتنفيذه، كما توفر القدرة على إسقاط بروتوكول خط النفق. رأيت ل كثير معلومة، الأمر وتشكيل قسم.
كما تتعامل آلية رسائل تنشيط النفق مع هذه المتطلبات الإضافية:
-
تعمل آلية رسائل تنشيط النفق حتى إذا كانت نقطة نهاية النفق البعيد لا تدعم رسائل تنشيط الاتصال.
-
تنشأ آلية رسائل تنشيط الاتصال عبر النفق رسائل تنشيط الاتصال.
-
تعالج آلية رسائل تنشيط الاتصال عبر النفق رسائل تنشيط الاتصال.
-
ترد آلية رسائل تنشيط النفق على حزم keepalive من الطرف البعيد، حتى عندما يكون بروتوكول خط النفق معطلا.
فيما يلي مثال على كيفية عمل آلية رسائل تنشيط الاتصال عبر النفق (راجع الشكل 1):
شكل 1 - مثال لآلية رسائل تنشيط الاتصال عبر النفق 
مردود
interface tunnel 0 interface tunnel 0 ip address 1.1.1.1 255.255.255.240 ip address 1.1.1.2 255.255.255.240 tunnel source 128.8.8.8 tunnel source 129.9.9.9 tunnel destination 129.9.9.9 tunnel destination 128.8.8.8 keepalive 5 4 keepalive 5 4 interface loopback 0 interface loopback 0 ip address 128.8.8.8 255.255.255.255 ip address 129.9.9.9 255.255.255.255
حزمة keepalive تنشأ من أ إلى ب
---outer IP header---' ---inner IP header---'
=============================================================
|IP | IP src | IP dst | GRE | IP | IP src | IP dst | GRE |
| |128.8.8.8|129.9.9.9|PT=IP| |129.9.9.9|128.8.8.8| PT=0|
=============================================================
----' ---'
GRE header GRE header
عندما تقوم بتمكين رسائل keepalives على نقطة نهاية النفق للموجه A، يقوم الموجه في كل فاصل ببناء رأس IP الداخلي. في نهاية الرأس، يقوم الموجه أيضا بإلحاق رأس GRE بنوع بروتوكول (PT) من 0، ولا يوجد حمل آخر. يرسل الموجه بعد ذلك الحزمة عبر النفق، والتي ينتج عنها عملية كبسلة مع رأس IP الخارجي، ورأس GRE مع نقطة IP. يزداد عداد رسائل تنشيط النفق بمقدار واحد. إذا كانت هناك طريقة للوصول إلى نقطة نهاية النفق الطرفي البعيد، ولم يتم إيقاف بروتوكول خط النفق بسبب أسباب أخرى، فإن الحزمة تصل إلى الموجه B. ثم تتم مطابقتها مقابل النفق 0، ويتم فك نسخها، وإعادة توجيهها إلى IP الوجهة، وهو مصدر النفق، الموجه A. عند الوصول إلى الموجه A، يتم فك كبسلة الحزمة مرة أخرى، ويتم التحقق من pt. إذا كانت نتيجة التحقق من pt هي 0، فإنها تشير إلى أن هذه حزمة keepalive. في مثل هذه الحالة، تتم إعادة تعيين عداد keepalive للنفق على 0، ويتم تجاهل الحزمة.
في حالة عدم إمكانية الوصول إلى الموجه B، يستمر الموجه A في إنشاء حزم keepalive وإرسالها مع حركة المرور العادية. إذا كان بروتوكول الخط معطلا، فإن رسائل keepalives لا تعود إلى الموجه A. لذلك، يستمر عداد keepalive في الزيادة. يبقى بروتوكول خط النفق لأعلى فقط طالما ظل عداد keepalive للنفق صفرا، أو أقل من قيمة تم تكوينها. إذا لم يكن هذا الشرط صحيحا، فإنه في المرة التالية التي تحاول فيها إرسال رسالة تنشيط إلى الموجه B، يتم إسقاط بروتوكول الخط، بمجرد أن يصل عداد keepalive إلى قيمة keepalive التي تم تكوينها. في حالة up/down، لا يقوم النفق بإعادة توجيه أو معالجة أي حركة مرور بعيدا عن حزم keepalive. ولكي يعمل هذا الإجراء بالنسبة لحزم keepalive فقط، يجب أن يكون النفق سهل التوجيه والاستقبال. لذلك يجب أن تكون خوارزمية بحث النفق ناجحة في جميع الحالات، ويجب أن تتجاهل حزم البيانات فقط إذا كان بروتوكول الخط معطلا. عند إستقبال حزمة keepalive، فإنها تعني أن نقطة نهاية النفق يمكن الوصول إليها مرة أخرى. ثم يتم إعادة تعيين عداد رسائل تنشيط النفق إلى 0، ويعود بروتوكول الخط.
الذاكرة وتأثير الأداء
لا تلقي هذه الميزة أي طلب إضافي تقريبا على ذاكرة نظام الموجه ومن المتوقع أن يظل الأداء غير متأثر بإضافتها. يتم التعامل مع الحزم keepalive على أنها حزم عادية، وبالتالي من الممكن إسقاطها في ظل ظروف حركة المرور العالية. في الوقت الحالي، يمكنك تغيير عدد المحاولات للتعامل مع هذه المشكلة. إذا تبين أن هذا غير كاف في نهاية المطاف، يمكنك وضع حزم keepalive محلية الصنع في قائمة انتظار عالية الأولوية للإرسال. يمكنك بعد ذلك تعيين قيمة TOS في رؤوس IP إلى قيمة أكثر ملاءمة، بخلاف القيمة الافتراضية أو المكونة.
اعتبارات التغليف
يتم تضمين الميزة في رمز نفق IP الأساسي وفي النظام الفرعي GRE. لذلك، يجب أن يكون متوفرا مع حزمة IP أساسية تحتوي على النفق والأنظمة الفرعية GRE.
الأوامر والتكوين
يخاطب هذا قسم ال keepalive أمر يمكن ومدد ب هذا سمة فقط تحت cisco بق id CSCuk26449. يتم توثيق أوامر أخرى في المقابلة بأدلة تكوين Cisco IOS ومرجعيات الأوامر. يتم تمكين الأمر [no] keepalive <period> <retry>وتوسيعه باستخدام معلمة ثانية، وهو متوفر في برنامج Cisco IOS الإصدار 12.2(8)T والإصدارات الأحدث. كما تم إرساله بموجب معرف تصحيح الأخطاء من Cisco CSCuk29980 و CSCuk29983 إلى برنامج Cisco IOS الإصدار 12.1E و 12.2S.
بما أن keepalive هو أمر تكوين واجهة الذي يمكن keepalives على واجهة النفق، فإن رسائل keepalive فقط لوضع GRE/IP مدعومة حاليا. المعلمة الثانية من الأمر ( retries ) مرئية ومتاحة فقط لواجهات النفق. يمكن أن تتراوح قيم المعلمة الأولى من 1 إلى 32767. عندما تكون القيمة 0، فإنها تعادل "no keepalive". تحتوي هذه المعلمة على قيمة افتراضية مقدارها 10. يمكن أن تتراوح قيم المعلمة الثانية من 1 إلى 255، وهي تشير إلى عدد رسائل keepalives التي يتم إرسالها ولكن لا يتم إرجاعها، والتي تقوم بعدها واجهة النفق بسحب بروتوكول الخط إلى أسفل. يتم تعطيل رسائل Keepalives على واجهات النفق بشكل افتراضي.
نموذج للمخرجات وتنسيقات الشاشة
يقدم هذا القسم نماذج للمخرجات.
cisco-7505#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
cisco-7505(config)#interface tunnel 1
cisco-7505(config-if)#?
access-expression Build a bridge boolean access expression
……………
keepalive Enable keepalive <=====
……………
timeout Define timeout values for this interface
cisco-7505(config-if)#keepalive ? <=====
<0-32767> Keepalive period (default 10 seconds)
cisco-7505(config-if)#keepalive 5 ? <=====
<1-255> Keepalive retries (default 3 times)
cisco-7505(config-if)#keepalive 5 4 <=====
cisco-7505(config-if)#end
cisco-7505#show interfaces tunnel 1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.1.1.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (5 sec), retries 4 <=====
Tunnel source 9.2.2.1, destination 6.6.6.2
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TOS 0xF, Tunnel TTL 128
Checksumming of packets disabled, fast tunneling enabled
Last input never, output 00:57:05, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 1 drops; input queue 0/75, 0 drops
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
3 packets output, 1860 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
التعليقات