Cisco Express Forwarding: روترهای مدرن چگونه بسته‌ها را در مقیاس فوروارد می‌کنند

روترهای سازمانی مدرن باید میلیون‌ها بسته را در ثانیه فوروارد کنند، بسیار فراتر از آنچه یک جستجوی جدول مسیریابی روی هر تک بسته می‌توانست پایدار نگه دارد، به همین دلیل Cisco Express Forwarding به‌عنوان معماری فوروارد‌کردن پیش‌فرض روی تقریباً همه دستگاه‌های سیسکو وجود دارد. این مقاله محدودیت‌های کارایی روش‌های فوروارد‌کردن قدیمی‌تر را توضیح می‌دهد، اینکه FIB و جدول adjacency در CEF چگونه فوروارد‌کردن سرعت-بالا را به دست می‌آورند مرور می‌کند، و دستورات ضروری برای تأیید عملیات CEF را پوشش می‌دهد.

Cisco Express Forwardingجدول FIB و Adjacencyتعادل بار CEF

~6 min read · Updated Sep 10, 2026

چرا سرعت فوروارد‌کردن به یک گلوگاه تبدیل شد

جستجوی پایه جدول مسیریابی که پیش‌تر در این مجموعه بحث شد فرآیند منطقی یافتن بهترین مسیر منطبق را توصیف می‌کند، اما چیزی درباره چگونگی انجام کارآمد آن جستجو توسط یک روتر برای هر تک بسته در سرعت‌های خط میلیون‌ها بسته در ثانیه نمی‌گوید. روترهای اولیه سیسکو از یک روش فوروارد‌کردن به نام Process Switching استفاده می‌کردند، که یک جستجوی کامل جدول مسیریابی و تفکیک ARP، که پیش‌تر در این مجموعه بحث شد، را برای هر بسته منفرد انجام می‌داد — فرآیندی بسیار کند برای هر چیز فراتر از حجم‌های ترافیک بسیار پایین.

جایگزین قدیمی‌تر: Fast Switching

یک بهبود میانی، Fast Switching، نتیجه جستجوی بسته اول را در یک کش مسیر ذخیره می‌کرد، پس بسته‌های بعدی به همان مقصد می‌توانستند فرآیند جستجوی کامل را رد کنند. این نسبتاً خوب کار می‌کرد، اما یک ضعف حیاتی داشت: کش به‌طور واکنشی، بر اساس ترافیکی که از قبل دیده شده بود، ساخته می‌شد، به این معنا که اولین بسته به هر مقصد جدید همیشه جریمه جستجوی کامل و کند را متحمل می‌شد، و خود کش می‌توانست منبع قابل‌توجهی از سربار حافظه و پردازش در مقیاس بسیار بزرگ شود.

CEF: پیش‌محاسبه تصمیم فوروارد‌کردن

Cisco Express Forwarding (CEF)، روش فوروارد‌کردن پیش‌فرض مدرن روی تقریباً همه پلتفرم‌های فعلی سیسکو، این را با پیشگیرانه پیش‌محاسبه اطلاعات فوروارد‌کردن برای هر مقصد شناخته‌شده پیش از اینکه حتی هر ترافیکی برایش برسد، به‌جای کش‌کردن واکنشی بر اساس ترافیک مشاهده‌شده، حل می‌کند.

دو ساختار داده اصلی CEF:

FIB (Forwarding Information Base):
  یک کپی ساده‌شده و بهینه‌شده‌برای-سخت‌افزار از
  جدول مسیریابی، شامل فقط اطلاعات مورد نیاز
  برای گرفتن یک تصمیم فوروارد‌کردن — اساساً
  یک نسخه پیش‌محاسبه‌شده از "show ip route"،
  که پیش‌تر در این مجموعه بحث شد، بهینه‌شده
  به‌طور خاص برای سرعت جستجو

Adjacency Table:
  شامل اطلاعات بازنویسی لایه ۲ مورد نیاز برای
  واقعاً فوروارد‌کردن یک بسته — آدرس MAC مقصد
  و اینترفیس خروجی، اساساً یک نسخه پیش‌محاسبه‌شده
  از جدول ARP، که پیش‌تر در این مجموعه درباره
  آدرس‌دهی IPv4 بحث شد

از آنجا که هر دو ساختار پیشگیرانه از جداول مسیریابی و ARP هروقت تغییر کنند ساخته می‌شوند، به‌جای واکنشی از ترافیک مشاهده‌شده، CEF "جریمه اولین-بسته"ای که Fast Switching از آن رنج می‌برد را حذف می‌کند — حتی اولین بسته به یک مقصد کاملاً جدید از همان سرعت فوروارد‌کردن پیش‌محاسبه‌شده مانند هر بسته بعدی بهره می‌برد.

یک تصمیم فوروارد‌کردن CEF واقعاً چگونه کار می‌کند

فرآیند فوروارد‌کردن CEF ساده‌شده برای یک بسته رسیده:

۱. روتر آدرس IP مقصد بسته را بررسی می‌کند
۲. یک جستجو مستقیماً در برابر FIB انجام می‌دهد
   (یک ساختار داده به‌شدت بهینه‌شده، اغلب یک
   ساختار مبتنی‌بر-trie که از نظر روحی مشابه با
   ایندکس‌گذاری مبتنی‌بر-درخت که پیش‌تر در این
   مجموعه درباره پایگاه‌داده‌ها بحث شد است)
۳. ورودی FIB مستقیماً به یک ورودی جدول
   adjacency از‌پیش‌ساخته‌شده اشاره می‌کند
۴. ورودی adjacency بازنویسی دقیق هدر لایه ۲
   مورد نیاز را فراهم می‌کند
۵. بسته با حداقل محاسبه اضافی مورد نیاز
   فوروارد می‌شود

این جداسازی تصمیم "کجا فرستادنش" (FIB) از تصمیم "چگونه فرمتش کنیم برای گام بعدی" (جدول adjacency) چیزی است که اجازه می‌دهد CEF به‌طور کارآمد در سخت‌افزار فوروارد‌کردن تخصصی (ASIC ها) روی پلتفرم‌های سطح‌بالا پیاده‌سازی شود، و نرخ‌های فوروارد‌کردنی بسیار فراتر از آنچه یک CPU عمومی‌منظوره که گام‌های منطقی معادل را انجام می‌دهد می‌توانست پایدار نگه دارد به دست می‌آورد.

تأیید عملیات CEF

Router# show ip cef

Prefix               Next Hop         Interface
0.0.0.0/0             203.0.113.1      GigabitEthernet0/0
192.168.1.0/24        attached         GigabitEthernet0/1
192.168.2.0/24        10.0.0.2         GigabitEthernet0/0

Router# show adjacency detail

IP GigabitEthernet0/0  10.0.0.2(5)
  0 packets, 0 bytes
  00000C9FF23300000C9FF2340800
  ARP    03:58:22

show ip cef تأیید می‌کند FIB با آنچه از جدول مسیریابی انتظار می‌رفت تطبیق دارد، و show adjacency detail اطلاعات بازنویسی لایه ۲ پیش‌محاسبه‌شده واقعی را آشکار می‌کند — رشته هگزادسیمال نشان‌داده‌شده دقیقاً آدرس MAC مقصد و بایت‌های هدری که روی هر بسته فوروارد‌شده به آن مقصد مهر می‌شود را نشان می‌دهد، که تأیید می‌کند CEF هر چیزی که نیاز دارد را بدون انجام تفکیک ARP به‌ازای هر بسته دارد.

تعادل بار CEF در سراسر چند مسیر

وقتی چند مسیر با هزینه-برابر به همان مقصد وجود دارد، که پیش‌تر در این مجموعه درباره معیارهای مسیریابی بحث شد، CEF باید تصمیم بگیرد چگونه ترافیک را در میان آن‌ها توزیع کند، و دو حالت متمایز تعادل بار ارائه می‌دهد.

تعادل بار به‌ازای-مقصد (پیش‌فرض):
  همه بسته‌ها به همان آدرس IP مقصد به‌طور سازگار
  از همان مسیر استفاده می‌کنند، در حالی که مقصدهای
  مختلف ممکن است از مسیرهای مختلف استفاده کنند
  بهره: ترتیب بسته را درون یک جریان واحد حفظ
  می‌کند، که بسیاری اپلیکیشن انتظار دارند

تعادل بار به‌ازای-بسته:
  بسته‌ها در سراسر مسیرهای موجود به‌صورت
  round-robin توزیع می‌شوند، صرف‌نظر از مقصد
  بهره: استفاده پهنای‌باند یکنواخت‌تر در سراسر
  مسیرها، اما ریسک رسیدن بسته‌ها به ترتیب نادرست را
  دارد، چون بسته‌های مختلف در همان جریان ممکن است
  مسیرهایی با تأخیر متفاوت طی کنند

Router(config)# interface gigabitethernet 0/0
Router(config-if)# ip load-sharing per-packet

-- به‌ازای-مقصد پیش‌فرض است و به‌شدت برای
-- بیشتر اپلیکیشن‌ها ترجیح داده می‌شود، چون تحویل
-- خارج‌از-ترتیب بسته می‌تواند کارایی TCP را
-- تنزل دهد و برخی اپلیکیشن‌های بی‌درنگ را مختل کند

تعادل بار به‌ازای-مقصد انتخاب درست برای اکثریت قریب‌به‌اتفاق شبکه‌های تولیدی است، چون ریسک تحویل خارج‌از-ترتیب تحت تعادل بار به‌ازای-بسته معمولاً بر بهبود حاشیه‌ای‌اش در یکنواختی استفاده پهنای‌باند غالب است.

چرا درک CEF برای عیب‌یابی اهمیت دارد

CEF به‌طور پیش‌فرض به‌طور خودکار و شفاف روی دستگاه‌های سیسکو مدرن عمل می‌کند، و بیشتر مدیران هرگز صراحتاً آن را پیکربندی نمی‌کنند — اما تعداد کمی سناریوی عیب‌یابی خاص نیازمند درک مستقیم آن هستند، مانند تشخیص یک روتر که به فوروارد‌کردن ترافیک به مقصدی که مسیرش تازه حذف شده ادامه می‌دهد (که نشان می‌دهد FIB هنوز با جدول مسیریابی همگام‌سازی نشده) یا تشخیص رفتار تعادل-بار غیرمنتظره در سراسر مسیرهای افزونه.

Router# clear ip cef inconsistency-checkers

-- گاهی در عیب‌یابی استفاده می‌شود وقتی به‌نظر
-- می‌رسد FIB و جدول مسیریابی از هم‌گام‌بودن
-- خارج شده‌اند، و بازسازی ساختارهای فوروارد‌کردن
-- CEF را از وضعیت فعلی جدول مسیریابی اجبار می‌کند

چرا معماری CEF زیربنای کارایی شبکه مدرن است

هر ویژگی فوروارد‌کردن پرتوان‌عملیاتی که بعداً در این مجموعه پوشش داده می‌شود، همراه با حجم‌های ترافیک عظیمی که شبکه‌های سازمانی و ارائه‌دهنده خدمات مدرن به‌طور روتین مدیریت می‌کنند، به معماری فوروارد‌کردن کارآمد و پیش‌محاسبه‌شده‌ای که CEF فراهم می‌کند متکی است. درک تمایز بین FIB و جدول adjacency، و دانستن چگونگی تأیید اینکه هر دو به‌درستی پر شده‌اند، دانش عیب‌یابی ضروری‌ای است که فراتر از آنچه تأیید پایه "show ip route" که پیش‌تر در این مجموعه بحث شد می‌تواند آشکار کند می‌رود.

Written & researched by Dr. Shahin Siami

Related Articles

عیب‌یابی سیستماتیک شبکه: یک روش‌شناسی که همه‌چیز را به هم پیوند می‌دهد

هر پروتکل و فناوری‌ای که در سراسر این مجموعه پوشش داده شد فقط زمانی مفید است که یک مسئله شامل آن واقعاً بتواند تحت فشار دنیای واقعی به‌طور کارآمد تشخیص و رفع شود. این مقاله یک روش‌شناسی عیب‌یابی سیستماتیک ساخته‌شده حول لایه‌های OSI ارائه می‌دهد، اعمالش روی یک مسئله اتصال واقع‌بینانه را مرور می‌کند، و نشان می‌دهد دستورات تأیید خاصی که در سراسر این کل مجموعه پوشش داده شدند چگونه در یک فرآیند تشخیصی ساختاریافته جا می‌گیرند.

Continue

NETCONF، YANG، و پایتون: پیکربندی برنامه‌ای شبکه در مقیاس

REST API ها و فرمت‌های JSON/YAML که پیش‌تر در این مجموعه پوشش داده شدند یک رویکرد به اتوماسیون شبکه را نشان می‌دهند، اما NETCONF و YANG یک جایگزین ساختاریافته‌تر و مبتنی‌بر-استاندارد فراهم می‌کنند که به‌طور خاص برای پیکربندی دستگاه شبکه ساخته شده. این مقاله توضیح می‌دهد چه چیزی NETCONF را از یک REST API ساده متمایز می‌کند، اینکه مدل‌های YANG چگونه دقیقاً تعریف می‌کنند داده پیکربندی چگونه به‌نظر می‌رسد را پوشش می‌دهد، و استفاده از پایتون برای تعامل برنامه‌ای با دستگاه‌های شبکه را مرور می‌کند.

Continue

اصول IPsec VPN: امن‌سازی ترافیک در سراسر شبکه‌های نامورد‌اعتماد

اتصال دو سایت در سراسر اینترنت عمومی ترافیک را در معرض رهگیری قرار می‌دهد مگر اینکه به‌درستی رمزگذاری شود، و IPsec چارچوب استانداردی برای ساخت تونل‌های امن و احراز‌هویت‌شده بین سایت‌ها فراهم می‌کند. این مقاله فرآیند مذاکره دومرحله‌ای IKE را توضیح می‌دهد، تمایز بین پروتکل‌های AH و ESP را پوشش می‌دهد، پیکربندی یک VPN سایت-به-سایت پایه IPsec را مرور می‌کند، و دستورات تأیید ضروری را پوشش می‌دهد.

Continue

اصول MPLS: توضیح سوئیچینگ برچسب

مسیریابی IP سنتی نیازمند این است که هر روتر در طول یک مسیر یک جستجوی کامل جدول مسیریابی روی هر بسته انجام دهد، اما MPLS رویکردی اساساً متفاوت را با گرفتن آن تصمیم فوروارد‌کردن یک‌بار و متصل‌کردن یک برچسب ساده که هر روتر بعدی می‌تواند به‌جای آن استفاده کند اتخاذ می‌کند. این مقاله مفهوم اصلی سوئیچینگ-برچسب را توضیح می‌دهد، اینکه پروتکل توزیع برچسب چگونه جداول فوروارد‌کردن برچسبی که این را ممکن می‌کنند می‌سازد را مرور می‌کند، و بهره‌های عملی‌ای که MPLS در شبکه‌های ارائه‌دهنده واقعی فراهم می‌کند را پوشش می‌دهد.

Continue

Route Reflector و Confederation های BGP: مقیاس‌دهی iBGP فراتر از Full Mesh

نیازمندی full-mesh iBGP، که به‌طور مختصر پیش‌تر در این مجموعه ذکر شد، با رشد یک سیستم خودمختار به یک مسئله جدی مقیاس‌دهی تبدیل می‌شود، که نیازمند تعدادی جلسه است که به‌طور درجه‌دوم با تعداد روتر افزایش می‌یابد. این مقاله دقیقاً توضیح می‌دهد چرا full mesh مقیاس‌پذیر نیست، اینکه route reflector ها چگونه این را با شل‌کردن قوانین معمول انتشار-مسیر BGP حل می‌کنند مرور می‌کند، و confederation ها را به‌عنوان یک رویکرد جایگزین که یک AS واحد را به سیستم‌های خودمختار زیرمجموعه کوچک‌تر تقسیم می‌کند پوشش می‌دهد.

Continue

بررسی عمیق انواع ناحیه OSPF: Stub، Totally Stubby، و NSSA

طراحی OSPF چندناحیه‌ای پایه، که پیش‌تر در این مجموعه پوشش داده شد، از قبل اندازه پایگاه‌داده را با نگه‌داشتن LSA های جزئی نوع ۱ و ۲ محلی به ناحیه خودشان کاهش می‌دهد، اما انواع ناحیه تخصصی OSPF فراتر می‌روند، و به‌طور خاص LSA های خارجی نوع ۵ را هدف قرار می‌دهند. این مقاله انواع LSA که باید برای ساخت هر نوع ناحیه تخصصی سرکوب شوند را توضیح می‌دهد، پیکربندی نواحی stub، totally stubby، و not-so-stubby را مرور می‌کند، و مبادلات خاصی که هر انتخاب طراحی شامل می‌شود را پوشش می‌دهد.

Continue