مقالات

خطاهای BGP، کدهای خطای BGP و مدیریت خطاهای BGP


در این پست وبلاگ، خطاهای BGP را بررسی خواهیم کرد. برای این اولین سوال ما باید این باشد: است آیا باگ وجود دارد یا همه چیز کار می کند؟ برای تعیین این موضوع، باید با ماشین نقطه پایانی BGP (FSM) آشنا باشیم. FSM روشی برای مدلسازی عملکرد یک سیستم است. از آنجایی که ما امروز پیاده سازی BGP را نمی سازیم، به نسخه کمی ساده شده BGP FSM نگاه خواهیم کرد:

در این نسخه ساده شده، حالت های Connect، OpenSent و OpenConfirm ادغام شده اند.

جلسات BGP در حالت بیکار شروع می شود. در این مرحله، روتر سعی نمی‌کند به همسایه BGP مورد نظر متصل شود و تلاش‌های اتصال ورودی را نادیده می‌گیرد. بنابراین دیدن همسایه BGP در حالت بیکار طبیعی است، اما اگر همسایه برای مدت طولانی در حالت بیکار بماند، معمولاً نتیجه برخی شرایط خطا است. در برخی شرایط، همسایه ممکن است بلافاصله از حالت غیرفعال به OpenSent یا OpenConfirm برود، اما معمولاً پیشرفت از غیرفعال به فعال است.

حالت فعال کمی اشتباه است زیرا در این مرحله جلسه BGP فعالی وجود ندارد – فعال به این معنی است که روتر فعال تلاش برای اتصال به همسایه BGP مورد نظر. هنگامی که شرایط خطا رخ می دهد، وضعیت ممکن است به حالت غیرفعال برگردد. اما پیشرفت عادی از Active به Connect / OpenSent / OpenConfirm است.

اتصال، OpenSent و OpenConfirm سه مرحله برای ایجاد یک جلسه BGP هستند. در این حالت ها فرصت های زیادی برای خطا وجود دارد که در ادامه به آن خواهیم پرداخت. بیشتر این خطاها منجر به بازگشت وضعیت به حالت غیرفعال می شود و برخی به این معنی است که جلسه به حالت فعال باز می گردد. اما اگر همه چیز طبق برنامه پیش برود، جلسه وارد حالت Established می شود.

به محض اینکه یک جلسه در وضعیت برقرار است، روتر شروع به اسکن جدول BGP خود می کند و می بیند که آیا نیاز به ارسال پیام های به روز رسانی BGP به همسایه خود دارد یا خیر. هیچ نشانگر اضافی وجود ندارد که نشان دهد آیا روتر هنوز در این وضعیت اولیه اسکن/ارسال به‌روزرسانی است یا اینکه یک نسخه کامل از جدول BGP (تا جایی که فیلترها اجازه می‌دهند) به همسایه ارسال شده است و اکنون فقط پیام‌های نگهدارنده وجود دارد. ارسال می شود، تا زمانی که چیزی تغییر کند.

با دستور show BGP همسایه می توانید ببینید که یک همسایه BGP در چه وضعیتی است. در روتر سیسکو اینطور خواهد بود نمایش خلاصه ip bgp یا نمایش خلاصه bgp ipv4 unicast دستور نمایش اطلاعات مربوط به همسایگان دارای IPv4 و نمایش خلاصه bgp ipv6 unicast برای نمایش اطلاعات همسایگان دارای IPv6. مثلا:

Router# show ip bgp summary
Neighbor      V     AS  MsgRcvd MsgSent  TblVer  InQ OutQ   Up/Down  State/PfxRcd
198.51.100.1  4  65001        0       0       0    0    0     never          Idle
198.51.100.2  4  65002        0       0       0    0    0     never        Active        
198.51.100.3  4  65003        3       8       0    0    0  00:01:18             1
198.51.100.4  4  65004        6       5       0    0    0  00:03:43        Idle (Admin)
198.51.100.5  4  65005        6       5       0    0    0  00:00:53        Idle (PfxCt)
198.51.100.6  4  65006        1       2       0    0    0     never          Idle   

همسایه اول در حالت غیر فعال و دومی در حالت فعال است. در هر دو مورد، همانطور که در پیام های دریافتی و ارسالی (ستون های MsgRcvd و MsgSent) نشان داده شده است، هنوز هیچ تماسی با همسایه وجود نداشته است.

همسایه سوم در ایالت تاسیس شده است. با این حال، در این حالت، روتر “Established” را نمی گوید، بلکه تعداد پیشوندهای دریافت شده و پذیرفته شده توسط همسایه را نمایش می دهد. اگر این عدد صفر باشد، یا همسایه هیچ پیشوندی ارسال نکرده است (هنوز)، یا آنهایی که توسط همسایه ارسال شده فیلتر شده اند.

همسایه چهارم در حالت بیکار است زیرا ما پیکربندی کردیم همسایه 198.51.100.4 خاموش شدن، همانطور که توسط (ادمین) مشخص شده است. تا زمانی که پیکربندی آن همسایه با را تغییر ندهیم در این حالت باقی می ماند بدون همسایه 198.51.100.4 خاموش شدن. توجه داشته باشید که امکان پیکربندی نیز وجود دارد خاموش کردن برای یک گروه همتا و سپس همه همسایگانی که بخشی از گروه همتا هستند حذف می شوند.

همسایه پنجم در حالت بیکار است، اما در اینجا دلیل آن را نیز می دانیم: همسایه از حداکثر حد پیشوند پیکربندی شده فراتر رفته است. (S همسایه 198.51.100.5 حداکثر پیشوند … فرمان.) همسایه در حالت بیکار باقی می ماند تا زمانی که جلسه به صورت دستی با دستور راه اندازی مجدد شود پاک کردن آی پی bgp 198.51.100.5. البته اگر همسایه همچنان همان تعداد پیشوند را ارسال می کند و حداکثر حد پیشوند تغییر نکرده است، به سرعت به حالت بیکار (PfxCt) برمی گردد.

همسایه ششم دوباره در حالت بیکار است، اما در اینجا با همسایه اول تفاوت وجود دارد: روتر تعدادی بسته را با همسایه ششم مبادله کرده است، همانطور که در زیر ستون های MsgRcvd و MsgSent می بینیم. این به این معنی است که به احتمال زیاد جلسه به حالت ثابت نمی رسد و در حالت بیکار باقی می ماند زیرا خطایی رخ داده است.
فیلتر کردن پیشوند BGP
هنگامی که مشکلی در جلسه BGP پیش می‌آید، همسایه‌ای که شرایط خطا را تشخیص می‌دهد یک پیام BGP “Notify” ارسال می‌کند و سپس جلسه BGP TCP را خاتمه می‌دهد. با دستور همسایگان ip bgp را نشان دهید [neighbor address] ما می توانیم اطلاعات دقیق در مورد جلسات BGP را ببینیم. (دوباره یا همسایگان unicast bgp ipv4 را نشان دهید یا نمایش همسایگان unicast bgp ipv6 به اندازه مناسب.)

در انتها یک خط “آخرین تنظیم مجدد” وجود دارد. این خط می تواند بسیار آموزنده باشد:

Router# show ip bgp neighbors | incl (BGP neighbor is|Last reset)
BGP neighbor is 192.0.2.1,  remote AS 65501, external link
  Last reset never
BGP neighbor is 192.0.2.2,  remote AS 65502, external link
  Last reset 1w6d, due to BGP Notification received, hold time expired
BGP neighbor is 192.0.2.3,  remote AS 65503, external link
  Last reset 7w0d, due to Active open failed
BGP neighbor is192.0.2.4,  remote AS 65504, external link
  Last reset 1w6d, due to BGP Notification received, Connection Rejected
BGP neighbor is 192.0.2.5,  remote AS 65505, external link
Last reset 2d18h, due to BGP Notification received, Connection Collision Resolution
BGP neighbor is 192.0.2.6,  remote AS 65506, external link
  Last reset 28w4d, due to Peer closed the session

IANA BGP Parameter Registry تعداد زیادی کد خطا و زیر کدهای BGP را برای انواع پیام های BGP که می توانند در یک پیام اعلان ظاهر شوند فهرست می کند. بسیاری از این موارد باید نادر باشند زیرا نشان دهنده مشکل در اجرای پروتکل BGP هستند. مرتبط ترین با عملیات BGP احتمالاً زیرکدهای Cease هستند:

  • به حداکثر تعداد پیشوندها رسیده است
  • تعطیلی اداری
  • شریک پیکربندی نشده است
  • بازنشانی اداری
  • اتصال رد شد
  • تغییر پیکربندی دیگر
  • حل تعارض اتصال
  • منابع تمام شده
  • هارد ریست

این موارد در RFC 4486 توضیح داده شده است که تنها چند صفحه است. توجه داشته باشید که رفع تصادمات اتصال یک اشکال نیست، زمانی اتفاق می‌افتد که دو روتر به طور همزمان به یکدیگر متصل شوند، بنابراین در ابتدا دو جلسه BGP وجود دارد، بنابراین یکی باید خاتمه یابد.

اکثر این اشتباهات کاملاً آشکار هستند. علت اصلی بسیاری از خطاها، پیکربندی نادرست در یک طرف است. این امر به ویژه در صورتی محتمل است که پس از پیکربندی همسایه، اتصال هنوز با موفقیت برقرار نشده باشد. بنابراین تنظیمات و پارامترهایی مانند آدرس های IP و شماره های AS را در هر دو طرف بررسی کنید – هیچ کس از اشتباه تایپی مصون نیست.

اگر جلسه قبلاً کار می کرد و هیچ یک از طرفین هیچ تغییری ایجاد نکردند، ممکن است مشکلی در روتر ارسال کننده اعلان وجود داشته باشد. به عنوان مثال، حافظه روتر ممکن است تمام شده باشد، یا ممکن است در اجرای BGP خطایی وجود داشته باشد. همچنین ممکن است آپدیت AS آپدیت های BGP را ارسال کند که باعث ایجاد مشکل در روتر محلی یا روتر همسایه شود. یک مثال از این مشکل ایجاد شده توسط AS 47868 در سال 2009 است. به دلیل شرایط ناگوار، AS 47868 یک مسیر AS با 252 شماره پیشوند ارسال کرد. این امر باعث شد روترهای سیسکو نتوانند مسیرهایی با 255 AS یا بیشتر را چندین هاپ پایین دست مدیریت کنند. بنابراین، وقتی خطاها واقعاً معنی ندارند، بررسی کنید که در یک AS چند پرش دورتر چه اتفاقی می‌افتد.

آخرین اما نه کم اهمیت، بررسی گزارش روتر می تواند مفید باشد. دستوری که این کار را انجام می دهد این است ورود به سیستم را نشان می دهد. با این کار آخرین پیام های گزارش در بافر لاگ روتر در RAM نمایش داده می شود. اگر این ویژگی فعال نیست یا می خواهید سطح گزارش را تغییر دهید، از دستور configure استفاده کنید ورود به سیستم بافر است . همچنین می‌توانید به مقاصد دیگر مانند سرور سیستم ثبت وارد شوید.

همچنین می توان نمایش پیام های گزارش و اطلاعات اشکال زدایی زنده را در یک جلسه خط فرمان به روتر با دستور روشن کرد. مانیتور ترمینال. این را دوباره خاموش کنید با ترمینال بدون مانیتور. دو پیامی که در گزارش باید مراقب آنها بود به شرح زیر است:

%TCP-6-BADAUTH: No MD5 digest from 192.0.2.1(179) to 192.0.2.2(64444)
%TCP-6-BADAUTH: Invalid MD5 digest from 192.0.2.1(11004) to 192.0.2.1(179)

(اعداد 64444 و 11004 شماره های پورت TCP هستند که متفاوت خواهند بود و شماره پورت 179 بسته به اینکه کدام روتر جلسه BGP را آغاز کرده است ممکن است از آدرس IP اول یا دوم پیروی کند.)

از آنجایی که این مشکلات در سطح TCP هستند، نه در سطح BGP، و فرآیند BGP نمی تواند پیام های ایجاد شده با رمز عبور گم شده یا نادرست را ببیند، این مشکل به راحتی بدون بررسی فایل log قابل چشم پوشی است.

وقتی اشکال زدایی همراه با فعال باشد مانیتور ترمینال، پیام های اشکال زدایی از طریق جلسه خط فرمان نمایش داده می شوند. با فعال کردن انواع مختلف اشکال زدایی مراقب باشید، زیرا اشکال زدایی بیش از حد می تواند به راحتی یک جلسه خط فرمان را مسدود کند و حتی گاهی اوقات باعث از کار افتادن روتر شود. مفیدترین نوع اشکال زدایی است اشکال زدایی رویدادهای bgp. این اطلاعات مفیدی در مورد رویدادهای BGP ارائه می دهد بدون اینکه خیلی طاقت فرسا باشد. دوباره خاموشش کنید با اشکال زدایی رویدادهای bgp یا حذف تمام خطاها

با در نظر گرفتن موارد فوق، باید بتوانید تقریباً تمام مشکلات مربوط به جلسات شکسته BGP را پیدا کنید.




Source link

نوشته های مشابه

دیدگاهتان را بنویسید

دکمه بازگشت به بالا