لب عملی: پیکربندی BGP روی DMVPN

هدف لب

پیکربندی iBGP در سراسر اینترفیس‌های تونل DMVPN استفاده‌شده در دو لب قبلی، تعیین hub به‌عنوان یک route reflector BGP برای هر دو spoke، و تأیید اینکه هر spoke LAN دیگری را از طریق hub بدون نیاز به یک جلسه مستقیم iBGP بین خود spoke ها یاد می‌گیرد.

هدف لب (چرا مهم است)

لب route reflector پیش‌تر در این مجموعه نیازمندی full-mesh iBGP را با استفاده از یک طراحی iBGP hub-and-spoke از نظر مفهومی حل کرد، اما روی یک توپولوژی عمومی. این لب آن مفهوم را مستقیماً با ساختار تونل hub-and-spoke خود DMVPN ترکیب می‌کند، و نشان می‌دهد این دو طراحی چقدر طبیعی مکمل یکدیگرند — همان hub که از‌قبل به‌عنوان hub تونل خدمت می‌کند می‌تواند همچنین به‌عنوان route reflector BGP خدمت کند.

توپولوژی لب

همان توپولوژی DMVPN دو لب قبلی، با OSPF
حذف‌شده و iBGP به‌جای آن پیکربندی‌شده، همه در
AS 65100:

Hub ---- Tunnel0 (mGRE): 172.16.200.1/24
Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24

وظیفه ۱: حذف پیکربندی OSPF قبلی

OSPF را از هر سه روتر حذف کن.

وظیفه ۲: پیکربندی جلسات iBGP بین Hub و هر Spoke

hub را با عبارات neighbor iBGP به هر دو spoke از میان آدرس‌های تونلشان پیکربندی کن.

وظیفه ۳: پیکربندی Hub به‌عنوان یک Route Reflector

هر دو جلسه spoke روی hub را به‌عنوان route-reflector-client علامت‌گذاری کن.

وظیفه ۴: تبلیغ LAN هر Spoke به BGP

LAN های متناظر Spoke1 و Spoke2 را به BGP روی هر روتر spoke تبلیغ کن.

وظیفه ۵: تأیید یادگیری LAN دیگری توسط هر Spoke از طریق Hub

تأیید کن Spoke1 LAN Spoke2 را یاد می‌گیرد و بالعکس، با وجود عدم‌وجود هیچ جلسه مستقیم BGP‌ای بین دو spoke.

راه‌حل و تأیید

Hub(config)# no router ospf 1
Spoke1(config)# no router ospf 1
Spoke2(config)# no router ospf 1

-- دسترس‌پذیری زیربنایی تونل (ثبت NHRP) مستقل
-- از پروتکل مسیریابی در حال اجرا روی آن است
-- -- حذف OSPF روی خود تونل DMVPN تأثیر نمی‌گذارد

Hub(config)# router bgp 65100
Hub(config-router)# neighbor 172.16.200.2 remote-as 65100
Hub(config-router)# neighbor 172.16.200.2 route-reflector-client
Hub(config-router)# neighbor 172.16.200.3 remote-as 65100
Hub(config-router)# neighbor 172.16.200.3 route-reflector-client

-- هر دو spoke در یک گام واحد به‌عنوان کلاینت
-- علامت‌گذاری شدند، و برقراری همسایه و
-- اختصاص نقش route reflector را با هم
-- ترکیب می‌کنند

Spoke1(config)# router bgp 65100
Spoke1(config-router)# neighbor 172.16.200.1 remote-as 65100
Spoke1(config-router)# network 192.168.11.0 mask 255.255.255.0

Spoke2(config)# router bgp 65100
Spoke2(config-router)# neighbor 172.16.200.1 remote-as 65100
Spoke2(config-router)# network 192.168.12.0 mask 255.255.255.0

-- هیچ‌کدام از spoke ها هیچ پیکربندی BGP‌ای که
-- به دیگری ارجاع دهد ندارند -- فقط یک جلسه
-- به‌سمت hub

Spoke1# show ip bgp

   Network             Next Hop        Metric  LocPrf  Weight  Path
*>i 192.168.12.0/24    172.16.200.3    0       100         0   i
-- Spoke1 LAN Spoke2 را با وجود عدم‌داشتن
-- هیچ جلسه مستقیمی با Spoke2 یاد گرفت -- hub،
-- در حال عمل به‌عنوان route reflector، این
-- مسیر را دقیقاً همان‌طور که از نظر مفهومی در
-- لب route reflector قبلی نشان داده شد رله کرد

Spoke2# show ip bgp

   Network             Next Hop        Metric  LocPrf  Weight  Path
*>i 192.168.11.0/24    172.16.200.2    0       100         0   i
-- تأیید‌شده متقارن -- Spoke2 به‌طور مشابه LAN
-- Spoke1 را از طریق همان مکانیزم بازتاب یاد گرفت

Spoke1-LAN-PC> traceroute 192.168.12.10

  1  172.16.200.1 (Hub)
  2  192.168.12.10
-- ترافیک همچنان برای فوروارد‌کردن از hub
-- عبور می‌کند، دقیقاً مانند لب‌های EIGRP و
-- OSPF روی DMVPN قبلی -- بازتاب مسیر BGP
-- انتشار مسیر را حل می‌کند، نه سؤال جداگانه
-- بهینه‌سازی مسیر داده مستقیم spoke-به-spoke،
-- که نیازمند shortcut/redirect NHRP همان‌طور
-- که در لب DMVPN فاز ۳ پوشش داده شد بود

نکته کلیدی

توپولوژی تونل فیزیکی hub-and-spoke در DMVPN و سلسله‌مراتب route reflector در BGP تقریباً کاملاً روی هم نگاشت می‌شوند — همان روتری که از‌قبل به‌عنوان hub NHRP خدمت می‌کند به‌طور طبیعی موقعیت دارد تا همچنین به‌عنوان route reflector BGP خدمت کند، و از یک mesh کامل iBGP در سراسر بالقوه ده‌ها spoke دقیقاً همان‌طور که لب route reflector مستقل روی یک توپولوژی ساده‌تر نشان داد اجتناب می‌کند، در حالی که همچنان مکانیزم جداگانه shortcut NHRP را نیاز دارد اگر فوروارد‌کردن داده مستقیم spoke-به-spoke (نه فقط دانش مسیر spoke-به-spoke) نیز مطلوب باشد.