أستكشاف أخطاء المرحلة الثانية من DMVPN وإصلاحها
المقدمة
يوضح هذا المستند كيفية أستكشاف أخطاء نفق DMVPN المتصل بالصوت أثناء المرحلة 2 وإصلاحها عند عدم تثبيته.
المتطلبات الأساسية
المتطلبات
cisco يوصي أن يتلقى أنت معرفة على التالي موضوع:
- الشبكة الخاصة الظاهرية متعددة النقاط الديناميكية (DMVPN)
- بروتوكولات IKE/IPSec
- بروتوكول تحليل الخطوة (Hop) التالية (NHRP)
المكونات المستخدمة
يستند هذا المستند إلى إصدار البرنامج هذا:
- Cisco CSR1000V (VXE) - الإصدار 17.03.08
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يصف هذا المستند كيفية تكوين أدوات أستكشاف الأخطاء وإصلاحها المختلفة واستخدامها على مشكلة DMVPN شائعة. المشكلة failed تفاوض من المرحلة 2 DMVPN نفق، حيث المصدر تكلم، ال DMVPN دولة ظهرت مع ال يصح غير بث multi-access (NBMA)/نفق يخطط إلى الغاية يتكلم. ومع ذلك، يتم عرض تعيين غير صحيح على الوجهة.
خلفية نظرية
ومن المهم فهم كيفية إنشاء أنفاق يجري الاتصال بها عند إعداد المرحلة الثانية من شبكة DMVPN. يقدم هذا القسم ملخصا نظريا موجزا لعملية NHRP خلال هذه المرحلة.
في المرحلة 2 من DMVPN، يمكنك بناء أنفاق ديناميكية يتم التحدث بها عند الطلب. وهذا ممكن لأنه، على جميع الأجهزة الموجودة داخل سحابة DMVPN (الموزع والنقاط الفرعية)، يتغير وضع واجهة النفق إلى النقطة المتعددة لتضمين التوجيه العام (GRE). أحد الميزات الرئيسية لهذه المرحلة هو أن الصرة لا يتم فهمها كالخطوة التالية بواسطة الأجهزة الأخرى. بدلا من ذلك، فإن كل مجموعة فرعية تحتوي على معلومات التوجيه لبعضها البعض. عند إنشاء نفق تحدث بالمحادثة في المرحلة 2، يتم تشغيل عملية NHRP حيث تتعرف الخوادم على المعلومات المتعلقة بالأسلاك الأخرى، وتقوم بوضع خريطة بين عناوين NBMA وعناوين IP الخاصة بالنفق.
تسرد الخطوات التالية كيفية تشغيل عملية تحليل NHRP:
- عندما يحاول المصدر الذي يتحدث الوصول إلى شبكة LAN الخاصة بالوجهة التي يتم التحدث عنها، فإنه يقوم ببحث عن المسار يطلق رسالة طلب الحل للحصول على عنوان NBMA الخاص بالوجهة التي يتم التحدث بها. المصدر تحدث أرسل هذا رسالة أولي إلى الصرة.
-
يستلم الصرة طلب القرار ويعيده إلى الوجهة التي تحدث فيها.
-
ترسل الوجهة التي تم التحدث بها رد الحل إلى المصدر الذي تم التحدث عنه. إذا كان لتكوين النفق ملف تعريف IPSec مرتبط:
-
تم تأجيل عملية تحليل NHRP حتى يمكن إنشاء بروتوكولات IKE/IPSec.
- تبدأ الوجهة محادثات إنشاء أنفاق IKE/IPSec.
-
بعد ذلك، يتم إستئناف عملية NHRP وترسل الوجهة التي تم التحدث بها رد الحل إلى المصدر الذي تحدث باستخدام نفق IPSec كطريقة نقل.
-
تدفق رسائل NHRP بين الفروع في المرحلة 2
ملاحظة: قبل أن تبدأ عملية الحل، يجب أن تكون كل الحروف الصغيرة مسجلة مسبقا في الصرة.
المخطط
يوضح هذا المخطط المخطط المخطط المخطط المستخدم للسيناريو:
الرسم التخطيطي للشبكة وشبكات IP الفرعية المستخدمة
خطوات أستكشاف الأخطاء وإصلاحها
في هذا السيناريو، لم يتم إنشاء النفق الذي يتم التحدث إليه بين Talk1 و Talk2، مما يؤثر على الاتصال بين مواردهما المحلية (الممثلة بواجهات الاسترجاع) حيث أنهما غير قادرين على الوصول إلى بعضهما البعض.
SPOKE1#ping 192.168.2.2 source loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
التحقق الأولي
عند مواجهة مثل هذا السيناريو، من المهم البدء بالتحقق من تكوين النفق والتأكد من أن كلا الجهازين يحتويان على القيم الصحيحة داخله. لمراجعة تكوين النفق، قم بتشغيل الأمر show running-config interface tunnel<id>.
تم إجراء تكوين نفق واحد:
SPOKE1#show running-config interface tunnel10
Building configuration...
Current configuration : 341 bytes
!
interface Tunnel10
ip address 10.10.10.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 10.10.10.10 172.20.10.10
ip nhrp map multicast 172.20.10.10
ip nhrp network-id 10
ip nhrp nhs 10.10.10.10
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel protection IPSEC profile IPSEC_Profile_1
end
تكوين نفق Talk 2:
SPOKE2#show running-config interface tunnel10
Building configuration...
Current configuration : 341 bytes
!
interface Tunnel10
ip address 10.10.10.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 10.10.10.10 172.20.10.10
ip nhrp map multicast 172.20.10.10
ip nhrp network-id 10
ip nhrp nhs 10.10.10.10
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel protection IPSEC profile IPSEC_Profile_1
end
في التكوين الذي تحتاج إليه للتحقق من صحة التعيين إلى الموزع، تتطابق سلسلة مصادقة NHRP بين الأجهزة، ولكل من الخادمين نفس مرحلة DMVPN التي تم تكوينها، وإذا تم إستخدام حماية IPSec، فتحقق من تطبيق تكوين التشفير الصحيح.
إذا كان التكوين صحيحا ويتضمن حماية IPSec، فمن الضروري التحقق من أن بروتوكولات IKE و IPSec تعمل بشكل صحيح. وذلك لأن NHRP يستخدم نفق IPSec كطريقة نقل للتفاوض الكامل. للتحقق من حالة بروتوكولات IKE/IPSec التي تشغل الأمر show crypto IPsec sa peer x.x.x (حيث يكون x.x.x.x هو عنوان IP ل NBMA الخاص بالكلام الذي تحاول إنشاء النفق به).
ملاحظة: للتحقق من تشغيل نفق IPSec، يجب أن يحتوي قسم حمولة أمان التضمين الوارد والصادر (ESP) على معلومات النفق (SPI، ومجموعة التحويل، وما إلى ذلك). يجب أن تتطابق كل القيم المعروضة في هذا المقطع مع كلا النهايتين.
ملاحظة: في حالة تحديد أي مشاكل مع IKE/IPSec، يجب أن يركز أستكشاف الأخطاء وإصلاحها على هذه البروتوكولات.
حالة نفق IKE/IPSec على Talk1:
SPOKE1#show crypto IPSEC sa peer 172.22.200.2
interface: Tunnel10
Crypto map tag: Tunnel10-head-0, local addr 172.21.100.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.21.100.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.22.200.2/255.255.255.255/47/0)
current_peer 172.22.200.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.21.100.1, remote crypto endpt.: 172.22.200.2
plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x6F6BF94A(1869347146)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x84502A19(2219846169)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2049, flow_id: CSR:49, sibling_flags FFFFFFFF80000008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4608000/28716)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x6F6BF94A(1869347146)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2050, flow_id: CSR:50, sibling_flags FFFFFFFF80000008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4608000/28716)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
حالة نفق IKE/IPSec على Talk2:
SPOKE2#show crypto IPSEC sa peer 172.21.100.1
interface: Tunnel10
Crypto map tag: Tunnel10-head-0, local addr 172.22.200.2
protected vrf: (none)
local ident (addr/mask/prot/port): (172.22.200.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.21.100.1/255.255.255.255/47/0)
current_peer 172.21.100.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 16, #pkts encrypt: 16, #pkts digest: 16
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.22.200.2, remote crypto endpt.: 172.21.100.1
plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x84502A19(2219846169)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x6F6BF94A(1869347146)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2045, flow_id: CSR:45, sibling_flags FFFFFFFF80004008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4608000/28523)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x84502A19(2219846169)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2046, flow_id: CSR:46, sibling_flags FFFFFFFF80004008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4607998/28523)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
تظهر المخرجات أن نفق IPSec قيد التشغيل على كلا البابين، ولكن، Talk2 يعرض الحزم المشفرة (عمليات التشفير) ولكن لا توجد حزم (عمليات فك تشفير). في الوقت نفسه، لا يعرض Talk1 أي حزم تتدفق عبر نفق IPSec. وهذا يشير إلى أن المشكلة يمكن أن تكون على بروتوكول NHRP.
أدوات استكشاف الأخطاء وإصلاحها
بعد إجراء التحقق الأولي من الصحة ودعم التكوين وبروتوكولات IKE/IPSec (إذا لزم الأمر) لا تتسبب في مشكلة الاتصال، يمكنك إستخدام الأدوات المقدمة على هذا القسم لمتابعة أستكشاف الأخطاء وإصلاحها.
أوامر مفيدة
يمنحك الأمر show dmvpn interface tunnel<id>معلومات الجلسة الخاصة ب DMVPN (عناوين IP للنفق/NBMA، حالة النفق، وقت up/down وسمة). يمكنك إستخدام الكلمة الأساسية detail لإظهار التفاصيل من جلسة/مقبس التشفير. ومن المهم أن نذكر أن حالة النفق يجب أن تتطابق على كلا الغرضين.
تحدث 1 عرض نفق واجهة dmvpn<id>إنتاج:
SPOKE1#show dmvpn interface tunnel10
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override, B - BGP
C - CTS Capable, I2 - Temporary
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel10, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
2 172.20.10.10 10.10.10.2 UP 00:00:51 I2
10.10.10.10 UP 02:53:27 S
تحدث 2 عرض نفق واجهة dmvpn<ID>إخراج:
SPOKE2#show dmvpn interface tunnel10
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override, B - BGP
C - CTS Capable, I2 - Temporary
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel10, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.21.100.1 10.10.10.1 UP 00:03:53 D
1 172.20.10.10 10.10.10.10 UP 02:59:14 S
تظهر المخرجات على كل جهاز معلومات مختلفة لكل محادثة. في جدول Talk1، يمكنك أن ترى أن إدخال Talk 2 لا يتضمن عنوان IP الصحيح ل NBMA، وتظهر السمة غير كاملة (I2). من ناحية أخرى، يوضح جدول Talk2 الخريطة الصحيحة (عناوين IP الخاصة ب NBMA/Tunnel) والحالة على أنها تشير إلى أن النفق تم التفاوض عليه بالكامل.
يمكن أن تكون الأوامر التالية مفيدة أثناء عملية أستكشاف الأخطاء وإصلاحها:
- عرض ip nhrp: عرض معلومات تعيين NHRP
- عرض ip nhrp حركة مرور قارن tunnel10: يعرض إحصائيات حركة مرور NHRP
ملاحظة: لمواصفات الأمر (الصيغة، الوصف، الكلمات الأساسية، مثال)، يرجى مراجعة مرجع الأوامر: مرجع أمر أمان Cisco IOS: أوامر S إلى Z
تصحيح الأخطاء
بعد التحقق من المعلومات السابقة وتأكيد أن النفق يواجه مشاكل في التفاوض، من الضروري تمكين تصحيح الأخطاء لمراقبة كيفية تبادل حزم NHRP. يجب تمكين تصحيح الأخطاء التالي على جميع الأجهزة المعنية:
- NBMA x.x.x.x (حيث يكون x.x.x.x هو عنوان IP الخاص بالجهاز البعيد) الخاص ب debug dmvpn.
- debug dmvpn all: يقوم هذا الأمر بتمكين أوامر تصحيح الأخطاء ISAKMP و IKEv2 و IPsec و DMVPN و NHRP.
تلميح: يوصى باستخدام الأمر النظير في كل مرة تقوم فيها بتمكين تصحيح الأخطاء حتى تتمكن من رؤية التفاوض حول هذا النفق المحدد.
لرؤية تدفق NHRP الكامل، تم إستخدام أوامر تصحيح الأخطاء التالية على كل جهاز:
تم التحدث 1
debug dmvpn condition peer NBMA 172.22.200.2
debug dmvpn condition peer NBMA 172.20.10.10
debug dmvpn all all
موزع
debug dmvpn condition peer NBMA 172.21.100.1
debug dmvpn condition peer NBMA 172.22.200.2
debug dmvpn all all
نطق 2
debug dmvpn condition peer NBMA 172.21.100.1
debug dmvpn condition peer NBMA 172.20.10.10
debug dmvpn all all
ملاحظة: يجب تمكين تصحيح الأخطاء وتجميعها في آن واحد على جميع الأجهزة المعنية.
يتم عرض تصحيح الأخطاء الممكنة على جميع الأجهزة باستخدام الأمر show debug:
ROUTER#show debug
IOSXE Conditional Debug Configs:
Conditional Debug Global State: Stop
IOSXE Packet Tracing Configs:
Packet Infra debugs:
Ip Address Port
------------------------------------------------------|----------
NHRP:
NHRP protocol debugging is on
NHRP activity debugging is on
NHRP detail debugging is on
NHRP extension processing debugging is on
NHRP cache operations debugging is on
NHRP routing debugging is on
NHRP rate limiting debugging is on
NHRP errors debugging is on
NHRP events debugging is on
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
Crypto ISAKMP Error debugging is on
Crypto IPSEC debugging is on
Crypto IPSEC Error debugging is on
Crypto secure socket events debugging is on
IKEV2:
IKEv2 error debugging is on
IKEv2 default debugging is on
IKEv2 packet debugging is on
IKEv2 packet hexdump debugging is on
IKEv2 internal debugging is on
Tunnel Protection Debugs:
Generic Tunnel Protection debugging is on
DMVPN:
DMVPN error debugging is on
DMVPN UP/DOWN event debugging is on
DMVPN detail debugging is on
DMVPN packet debugging is on
DMVPN all level debugging is on
بعد تجميع جميع تصحيح الأخطاء، يجب أن تبدأ تحليل تصحيح الأخطاء على المصدر الذي تم التحدث عنه (Talk1)، وهذا يسمح لك بتتبع التفاوض من البداية.
إخراج تصحيح الأخطاء TALK1:
-------------------- [IKE/IPSEC DEBUG OUTPUTS OMITTED]--------------------
*Feb 1 01:31:34.657: ISAKMP: (1016):Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE
*Feb 1 01:31:34.657: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Feb 1 01:31:34.657: IPSEC(key_engine_enable_outbound): rec'd enable notify from ISAKMP
*Feb 1 01:31:34.657: CRYPTO_SS(TUNNEL SEC): Sending MTU Changed message
*Feb 1 01:31:34.661: IPSEC-IFC MGRE/Tu10(172.21.100.1/172.22.200.2): Got MTU message mtu 1458
*Feb 1 01:31:34.661: IPSEC-IFC MGRE/Tu10(172.21.100.1/172.22.200.2): connection lookup returned 80007F2B7055F5A8
*Feb 1 01:31:34.662: CRYPTO_SS(TUNNEL SEC): Sending Socket Up message
*Feb 1 01:31:34.662: IPSEC-IFC MGRE/Tu10(172.21.100.1/172.22.200.2): connection lookup returned 80007F2B7055F5A8
*Feb 1 01:31:34.662: IPSEC-IFC MGRE/Tu10(172.21.100.1/172.22.200.2): tunnel_protection_socket_up
*Feb 1 01:31:34.662: IPSEC-IFC MGRE/Tu10(172.21.100.1/172.22.200.2): Signalling NHRP
*Feb 1 01:31:36.428: NHRP: Checking for delayed event NULL/10.10.10.2 on list (Tunnel10 vrf: global(0x0))
*Feb 1 01:31:36.429: NHRP: No delayed event node found.
*Feb 1 01:31:36.429: NHRP: There is no VPE Extension to construct for the request
*Feb 1 01:31:36.429: NHRP: Sending NHRP Resolution Request for dest: 10.10.10.2 to nexthop: 10.10.10.2 using our src: 10.10.10.1 vrf: global(0x0)
*Feb 1 01:31:36.429: NHRP: Attempting to send packet through interface Tunnel10 via DEST dst 10.10.10.2
*Feb 1 01:31:36.429: NHRP-DETAIL: First hop route lookup for 10.10.10.2 yielded 10.10.10.2, Tunnel10
*Feb 1 01:31:36.429: NHRP: Send Resolution Request via Tunnel10 vrf: global(0x0), packet size: 85
*Feb 1 01:31:36.429: src: 10.10.10.1, dst: 10.10.10.2
*Feb 1 01:31:36.429: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 1 01:31:36.429: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 1 01:31:36.429: pktsz: 85 extoff: 52
*Feb 1 01:31:36.429: (M) flags: "router auth src-stable nat ", reqid: 10
*Feb 1 01:31:36.429: src NBMA: 172.21.100.1
*Feb 1 01:31:36.429: src protocol: 10.10.10.1, dst protocol: 10.10.10.2
*Feb 1 01:31:36.429: (C-1) code: no error(0), flags: none
*Feb 1 01:31:36.429: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:36.429: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
*Feb 1 01:31:36.429: Responder Address Extension(3):
*Feb 1 01:31:36.429: Forward Transit NHS Record Extension(4):
*Feb 1 01:31:36.429: Reverse Transit NHS Record Extension(5):
*Feb 1 01:31:36.429: Authentication Extension(7):
*Feb 1 01:31:36.429: type:Cleartext(1), data:DMVPN
*Feb 1 01:31:36.429: NAT address Extension(9):
*Feb 1 01:31:36.430: NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 172.20.10.10
*Feb 1 01:31:36.430: NHRP: 109 bytes out Tunnel10
*Feb 1 01:31:36.430: NHRP-RATE: Retransmitting Resolution Request for 10.10.10.2, reqid 10, (retrans ivl 4 sec)
*Feb 1 01:31:39.816: NHRP: Checking for delayed event NULL/10.10.10.2 on list (Tunnel10 vrf: global(0x0))
*Feb 1 01:31:39.816: NHRP: No delayed event node found.
*Feb 1 01:31:39.816: NHRP: There is no VPE Extension to construct for the request
*Feb 1 01:31:39.817: NHRP: Sending NHRP Resolution Request for dest: 10.10.10.2 to nexthop: 10.10.10.2 using our src: 10.10.10.1 vrf: global(0x0)
*Feb 1 01:31:39.817: NHRP: Attempting to send packet through interface Tunnel10 via DEST dst 10.10.10.2
*Feb 1 01:31:39.817: NHRP-DETAIL: First hop route lookup for 10.10.10.2 yielded 10.10.10.2, Tunnel10
*Feb 1 01:31:39.817: NHRP: Send Resolution Request via Tunnel10 vrf: global(0x0), packet size: 85
*Feb 1 01:31:39.817: src: 10.10.10.1, dst: 10.10.10.2
*Feb 1 01:31:39.817: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 1 01:31:39.817: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 1 01:31:39.817: pktsz: 85 extoff: 52
*Feb 1 01:31:39.817: (M) flags: "router auth src-stable nat ", reqid: 10
*Feb 1 01:31:39.817: src NBMA: 172.21.100.1
*Feb 1 01:31:39.817: src protocol: 10.10.10.1, dst protocol: 10.10.10.2
*Feb 1 01:31:39.817: (C-1) code: no error(0), flags: none
*Feb 1 01:31:39.817: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:39.817: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
*Feb 1 01:31:39.817: Responder Address Extension(3):
*Feb 1 01:31:39.817: Forward Transit NHS Record Extension(4):
*Feb 1 01:31:39.817: Reverse Transit NHS Record Extension(5):
*Feb 1 01:31:39.817: Authentication Extension(7):
*Feb 1 01:31:39.817: type:Cleartext(1), data:DMVPN
*Feb 1 01:31:39.817: NAT address Extension(9):
*Feb 1 01:31:39.817: NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 172.20.10.10
*Feb 1 01:31:39.818: NHRP: 109 bytes out Tunnel10
*Feb 1 01:31:39.818: NHRP-RATE: Retransmitting Resolution Request for 10.10.10.2, reqid 10, (retrans ivl 8 sec)
*Feb 1 01:31:46.039: NHRP: Checking for delayed event NULL/10.10.10.2 on list (Tunnel10 vrf: global(0x0))
*Feb 1 01:31:46.040: NHRP: No delayed event node found.
*Feb 1 01:31:46.040: NHRP: There is no VPE Extension to construct for the request
بمجرد بدء عملية Talk1 NHRP، تظهر السجلات أن الجهاز يرسل طلب تحليل NHRP. تحتوي الحزمة على بعض المعلومات المهمة مثل SRC NMBA وبروتوكول SRC التي هي عنوان IP ل NBMA وعنوان IP للنفق للمصدر الذي يتم التحدث به (Talk1). أنت يستطيع أيضا رأيت ال DST بروتوكول قيمة أن يتلقى النفق عنوان من الغاية يتكلم (Talk2). هذا يشير إلى أن Talk1 يطلب عنوان NBMA ل TALK2 لإكمال التعيين. أيضا على الحزمة، أنت يستطيع وجدت ال reqid قيمة أن يستطيع ساعدت أنت تتبعت الربط على المسار. ستبقى هذه القيمة هي نفسها من خلال العملية بأكملها، ويمكن أن تكون مفيدة لتعقب تدفق معين من تفاوض NHRP. تحتوي الحزمة على قيم أخرى مهمة للتفاوض مثل سلسلة مصادقة NHRP.
بعد أن يرسل الجهاز طلب تحليل NHRP، تظهر السجلات أنه يتم إرسال إعادة إرسال. وذلك لأن الجهاز لا يرى إستجابة تحليل NHRP لذلك فإنه يرسل الحزمة مرة أخرى. بما أن Talk1 لا يرى الاستجابة، من الضروري أن يتتبع أن ربط على التالي أداة في المسار، أي الصرة.
إخراج تصحيح أخطاء الموزع:
*Feb 1 01:31:34.262: NHRP: Receive Resolution Request via Tunnel10 vrf: global(0x0), packet size: 85
*Feb 1 01:31:34.262: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 1 01:31:34.262: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 1 01:31:34.263: pktsz: 85 extoff: 52
*Feb 1 01:31:34.263: (M) flags: "router auth src-stable nat ", reqid: 10
*Feb 1 01:31:34.263: src NBMA: 172.21.100.1
*Feb 1 01:31:34.263: src protocol: 10.10.10.1, dst protocol: 10.10.10.2
*Feb 1 01:31:34.263: (C-1) code: no error(0), flags: none
*Feb 1 01:31:34.263: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:34.263: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
*Feb 1 01:31:34.263: Responder Address Extension(3):
*Feb 1 01:31:34.263: Forward Transit NHS Record Extension(4):
*Feb 1 01:31:34.263: Reverse Transit NHS Record Extension(5):
*Feb 1 01:31:34.263: Authentication Extension(7):
*Feb 1 01:31:34.263: type:Cleartext(1), data:DMVPN
*Feb 1 01:31:34.263: NAT address Extension(9):
*Feb 1 01:31:34.263: NHRP-DETAIL: netid_in = 10, to_us = 0
*Feb 1 01:31:34.263: NHRP-DETAIL: Resolution request for afn 1 received on interface Tunnel10 , for vrf: global(0x0) label: 0
*Feb 1 01:31:34.263: NHRP-DETAIL: Multipath IP route lookup for 10.10.10.2 in vrf: global(0x0) yielded Tunnel10, pfx:10.10.10.0/24 (netid_in:10 if_in:Tunnel10)
*Feb 1 01:31:34.263: NHRP: Route lookup for destination 10.10.10.2 in vrf: global(0x0) yielded interface Tunnel10, prefixlen 24
*Feb 1 01:31:34.263: NHRP-DETAIL: netid_out 10, netid_in 10
*Feb 1 01:31:34.263: NHRP: Forwarding request due to authoritative request.
*Feb 1 01:31:34.263: NHRP-ATTR: NHRP Resolution Request packet is forwarded to 10.10.10.2 using vrf: global(0x0)
*Feb 1 01:31:34.263: NHRP: Attempting to forward to destination: 10.10.10.2 vrf: global(0x0)
*Feb 1 01:31:34.264: NHRP: Forwarding: NHRP SAS picked source: 10.10.10.10 for destination: 10.10.10.2
*Feb 1 01:31:34.264: NHRP: Attempting to send packet through interface Tunnel10 via DEST dst 10.10.10.2
*Feb 1 01:31:34.264: NHRP-DETAIL: First hop route lookup for 10.10.10.2 yielded 10.10.10.2, Tunnel10
*Feb 1 01:31:34.264: NHRP: Forwarding Resolution Request via Tunnel10 vrf: global(0x0), packet size: 105
*Feb 1 01:31:34.264: src: 10.10.10.10, dst: 10.10.10.2
*Feb 1 01:31:34.264: (F) afn: AF_IP(1), type: IP(800), hop: 254, ver: 1
*Feb 1 01:31:34.264: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 1 01:31:34.264: pktsz: 105 extoff: 52
*Feb 1 01:31:34.264: (M) flags: "router auth src-stable nat ", reqid: 10
*Feb 1 01:31:34.264: src NBMA: 172.21.100.1
*Feb 1 01:31:34.264: src protocol: 10.10.10.1, dst protocol: 10.10.10.2
*Feb 1 01:31:34.264: (C-1) code: no error(0), flags: none
*Feb 1 01:31:34.264: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:34.264: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
*Feb 1 01:31:34.264: Responder Address Extension(3):
*Feb 1 01:31:34.264: Forward Transit NHS Record Extension(4):
*Feb 1 01:31:34.264: (C-1) code: no error(0), flags: none
*Feb 1 01:31:34.264: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:34.264: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
*Feb 1 01:31:34.264: client NBMA: 172.20.10.10
*Feb 1 01:31:34.264: client protocol: 10.10.10.10
*Feb 1 01:31:34.264: Reverse Transit NHS Record Extension(5):
*Feb 1 01:31:34.264: Authentication Extension(7):
*Feb 1 01:31:34.264: type:Cleartext(1), data:DMVPN
*Feb 1 01:31:34.265: NAT address Extension(9):
*Feb 1 01:31:34.265: NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 172.22.200.2
*Feb 1 01:31:34.265: NHRP: 129 bytes out Tunnel10
باستخدام قيمة reqid، يمكنك ملاحظة أن HUB يستلم طلب الحل المرسل بواسطة Talk1. في الحزمة، القيمة من src nbma وsrc بروتوكول هي المعلومة من Talk1، وقيمة بروتوكول DST هي النفق ip من Talk2، كما شوهد على تصحيح الأخطاء من Talk1. عندما يستلم الصرة طلب الحل، فإنه يجري بحث المسار ويرسل الربط إلى Talk2. في الحزمة المعاد توجيهها، يضيف الصرة ملحق يحتوي على معلوماته الخاصة (عنوان IP الخاص ب NBMA وعنوان IP للنفق).
تظهر تصحيح الأخطاء السابقة أن HUB يقوم بإعادة توجيه طلب الحل بشكل صحيح للكلام 2. لذلك، الخطوة التالية هي تأكيد تلقيها، ومعالجتها بشكل صحيح، وإرسال الرد على الحل إلى Talk1.
إخراج تصحيح الأخطاء TALK2:
-------------------- [IKE/IPSEC DEBUG OUTPUTS OMITTED]--------------------
*Feb 1 01:31:34.647: ISAKMP: (1015):Old State = IKE_QM_IPSEC_INSTALL_AWAIT New State = IKE_QM_PHASE2_COMPLETE
*Feb 1 01:31:34.647: NHRP: Process delayed resolution request src:10.10.10.1 dst:10.10.10.2 vrf: global(0x0)
*Feb 1 01:31:34.648: NHRP-DETAIL: Resolution request for afn 1 received on interface Tunnel10 , for vrf: global(0x0) label: 0
*Feb 1 01:31:34.648: NHRP-DETAIL: Multipath IP route lookup for 10.10.10.2 in vrf: global(0x0) yielded Tunnel10, pfx:10.10.10.0/24 (netid_in:10 if_in:Tunnel10)
*Feb 1 01:31:34.648: NHRP: Route lookup for destination 10.10.10.2 in vrf: global(0x0) yielded interface Tunnel10, prefixlen 24
*Feb 1 01:31:34.648: NHRP-ATTR: smart spoke feature and attributes are not configured
*Feb 1 01:31:34.648: NHRP: Request was to us. Process the NHRP Resolution Request.
*Feb 1 01:31:34.648: NHRP-DETAIL: Multipath IP route lookup for 10.10.10.2 in vrf: global(0x0) yielded Tunnel10, pfx:10.10.10.0/24 (netid_in:10 if_in:Tunnel10)
*Feb 1 01:31:34.648: NHRP: nhrp_rtlookup for 10.10.10.2 in vrf: global(0x0) yielded interface Tunnel10, prefixlen 24, label none(0)
*Feb 1 01:31:34.648: NHRP: Request was to us, responding with ouraddress
*Feb 1 01:31:34.648: NHRP: Checking for delayed event 10.10.10.1/10.10.10.2 on list (Tunnel10 vrf: global(0x0))
*Feb 1 01:31:34.648: NHRP: No delayed event node found.
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10: Checking to see if we need to delay for src 172.22.200.2 dst 172.21.100.1
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10: crypto_ss_listen_start already listening
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): Opening a socket with profile IPSEC_Profile_1
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): connection lookup returned 80007F1CE6348C68
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): Socket is already open. Ignoring.
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): connection lookup returned 80007F1CE6348C68
*Feb 1 01:31:34.648: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): tunnel is already open!
*Feb 1 01:31:34.648: NHRP: No need to delay processing of resolution event NBMA src:172.22.200.2 NBMA dst:172.21.100.1
*Feb 1 01:31:34.648: NHRP-MEF: No vendor private extension in NHRP packet
*Feb 1 01:31:34.649: NHRP-CACHE: Tunnel10: Cache update for target 10.10.10.1/32 vrf: global(0x0) label none next-hop 10.10.10.1
*Feb 1 01:31:34.649: 172.21.100.1 (flags:0x2080)
*Feb 1 01:31:34.649: NHRP: Adding Tunnel Endpoints (VPN: 10.10.10.1, NBMA: 172.21.100.1)
*Feb 1 01:31:34.649: IPSEC-IFC MGRE/Tu10: crypto_ss_listen_start already listening
*Feb 1 01:31:34.649: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): Opening a socket with profile IPSEC_Profile_1
*Feb 1 01:31:34.649: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): connection lookup returned 80007F1CE6348C68
*Feb 1 01:31:34.649: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): Found an existing tunnel endpoint
*Feb 1 01:31:34.649: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): tunnel_protection_stop_pending_timer 80007F1CE6348C68
*Feb 1 01:31:34.649: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): Socket is already open. Ignoring.
*Feb 1 01:31:34.653: NHRP: Successfully attached NHRP subblock for Tunnel Endpoints (VPN: 10.10.10.1, NBMA: 172.21.100.1)
*Feb 1 01:31:34.653: NHRP: Peer capability:0
*Feb 1 01:31:34.653: NHRP-CACHE: Inserted subblock node(1 now) for cache: Target 10.10.10.1/32 nhop 10.10.10.1
*Feb 1 01:31:34.653: NHRP-CACHE: Converted internal dynamic cache entry for 10.10.10.1/32 interface Tunnel10 vrf: global(0x0) to external
*Feb 1 01:31:34.653: NHRP-EVE: NHP-UP: 10.10.10.1, NBMA: 172.21.100.1
*Feb 1 01:31:34.653: NHRP-MEF: No vendor private extension in NHRP packet
*Feb 1 01:31:34.653: NHRP-CACHE: Tunnel10: Internal Cache add for target 10.10.10.2/32 vrf: global(0x0) label none next-hop 10.10.10.2
*Feb 1 01:31:34.653: 172.22.200.2 (flags:0x20)
*Feb 1 01:31:34.653: NHRP: Attempting to send packet through interface Tunnel10 via DEST dst 10.10.10.1
*Feb 1 01:31:34.654: NHRP-DETAIL: First hop route lookup for 10.10.10.1 yielded 10.10.10.1, Tunnel10
*Feb 1 01:31:34.654: NHRP: Send Resolution Reply via Tunnel10 vrf: global(0x0), packet size: 133
*Feb 1 01:31:34.654: src: 10.10.10.2, dst: 10.10.10.1
*Feb 1 01:31:34.654: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 1 01:31:34.654: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 1 01:31:34.654: pktsz: 133 extoff: 60
*Feb 1 01:31:34.654: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 10
*Feb 1 01:31:34.654: src NBMA: 172.21.100.1
*Feb 1 01:31:34.654: src protocol: 10.10.10.1, dst protocol: 10.10.10.2
*Feb 1 01:31:34.654: (C-1) code: no error(0), flags: none
*Feb 1 01:31:34.654: prefix: 32, mtu: 9976, hd_time: 599
*Feb 1 01:31:34.654: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
*Feb 1 01:31:34.654: client NBMA: 172.22.200.2
*Feb 1 01:31:34.654: client protocol: 10.10.10.2
*Feb 1 01:31:34.654: Responder Address Extension(3):
*Feb 1 01:31:34.654: (C) code: no error(0), flags: none
*Feb 1 01:31:34.654: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:34.654: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
*Feb 1 01:31:34.654: client NBMA: 172.22.200.2
*Feb 1 01:31:34.654: client protocol: 10.10.10.2
*Feb 1 01:31:34.654: Forward Transit NHS Record Extension(4):
*Feb 1 01:31:34.654: (C-1) code: no error(0), flags: none
*Feb 1 01:31:34.654: prefix: 0, mtu: 9976, hd_time: 600
*Feb 1 01:31:34.654: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
*Feb 1 01:31:34.654: client NBMA: 172.20.10.10
*Feb 1 01:31:34.654: client protocol: 10.10.10.10
*Feb 1 01:31:34.654: Reverse Transit NHS Record Extension(5):
*Feb 1 01:31:34.654: Authentication Extension(7):
*Feb 1 01:31:34.654: type:Cleartext(1), data:DMVPN
*Feb 1 01:31:34.655: NAT address Extension(9):
*Feb 1 01:31:34.655: NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 172.21.100.1
*Feb 1 01:31:34.655: NHRP: 157 bytes out Tunnel10
*Feb 1 01:31:34.655: IPSEC-IFC MGRE/Tu10(172.22.200.2/172.21.100.1): connection lookup returned 80007F1CE6348C68
*Feb 1 01:31:34.655: NHRP-DETAIL: Deleted delayed event on interfaceTunnel10 dest: 172.21.100.1
يطابق الرقم reqid القيمة التي ظهرت في المخرجات السابقة، مع هذا، تأكد أن حزمة طلب تحليل NHRP التي تم إرسالها بواسطة Talk1 تصل إلى Talk2. تقوم هذه الحزمة بتشغيل بحث عن مسار على Talk2، وتدرك أن طلب الحل هو لنفسه، لذلك، يضيف Talk2 المعلومات من Talk1 إلى جدول NHRP الخاص به. قبل إرسال حزمة الرد على الحل مرة أخرى إلى Talk1، يضيف الجهاز معلوماته الخاصة (عنوان IP الخاص ب NBMA وعنوان IP للنفق) حتى يمكن ل Talk1 إستخدام تلك الحزمة لإضافة تلك المعلومات إلى قاعدة البيانات الخاصة به.
استنادا إلى جميع عمليات تصحيح الأخطاء التي تم الاطلاع عليها، لم يصل الرد على حل NHRP الذي تم إرساله من TALK2 إلى TALK1. يمكن تجاهل الصرة من المشكلة حيث إنها تتلقى وتعيد توجيه حزمة طلب تحليل NHRP كما هو متوقع. لذلك، الخطوة التالية هي التقاط صور بين Talk1 و Talk2 للحصول على مزيد من التفاصيل حول المسألة.
التقاط حزمة مضمنة
تتيح لك ميزة التقاط الحزمة المضمنة تحليل حركة مرور البيانات التي تمر عبر الجهاز. تتمثل الخطوة الأولى لتكوينها في إنشاء قائمة وصول تشمل حركة المرور التي تريد الاستيلاء عليها على كل من تدفقات حركة المرور (الواردة والصادرة).
لهذا السيناريو، يتم إستخدام عناوين IP الخاصة ب NBMA:
ip access-list extended filter
10 permit ip host 172.21.100.1 host 172.22.200.2
20 permit ip host 172.22.200.2 host 172.21.100.1
بعد ذلك، قم بتكوين الالتقاط باستخدام الأمر monitor capture <capture_name> access-list <acl_name> buffer size 10 interface <wan_interface> على حد سواء وابدأ الالتقاط باستخدام بدء التقاط مراقبة الأمر <capture_name>.
تكوين الالتقاط على Talk1 و Talk2:
monitor capture CAP access-list filter buffer size 10 interface GigabitEthernet1 both
monitor capture CAP start
لعرض مخرجات الالتقاط أستخدم الأمر show monitor capture <capture_name> buffer brief.
تسجيل إخراج الفيديو 1:
SPOKE1#show monitor capture CAP buffer brief
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 210 0.000000 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
1 150 0.014999 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
2 478 0.028990 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
3 498 0.049985 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
4 150 0.069988 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
5 134 0.072994 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
6 230 0.074993 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
7 230 0.089992 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
8 118 0.100993 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
9 218 0.108988 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
10 70 0.108988 172.21.100.1 -> 172.22.200.2 0 BE ICMP
11 218 1.907994 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
12 70 1.907994 172.21.100.1 -> 172.22.200.2 0 BE ICMP
13 218 5.818003 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
14 70 5.818003 172.21.100.1 -> 172.22.200.2 0 BE ICMP
15 218 12.559969 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
16 70 12.559969 172.21.100.1 -> 172.22.200.2 0 BE ICMP
17 218 26.859001 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
18 70 26.859001 172.21.100.1 -> 172.22.200.2 0 BE ICMP
19 218 54.378978 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
20 70 54.378978 172.21.100.1 -> 172.22.200.2 0 BE ICMP
تسجيل الإخراج عبر 2:
SPOKE2#show monitor capture CAP buffer brief
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 210 0.000000 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
1 150 0.015990 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
2 478 0.027998 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
3 498 0.050992 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
4 150 0.069988 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
5 134 0.072994 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
6 230 0.074993 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
7 230 0.089992 172.21.100.1 -> 172.22.200.2 48 CS6 UDP
8 118 0.099986 172.22.200.2 -> 172.21.100.1 48 CS6 UDP
9 218 0.108988 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
10 70 0.108988 172.21.100.1 -> 172.22.200.2 0 BE ICMP
11 218 1.907994 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
12 70 1.909001 172.21.100.1 -> 172.22.200.2 0 BE ICMP
13 218 5.817011 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
14 70 5.818002 172.21.100.1 -> 172.22.200.2 0 BE ICMP
15 218 12.559968 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
16 70 12.560960 172.21.100.1 -> 172.22.200.2 0 BE ICMP
17 218 26.858009 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
18 70 26.859001 172.21.100.1 -> 172.22.200.2 0 BE ICMP
19 218 54.378978 172.22.200.2 -> 172.21.100.1 48 CS6 ESP
20 70 54.379970 172.21.100.1 -> 172.22.200.2 0 BE ICMP
يوضح إخراج عمليات الالتقاط أن الحزم الأولية هي حركة مرور UDP، مما يشير إلى تفاوض IKE/IPSec. بعد ذلك، يرسل Talk2 الرد على الحل إلى Talk1، والذي يتم رؤيته على أنه حركة مرور ESP (الحزمة 9). بعد هذا، يكون تدفق حركة المرور المتوقع هو ESP، ومع ذلك، الحزمة التالية التي يتم رؤيتها هي حركة مرور ICMP القادمة من Talk1 إلى Talk2.
لتحليل أعمق الربط، أنت يستطيع صدرت ال PCAP مبرد من الأداة ب يركض الأمر show monitor capture <CAPTURE_NAME> مصد. ثم أستخدم أداة فك الترميز لتحويل مخرجات التفريغ إلى ملف PCAP بحيث يمكنك فتحه باستخدام Wireshark.
ملاحظة: تحتوي Cisco على محلل حزم حيث يمكنك العثور على تكوين الالتقاط والأمثلة وفك التشفير: أداة Cisco TAC - مولد تكوين التقاط الحزمة ومحلل
إخراج Wireshark:
إخراج الالتقاط على Wireshark
يحتوي محتوى حزمة ICMP على وجهة رسالة الخطأ التي يتعذر الوصول إليها (تمت تصفية الاتصال إداريا). هذا يشير إلى وجود نوع من التصفية، مثل قائمة التحكم في الوصول للموجه أو جدار الحماية الذي يؤثر على حركة المرور على المسار. في معظم الأحيان، يتم تكوين عامل التصفية على الجهاز الذي يرسل الحزمة (في هذه الحالة، Talk1) ولكن الأجهزة الوسطى يمكنها إرسالها كذلك.
ملاحظة: تكون مخرجات Wireshark هي نفسها على كلا الخاصتين.
ميزة تتبع حزمة بيانات Cisco IOS® XE
يتم إستخدام ميزة تتبع حزمة بيانات Cisco IOS XE لتحليل كيفية معالجة الجهاز لحركة مرور البيانات. لتكوينها، يلزمك إنشاء قائمة وصول تتضمن حركة المرور التي تريد الاستيلاء عليها على كل من تدفقات حركة المرور (الواردة والصادرة).
لهذا السيناريو، يتم إستخدام عناوين IP الخاصة ب NBMA.
ip access-list extended filter
10 permit ip host 172.21.100.1 host 172.22.200.2
20 permit ip host 172.22.200.2 host 172.21.100.1
بعد ذلك، قم بتكوين ميزة تتبع FIA وعين حالة تصحيح الأخطاء لاستخدام قائمة الوصول. أخيرا، ابدأ الشرط.
debug platform packet-trace packet 1024 fia-trace
debug platform condition ipv4 access-list filter both
debug platform condition start
- debug platform packet-trace packet <count> fia-trace: يمكن تتبع FIA المفصل، ويوقفه بمجرد التقاط مقدار الحزم التي تم تكوينها
- debug platform condition ipV4 access-list <acl-name> كلا: يحدد شرطا على الجهاز باستخدام قائمة الوصول التي تم تكوينها مسبقا
- بداية شرط منصة تصحيح الأخطاء: يبدأ الشرط
لمراجعة مخرجات تتبع FIA أستخدم الأوامر التالية.
show platform packet-trace statistics
show platform packet-trace summary
show platform packet-trace packet <number>
تحدث 1 عرض إخراج إحصائيات تتبع حزم النظام الأساسي:
SPOKE1#show platform packet-trace statistics
Packets Summary
Matched 18
Traced 18
Packets Received
Ingress 11
Inject 7
Count Code Cause
4 2 QFP destination lookup
3 9 QFP ICMP generated packet
Packets Processed
Forward 7
Punt 8
Count Code Cause
5 11 For-us data
3 26 QFP ICMP generated packet
Drop 3
Count Code Cause
3 8 Ipv4Acl
Consume 0
PKT_DIR_IN
Dropped Consumed Forwarded
INFRA 0 0 0
TCP 0 0 0
UDP 0 0 5
IP 0 0 5
IPV6 0 0 0
ARP 0 0 0
PKT_DIR_OUT
Dropped Consumed Forwarded
INFRA 0 0 0
TCP 0 0 0
UDP 0 0 0
IP 0 0 0
IPV6 0 0 0
ARP 0 0 0
في إخراج إحصائيات تتبع حزم النظام الأساسي show platform، يمكنك رؤية عدادات الحزم التي تمت معالجتها بواسطة الجهاز. وهذا يسمح لك برؤية الحزم الواردة والصادرة، والتحقق مما إذا كان الجهاز يقوم بإسقاط أي حزم، مع سبب الإسقاط.
في الإخراج المعروض، يقوم Talk1 بإسقاط بعض الحزم باستخدام الوصف IPv4ACL. لمزيد من تحليل هذه الحزم، يمكن إستخدام الأمر show platform packet-trace summary.
تحدث 1 عرض ملخص تتبع حزم النظام الأساسي:
SPOKE1#show platform packet-trace summary
Pkt Input Output State Reason
0 Gi1 internal0/0/rp:0 PUNT 11 (For-us data)
1 INJ.2 Gi1 FWD
2 Gi1 internal0/0/rp:0 PUNT 11 (For-us data)
3 INJ.2 Gi1 FWD
4 Gi1 internal0/0/rp:0 PUNT 11 (For-us data)
5 INJ.2 Gi1 FWD
6 Gi1 internal0/0/rp:0 PUNT 11 (For-us data)
7 INJ.2 Gi1 FWD
8 Gi1 internal0/0/rp:0 PUNT 11 (For-us data)
9 Gi1 Gi1 DROP 8 (Ipv4Acl)
10 Gi1 internal0/0/recycle:0 PUNT 26 (QFP ICMP generated packet)
11 INJ.9 Gi1 FWD
12 Gi1 Gi1 DROP 8 (Ipv4Acl)
13 Gi1 internal0/0/recycle:0 PUNT 26 (QFP ICMP generated packet)
14 INJ.9 Gi1 FWD
15 Gi1 Gi1 DROP 8 (Ipv4Acl)
16 Gi1 internal0/0/recycle:0 PUNT 26 (QFP ICMP generated packet)
17 INJ.9 Gi1 FWD
18 Gi1 Gi1 DROP 8 (Ipv4Acl)
19 Gi1 internal0/0/recycle:0 PUNT 26 (QFP ICMP generated packet)
20 INJ.9 Gi1 FWD
21 Gi1 Gi1 DROP 8 (Ipv4Acl)
22 Gi1 internal0/0/recycle:0 PUNT 26 (QFP ICMP generated packet)
23 INJ.9 Gi1 FWD
24 Gi1 Gi1 DROP 8 (Ipv4Acl)
25 Gi1 internal0/0/recycle:0 PUNT 26 (QFP ICMP generated packet)
26 INJ.9 Gi1 FWD
مع هذا الناتج، أنت يستطيع رأيت كل ربط قادم ويترك الأداة، as well as مدخل ومخرج قارن. يتم عرض حالة الحزمة أيضا، للإشارة إلى ما إذا كان قد تمت إعادة توجيهها أو إسقاطها أو معالجتها داخليا (PUNT).
في هذا المثال، ساعد هذا الإخراج في تحديد الحزم التي يتم إسقاطها بواسطة الجهاز. باستخدام الأمر show platform packet-trace packet <PACKET_NUMBER>، يمكنك رؤية كيفية معالجة الجهاز للحزمة المحددة.
تحدث 1 عرض إخراج حزمة تتبع حزم النظام الأساسي <PACKET_NUMBER>:
SPOKE1#show platform packet-trace packet 9
Packet: 9 CBUG ID: 9
Summary
Input : GigabitEthernet1
Output : GigabitEthernet1
State : DROP 8 (Ipv4Acl)
Timestamp
Start : 366032715676920 ns (02/01/2024 04:30:15.708990 UTC)
Stop : 366032715714128 ns (02/01/2024 04:30:15.709027 UTC)
Path Trace
Feature: IPV4(Input)
Input : GigabitEthernet1
Output : <unknown>
Source : 172.22.200.2
Destination : 172.21.100.1
Protocol : 50 (ESP)
Feature: DEBUG_COND_INPUT_PKT
Entry : Input - 0x812707d0
Input : GigabitEthernet1
Output :
Lapsed time : 194 ns
Feature: IPV4_INPUT_DST_LOOKUP_ISSUE
Entry : Input - 0x8129bf74
Input : GigabitEthernet1
Output :
Lapsed time : 769 ns
Feature: IPV4_INPUT_ARL_SANITY
Entry : Input - 0x812725cc
Input : GigabitEthernet1
Output :
Lapsed time : 307 ns
Feature: EPC_INGRESS_FEATURE_ENABLE
Entry : Input - 0x812782d0
Input : GigabitEthernet1
Output :
Lapsed time : 6613 ns
Feature: IPV4_INPUT_DST_LOOKUP_CONSUME
Entry : Input - 0x8129bf70
Input : GigabitEthernet1
Output :
Lapsed time : 272 ns
Feature: STILE_LEGACY_DROP
Entry : Input - 0x812a7650
Input : GigabitEthernet1
Output :
Lapsed time : 278 ns
Feature: INGRESS_MMA_LOOKUP_DROP
Entry : Input - 0x812a1278
Input : GigabitEthernet1
Output :
Lapsed time : 697 ns
Feature: INPUT_DROP_FNF_AOR
Entry : Input - 0x81297278
Input : GigabitEthernet1
Output :
Lapsed time : 676 ns
Feature: INPUT_FNF_DROP
Entry : Input - 0x81280f24
Input : GigabitEthernet1
Output :
Lapsed time : 1018 ns
Feature: INPUT_DROP_FNF_AOR_RELEASE
Entry : Input - 0x81297274
Input : GigabitEthernet1
Output :
Lapsed time : 174 ns
Feature: INPUT_DROP
Entry : Input - 0x8126e568
Input : GigabitEthernet1
Output :
Lapsed time : 116 ns
Feature: IPV4_INPUT_ACL
Entry : Input - 0x81271f70
Input : GigabitEthernet1
Output :
Lapsed time : 12915 ns
في الجزء الأول، أنت يستطيع رأيت المدخل ومخرج قارن، وحالة الربط. ويتبع هذا الجزء الثاني من الإخراج حيث يمكنك العثور على عناوين IP للمصدر والوجهة والبروتوكول.
توضح كل مرحلة تالية كيفية معالجة الجهاز لهذه الحزمة المحددة. وهذا يوفر رؤى إلى أي تكوينات مثل ترجمة عنوان الشبكة (NAT) أو قائمة الوصول أو العوامل الأخرى التي قد تؤثر عليها.
في هذه الحالة، يمكن التعرف على أن بروتوكول الحزمة هو ESP، والمصدر IP هو عنوان IP ل TALK2 ل NBMA، والوجهة IP هو عنوان IP ل TALK1. هذا يشير إلى أن هذه هي الحزمة المفقودة في تفاوض NHRP. ويلاحظ أيضا أنه لم يتم تحديد واجهة مخرج في أي مرحلة، مما يشير إلى أن شيئا ما أثر على حركة المرور قبل إعادة توجيهها. في المرحلة قبل الأخيرة، يمكنك أن ترى أن الجهاز يقوم بإسقاط حركة المرور الواردة على الواجهة المحددة (GigabitEthernet1). تعرض المرحلة الأخيرة قائمة وصول إلى الإدخال، مما يشير إلى إمكانية وجود بعض التكوين على الواجهة التي تتسبب في الإسقاط.
ملاحظة: في حالة عدم ظهور أية علامات تدل على إنزال كافة أدوات أستكشاف الأخطاء وإصلاحها المذكورة في هذا المستند أو أنها تؤثر على حركة المرور، فإن ذلك يعني إنهاء أستكشاف الأخطاء وإصلاحها على هذه الأجهزة.
يجب أن تكون الخطوة التالية فحص الأجهزة المتوسطة بينها، مثل جدران الحماية والمحولات و ISP.
الحل
وفي حال رؤية سيناريو من هذا القبيل، فإن الخطوة التالية هي التحقق من الواجهة الموضحة في المخرجات السابقة. وهذا يتضمن التحقق من التكوين للتحقق من ما إذا كان هناك أي شيء يؤثر على حركة المرور.
تكوين واجهة WAN:
SPOKE1#show running-configuration interface gigabitEthernet1
Building configuration...
Current configuration : 150 bytes
!
interface GigabitEthernet1
ip address 172.21.100.1 255.255.255.0
ip access-group ESP_TRAFFIC in
negotiation auto
no mop enabled
no mop sysid
end
كجزء من التكوين الخاص بها، تم تطبيق مجموعة الوصول على الواجهة. من المهم التحقق من أن الأجهزة المضيفة التي تم تكوينها على قائمة الوصول لا تتداخل مع حركة المرور المستخدمة لمفاوضات NHRP.
SPOKE1#show access-lists ESP_TRAFFIC
Extended IP access list ESP_TRAFFIC
10 deny esp host 172.21.100.1 host 172.22.200.2
20 deny esp host 172.22.200.2 host 172.21.100.1 (114 matches)
30 permit ip any any (22748 matches)
البيان الثاني لقائمة الوصول ينكر الاتصال بين عنوان IP ل TALK2 الخاص ب NBMA وعنوان IP الخاص ب TALK1، مما سبب الهبوط الذي تمت مشاهدته سابقا. بعد إزالة مجموعة الوصول من الواجهة، يكون الاتصال بين البابين ناجحا:
SPOKE1#ping 192.168.2.2 source loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/3 ms
تم تشغيل نفق IPSec وهو يعرض الآن عمليات التشفير وفك التشفير على كلا الجهازين:
تم التحدث 1:
SPOKE1#show crypto IPSEC sa peer 172.22.200.2
interface: Tunnel10
Crypto map tag: Tunnel10-head-0, local addr 172.21.100.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.21.100.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.22.200.2/255.255.255.255/47/0)
current_peer 172.22.200.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 6, #pkts encrypt: 6, #pkts digest: 6
#pkts decaps: 7, #pkts decrypt: 7, #pkts verify: 7
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.21.100.1, remote crypto endpt.: 172.22.200.2
plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0x9392DA81(2475874945)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xBF8F523D(3213840957)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2073, flow_id: CSR:73, sibling_flags FFFFFFFF80000008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4607998/28783)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x9392DA81(2475874945)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2074, flow_id: CSR:74, sibling_flags FFFFFFFF80000008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4607999/28783)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
تحدث 2:
SPOKE2#show crypto IPSEC sa peer 172.21.100.1
interface: Tunnel10
Crypto map tag: Tunnel10-head-0, local addr 172.22.200.2
protected vrf: (none)
local ident (addr/mask/prot/port): (172.22.200.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.21.100.1/255.255.255.255/47/0)
current_peer 172.21.100.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 7, #pkts encrypt: 7, #pkts digest: 7
#pkts decaps: 6, #pkts decrypt: 6, #pkts verify: 6
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.22.200.2, remote crypto endpt.: 172.21.100.1
plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0xBF8F523D(3213840957)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x9392DA81(2475874945)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2073, flow_id: CSR:73, sibling_flags FFFFFFFF80000008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4607998/28783)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xBF8F523D(3213840957)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Transport, }
conn id: 2074, flow_id: CSR:74, sibling_flags FFFFFFFF80000008, crypto map: Tunnel10-head-0
sa timing: remaining key lifetime (k/sec): (4607999/28783)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
الآن يعرض جدول DMVPN ل Talk1 التخطيط الصحيح على كلا الإدخالين:
SPOKE1#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override, B - BGP
C - CTS Capable, I2 - Temporary
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel10, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.22.200.2 10.10.10.2 UP 00:01:31 D
1 172.20.10.10 10.10.10.10 UP 1d05h S
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
12-Feb-2024 |
الإصدار الأولي |
التعليقات