أستكشاف أخطاء BGP وإصلاحها بين حزمة Ultra Packet Core ومحول Nexus بسبب التكوين غير الصحيح

المقدمة

يصف هذا المستند حل نقاط الوصول إلى بروتوكول العبارة الحدودية (BGP) بين Cisco Ultra Packet Core (UPC) ومحول Nexus 9000 الذي تم تكوينه باستخدام اتصال BGP المتكرر.

المشكلة

يتم تشغيل نقاط BGP عند أحد الواجهات المتكررة بين نقاط الوصول في محولات Cisco Ultra Packet Core و Nexus Switch.

شروط

تتصل عقدة Ultra Packet Core (UPC) ب Nexus Leaf A و B على منافذ منفصلة. يتم إنشاء نظائر BGP IPv6 ويتم تثبيت المسارات الافتراضية على عقدة UPC. الشكل 1 يوضح الرسم التخطيطي للشبكة رفيع المستوى مع المسار المتكرر إلى المحولات الطرفية.

الشكل 1: الرسم التخطيطي للشبكة

التكوين

تكوين منفذ UPC باستخدام شبكة VLAN وربط الواجهة:

port ethernet 1/10
    no shutdown
    vlan 140
        no shutdown
        bind interface saegw_vlan140_1/10 saegw
#exit

#exit
port ethernet 1/11
    no shutdown
    vlan 141
        no shutdown
        bind interface saegw_vlan141_1/11 saegw
#exit
#exit
end

تكوين واجهة UPC باستخدام عناوين IP:

interface saegw_vlan140_1/10
  ip address 10.11.11..8 255.255.255.0
  ipv6 address fd00:10:11:11::8/64 secondary
  bfd interval 300 min_rx 300 multiplier 3
#exit
interface saegw_vlan141_1/11
  ip address 10.11.12.8 255.255.255.0
  ipv6 address fd00:10:11:12::8/64 secondary
  bfd interval 300 min_rx 300 multiplier 3
#exit

تكوين UPC BGP:

router bgp 25949
  router-id 172.19.20.30
  maximum-paths ebgp 4
  neighbor 10.11.11..1 remote-as 25949
  neighbor 10.11.11..1 fall-over bfd 
  neighbor 10.11.12.1 remote-as 25949
  neighbor 10.11.12.1 fall-over bfd 
  neighbor fd00:10:11:11::1 remote-as 25949
  neighbor fd00:10:11:12::1 remote-as 25949
  address-family ipv4
    neighbor 10.11.11..1 route-map accept_default in
    neighbor 10.11.11..1 route-map gw-1-OUT out
    neighbor 10.11.12.1 route-map accept_default in
    neighbor 10.11.12.1 route-map gw-1-OUT out
    redistribute connected
#exit
address-family ipv6
  neighbor fd00:10:11:11::1 activate
  neighbor fd00:10:11:11::1 route-map accept_v6_default in
  neighbor fd00:10:11:11::1 route-map allow_service_ips_v6 out
  neighbor fd00:10:11:12::1 activate
  neighbor fd00:10:11:12::1 route-map accept_v6_default in
  neighbor fd00:10:11:12::1 route-map allow_service_ips_v6 out
  redistribute connected
#exit

ipv6 prefix-list name accept_v6_default_routes seq 10 permit ::/0
route-map accept_v6_default permit 10
  match ipv6 address prefix-list accept_v6_default_routes
#exit

تكوين المحول Nexus 9000 Switch:

Interface vlan140
ipv6 address fd00:10:11:11::1/64
no ipv6 redirects

interface vlan141
ipv6 address fd00:10:11:12::1/64
no ipv6 redirects

vrf upc
address-family ipv4 unicast
advertise l2vpn evpn
maximum-paths ibgp 2
address-family ipv6 unicast
advertise l2vpn evpn
maximum-paths ibgp 2
neighbor fd00:10:11:12::5
remote-as 25949
address-family ipv6 unicast
neighbor fd00:10:11:12::6
remote-as 25949
address-family ipv6 unicast
neighbor fd00:10:11:12::8
remote-as 25949
address-family ipv6 unicast

تحليل

مبدئيا تتم ملاحظة اتصال BGP عادي بين إحدى واجهات UPC (fd00:10:11:12::8) ومفتاح Nexus (fd00:10:11:12::1 ينتمي إلى VLAN141) يتضمن رسائل TCP ACK:

2023-01-01 01:01:59.000000 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=8664 Win=31744 Len=0 TSV=2412344062 TSER=531234647
2023-01-01 01:01:59.000087 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=11520 Win=37376 Len=0 TSV=2412344062 TSER=531234647
2023-01-01 01:01:59.000162 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=14376 Win=43008 Len=0 TSV=241234062 TSER=531234647
2023-01-01 01:01:59.000281 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=17232 Win=49152 Len=0 TSV=2412344062 TSER=531234647
2023-01-01 01:01:59.000936 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=20663 Win=48640 Len=0 TSV=2412344063 TSER=531234647

عند فشل الواجهة B باتجاه UPC، يظهر سلوك غير صحيح في السجلات التي يتم فيها بدء محاولة اتصال BGP جديدة من قبل UPC ( المصدر: fd00:10:11:12::8) باتجاه الورقة A على الواجهة fd00:10:11:11::1، والتي تنتمي إلى شبكة VLAN مختلفة، VLAN140.

2023-01-01 22:36:12.370117 fd00:10:11:12::8 -> fd00:10:11:11::1 TCP 41987 > bgp [SYN] Seq=0 Win=14400 Len=0 MSS=1440 TSV=2412347369 TSER=0 WS=9

ينتج عن رسالة BGP SYN غير الصالحة التي يتم إرسالها على الواجهة الخطأ في BGP down. عندما يعلن Nexus عن مساره المتصل وتحصل UPC على مسار للواجهة التي كانت معطلة عبر BGP، يحاول UPC الاتصال عبر واجهة أخرى مع IP صادر مختلف/خاطئ.

الحل

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

لتجنب UPC لإرسال رسائل إنشاء اتصال BGP من الواجهة الخطأ، فيما يلي تغييرات التكوين للنظر فيها:

1. في تكوين UPC، أضف update-source بالنسبه للجار. يمنع هذا التكوين اتصال BGP من واجهة مختلفة، إذا كانت الواجهة الرئيسية معطلة. على سبيل المثال، عندما تكون العقدة saegw_vlan140_1/10 (fd00:10:11:11::1/64) في أسفل، فلا يمكن للعقدة إستخدام الواجهة الصادرة saegw_vlan141_1/11 لنظير BGP fd00:10:11:11::8. 
   فيما يلي نموذج للتكوين :
   

   neighbor fd00:10:11:11::1 update-source fd00:10:11:11::8
   neighbor fd00:10:11:12::1 update-source fd00:10:11:12::8

2. في تكوين Nexus، قم بحظر البادئات من الواجهات الخطأ.
   على سبيل المثال، نقوم برفض المسارات الخاصة بالورقة المكررة عبر الطابعة المجاورة fd00:10:11:11::1
   

   neighbor fd00:10:11:11::1
   update prefix list to deny fd00:10:11:12::8/64

3. في Nexus مفتاح، ال eBGP نظير من ال VTEP إلى عقدة خارجية عبر VXLAN ينبغي كنت في مستأجر VRF ويجب أن يستعمل ال update-source من a loopback الواجهة (النظر عبر VXLAN) كما هو موصى به في دليل تكوين Cisco Nexus 9000