تحديد التأثيرات التي تؤثر على حالات واجهة نفق GRE

المقدمة

يصف هذا المستند الحالات المختلفة التي يمكن أن تؤثر على حالة واجهة نفق تضمين التوجيه العام (GRE).

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

تم تصميم أنفاق GRE لتكون عديمة الحالة تمامًا. وهذا يعني أن كل نقطة نهاية نفق لا تحتفظ بأي معلومات حول حالة نقطة نهاية النفق البعيد أو توفرها.

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

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

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

وهذا يسمح بتثبيت مسار ثابت بديل (عائم) أو للتوجيه المستند إلى السياسة (PBR) من أجل تحديد قفزة تالية بديلة أو واجهة.

أيضا، هناك تطبيقات أخرى أن يطلق عندما تغير قارن حالة؛ على سبيل المثال، "واجهة النسخ الاحتياطي<b-interface>".

أربع حالات أنفاق مختلفة

هناك أربع حالات محتملة توجد فيها واجهة نفق GRE:

1. Up/up - يشير هذا إلى أن النفق يعمل بكامل طاقته ويمرر حركة المرور. فهو يعمل من الناحية الإدارية كما أن بروتوكوله قيد التشغيل كذلك.
2. Administratively down/down - يشير هذا إلى أن الواجهة قد تم إيقاف تشغيلها إداريًا.
3. Up/down - يشير هذا إلى أنه على الرغم من أن النفق يعمل إداريًا، إلا أن شيئًا ما يتسبب في تعطل بروتوكول الخط على الواجهة.
4. Reset/down - عادة ما تكون هذه حالة عابرة عند إعادة تعيين النفق بواسطة برنامج. يحدث هذا عادة عندما يتم تكوين النفق بشكل غير صحيح باستخدام خادم Hop (NHS) التالي الذي هو عنوان IP الخاص به.

عند إنشاء واجهة نفق لأول مرة دون تطبيق أي تكوين آخر عليها، لا يتم إغلاق الواجهة افتراضيًا:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 40 bytes
!
interface Tunnel1
 no ip address
end

في هذه الحالة، تكون الواجهة دائمًا up/down:

Router(config-if)#do show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         172.16.52.1     YES NVRAM  administratively down down    
GigabitEthernet0/1         10.36.128.49    YES NVRAM  down                  down    
GigabitEthernet0/2         unassigned      YES NVRAM  down                  down    
GigabitEthernet0/3         unassigned      YES NVRAM  down                  down    
Loopback1                  192.168.2.1     YES NVRAM  up                    up      
Tunnel1                    unassigned      YES unset  up                    down

وهذا بسبب تمكين الواجهة إداريًا، ولكن نظرًا لعدم وجود مصدر نفق أو وجهة نفق، فإن بروتوكول الخط متوقف.

ولجعل هذه الواجهة في الحالة up/up، يجب تكوين مصدر نفق ووجهة نفق صالحين:

Router#show run interface tunnel  1
Building configuration...

Current configuration : 113 bytes
!
interface Tunnel1
 ip address 10.1.1.1 255.255.255.0
 tunnel source Loopback1
 tunnel destination 10.0.0.1
end

Router#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         172.16.52.1     YES NVRAM  up                    up      
GigabitEthernet0/1         10.36.128.49    YES NVRAM  down                  down    
GigabitEthernet0/2         unassigned      YES NVRAM  down                  down    
GigabitEthernet0/3         unassigned      YES NVRAM  down                  down    
Loopback0                  unassigned      YES unset  up                    up      
Loopback1                  192.168.2.1     YES manual up                    up      
Tunnel1                    10.1.1.1         YES manual up                    up      

يوضح التسلسل السابق ما يلي:

• يتكون مصدر النفق الصالح من أي واجهة هي نفسها في الحالة up/up ولها عنوان IP مُكون عليها.
• على سبيل المثال، إذا تم تغيير مصدر النفق إلى Loopback0، فستتعطل واجهة النفق على الرغم من أن Loopback0 في حالة up/up:
  
  

  Router(config)#interface tunnel 1
  Router(config-if)#tunnel source loopback 0
  Router(config-if)#
  *Sep  6 19:51:31.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

• واجهة النفق الصالحة هي وجهة قابلة للتوجيه. ومع ذلك، ليس من الضروري أن يكون الوصول إليه ممكنًا، وهو ما يمكن ملاحظته من خلال اختبار الاتصال هذا:
  
  

  Router#show ip route 10.0.0.1
  % Network not in table
  Router#show ip route | inc 0.0.0.0
  Gateway of last resort is 172.16.52.100 to network 0.0.0.0
  S*    0.0.0.0/0 [1/0] via 172.16.52.100
  Router#ping 10.0.0.1 
  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
  .....
  Success rate is 0 percent (0/5)

حتى الآن، تم تكوين النفق كنفق GRE من نقطة إلى نقطة (P2P)، وهو الأمر الافتراضي.

إذا تم تغيير هذا النفق إلى نفق GRE متعدد النقاط (mGRE)، فإن كل المطلوب لحالة up هو مصدر نفق صالح. 

Router#show run interface tunnel 1
Building configuration...

Current configuration : 129 bytes
!
interface Tunnel1
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 tunnel source Loopback1
 tunnel mode gre multipoint
end

Router#show ip interface brief | include Tunnel
Tunnel1                    10.1.1.1         YES manual up                    up    

في أي وقت، إذا كانت واجهة النفق متوقفة إداريًا، ينتقل النفق على الفور إلى حالة Administratively down/down:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 50 bytes
!
interface Tunnel1
 no ip address
shutdown
end

Router#show ip interface brief | include Tunnel
Tunnel1                    unassigned      YES unset  administratively down down    

حالة النفق P2P GRE

عادة ما تظهر واجهة نفق P2P GRE بمجرد تكوينها باستخدام عنوان مصدر نفق صالح أو واجهة قيد التشغيل وعنوان IP لوجهة النفق الذي يكون موجها (معروض مسبقا).

تعطُل بروتوكول الخط محليًا على الموجّه

في ظل الظروف العادية، هناك ثلاثة أسباب فقط ليكون نفق GRE في حالة up/down:  

• لا يوجد مسار، والذي يتضمن المسار الافتراضي، لعنوان وجهة النفق.
• الواجهة التي تُثبّت مصدر النفق معطلة.
• يكون المسار إلى عنوان وجهة النفق من خلال النفق نفسه، مما يؤدي إلى حدوث تكرار.

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

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

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

لا تغطي القواعد الأساسية الحالة التي يتم فيها إعادة توجيه حزم GRE النفقية بنجاح إلا أنها تفقد قبل وصولها إلى الطرف الآخر من النفق.

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

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

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

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

ملاحظة: تكون رسائل تنشيط اتصال نفق GRE صالحة فقط ولها تأثير على أنفاق P2P GRE؛ وهي غير صالحة وليس لها أي تأثير على أنفاق mGRE.

أنفاق GRE مع حماية الأنفاق

في الإصدار 15.4(3)M/15.4(3)S من برنامج Cisco IOS^® والإصدارات الأحدث، تتبع حالة بروتوكول سطر سطر بروتوكول GRE حالة اقتران أمان IPsec (SA). لذلك، يمكن أن يبقى بروتوكول الخط معطلا حتى يتم إنشاء جلسة عمل IPsec بالكامل.

تم الالتزام بهذا الأمر بواسطة مُعرف خطأ Cisco CSCum34057 (وكانت المحاولة المبدئية بواسطة مُعرف خطأ Cisco CSCuj29996 ثم تم دعمه بواسطة مُعرف خطأ Cisco CSCuj99287).

واجهات أنفاق GRE متعددة النقاط (mGRE)

بالنسبة لواجهات نفق MGRE، لا تنطبق بعض عمليات التحقق السابقة لأنفاق P2P (نظرا لعدم وجود وجهة نفق ثابتة).

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

• واجهة مصدر النفق في حالة توقف.
• إن مكنت القارن دولة تحكم سمة يكون ل Dynamic Multipoint VPN (DMVPN) ولا NHS يستجيب، بعد ذلك الخط بروتوكول وضعت في حالة أسفل.
• للحصول على تفاصيل حول ميزة التحكم في حالة الواجهة، راجع دليل تكوين مراقبة واستعادة صحة نفق DMVPN.

التبعيات على حالة التكرار

عند تكوين عنوان IP لمصدر النفق كعنوان IP متكرر على سبيل المثال، عنوان IP بروتوكول جهاز التوجيه الاحتياطي الفعّال (HSRP VIP)، فإن حالة واجهة النفق تتبع حالة التكرار.

وهذا يضيف تحققا آخر يحافظ على واجهات النفق في حالة أسفل بروتوكول الخط حتى تتغير حالة التكرار إلى ACTIVE.

في هذا المثال، يتسبب التكوين الافتراضي ipc zone default الذي تم تكوينه بشكل خاطئ في أن يكون التكرار في حالة تفاوض (NEGOTIATION) ويحتفظ بواجهات النفق هذه في حالة توقف:

Router#show redundancy state
       my state = 3  -NEGOTIATION 
     peer state = 1  -DISABLED 
           Mode = Simplex
        Unit ID = 0

     Maintenance Mode = Disabled
    Manual Swact = disabled (system is simplex (no peer unit))
 Communications = Down      Reason: Simplex mode

   client count = 16
 client_notification_TMR = 60000 milliseconds
           RF debug mask = 0x0   

Router#show interface tunnel100
Tunnel100 is up, line protocol is down 
  Hardware is Tunnel
  Internet address is 172.16.1.100/24
  MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 10.122.162.254 (GigabitEthernet0/1)
   Tunnel Subblocks:
      src-track:
         Tunnel100 source tracking subblock associated with GigabitEthernet0/1
          Set of tunnels with source GigabitEthernet0/1, 2 members (includes
          iterators), on interface <OK>
  Tunnel protocol/transport multi-GRE/IP
<SNIP>

استكشاف الأخطاء وإصلاحها

بالإضافة إلى الأسباب الموضحة مسبقا، يمكن رؤية تقييم حالة خط النفق لسبب النفق إلى أسفل باستخدام الأمر show tunnel interface tunnel x hidden:

Router#show tunnel interface tunnel 100
Tunnel100
   Mode:multi-GRE/IP, Destination UNKNOWN, Source GigabitEthernet0/1
   Application ID 1: unspecified
   Tunnel Subblocks:
      src-track:
         Tunnel100 source tracking subblock associated with GigabitEthernet0/1
          Set of tunnels with source GigabitEthernet0/1, 2 members (includes
          iterators), on interface <OK>
   Linestate - current down
   Internal linestate - current down, evaluated down - interface not up
   Tunnel Source Flags: Local   
   Transport IPv4 Header DF bit cleared
   OCE: IP tunnel decap 
   Provider: interface Tu100, prot 47   
     Performs protocol check [47] 
     Performs Address save check 
     Protocol Handler: GRE: key 0x64, opt 0x2000
       ptype: ipv4 [ipv4 dispatcher: drop] 
       ptype: ipv6 [ipv6 dispatcher: drop] 
       ptype: mpls [mpls dispatcher: drop] 
       ptype: otv [mpls dispatcher: drop] 
       ptype: generic [mpls dispatcher: drop] 

ملاحظة: هناك تحسين مفتوح لجعل سبب أسفل النفق أكثر وضوحا للإشارة إلى أنه يرجع إلى حالة التكرار لأنه غير نشط. يتم تعقب ذلك بواسطة معرف الخطأ من Cisco CSCuq31060.

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

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