طراحی شبکه بخش 1: موضوعات پایه

طراحی شبکه‌های بزرگ‌مقیاس برای پاسخ‌گویی به نیازهای پویای کسب‌وکارها و فناوری اطلاعات (IT) امروزی، کاری پیچیده است. این موضوع به‌ویژه زمانی چالش‌برانگیز می‌شود که شبکه برای فناوری‌ها و نیازهایی طراحی شده باشد که مربوط به سال‌ها پیش هستند و اکنون کسب‌وکار تصمیم گرفته فناوری‌ها و معماری‌های جدید IT را به‌کار گیرد تا به اهداف خود برسد. با این حال، شبکهٔ موجود ممکن است برای پاسخ‌گویی به نیازهای این فناوری‌های جدید طراحی نشده باشد.
بنابراین، برای دستیابی به هدف مورد نظر در یک طراحی خاص، طراح شبکه باید رویکردی ساختاریافته برای طراحی اتخاذ کند.

دو رویکرد متداول برای تحلیل و طراحی شبکه وجود دارد:

رویکرد از بالا به پایین (Top-down approach):

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

رویکرد از پایین به بالا (Bottom-up approach):

در مقابل، رویکرد از پایین به بالا بر انتخاب فناوری‌های شبکه و مدل‌های طراحی از ابتدا تمرکز دارد. این رویکرد احتمال خطای طراحی را افزایش می‌دهد، زیرا ممکن است شبکه نتواند نیازهای کسب‌وکار یا برنامه‌های کاربردی را برآورده کند.

برای دستیابی به طراحی راهبردی (strategic design) موفق، باید تمرکز بیشتری بر جنبه‌های کسب‌وکار وجود داشته باشد. این شامل تمرکز اولیه بر اولویت‌های تجاری، محرک‌ها و نتایج، اهداف فنی، و سرویس‌های فعلی و آینده است.
در واقع، در شبکه‌های امروزی، نیازهای کسب‌وکار هستند که جهت‌دهندهٔ ابتکارهای IT و شبکه محسوب می‌شوند.

هنگامی که بحث طراحی شبکه مطرح می‌شود، عناصر کلیدی که هر طراح شبکه باید بداند و درک کند عبارت‌اند از:

• Network Design Fundamentals (پایه‌های طراحی شبکه)

• Network Design Principles (اصول طراحی شبکه)

• Network Design Techniques (تکنیک‌های طراحی شبکه)

شکل‌های 1-1 و 1-2 نشان می‌دهند چگونه این عناصر طراحی شبکه با یکدیگر تعامل دارند تا پایهٔ معماری طراحی شبکه را شکل دهند. در ادامهٔ این فصل، همچنین متداول‌ترین خطاهای طراحی شبکه را که ممکن است طراحان مرتکب شوند بررسی خواهیم کرد.

مبانی طراحی شبکه (Network Design Fundamentals)

مبانی طراحی شبکه عناصر پایه‌ای هستند که همهٔ طراحان شبکه باید آن‌ها را درک کرده و بدانند چگونه از آن‌ها استفاده کنند.

عناصر کلیدی شامل موارد زیر است:

• Mindset (طرز فکر)
• Requirements (الزامات)
• Design use cases (موارد استفاده طراحی)
• The business (جنبه‌های تجاری)
• Constraints (محدودیت‌ها)
• “Why” (چرایی طراحی)

Mindset (طرز فکر)

در وهلهٔ اول، طرز فکر شما مهم‌ترین عامل برای موفقیت است. دانستن فناوری مهم است، اما بخش نسبتاً آسان‌تر این مسیر محسوب می‌شود. با صرف زمان و تلاش می‌توان دانش فنی لازم را فرا گرفت، اما بسیاری از داوطلبانی که قصد دارند در آزمون CCDE یا طراحی شبکه شرکت کنند، فاقد طرز فکر طراحی (design mindset) صحیح هستند.

بیشتر ما تا مراحل بعدی شغلی خود، آموزش رسمی در مورد طرز فکر طراحی دریافت نمی‌کنیم. در این بخش، به تشریح مؤلفه‌های مختلف یک طرز فکر طراحی مناسب پرداخته می‌شود، طرز فکری که می‌تواند در تمام موقعیت‌های طراحی، چه در CCDE و چه در هر موقعیت طراحی شبکه، شما را موفق کند. طرز فکر (Mindset) یکی از شش عنصر اصلی مبانی طراحی شبکه است.

نکته: ذهنیت «اجرایی» (implementation mindset) برای طراحی شبکه مناسب نیست؛ باید ذهنیتی مبتنی بر طراحی شبکه داشته باشید تا بتوانید در موقعیت‌های مختلف طراحی شبکه موفق شوید.

Functional Requirements (الزامات عملکردی)

الزامات عملکردی (Functional Requirements) اساس هر طراحی سیستم را تشکیل می‌دهند، زیرا مشخص می‌کنند سیستم چه کارهایی انجام می‌دهد و شامل عملکردهای فناوری و سیستمی می‌شوند.

به طور خاص، الزامات عملکردی تعیین می‌کنند که چه فناوری‌ها یا سیستم‌هایی باید از دیدگاه فنی، نیازهای کسب‌وکار را برآورده سازند.

برای مثال:
ارائه‌دهندهٔ خدماتی که از MPLS (Multiprotocol Label Switching) استفاده می‌کند، ممکن است الزام عملکردی خود را چنین تعریف کند:

“روترهای لبهٔ ارائه‌دهنده (Provider Edge Routers) باید بتوانند ترافیک VoIP را از طریق لینک فیبر نوری 10G منتقل کنند، در حالی که داده‌های عادی از طریق لینک OC-48 ارسال می‌شوند.”

به طور ضمنی، این الزام بیانگر آن است که روترهای PE باید مکانیزمی برای ارسال انواع مختلف ترافیک در مسیرهای متفاوت داشته باشند، مانند MPLS Traffic Engineering (MPLS-TE). بنابراین، الزامات عملکردی گاهی به عنوان الزامات رفتاری (Behavioral Requirements) شناخته می‌شوند، زیرا مشخص می‌کنند سیستم چه کار می‌کند.

یادداشت:
طراحی‌ای که الزامات عملکردی کسب‌وکار را در نظر نگیرد، طراحی ضعیفی محسوب می‌شود.
البته در دنیای واقعی، همیشه همهٔ الزامات عملکردی مستقیماً به طراح اعلام نمی‌شوند و ممکن است به‌صورت غیرمستقیم یا ضمنی وجود داشته باشند.
معمولاً مسئولیت شناسایی و مستندسازی الزامات عملکردی بر عهدهٔ طراح شبکه است و او باید تأیید نهایی (sign-off) مدیران را پیش از آغاز طراحی دریافت کند.

Technical Requirements (الزامات فنی)

الزامات فنی (Technical Requirements) جنبه‌های فنی زیرساخت شبکه را مشخص می‌کنند از جمله سطح امنیت، دسترس‌پذیری (availability)، و یکپارچگی (integration).

این الزامات که گاهی الزامات غیرعملکردی (Nonfunctional Requirements) نامیده می‌شوند، باید به‌گونه‌ای تنظیم شوند که انتخاب فناوری را توجیه کنند.

از آنجا که فناوری‌ها به سرعت تغییر می‌کنند، الزامات فنی پویاترین بخش الزامات محسوب می‌شوند.

نمونه‌هایی از الزامات فنی عبارت‌اند از:

• سطح بالاتر در دسترس‌پذیری شبکه (مثلاً استفاده از FHRP – First Hop Redundancy Protocol)
• پشتیبانی از یکپارچگی با ابزارها و سرویس‌های شبکه مانند NetFlow Collector یا سرورهای احراز هویت و مجوزدهی (RADIUS)
• پیاده‌سازی مکانیزم‌های امنیتی برای زیرساخت شبکه (مانند Control Plane Protection یا Access Control Lists)

یادداشت:
الزامات فنی به طراحان کمک می‌کنند تا مشخصات فنی (features, protocols) و نرم‌افزارهای لازم برای برآوردن نیازها را تعیین کنند و حتی می‌توانند بر انتخاب سخت‌افزار تأثیر بگذارند.

Application Requirements (الزامات برنامه‌ها یا سرویس‌ها)

الزامات برنامه‌ها (Application Requirements) عوامل اصلی هستند که مسیر طراحی شبکه را تعیین یا محدود می‌کنند.
برای مثال، اگر یک برنامه نیاز به اتصال در لایهٔ ۲ (Layer 2) داشته باشد، طراحی باید از پروتکل‌های لایهٔ ۲ مانند VLAN Spanning بین دیتاسنترها استفاده کند.

از دیدگاه کسب‌وکار، تجربهٔ کاربر (User Experience) یکی از بالاترین اولویت‌هاست. اصطلاح End Users (کاربران نهایی) بسته به نوع کسب‌وکار، می‌تواند معانی متفاوتی داشته باشد.

سه دستهٔ اصلی کاربران نهایی عبارت‌اند از:

• Customers (مشتریان): افراد یا گروه‌هایی مانند کاربران یک بانک یا مشتریان ارائه‌دهندهٔ سرویس MPLS. رضایت مشتری به‌طور مستقیم بر شهرت و درآمد کسب‌وکار اثر دارد.
• Internal Users (کاربران داخلی): کارمندان یا کاربران درون‌سازمانی؛ بهره‌وری این گروه تأثیر مستقیمی بر کارایی عملکرد کسب‌وکار دارد.
• Business Partners (شرکای تجاری): سازمان‌ها یا نهادهایی که با شرکت همکاری می‌کنند؛ تعامل مؤثر با شرکا باعث موفقیت تجاری و دستیابی به اهداف استراتژیک می‌شود.

اگر یک شبکه یا فناوری نتواند سطح مورد انتظار تجربهٔ کاربر را تأمین کند (Quality of Experience – QoE)، شکست در اهداف تجاری رخ می‌دهد.

به بیان دیگر، در طراحی شبکه باید درک شود که تجربهٔ کاربر چگونه شکل می‌گیرد و چه عواملی بر آن اثر می‌گذارند.

برای مثال، شرکتی که خدمات مالی آنلاین ارائه می‌دهد و از Video Communication برای ارتباط با مشتریان استفاده می‌کند، اگر طراحی شبکه به درستی انجام نشود، تجربهٔ ضعیفی برای کاربران ایجاد می‌شود که در نهایت به شکست در کسب‌وکار منجر خواهد شد.

همچنین در برخی شرایط، الزامات برنامه‌ها ممکن است به الزامات عملکردی تبدیل شوند. برای مثال، ارائه‌دهندهٔ خدمات VoIP ممکن است الزام کند که تأخیر (Delay) کمتر از 150 ms و Packet Loss کمتر از 1% باشد. این الزامات SLA (Service Level Agreement) محسوب می‌شوند و باید در طراحی در نظر گرفته شوند.

برای ارزیابی الزامات برنامه‌ها، طراحان شبکه باید به سؤالات زیر پاسخ دهند:

• برنامه چه میزان ترافیک شبکه نیاز دارد؟
• سطح بحرانی بودن (Criticality) برنامه و نیازمندی سطح سرویس (Service Level Requirement) آن برای کسب‌وکار چقدر است؟
• آیا برنامه نیاز به جداسازی خاصی برای رعایت الزامات امنیتی یا مقررات صنعتی دارد؟
• ویژگی‌های فنی برنامه چیست؟

• پس از قطع اتصال، برنامه چه مدت زمان برای بازیابی وضعیت (State) یا نشست (Session) خود نیاز دارد؟

تدوین الزامات طراحی (Crafting the Design Requirements)

این بخش نشان می‌دهد چگونه انواع مختلف الزامات می‌توانند به‌صورت جمعی منجر به دستیابی به طراحی شبکهٔ مطلوب شوند؛ طراحی‌ای که در نهایت دستیابی به اهداف تجاری را تسهیل می‌کند.

برای روشن‌سازی این موضوع، از مثالی استفاده شده که فرآیند گردآوری اطلاعات را از نتایج مورد انتظار کسب‌وکار تا سطح فنی (مانند الزامات فنی مورد نیاز) دنبال می‌کند. الزامات (Requirements) یکی از شش بخش اصلی در مبانی طراحی شبکه محسوب می‌شود.

یک شرکت خرده‌فروشی در حال گسترش کسب‌وکار خود به چندین شعبهٔ بین‌المللی جدید در ۱۲ ماه آینده است. اما با زیرساخت فعلی IT خود، با مشکلاتی از جمله هزینهٔ بالا در مدیریت و نگهداری دو شبکهٔ داده و صوت جداگانه مواجه است. این شرکت همچنین می‌خواهد در فناوری‌هایی سرمایه‌گذاری کند که بهره‌وری کارکنان را افزایش داده و فرآیندهای کاری را بهبود بخشد.

این سناریوی ساده به ما کمک می‌کند تا متوجه شویم دامنهٔ طراحی (Design Scope) چیست و چگونه می‌تواند بر گزینه‌های مختلف طراحی شبکه در هر موقعیت خاص تأثیر بگذارد.

Design Scope (دامنه طراحی)

در هر پروژهٔ طراحی، طراحان شبکه باید دامنهٔ طراحی را با دقت تحلیل و ارزیابی کنند، پیش از آن‌که اقدام به گردآوری اطلاعات یا طراحی نقشهٔ شبکه نمایند.

مشخص‌کردن دامنه اهمیت حیاتی دارد، زیرا تعیین می‌کند که آیا طراحی برای ایجاد یک شبکهٔ جدید (Greenfield) است یا برای بهبود شبکهٔ موجود (Brownfield).

دامنه طراحی می‌تواند گسترده یا محدود باشد؛ برای مثال، آیا فقط یک ماژول شبکه در حال طراحی است یا کل شبکه شامل چندین ماژول؟ دامنهٔ طراحی بر نوع اطلاعات مورد نیاز، حجم داده‌های جمع‌آوری‌شده و حتی زمان انجام طراحی تأثیر مستقیم دارد.

Table 1-2 – نمونه‌هایی از دامنه طراحی (Design Scope Examples

Design Scope	Detailed Design Scope Example
Enterprise campus network and remote sites	پیاده‌سازی تلفن IP در سراسر سازمان، که ممکن است نیاز به طراحی مجدد VLANها، QoS، LAN، WAN، دیتاسنتر (DC) و نقاط دسترسی از راه دور داشته باشد.
Campus only	افزودن مفهوم چندمستاجری (Multi-tenancy) به شبکهٔ محلی دانشگاه یا سازمان، شامل طراحی VLAN، آدرس‌های IP و ایزوله‌سازی مسیر در سطح LAN.
Optimize enterprise edge availability	افزودن لینک افزونه (Redundant link) برای دسترسی از راه دور که ممکن است نیازمند طراحی مجدد ماژول WAN یا استفاده از تونل‌های Overlay باشد.

یادداشت:
شناسایی دقیق دامنه طراحی بسیار مهم است.
به عنوان مثال، ممکن است محدودهٔ شبکه بزرگ باشد، اما تمرکز طراحی فقط روی افزودن یا ادغام یک دیتاسنتر جدید باشد. در این حالت، طراح باید روی همان بخش تمرکز کند، اما همچنان باید کل شبکه را از دیدگاه جامع (Holistic) در نظر بگیرد.

نکته:
شناسایی آنچه خارج از دامنه (Out of Scope) است نیز بسیار حیاتی است. این امر از بروز پدیده‌ای به نام Scope Creep (گسترش غیرقابل کنترل دامنه پروژه) جلوگیری می‌کند که می‌تواند کل پروژه را با شکست مواجه سازد.

Design Use Cases (موارد استفاده طراحی شبکه)

برای ایجاد یک طراحی موفق، باید نوع مورد استفاده (Use Case) پروژهٔ طراحی شبکه را به‌درستی شناسایی کنید.
Use Caseها یکی از شش بخش اصلی در مبانی طراحی شبکه هستند.

انواع اصلی Use Caseهای طراحی شبکه عبارت‌اند از:

Greenfield (شبکه جدید)

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

در این حالت، شما در حال طراحی، معماری و ساخت محیطی کاملاً تازه هستید و باید اطمینان حاصل کنید که پیشنهادتان با نیازهای واقعی کسب‌وکار هم‌خوانی دارد.

Brownfield (شبکه موجود)

اکثر طراحی‌های شبکه در دنیای واقعی از نوع Brownfield هستند یعنی شبکه‌ای از قبل وجود دارد که در حال فعالیت است.

در این سناریو، باید وضعیت فعلی را دقیقاً تحلیل کرده و بفهمید چه پروتکل‌ها و توپولوژی‌هایی در حال اجرا هستند.
این تحلیل به شما کمک می‌کند تا بفهمید چگونه طراحی جدید می‌تواند با محیط موجود ادغام شود.

Add Technology or Application (افزودن فناوری یا برنامه)

افزودن فناوری جدید یا برنامه‌ای به شبکهٔ موجود می‌تواند فرآیندی پیچیده باشد. در این Use Case باید بررسی شود که افزودن فناوری جدید چه تأثیری بر اجزای دیگر شبکه می‌گذارد.

مثلاً آیا افزودن فناوری جدید باعث ایجاد اختلال در الگوهای ترافیک یا کاهش زمان همگرایی (Convergence Time) می‌شود؟
درک صحیح این الزامات به طراح کمک می‌کند تا در مورد تنظیمات شبکه و ویژگی‌هایی مانند QoS تصمیم‌گیری بهتری انجام دهد.

Replace Technology (جایگزینی فناوری)

در این نوع Use Case، فناوری موجود با فناوری جدید جایگزین می‌شود تا نیازهای فنی جدید را برآورده کند. ممکن است شامل جایگزینی پروتکل مسیریابی، سازوکار امنیتی یا حتی فناوری هستهٔ شبکه باشد. در این حالت، باید اثرات جانبی و ناسازگاری احتمالی با سیستم‌های فعلی را بررسی کنید.

نکته:
هنگام جایگزینی فناوری، باید مطمئن شوید این کار به دلایل صحیح انجام می‌شود.
مثلاً جایگزینی WAN فعلی با SD-WAN بدون توجیه تجاری منطقی اشتباه است.
همچنین باید یک Migration Plan (برنامهٔ مهاجرت) دقیق و آزموده داشته باشید و پس از هر گام، اعتبارسنجی انجام دهید تا مطمئن شوید همه چیز طبق انتظار پیش می‌رود.

Merge or Divest (ادغام یا تفکیک شبکه‌ها)

این Use Case شامل چالش‌های فنی و غیرفنی مرتبط با ادغام (Merger) یا تفکیک (Divestment) شبکه‌ها است.

• Merger (ادغام):
  در این سناریو دو کسب‌وکار مستقل با هم ادغام می‌شوند تا یک شبکهٔ یکپارچه تشکیل دهند. مثلاً باید از تداخل آدرس‌های IP (مانند محدوده‌های RFC1918) جلوگیری شود. در کوتاه‌مدت می‌توان از NAT برای ترجمهٔ IPها استفاده کرد و در بلندمدت ممکن است لازم باشد کل آدرس‌دهی یک سازمان بازطراحی شود.

• Divestment (تفکیک):
  در این حالت، یک شرکت یا بخش از آن جدا می‌شود و شبکه به چند بخش مستقل تقسیم می‌گردد. این دشوارترین نوع Use Case است، زیرا طراح باید اطمینان حاصل کند که هر بخش جداشده همچنان بتواند به‌صورت مستقل و موفق عمل کند.

Scaling a Network (مقیاس‌پذیری شبکه)

سناریوی scaling جنبه‌های مختلف مقیاس‌پذیری را در سطوح مختلف مانند توپولوژی فیزیکی و طراحی مقیاس‌پذیری در لایه‌های ۲ و ۳ پوشش می‌دهد.

چالش اصلی در این بخش به بهینه‌سازی طراحی موجود برای دستیابی به سطح بالاتری از مقیاس‌پذیری مربوط است. در این مسیر، ممکن است محدودیت‌ها یا نیازهای خاص تجاری وجود داشته باشد که گزینه‌های در دسترس طراح شبکه را محدود کند.

برخی سؤالات کلیدی که باید در این سناریو بررسی شوند عبارت‌اند از:

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

مثال:
فرض کنید از شما خواسته می‌شود تا مشکل معماری شبکه‌ای را که با رشد شرکت همگام نیست، برطرف کنید. ممکن است طراحی فعلی فقط شامل یک ناحیهٔ OSPF ساده باشد که دیگر پاسخگوی الزامات کسب‌وکار نیست. در این حالت می‌توان از طراحی چندناحیه‌ای (multi-area) و تکنیک‌های فیلترینگ LSA برای بهبود مقیاس‌پذیری استفاده کرد.

Design Failure (شکست طراحی)

در بیشتر مواقع، سناریوی design failure زمانی رخ می‌دهد که طراح برای رفع مشکلی فراخوانده می‌شود. در چنین شرایطی، نقش شما شبیه پزشک اورژانس است که باید منبع مشکل را شناسایی و فوراً درمان کند.

مثال رایج شکست طراحی می‌تواند تنظیم نادرست نقش‌های حیاتی مانند Spanning Tree Protocol (STP) و First Hop Redundancy Protocol (FHRP) باشد. اگر STP root bridge و FHRP default gateway در یک مسیر تراز نباشند، شبکه دچار مسیر‌یابی غیربهینه می‌شود که در نهایت منجر به شکست طراحی خواهد شد.

The Business (کسب‌وکار)

چرا تصمیمات طراحی شبکه می‌گیریم؟

مهندسان و طراحان شبکه اغلب شبکه‌ها را بدون در نظر گرفتن هدف واقعی طراحی می‌کنند. وقتی از آن‌ها پرسیده می‌شود «چرا این کار را کردی؟»، پاسخ‌هایی مثل «همیشه همین‌طور انجام داده‌ایم» یا «در اسکریپت نوشته شده بود» می‌دهند.

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

البته، همهٔ سازمان‌ها به‌منظور کسب سود کار نمی‌کنند. در سازمان‌های عمومی یا دولتی، هدف ممکن است ارائهٔ خدمات (مثل پلیس، آتش‌نشانی یا مراقبت‌های محیط‌زیستی) باشد نه سود مالی.

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

Constraints (محدودیت‌ها)

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

محدودیت‌ها یکی از مؤلفه‌های اصلی مبانی طراحی شبکه هستند و به سه دسته تقسیم می‌شوند:

1. Business constraints (محدودیت‌های تجاری)
2. Application constraints (محدودیت‌های نرم‌افزار یا کاربرد)
3. Technology constraints (محدودیت‌های فنی)

Business Constraints (محدودیت‌های تجاری)

این محدودیت‌ها می‌توانند شامل مواردی مانند بودجهٔ محدود، کمبود نیروی متخصص، یا محدودیت‌های قراردادی (Contractual) باشند.
مثلاً:

«کسب‌وکار بودجه ندارد تا تجهیزات جدید خریداری کند»
یا
«قرارداد پشتیبانی فقط برای مدت مشخصی معتبر است.»

Application Constraints (محدودیت‌های برنامه‌ای)

محدودیت‌هایی هستند که به‌دلیل نحوهٔ توسعهٔ نرم‌افزار یا سرویس ایجاد می‌شوند. مثلاً یک نرم‌افزار قدیمی ممکن است به ارتباط لایهٔ ۲ بین سرورها نیاز داشته باشد. در نتیجه، طراح مجبور می‌شود توپولوژی‌ای طراحی کند که چنین ارتباطی را فراهم کند.

همچنین ممکن است آدرس‌های IP در کد نرم‌افزار به‌صورت Hardcode باشند، در نتیجه باید طراحی طوری باشد که این آدرس‌ها بدون مشکل کار کنند.

Technology Constraints (محدودیت‌های فنی)

از دید فنی، ممکن است سازمان به تجهیزات یا فناوری خاصی وابسته باشد مثلاً فقط از محصولات یک Vendor مشخص (مثل Cisco یا Juniper) استفاده کند. یا برعکس، ممکن است از فناوری اختصاصی‌ای استفاده کند که به‌راحتی قابل جایگزینی نیست.

این محدودیت‌ها مانند «قوانین فیزیکی» در طراحی شبکه هستند باید آن‌ها را بپذیریم و بر اساسشان تصمیم بگیریم. هر طراحی شبکه منحصر‌به‌فرد است، زیرا هر سازمان مجموعه‌ای متفاوت از محدودیت‌های تجاری، فنی و برنامه‌ای دارد.

Common Constraints (محدودیت‌های رایج)

1. Cost (هزینه):
   یکی از مهم‌ترین محدودیت‌هاست. هزینه فقط زمانی محدودیت محسوب می‌شود که به‌طور صریح در سناریو ذکر شده باشد.
2. Time (زمان):
   اگر زمان پیاده‌سازی یا انتقال محدود باشد، این نیز به‌عنوان Constraint در نظر گرفته می‌شود.
3. Location (مکان):
   مکان‌های جغرافیایی دورافتاده ممکن است محدودیت‌هایی مانند پهنای باند پایین یا تأخیر زیاد داشته باشند.
4. Infrastructure (زیرساخت):
   استفاده از تجهیزات قدیمی که قابلیت ارتقا ندارند می‌تواند طراحی را محدود کند.
5. Staff Expertise (تجربهٔ کارکنان):
   اگر پرسنل در فناوری جدید مهارت کافی نداشته باشند، دو گزینه وجود دارد:
   • آموزش نیروهای فعلی (با هزینه و ریسک زمانی بالا)
   • استخدام نیروهای متخصص جدید (با هزینهٔ بالاتر اما زمان کمتر)

نکته:
در صورتی که راه‌حل جدید موجب صرفه‌جویی قابل‌توجه در هزینه‌های سازمان شود، می‌توان هزینهٔ استخدام نیروی متخصص جدید را توجیه کرد.

Identifying Requirements with “Why” (شناسایی الزامات با پرسش «چرا؟»)

اغلب، مشتریان می‌گویند «این یک الزام است»، اما وقتی بپرسید «چرا؟»، پاسخ منطقی ندارند. اینجاست که باید از روش پنج چرا (Five Whys) استفاده کرد همان روشی که شرکت Toyota برای یافتن ریشهٔ مشکلات به‌کار می‌برد.

طراح شبکه باید همیشه بفهمد که چرا مشتری یک نیاز خاص را مطرح کرده است. مثلاً، ممکن است مشتری فکر کند فناوری جدید:

• امنیت را افزایش می‌دهد،
• هزینه‌ها را کاهش می‌دهد،
• یا عملکرد را بهبود می‌بخشد.

وظیفهٔ طراح این است که دلیل واقعی را کشف کند.

سؤالات کلیدی که باید بپرسید:

• با این فناوری دقیقاً چه مشکلی را حل می‌کنیم؟
• فرآیندهای فعلی مشتری چگونه کار می‌کنند؟
• این فناوری چه تغییری در آن فرآیندها ایجاد خواهد کرد؟
• سیاست‌ها و خط‌مشی‌های حاکمیتی چگونه تحت تأثیر قرار می‌گیرند؟

در نهایت، پرسش «چرا؟» یکی از شش رکن اصلی در مبانی طراحی شبکه است و دقیقاً در همین نقطه است که فرآیند طراحی، معماری و مهندسی شبکه آغاز می‌شود.

Network Design Principles (اصول طراحی شبکه)

در ده سال گذشته تغییرات متعددی در نحوهٔ نگرش طراحان شبکه به اصول طراحی شبکه ایجاد شده است. اصول طراحی شبکه شامل موارد زیر هستند:

• Security (امنیت)
• Scalability (مقیاس‌پذیری)
• Availability (دسترس‌پذیری)
• Cost (هزینه)
• Manageability (قابلیت مدیریت)

قبل از بررسی این پنج اصل طراحی شبکه، ابتدا باید با مفهومی آشنا شویم که به‌صورت دقیق در هیچ‌کدام از دسته‌های فوق قرار نمی‌گیرد اما برای همهٔ طراحان شبکه حیاتی است این مفهوم Unstated Requirements (الزامات بیان‌نشده) نام دارد.

Unstated Requirements (الزامات بیان‌نشده)

در بسیاری از موارد، مشتریان به‌صورت صریح نیازهای خود را اعلام نمی‌کنند. آن‌ها فرض می‌کنند شما به‌عنوان طراح شبکه متوجه نیازشان هستید. وظیفهٔ شما فقط شناسایی الزامات نیست، بلکه باید سطح اهمیت هر الزام را نیز تعیین کنید.

به‌عنوان مثال، آیا این شبکه نباید نقطهٔ تکیه‌گاه (Single Point of Failure) داشته باشد؟
یا باید چند نقطهٔ افزونه برای افزونگی (Dual Points of Failure) طراحی شود؟

به یاد داشته باشید: مفهوم الزامات بیان‌نشده همیشه باید در ذهن طراح وجود داشته باشد، زیرا در دنیای امروز تقریباً تمام اصول طراحی شبکه، شامل الزامات ضمنی یا بیان‌نشده هستند.

Pervasive Security (امنیت فراگیر)

به‌طور تاریخی، امنیت به‌عنوان یکی از اصول طراحی شبکه در نظر گرفته نمی‌شد؛ اما اکنون به دلیل اهمیت حیاتی آن برای کسب‌وکار، یکی از ارکان اصلی طراحی شبکه محسوب می‌شود.

دو سؤال ساده اما حیاتی در این زمینه عبارت‌اند از:

• اگر شبکه‌تان مورد نفوذ قرار گیرد چه اتفاقی برای کسب‌وکارتان می‌افتد؟
• اگر یکپارچگی داده‌هایتان از بین برود چه می‌شود؟

پاسخ به این پرسش‌ها می‌تواند نتایج شدیدی داشته باشد:

• از بین رفتن اعتبار تجاری (Business Reputation)
• از دست رفتن اعتماد مشتریان
• زیان مالی و کاهش درآمد
• عدم انطباق با استانداردهای قانونی و جریمه یا تعطیلی
• در موارد شدید، ورشکستگی کسب‌وکار

سه مدل امنیتی رایج در طراحی شبکه:

1. Perimeter Security (امنیت محیطی یا مدل لاک‌پشتی)

این مدل قدیمی‌ترین نوع امنیت است که بر فایروال در مرز شبکه تمرکز دارد. فایروال محدود می‌کند چه ترافیکی وارد شبکه شود یا از آن خارج گردد. در داخل شبکه اما هیچ کنترل امنیتی دیگری وجود ندارد؛ در نتیجه ترافیک East–West (میان سرورها و منابع داخلی) آزادانه جریان دارد.

2. Session- and Transaction-Based Security (امنیت مبتنی بر نشست و تراکنش)

این مدل تکامل‌یافتهٔ مدل محیطی است. در اینجا کاربران و دستگاه‌ها شامل چاپگرها، دوربین‌ها و غیره قفل‌شده و کنترل‌شده‌اند. ترافیک East–West بر اساس هویت دستگاه، کاربر، و سطح دسترسی موردنیاز (Need-to-Access) کنترل می‌شود. در این مدل، احراز هویت و مجوزدهی ۱۰۰٪ برای هر نشست و تراکنش انجام می‌گیرد.

3. Zero Trust Architecture (معماری اعتماد صفر)

مدرن‌ترین مدل امنیتی است که با تحلیل داده‌های بلادرنگ و تصمیم‌گیری مبتنی بر AI/ML (هوش مصنوعی و یادگیری ماشین) کار می‌کند. در این مدل، هر کاربر، سرویس، یا دستگاه یک Trust Score (امتیاز اعتماد) دارد. این امتیاز ممکن است بر اساس موقعیت جغرافیایی، نوع اتصال، یا حتی زمان روز تغییر کند.

به‌عنوان مثال، اگر کاربری از کافی‌شاپ با VPN متصل شود، Trust Score پایین‌تری نسبت به کاربری دارد که از دفتر شرکت متصل است.

در بخش ها و پست های بعدی (Security Is Pervasive) به تفصیل دربارهٔ Zero Trust صحبت خواهد شد، اما فعلاً کافی است بدانید که این مدل تحول بعدی امنیت شبکه است.

Shifting of Availability (تحول در مفهوم دسترس‌پذیری)

در گذشته وقتی از Availability صحبت می‌شد، بیشتر منظور redundancy (افزونگی) یا fault tolerance (تحمل خطا) بود. اما امروزه Availability ترکیبی از چند مفهوم کلیدی است:

• Redundancy: داشتن منابع جایگزین برای انجام همان وظیفه، تا در صورت خرابی یکی، دیگری بدون تأثیر بر سرویس تولیدی جایگزین شود.
• Resilience: توانایی خودکار شبکه برای بازیابی از خرابی.
• Reliability: درصد داده‌هایی که در بازهٔ زمانی درست و به‌موقع از مبدأ به مقصد می‌رسند.

سطح موردنیاز از دسترس‌پذیری باید به‌دقت تعیین شود، زیرا هرچه سطح آن بالاتر رود، هزینه و پیچیدگی طراحی نیز افزایش می‌یابد.

برای مثال، حذف Single Point of Failure ساده‌ترین راه افزایش دسترس‌پذیری است، اما اگر بخواهید Dual Point of Failure را هم حذف کنید، هزینه‌ها و پیچیدگی‌ها به‌صورت نمایی افزایش می‌یابند.

مثال:
اگر مشتری بخواهد شبکه‌ای بدون هیچ قطعی (Outage) داشته باشد، طراح باید هزینه و منابع لازم برای ایجاد چنین محیطی را به او نشان دهد تا بداند دستیابی به ۱۰۰٪ Availability چه هزینه‌ای دارد.

امروزه تمرکز طراحی شبکه دیگر فقط بر availability نیست، بلکه بر service availability (دسترس‌پذیری سرویس‌ها) است. شبکه فقط داده‌ها را جابه‌جا نمی‌کند بلکه منابع حیاتی (resources) را منتقل می‌کند. شبکه مثل لوله‌کشی آب در یک خانه است؛ اگر لوله خراب شود، جریان داده (آب) متوقف می‌شود.

درک این موضوع حیاتی است:
اگر مثلاً سرویس VoIP شما کار نکند، پیامدش چیست؟
اگر سرویس SaaS شرکت‌تان قطع شود، چند کاربر تحت‌تأثیر قرار می‌گیرند؟

طراح شبکه باید سطح دسترس‌پذیری موردنیاز برای هر سرویس یا برنامه را شناسایی کرده و بر اساس آن تصمیمات طراحی مناسب بگیرد.

Limiting Complexity – Manageability (محدودسازی پیچیدگی و قابلیت مدیریت)

یکی از دشوارترین وظایفی که یک طراح شبکه بر عهده دارد، مدیریت سطح پیچیدگی طراحی پیشنهادی است. باید طراحی را تا حد ممکن ساده نگه دارید اصل معروف KISS (Keep It Super Simple). به همین دلیل، Manageability (قابلیت مدیریت) یکی از پنج اصل اصلی طراحی شبکه است.

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

«آیا تیم فعلی مشتری قادر به مدیریت طراحی پیشنهادی من هست؟»

برای مثال، فرض کنید طراحی شبکه‌ای ارائه داده‌اید که از نظر قابلیت، در دسترس‌پذیری، افزونگی و کارایی بسیار عالی است. اما این طراحی شامل مؤلفه‌هایی در سطح CCIE (Cisco Certified Internetwork Expert) است، در حالی که مشتری هیچ متخصصی با این سطح از مهارت ندارد.

در چنین حالتی، اگر مشکلی رخ دهد، مشتری چگونه باید شبکه را عیب‌یابی کند؟ به‌عنوان طراح شبکه، باید توانایی تیم نگهدارنده را ارزیابی کنید و مطمئن شوید که آن‌ها می‌دانند چه کاری، چگونه و چرا انجام می‌شود. در واقع، دانستن چرایی (Why) از چگونگی (How) یا چیستی (What) مهم‌تر است.

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

در این مواقع، شما در نقش مشاور مورد اعتماد (Trusted Advisor) ظاهر می‌شوید. باید به زبان غیر‌فنی، تأثیر و دلایل انتخاب راهکار پیچیده را برای کسب‌وکار توضیح دهید.

استفاده از فناوری‌های دیگر برای پنهان‌کردن پیچیدگی، لزوماً طراحی را ساده نمی‌کند. مثلاً استفاده از تونل GRE برای تشکیل ارتباط Routing بین دو ناحیهٔ OSPF multi-area می‌تواند پیچیدگی زیرین (underlay) را پنهان کند، اما ساختار کلی هنوز پیچیده است. به عبارت دیگر، ساده دیده‌شدن طراحی به معنی ساده بودن آن نیست.

Making a Business Flexible with Scalability (انعطاف‌پذیری کسب‌وکار با مقیاس‌پذیری)

Scalability (مقیاس‌پذیری) همیشه یکی از اصول اصلی طراحی شبکه بوده است و همچنان خواهد بود. اما این اصل فقط به مقیاس‌پذیری شبکه محدود نمی‌شود بلکه به انعطاف‌پذیری کسب‌وکار (Business Flexibility) نیز مربوط است.

طراح شبکه باید شبکه‌ای طراحی کند که کسب‌وکار بتواند به‌صورت پویا رشد کند و با تغییرات وفق یابد. چنین شبکه‌ای دیگر مرکز هزینه نیست، بلکه به یک ابزار توانمندساز کسب‌وکار (Business Enabler) تبدیل می‌شود.

برای مثال، افزودن قابلیت‌هایی مانند انتخاب معماری‌های مختلف در طراحی (مثل طراحی ماژولار یا مقیاس‌پذیر) به سازمان کمک می‌کند تا هنگام رشد بتواند ساختار شبکه را گسترش دهد.

از دید معماری، طراحی شبکه‌ای با توپولوژی Spine-Leaf که از pods‌های مستقل تشکیل شده، نمونه‌ای عالی از ترکیب Scalability و Business Flexibility است. اگر کسب‌وکار نیاز به افزودن سرویس‌ها یا برنامه‌های جدید داشته باشد، این معماری امکان گسترش آسان را فراهم می‌کند.

در سطح پایین‌تر طراحی (Low-level design)، می‌توان از مفاهیمی مانند OSPF Areas، LSA Filtering، و Type Boundaries برای افزایش مقیاس‌پذیری Routing استفاده کرد. این رویکرد به کسب‌وکار اجازه می‌دهد تا بدون بازطراحی کلی شبکه، رشد کند.

Cost Constraints and What to Do (محدودیت‌های هزینه و نحوهٔ مدیریت آن)

آخرین اصل طراحی شبکه، مدیریت هزینه‌ها (Cost Management) است. در هر پروژهٔ طراحی شبکه، هزینه همیشه یک محدودیت حیاتی محسوب می‌شود.

هزینه فقط به پول مربوط نمی‌شود بلکه می‌تواند شامل منابع انسانی، زمان، انرژی، و هزینه‌های فنی (مثل CPU، حافظه، پهنای باند، برق و خنک‌کننده) نیز باشد. به‌عنوان طراح شبکه، باید هزینهٔ کل طراحی را برای مشتری مدیریت کنید.

یک قاعدهٔ مهم این است که هرگز از وضعیت مالی مشتری خود غافل نشوید. برای مثال، اگر بودجهٔ مشتری ۱۰۰ هزار دلار است و شما طراحی‌ای با هزینهٔ ۵ میلیون دلار پیشنهاد دهید، disconnect بزرگی وجود دارد.

در چنین حالتی، باید تمام گزینه‌ها را با مزایا و معایبشان (Pros and Cons) برای مشتری توضیح دهید شامل هزینه‌های مرتبط با هر انتخاب تا بتواند تصمیمی آگاهانه (Educated Decision) بگیرد.

در نتیجه، به‌عنوان یک طراح شبکه حرفه‌ای، باید بین سه عامل کلیدی تعادل برقرار کنید:

1. Complexity (پیچیدگی)
2. Scalability (مقیاس‌پذیری)
3. Cost (هزینه)

تا شبکه‌ای طراحی کنید که هم قابل مدیریت، مقیاس‌پذیر، و مقرون‌به‌صرفه باشد و در عین حال اهداف تجاری سازمان را پشتیبانی کند.

Network Design Techniques (تکنیک‌های طراحی شبکه)

در دنیای واقعی، طراحی‌های بد شبکه اتفاق می‌افتند. شاید در ابتدا تمایل نداشته باشید این موضوع را بپذیرید، اما اگر این‌گونه نبود، دیگر نیازی به نقش «طراح شبکه» وجود نداشت.

این بخش با هدف بررسی مفهوم «طراحی‌های نادرست شبکه» نگاشته شده است و مجموعه‌ای از تکنیک‌های طراحی را معرفی می‌کند که همهٔ طراحان شبکه باید بدانند نه‌تنها برای جلوگیری از ایجاد طراحی‌های بد، بلکه برای بازسازی (Remediate) طراحی‌های اشتباهی که دیگران انجام داده‌اند.

برای توضیح این تکنیک‌ها، از یک مطالعهٔ موردی (Case Study) مربوط به یک دانشگاه بزرگ استفاده می‌شود. شکل زیر توپولوژی فعلی شبکهٔ این دانشگاه را نشان می‌دهد:

در این توپولوژی، دو سایت به نام‌های West Campus و East Campus به‌همراه Data Center از طریق یک بستر لایهٔ ۲ گسترده به یکدیگر متصل شده‌اند.

Failure Isolation (ایزوله‌سازی خرابی‌ها)

اگر به توپولوژی دقت کنید، متوجه می‌شوید که کل محیط در لایهٔ ۲ (Layer 2) گسترده شده است و شامل تمام سایت‌ها دیتاسنتر، پردیس غربی و شرقی می‌شود. در چنین معماری، Failure Domain (دامنهٔ خرابی) بسیار وسیع است. این بدان معناست که هر خطا در یک بخش، می‌تواند به کل شبکه سرایت کند.

برای مثال، اگر دانشجویی در یکی از سوئیچ‌های دسترسی در East Campus یک هاب ساده را با دو کابل متصل کند، یک Broadcast Storm (طوفان پخشی) ایجاد می‌شود. این طوفان در طراحی فعلی به‌سرعت به کل شبکه از جمله روترهای اصلی، West Campus و Data Center گسترش می‌یابد و می‌تواند کل شبکهٔ دانشگاه را در چند دقیقه از کار بیندازد.

این سناریو نمونه‌ای از شکست طراحی (Design Failure) است. در ادامهٔ شکل‌ها، نحوهٔ انتشار این Broadcast Storm نمایش داده شده است:

Mitigating Failures with Layer Boundaries (جلوگیری از خرابی با مرزهای لایه‌ای)

برای جلوگیری از چنین وضعیت‌هایی، می‌توان از مفهومی به نام Failure Isolation (جداسازی خرابی) استفاده کرد. در این روش، مرزهای منطقی (Logical Boundaries) بین نواحی مختلف شبکه ایجاد می‌شود تا از گسترش خطا جلوگیری گردد. این مرزها با نام‌های دیگری چون Failure Radius، Impact Domain، یا Failure Boundary نیز شناخته می‌شوند.

در این طراحی جدید، مرز بین لایهٔ ۲ و لایهٔ ۳ به هر سایت جداگانه (West, East, Data Center) منتقل می‌شود. به این ترتیب، هر بخش از شبکه دارای Core Deviceهای مخصوص خود خواهد بود و دیگر ارتباط لایهٔ ۲ بین سایت‌ها وجود ندارد.

اگر اکنون همان خطای قبلی رخ دهد (مثلاً اتصال نادرست یک هاب)، Broadcast Storm فقط در همان بخش (مثلاً East Campus) محدود می‌ماند و به بقیهٔ شبکه سرایت نمی‌کند.

Failure Isolation within Routing Protocols (جداسازی خرابی در پروتکل‌های مسیریابی)

مفهوم ایزوله‌سازی خرابی محدود به لایه‌های پایین شبکه نیست می‌توان آن را در پروتکل‌های مسیریابی لایهٔ ۳ مثل OSPF نیز به‌کار برد.

اگر در طراحی خود از یک ساختار Flat OSPF Area 0 استفاده کرده باشید، هر زمان که یک روتر جدید اضافه یا حذف شود، کل ناحیه باید بازمحاسبه (Reconverge) شود. این اتفاق موجب افزایش زمان بازیابی و حتی قطعی سرویس می‌شود.

حال اگر از تکنیک Failure Isolation استفاده کنیم، می‌توانیم طراحی OSPF را به‌صورت چندناحیه‌ای (Multi-Area) پیاده‌سازی کنیم تا بار تغییرات و اثرات خرابی محدود به ناحیهٔ مربوطه شود.

در این مثال، هر بخش از شبکه در ناحیهٔ OSPF مخصوص خود قرار دارد:

• Internet Routers در Area 0 (Normal Area)
• West Campus در Area 1 (Totally Stubby Area)
• East Campus در Area 2 (Totally Stubby Area)
• Data Center در Area 10 (Totally Stubby Area)
• و لینک‌های به شبکهٔ اینترنت در Area 20 (Not So Stubby Area)

این طراحی باعث می‌شود هر تغییر یا خرابی فقط در محدودهٔ همان Area باقی بماند و شبکهٔ کلی پایدارتر عمل کند.

نتیجه‌گیری: نقش Failure Isolation در پایداری شبکه

Failure Isolation یکی از مهم‌ترین تکنیک‌های طراحی شبکه است که به شما امکان می‌دهد:

• محدودهٔ اثر خرابی‌ها را کاهش دهید.
• Broadcast Storm و Loop را به یک ناحیهٔ کوچک محدود کنید.
• زمان بازیابی شبکه (Convergence Time) را به‌شدت کاهش دهید.
• و در نهایت، پایداری، مقیاس‌پذیری و قابلیت مدیریت شبکه را افزایش دهید.

Shared Failure State (وضعیت خرابی مشترک)

Shared Failure State یا همان Fate Sharing (اشتراک سرنوشت) زمانی رخ می‌دهد که یک دستگاه، سیستم یا بخش از شبکه چندین نقش حیاتی را به‌طور هم‌زمان ایفا می‌کند مثلاً اجرای چند سرویس مهم یا چند پروتکل کلیدی روی یک دستگاه واحد.

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

در این مثال، شبکهٔ دانشگاهی معرفی‌شده از قبل حالا با تمرکز بر پروتکل BGP (Border Gateway Protocol) بررسی می‌شود. هر سایت (مثل West Campus) شامل روترهای BGP است که از IPv4 و IPv6 پشتیبانی می‌کنند.

روترهای POP (Point of Presence) در این طراحی دو نقش دارند:

• به‌صورت eBGP برای اتصال به ارائه‌دهندگان اینترنت جهت دریافت مسیرهای بیرونی
• به‌صورت iBGP برای همسایگی با روترهای هر پردیس داخلی

به‌منظور مقیاس‌پذیری، این روترها به‌عنوان Route Reflector عمل می‌کنند تا از نیاز به Full Mesh iBGP جلوگیری شود.

اما مشکل اصلی اینجاست:
این روترهای IPv4/IPv6 نقش حیاتی برای هر دو نوع ترافیک دارند. اگر مثلاً یک آسیب‌پذیری در IPv4 باعث از کار افتادن این روترها شود، ترافیک IPv6 هم تحت تأثیر قرار می‌گیرد، حتی اگر در IPv6 هیچ نقصی وجود نداشته باشد. این یک نمونهٔ واقعی از Shared Failure State است.

برای کاهش این نوع ریسک، می‌توان نقش‌های IPv4 و IPv6 را از هم جدا کرد تا هرکدام Route Reflector مخصوص خود را داشته باشند. شکل بعدی این طراحی را نشان می‌دهد:

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

نکتهٔ مهم این است که Shared Fate Scenario همیشه بد نیست. در بعضی شرایط، این هم‌پوشانی عمداً انجام می‌شود تا اگر بخشی از سرویس دچار خرابی شد، کل بخش مرتبط با آن نیز از کار بیفتد و حالت ناسازگاری ایجاد نشود.

برای مثال، در IPv4 Internet Block (تصویر زیر)، اگر یکی از رابط‌های داخلی روتر سمت A از کار بیفتد، طراحی باید به‌گونه‌ای باشد که ترافیک IPv4 فوراً به سمت B هدایت شود. در غیر این صورت، بخشی از مسیر در حالت بن‌بست (black-holed) قرار می‌گیرد و قطعی گسترده‌ای رخ می‌دهد.

جمع‌بندی فنی: Shared Failure State در طراحی شبکه

مزایا:

• کاهش تعداد دستگاه‌ها و پیچیدگی اولیهٔ طراحی
• همگرایی ساده‌تر بین سرویس‌ها

معایب:

• افزایش نقاط خرابی مشترک (Single Shared Points of Failure)
• تأثیر هم‌زمان بر چندین سرویس حیاتی در زمان بروز خرابی
• نیاز به Failover Mechanism پیچیده‌تر

راه‌حل‌های کاهش ریسک:

1. جداسازی نقش‌ها (مثل تفکیک Route Reflectorهای IPv4 و IPv6)
2. پیاده‌سازی Redundant Stack برای هر مسیر حیاتی
3. تعریف Failure Domain‌های مجزا برای هر سرویس

Modularity Building Blocks (بلوک‌های سازندهٔ ماژولار)

Modularity (ماژولار بودن) مفهومی است که در طراحی شبکه به تقسیم اجزای طراحی به بلوک‌ها یا پادهای عملکردی (Functional Blocks / Pods) اشاره دارد. هدف این رویکرد، جداسازی فناوری‌ها و قابلیت‌های مرتبط درون هر بلوک است تا مدیریت، مقیاس‌پذیری و نگه‌داری شبکه ساده‌تر شود.

به بیان ساده‌تر، ماژولاریتی یعنی طراحی شبکه با استفاده از بلوک‌های هدفمند (Purpose-built blocks) که هرکدام وظیفه‌ای خاص دارند مثلاً بلوک مخصوص اینترنت، دیتاسنتر، یا سایت‌های پردیس.

Campus Modularity Example (نمونهٔ ماژولار در شبکهٔ دانشگاهی)

برای درک بهتر این مفهوم، همان سناریوی دانشگاهی را در نظر بگیریم.
در طراحی فعلی، ما چند پاد (Pod) جداگانه داریم:

• Internet Pod
• West Campus Pod
• East Campus Pod
• Data Center Pod

در این معماری، هر پاد نقش خود را دارد، اما همگی از طریق ارتباطات متقابل به‌صورت Full Mesh به هم متصل شده‌اند.

Full Mesh Modularity (ماژولاریت با اتصال کامل)

در این حالت، هر بلوک با تمامی بلوک‌های دیگر ارتباط مستقیم دارد. این طراحی اگرچه از نظر افزونگی (Redundancy) قوی است، اما به‌مرور باعث افزایش پیچیدگی و هزینه می‌شود.

اکنون فرض کنید این دانشگاه با مؤسسهٔ آموزشی دیگری ادغام شود و دو مکان جدید به نام North و South به شبکه افزوده شوند. ادامه دادن طراحی Full Mesh در این وضعیت منجر به ایجاد شبکه‌ای عظیم و بسیار درهم می‌شود، با حجم زیادی از لینک‌های فیبر بین سایت‌ها.

این طراحی از نظر مقیاس‌پذیری کارآمد نیست و با افزایش سایت‌ها، مدیریت آن تقریباً غیرممکن می‌شود.

Core Pod Design (طراحی پاد مرکزی)

برای رفع این مشکل، می‌توان یک Core Pod (پاد مرکزی) طراحی کرد تا همهٔ سایت‌ها، از جمله اینترنت و دیتاسنتر، فقط به آن متصل شوند. این ساختار در تصویر زیر نمایش داده شده است:

در این طراحی:

• پاد مرکزی نقش ستون فقرات ارتباطی شبکه را دارد.
• هر پاد لایهٔ ۲ خود را جداگانه مدیریت می‌کند و ارتباط بین پادها از طریق لایهٔ ۳ (Layer 3) انجام می‌شود.
• هر پاد دارای مسیرها و لینک‌های افزونه (Redundant) است تا قابلیت اطمینان افزایش یابد.

Scalability and Fault Isolation (مقیاس‌پذیری و جداسازی خطا)

از دید Scalability (مقیاس‌پذیری)، زمانی که پاد مرکزی به محدودیت ظرفیت برسد، می‌توان یک پاد مرکزی دوم ایجاد و آن را با پاد اول ارتباط داد. به‌این‌ترتیب، شبکه بدون نیاز به بازطراحی کلی قابل گسترش باقی می‌ماند.

همچنین، هر پاد محدودهٔ خطای خاص خود را دارد. در صورت بروز مشکل، می‌توان تنها پاد معیوب را از مدار خارج کرد، بدون آن‌که سایر بخش‌ها دچار اختلال شوند.

Advantages of Modularity (مزایای طراحی ماژولار)

1. افزایش قابلیت مقیاس‌پذیری:
   با افزودن پادهای جدید می‌توان شبکه را به‌آسانی گسترش داد.
2. مدیریت آسان‌تر:
   هر پاد به‌صورت مستقل قابل عیب‌یابی و نگه‌داری است.
3. جداسازی خرابی‌ها (Failure Isolation):
   خرابی در یک پاد تأثیری بر سایر پادها ندارد.
4. تکرارپذیری (Repeatability):
   الگوی طراحی قابل تکرار برای سایت‌های جدید است (Plug-and-Play).
5. انعطاف‌پذیری بالا:
   با تغییر نیازها می‌توان پادهای جدید اضافه کرد (مثل Internet Edge جدید یا Access Block جدید).

Hierarchy of Design (سلسله‌مراتب طراحی شبکه)

Hierarchy (سلسله‌مراتب) در طراحی شبکه به مفهوم ایجاد سطوح اختصاصی با اهداف متفاوت درون معماری شبکه اشاره دارد. مدل سنتی سلسله‌مراتبی معمولاً شامل سه یا چهار لایه است:

• Access Layer (لایه دسترسی) – نقطه اتصال کاربران یا دستگاه‌ها به شبکه
• Distribution Layer (لایه توزیع) – محل پیاده‌سازی سیاست‌ها، کنترل ترافیک و تجمیع لینک‌ها
• Aggregation Layer (لایه تجمیع) – (در برخی مدل‌ها بین توزیع و هسته قرار دارد) برای ادغام ترافیک
• Core Layer (لایه هسته) – مسیر اصلی ارتباطات پرسرعت بین بخش‌های مختلف شبکه

این ساختار باعث می‌شود طراحی شبکه پایدارتر، مقیاس‌پذیرتر و قابل نگهداری‌تر شود.

Flat Hierarchy (سلسله‌مراتب تخت)

در ادامه از همان سناریوی دانشگاهی استفاده می‌کنیم. شکل زیر نشان‌دهندهٔ بخشی از معماری مربوط به West Campus است، که در آن هشت سایت مستقیماً به پاد مرکزی (Core Pod) متصل هستند بدون هیچ لایهٔ میانی:

این نوع طراحی بسیار تخت است و فاقد سلسله‌مراتب می‌باشد. چنین ساختاری در مقیاس کوچک قابل استفاده است اما در شبکه‌های بزرگ باعث افزایش بار بر روی لایهٔ Core و پیچیدگی در مدیریت می‌شود.

Adding a Distribution Layer (افزودن لایهٔ توزیع)

برای رفع این مشکل، می‌توان لایهٔ توزیع (Distribution Layer) را به معماری اضافه کرد. این لایه بین Core و Access قرار می‌گیرد و وظیفهٔ کنترل، فیلتر و مسیریابی محلی را بر عهده دارد.

در این مثال، همهٔ سایت‌های West Campus به یک West Distribution Block متصل هستند و این بلوک با لایهٔ Core در ارتباط است. این تغییر کوچک باعث بهبود مدیریت ترافیک، کاهش بار پردازشی بر Core و افزایش مقیاس‌پذیری می‌شود.

Adding Aggregation and Access Layers (افزودن لایه‌های تجمیع و دسترسی)

با رشد شبکه می‌توان سلسله‌مراتب را گسترش داد و لایه‌های Aggregation و Access را نیز اضافه کرد. نتیجهٔ این کار، ساختاری چندسطحی و بهینه از نظر مدیریت و عملکرد است.

در این ساختار:

• Access Layer میزبان سوئیچ‌های متصل به کاربران و دستگاه‌های نهایی است.
• Aggregation Layer چند Access Switch را به هم متصل کرده و به Distribution Layer لینک می‌دهد.
• Distribution Layer چندین ناحیهٔ Aggregation را به Core Layer متصل می‌کند.

این مدل امکان کنترل دقیق‌تر ترافیک، مسیریابی بهتر و ایزوله‌سازی خطا را فراهم می‌کند.

Putting It All Together (ترکیب تمام مفاهیم طراحی)

در شکل زیر، طراحی اولیه شبکه را مشاهده می‌کنیم که فاقد سلسله‌مراتب بود:

و در شکل بعد، نسخهٔ نهایی و اصلاح‌شده با همهٔ اصولی که تاکنون آموختیم نشان داده شده است:

در این طراحی نهایی:

• یک Core Block اختصاصی وجود دارد که تمام بخش‌های شبکه را به هم متصل می‌کند.
• بلوک‌های Internet و Data Center تقریباً ثابت مانده‌اند.
• پردیس‌های مختلف (West, East, North, South) به‌صورت مستقل و ماژولار عمل می‌کنند اما از طریق Core به‌هم مرتبط هستند.

دام‌های طراحی شبکه (Network Design Pitfalls)

دام‌های طراحی شبکه، برخی از رایج‌ترین اشتباهاتی هستند که ممکن است به‌عنوان یک طراح شبکه مرتکب شوید. این‌ها تله‌هایی هستند که می‌توانند هر طراحی شبکه‌ای را که ایجاد می‌کنید یا هر تصمیمی را که در طراحی شبکه می‌گیرید، از بین ببرند.

فرضیات (Making Assumptions)

در این‌جا شما آماده‌اید تا به مشتری خود کمک کنید که در این سناریو همان شرکت شماست تا یک مشکل تجاری را حل کند. شما وارد مرحله کشف طراحی (design discovery) در فاز تعامل یا ابتکار عمل می‌شوید. در حین تسهیل گفت‌وگو با ذی‌نفعان مختلف، ممکن است شروع کنید به این فکر که پیچیدگی چیز بدی است. شاید از همان ابتدای جلسه این‌طور فکر می‌کردید که این محیط یا این مشتری یا شرکت شما، نمی‌خواهد یک راه‌حل پیچیده داشته باشد.

اینجا همان دامِ «فرض کردن» و «درستی‌سنجی نکردن آن فرض» است.

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

فرضیات خود را با پرسش از مشتری، ذی‌نفعان تجاری و تیم خود بررسی کنید. از کارگاه‌ها برای ایجاد گفت‌وگو با مشتری استفاده کنید، اما اجازه دهید او نیز صحبت کند. تمام مدت حرف نزنید؛ با دقت گوش دهید، پردازش کنید، و یادداشت بردارید تا مشتری و وضعیت را بهتر درک کنید.

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

طراحی بیش‌از‌حد خوب است؟ (Overdesigning Is Good, Right?)

طراحی بیش‌از‌حد (Overdesigning)، که به آن Gold Plating نیز می‌گویند، یک تله رایج (و دشوار برای اجتناب) است. فرض رایج این است که افزودن امکانات یا ویژگی‌های اضافی به طراحی شبکه، مشتری را تحت‌تأثیر قرار می‌دهد و امنیت شغلی طراح را افزایش می‌دهد. گاهی طراحان فکر می‌کنند با این کار دارند شبکه را برای آینده مقاوم می‌سازند، اما در واقع در حال افزودن اجزای غیرضروری هستند.

فرض کنید برای مشتری‌ای طراحی انجام می‌دهید که می‌خواهد هیچ نقطه‌ی شکست تکی (Single Point of Failure) نداشته باشد. شما ایده‌ای درخشان دارید که حتی نقاط شکست دوگانه را هم حذف می‌کند! اما این کار منجر به پیچیدگی و هزینه‌ی مضاعف می‌شود. مشتری شاید حتی نیازی به چنین طرحی نداشته باشد. این دقیقاً نمونه‌ای از Gold Plating است که اغلب بیشتر موجب ناراحتی مشتری می‌شود تا رضایت او. شما دارید بیش از حد فکر می‌کنید.

اگر در این مسیر افتادید، دوباره به نیازمندی‌ها برگردید. تمرکز کنید بر آنچه واقعاً لازم است، نه بر چیزهایی که تصور می‌کردید ارزش افزوده دارند.

نمونه‌ای دیگر از Overdesign این است که شما مأمور حذف Single Points of Failure هستید، اما خودتان تصمیم می‌گیرید نقاط دوگانه را هم حذف کنید! این اغلب نمونه‌ی واضحی از طراحی بیش‌از‌حد است.

نمونه‌های رایج Gold Plating

• IPv4 Internet Table کامل روی روترهای Edge:
  در گذشته طراحان شبکه تصور می‌کردند باید تمام جدول اینترنت را دریافت کنند تا شبکه انعطاف‌پذیر شود. اما این کار نیازی به آن نداشت و طراحی بیش‌از‌حد بود.
• MPLS شبکه در سرویس‌دهنده‌ها:
  طراحی MPLS-TE با failover زیر یک ثانیه و protectionهای متعدد ممکن است نیاز واقعی را برآورده کند، اما اضافه‌کاری و پیچیدگی غیرضروری است.
• پروژه CCIE Lab یا امتحان:
  بسیاری از افراد فناوری یا راه‌حلی را فقط برای “تست کردنش” در شبکه قرار داده‌اند. این هم نوعی Gold Plating است وقتی که هیچ نیازی برای آن وجود ندارد.

برای جلوگیری از این تله، همیشه Hyperfocus بر روی نیازمندی‌ها داشته باشید. هر چیزی که طراحی می‌کنید باید به یک نیاز تجاری مشخص نگاشت شود. این نگاشت ممکن است یک‌به‌چند باشد، اما همیشه باید وجود داشته باشد.

بهترین شیوه‌ها (Best Practices)

آیا تا به حال تصمیم طراحی گرفته‌اید فقط چون «بهترین شیوه» است؟
آیا واقعاً تأثیر آن تصمیم را درک کردید یا فقط آن را بدون توجیه خاصی اعمال کردید؟

در حوزه طراحی شبکه، بسیاری از افراد تصمیم‌هایی می‌گیرند که به‌ظاهر «Best Practice» است، بدون اینکه درک کنند چرا و چه تأثیری دارد.

مثلاً:
چرا باید رابط OSPF را point-to-point کنیم؟ آیا نیاز تجاری خاصی وجود دارد؟
سؤال بهتر این است: «آیا کسب‌وکار به این نیاز دارد؟»

نمونه‌ای واقعی‌تر:
چرا failover زیر ۵ ثانیه برای IGP پیاده‌سازی می‌کنیم؟ آیا چون Best Practice است یا چون واقعاً نیاز تجاری دارد؟

طراحان شبکه نباید در دام “Best Practice” بیفتند. باید نیاز تجاری را در نظر بگیرند و در صورت لزوم راه‌حل‌ها را تغییر دهند. گاهی طراحی شما ممکن است از دید Best Practice بهینه نباشد، اما برای نیاز مشتری بهترین گزینه است.

مثال:
اتصال دو دیتاسنتر از طریق Layer 2 و STP شاید از نظر Best Practice کار اشتباهی باشد، اما اگر نیاز اپلیکیشن این را الزام کند، ناچارید این کار را انجام دهید. امروزه راه‌های بهتری مثل EVPN وجود دارد، اما مفهوم کلی همان است.

پیش‌فرض‌ها (Preconceived Notions)

پیش‌فرض‌ها شبیه به فرضیات‌اند، اما از تجربه‌های شخصی یا دیدگاه‌های قبلی نشأت می‌گیرند. مثلاً چون قبلاً در شبکه‌ای از EIGRP استفاده کرده‌اید، تصور می‌کنید همیشه بهترین گزینه است. یا چون MPLS L3VPN گران‌تر از L2VPN است، فکر می‌کنید بهتر است. اما در طراحی، هیچ‌کدام از این‌ها نباید مبنا باشند. طراحی باید همیشه به نیازهای کسب‌وکار مشتری گره بخورد.

خلاصه (Summary)

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

سپس اشتباهات رایج طراحان شبکه را مرور کردیم: فرضیات، طراحی بیش‌از‌حد، پایبندی کورکورانه به Best Practice و پیش‌فرض‌ها.

اگر هیچ نیاز تجاری خاصی وجود ندارد، استفاده از Best Practice راه خوبی است؛ اما قبل از تصمیم‌گیری باید تصویر کامل را ببینید. در نهایت، همه‌چیز به انجام کاری برمی‌گردد که برای موقعیت خاص درست است، نه صرفاً تکیه بر پاسخ‌های عمومی.

هیچ «راه‌حل واحدی» وجود ندارد. کسانی که دنبال ساده‌ترین مسیر هستند، در نهایت به شبکه‌ها و مشتریان خود آسیب می‌زنند.

تمام موارد مطرح‌شده در این فصل مهم‌اند و نیاز به زمان و تمرین دارند تا در ذهن طراح نهادینه شوند. توصیه می‌شود این مفاهیم را هنگام طراحی شبکه در فرآیند تفکر خود ادغام کنید.