https://virgool.ir/feed/@mohamad.labbaffa2026-11-11 11:35:52https://files.virgool.ir/upload/users/1119940/avatar/xE2P0C.jpeghttps://virgool.ir/@mohamad.labbafhttps://virgool.ir/@mohamad.labbaf/head-تیم-مدیریت-محصول-بودن-توی-یه-شرکت-tech-yi34df1qnjofسلامتوی یک سال و سه ماه گذشته با یه تجربه جدید توی مسیر شغلیم مواجه شدم که به نظرم اومد به اشتراک گذاشتنش کار خوبی باشه.من مسیر شغلیم رو از فضای Engineering شروع کردم و از توسعه به زبون‌های Verilog و VHDL برای FPGA شروع کردم و بعدش اومدم سراغ بحث‌های Embeddedی و بعدش بحث‌های شبکه‌ای با تمرکز بیشتر روی لایه‌های Physical، MAC و IP. بعدش هم بیشتر اومدم توی فضاهای Leadership و People Management و اینها. بعدش هم بیشتر نقش Line Managerی پیدا کردم که خودش قصه‌های خودش رو داره.نهایتا بعد از یه سری کش و قوس، از اول پاییز پارسال درگیر فضاهای مدیریت محصول شدم و واقعیت اینه که از مسیری که توی این چند سال اومدم خوشحالم و باعث شده که وقتی کار میکنم، خوشحال‌تر هم باشم.حالا میخوام یه قدری درباره همین تجربه مدیریت محصول بنویسم و یه چند دقیقه‌ای با هم باشیم.ما توی شرکتمون، نقشی با عنوان مدیر محصول نداشتیم و یه سری مشکلات داشتیم که باعث شد به این فکر کنیم که مدیر محصول میتونه برای حل این مشکلات کمکمون کنه. (البته بگم اصلا این طوری نبود که همه یه جور فکر کنن و کلی دعوا داشتیم سر اینکه قراره کدوم مشکل رو مدیرمحصول حل کنه و کدوم مشکل ربطی به مدیرمحصول نداره، حالا سعی میکنم از هر دو تاش بگم)یه سری از مشکل‌هایی که فکر میکردیم مدیرمحصول میتونه حلشون کنه و به نظر من درست بودن:انواع و اقسام تصمیم‌های محصولی به صورت خیلی غیرمتمرکز گرفته میشد و حالا محصول‌های مختلف با هم فرق داشتن ولی توی تصمیم‌گیری‌ها قشنگ CEO، CTO، CMO، Line Manager، Marketing، Team Lead و ... درگیر میشدن که حالا خیلی توازن لزوما درستی نداشت و بین محصول‌های مختلف هم متفاوت بود.خلاصه‌اش مکانیزم درست و حسابی برای اینکه تصمیم‌گیری‌ها درست و به موقع انجام بگیره، وجود نداشت. حتی یه سری از تصمیم‌ها گرفته نمیشد اصلا. گفتیم اگه مدیریت محصول داشته باشیم، یه نفری وجود داره که حواسش به محصولش هست که بهتر و درست‌تر تصمیم‌ها گرفته بشن. مشخصه که منظورم این نیست که مدیرمحصول پا میشه میره تصمیم میگیره بدون اینکه بقیه مشارکت داشته باشن، منظورم اینه که درست و حسابی کار در نمیومد.یه مشکل دیگه‌ای که داشتیم، تفاوت‌های فاحش رفتاری بین قسمت‌های مختلف وجود داشت (فکرت زیاد نره سمت HR، الان بیشتر توضیح میدم). ما یه بیزینس B2B هستیم که B دوم اون از جنس Businessهای خیلی بزرگ هستش. حالا این جاهای بزرگ با فرهنگ خاص به خودشون کار میکنن. از اون طرف، ما یه شرکت Tech هستیم و بالاخره تیم‌های توسعه‌مون دغدغه‌های خاص به خودشون رو دارن.اون سمت ارتباط با مشتری ما خیلی مجبوره فضای این مدلی رو داشته باشه که هر چی شما دستور فرمایید را ما انجام میدهیم. برای این موضوع، اول مدیر مربوطه در جریان قرار گیرد و پس از آن سراغ کارشناس‌ها برویم و ... . برای پیشبرد این موضوع لازم است که در گام اول مخ فلان شخص تاثیر گذار را بزنیم و پس از آن حواسمان به فلان رقیب باشد که دارد مخ فلان شخص تاثیرگذار دیگر را میزند و چگونه این فرآیند را مدیریت کنیم.از این طرف تیم توسعه‌دهنده ما دغدغه این رو داره که سطح مشارکتش در تصمیم‌گیری‌ها بره بالاتر. چرا فضای Open Office‌ فلان جور نداریم. فلان موضوع جدید لبه تکنولوژی اومده و اون رو کجای محصولمون میخوایم ببینیم. من دوست دارم که یه وقتی رو بذارم و با فلان موضوع high tech آشنایی کافی پیدا کنم. اصلا Career Path من چجوریه و من چند وقت دیگه قراره کجا باشم و ... .خلاصه‌اش واقعیت اینه که اصلا زبون صحبت کردن قسمت‌های مختلف شرکت با همدیگه فرق داره. حالا ما گفتیم که میتونیم مدیر محصولی رو این وسط داشته باشیم که میتونه با زبون همه صحبت کنه و شبیه به یه چسب، قسمت‌های مختلف رو به هم بچسبونه تا با هم‌افزایی بیشتری بتونیم با همدیگه کار کنیم و کار رو جلو ببریم.یه دلیل دیگه‌ای که باعث شد بخوایم مدیرمحصول داشته باشیم، این بود که نیازمندی‌های سمت مشتری‌ها خیلی بهتر به تیم توسعه‌مون برسه. عملا به خاطر دو تا مساله، تیم توسعه‌مون نمیتونست دقیقا روی موضوعی که ارزش داشت، کار کنه (تاکید میکنم که دقیقا نمیتونست وگرنه تا حدی داشت این کار رو انجام میداد). یکی اینکه زبون صحبت کردن تیم‌هایی از ما که با مشتری‌ها ارتباط داشتن با زبون تیم توسعه‌مون فرق داشت و یکی هم اینکه اساسا اون تیم‌ها اینقدر دانش فنی نداشتن که درست نیاز سمت مشتری رو دربیارن. حتی مشکل برعکس هم داشتیم، تیم‌هایی از ما که با مشتری‌ها ارتباط داشتن، خوب نمیتونستن از محصولمون دفاع کنن یا حتی براشون واضح نبود که الان این تعهد رو بدن یا ندن.دلیل‌های دیگه‌ای هم مثل اینکه Benchmark محصول‌های رقبا بهتر انجام بگیره، نیازمندی‌ها شفاف‌تر مطرح بشه، وضعیت فعلی محصول برای همه شفاف باشه و بدونیم الان چی رو داریم و چی رو نداریم و در آینده قراره چی رو داشته باشیم و ... هم وجود داشت که حالا خیلی بازشون نکنم.از اون طرف یه سری مشکلات دیگه هم بود که ربط خیلی جدی به مدیر محصول نداشت ولی بعضی‌ها فکر میکردن که مدیرمحصول قراره بیاد و این مشکل‌ها رو هم برطرف کنه.مثلا نیاز داریم که یه سری مستندات رو آماده کنیم و در اختیار مشتری‌ها قرار بدیم. از اون طرف کسی رو نداریم که گردن بگیره مسئولیت آماده کردن این مستندات رو. چه کسی بهتر از مدیرمحصول. استدلال هم اینه که کی بهتر از مدیرمحصول، محصولش رو میشناسه که مستنداتش رو آماده کنه! (همیشه من در جواب این جمله میگفتم، کی بهتر از مدیر محصول، محصولش رو میشناسه،‌ بره مدیرمحصول کدهاش رو هم بزنه دیگه. مارکتینگش رو هم انجام بده. بقیه کارهاش رو انجام بده. چه نیازی به بقیه هست ... )یا یه مثال دیگه، ما میخوایم برای اینکه جنسمون رو بفروشیم به مشتری‌هامون، نیاز داریم که باهاشون یه سری بحث‌های فنی داشته باشیم که بتونیم اولا اونها رو از توانمندی‌های فنی محصولمون آگاه کنیم، دوما بتونیم متناسب با نیاز اونها بهشون سولوشن بدیم. کی بهتر از مدیرمحصول که این کار رو انجام بده ... (اگه با این آیتم حال نمیکنی و فکر میکنی کار مدیرمحصول هست حتما، یه چرخی روی موقعیت‌های شغلی Pre-Sales، Sales Engineer، Solution Architect و مشابه اون بزن و حتی میتونیم یه گپی با هم داشته باشیم)یا یه مثال دیگه، قراره برای مشتری‌هامون در ضمن پروژه یا قبل از اون، دموهایی رو داشته باشیم و اتفاقی که میفتاد این بود که این دموها اون جوری که باید و شاید اتفاق نمیفتاد و در نهایت اون طوری که باید، مشتری‌های ما راضی نبودن. خوب طبق معمول کی بهتر از مدیر محصول ... .یا یه مثال دیگه، قراره یه تجهیزی رو در اختیار مشتریمون قرار بدیم. بالاخره قراره این تجهیز خوشگل مشگل در اختیار مشتری قرار بگیره دیگه. الان به سختی داره این اتفاق میفته، کی بهتر از مدیرمحصول که بیفته و اون رو آماده کنه.و یه سری مثال‌های دیگه با همین سبک و سیاق‌ که حالا سخن رو کوتاه کنم.این رو هم بگم که مثال‌هایی که بالاتر گفتم واقعا طرفدارهای جدی داشتن و باید باهاشون بحث و دعوا میکردی که بابا بیخیال ...تا اینجا سعی کردم که شرایط اون موقع رو توصیف کنم که فضا چه مدلی بود و چی شد که رفتیم سمت تیم مدیریت محصول. حالا سعی میکنم توی پست‌های بعدی، درباره ادامه‌اش بیشتر توضیح بدم.محمد لبافمحمد لبافMon, 27 Nov 2023 17:32:04 +0330https://virgool.ir/@mohamad.labbaf/چرایی-وجود-mpls-در-شبکه-بخش-دوم-و-آخر-qqndel1qovbtدر پست قبلی درباره MPLS صحبت کردیم و اونجا صحبت شد که از دید آکادمیک، وجود MPLS به چه دلایلی تعریف میشه که با دلایلی که در واقعیت وجود داره، یه تفاوت‌هایی دارن. در واقع، تکنولوژی TCAM و ذات اترنتی ترافیک‌های جدید، تغییراتی رو در شبکه به وجود آورده. اونجا اشاره کردیم که MPLS در عمل به سه دلیل استفاده میشه، اگر چه مفهوم packet switched و circuit switched در جای خودش هم‌چنان پابرجاست.- مهندسی ترافیک- ایجاد VPNهای مختلف- امکان حفاظت در شبکهخوب، توی این پست یه مقداری درباره این سه مزیت گپی بزنیم،‌ ببینیم که معنی اونها اساسا چی هستش، به چه دردی میخورن و MPLS چجوری اونها رو در اختیار قرار میده.با مهندسی ترافیک (Traffic Engineering) شروع کنیم. توی پست قبلی یه مقداری درباره تفاوت شبکه TDM و اترنتی صحبت کردیم. توی TDM مسیر ارسال ترافیک از ابتدا تا انتها مشخص هستش و لینک اختصاصی برای اون در نظر گرفته میشه ولی در شبکه اترنتی این شکلی نیست و هر نود تصمیم میگیره که ترافیک رو از چه مسیری ارسال کنه. MPLS اومده بود که این امکان رو در شبکه اترنت در اختیار قرار بده. در واقع، در شبکه MPLS یه سری مسیر LSP (Label Switched Path) ساخته میشن که ترافیک از مسیر اونها ارسال میشه. یه جورایی انگاری مسیر ابتدا تا انتها برای ترافیک مشخص میشه (البته به این خوشگلی ها هم نیست و باطنش یه تفاوت‌هایی داره و امیدوارم فرصتی پیش بیاد بشه درباره‌اش صحبت کنیم. اینجا هم همون پروتکل‌های OSPF و IS-IS و BGP مسیر رو مشخص میکنن.). حالا معنی مهندسی ترافیک این هستش که بیایم یه سری قید تعریف کنیم برای مشخص شدن این LSPها. مثلا بگیم اینقدر پهنای باند رو در نظر بگیر، از این لینک عبور نکن، از این لینک عبور داشته باش و ... . به عبارتی، با تعریف کردن یه سری policy مسیر ارسال ترافیک‌ها رو مهندسی میکنیم که این مزیتی هستش که شبکه MPLS در اختیار قرار میده.مزیت بعدی، امکان ایجاد VPNهای مختلف بر روی شبکه MPLS هستش. یه ذره درباره خود VPN صحبت کنیم. به خاطر مسائل فیلترینگ و این حرف‌ها در داخل کشور، همه با مفهوم VPN برای استفاده روزمره آشنا هستیم. VPN به این معنی هستش که دو تا نود جدا از هم در شبکه رو از طریق یک شبکه واسط به هم وصل کنیم، گویی که این دو تا مستقیما و بدون شبکه واسط به هم وصل شدن. حالا توی ابزارهای مختلفی که برای دور زدن فیلترینگ عموما استفاده میکنن، این کار سمت customer‌ اتفاق میفته. مثلا یه تونل IPSec (IP Security) ایجاد میشه یا L2TP (Layer 2 Tunneling Protocol) به همراه / بدون IPSec یا ... . البته وقتی صحبت درباره این applicationها مطرح میشه، میتونیم این کار رو در سطح لایه‌های مختلف شبکه انجام بدیم.حالا این VPNی که اینجا داریم درباره‌اش صحبت میکنیم، VPNی هستش که سمت Service Provider ایجاد میشه. یعنی مشتری بدون اینکه VPNی رو ستاپ کنه، از VPN استفاده میکنه. مثلا توی شکل زیر، اگر VPN بین CE (Customer Edge)ها ایجاد بشه،‌ از نوع اول خواهد بود و اگر VPN بین PE(Provider Edge)ها ایجاد بشه، میشه از نوع دوم.بخوایم جمع‌بندی کنیم، VPN از لحاظ مفهومی همون VPN مرسوم هستش که معمولا استفاده میکنیم. البته برای VPN تکنولوژی‌های مختلفی در دو سطح لایه داده و لایه کنترلی وجود داره.حالا بخوایم بریم سراغ VPN در شبکه MPLS، اینجا لایه داده ما میشه زیرساخت MPLS و لایه کنترلی هم میشه انواع VPNهایی که در شبکه MPLS تعریف میشن. یه مقداری لایه کنترلی رو باز کنم، این VPNها میتونن در دو لایه دو و سه تعریف بشن. لایه دو به این معنی هستش که دو شبکه لایه ۲ رو از طریق MPLS به هم وصل کنیم، به نحوی که اون دو شبکه احساس کنن که مستقیما به هم وصل هستن. لایه سه هم اینطوریه که دو تا شبکه همون مدل لایه ۳ی به هم وصل میشن.بخوایم از جزئیات این VPNها بگذریم، اینکه میشه سرویس‌های VPN لایه ۲ و لایه ۳ رو روی شبکه MPLS در اختیار قرار داد، یکی از مزایای استفاده از MPLS میشه.مزیت سوم شبکه MPLS هم در اختیار داشتن امکان حفاظت در اون هستش. در واقع مدل‌های مختلف حفاظت برای نود و مسیر وجود داره که در شبکه از اون استفاده میشه. در واقع برای هر دو حالتی که یه نود براش مشکل پیش بیاد و هم‌چنین یه مسیر LSP قطع بشه، امکان حفاظت وجود داره.توی این پست سعی کردم که مزایای استفاده از MPLS در سطح شبکه رو بیشتر باز کنم و درباره‌اش صحبتی داشته باشم. از این پست که بگذریم، توی این چند هفته سعی کردم که پست‌های فارسی با محتوایی رو آماده کنم و درباره‌شون صحبت‌هایی رو داشته باشیم و سعی دارم این مسیر رو ادامه بدیم. پست‌هایی که گذاشته میشه، یه جورایی عصاره مفاهیمی هستن که در طول این سال ها در شرکت همراه با دوستانم و از اونها یاد گرفتم و امیدوارم نشر محتوای با کیفیت بتونه اثرات مثبتی رو داشته باشه.قاعدتا یه قسمت‌هایی از پست‌هایی که گذاشته شده، واضح نبودن، ابهام داشتن، نادرست بودن و ... . از همین جهت، اگر نکته‌ای درباره‌شون وجود داشته باشه، خوشحال میشم که درباره‌شون با هم از طریق مسیرهای مختلف در ارتباط باشیم.محمد لبافمحمد لبافThu, 21 Oct 2021 14:57:54 +0330https://virgool.ir/@mohamad.labbaf/چرایی-وجود-mpls-در-شبکه-بخش-اول-cboofv74chbxتوی پست قبلی خیلی کلی و مختصر درباره لایه ۲ و ۳ و عملکردهای سوییچی و روتری صحبت کردیم. البته واضحه که هر دو لایه خیلی جزییات و مباحث مفصلی دارن که در جای خودش میشه درباره‌شون صحبت کرد. اونجا صحبت شد که وقتی درباره شبکه کوچیکی صحبت میشه، میتونیم از لایه ۲ استفاده کنیم و وقتی که نیاز به scaling به وجود میاد، دیگه لایه ۲ پاسخگو نیست و از امکانات لایه ۳ استفاده میکنیم. توی این پست دوست دارم یه قدری درباره MPLS بیشتر صحبت کنیم و سعی کنیم جایگاه MPLS رو در شبکه بهتر بشناسیم.اگه تو فضای آکادمیک بخوایم فکر کنیم، وقتی صحبت از MPLS (Multi-Protocol Label Switching) میشه، حکمتش وجودیش بیشتر میره سمت سه تا موضوع. یکی موضوع circuit switched و packet switched (موضوعی مهم)، یکی تسریع lookup در جدول مسیریابی لایه ۳ (موضوع مهم‌تر) و یکی پشتیبانی از انواع پروتکل‌ها (موضوع کم‌اهمیت‌تر). در ادامه درباره این سه تا موضوع یه مقداری صحبت میکنیم. اول موضوع circuit switched و packet switched. اگه بخوام مختصر درباره‌شون توضیح بدم، فضای circuit switched بیشتر توی فضای شبکه‌های TDMی مطرح میشه که مسیر ارسال ترافیک کاملا مشخص هستش و یه circuitی از قبل اختصاص پیدا کرده و قشنگ تضمین ارسال ترافیک وجود داره. فضای packet switched اینطوری نیست و هر نودی توی شبکه تصمیم میگیره که با این ترافیک چی کار کنه و هیچ مسیر مشخصی از مبدا تا مقصد وجود نداره و نتیجتا تضمینی برای ارسال ترافیک نیست. از اون طرف، از ظرفیت شبکه بهینه‌تر استفاده میشه و انعطاف شبکه خیلی بالاتره و استفاده کردن از شبکه راحت‌تره و ... . کلا درباره تفاوت‌های این دو رویکرد که در واقع تقابل بین شبکه TDM و Ethernetی هستش، میشه خیلی بیشتر از این حرف‌ها صحبت کرد.حالا کاری که MPLS انجام میده، یه جورایی این هستش که توی شبکه packet switched، امکان circuit switched بودن رو فراهم میکنه. شما میتونی زیرساخت غیر circuit switchedی داشته باشی ولی مدل circuit switchedی از اون استفاده کنی. قطعا این موضوع یکی از مزیت‌های MPLS میشه توی شبکه.circuit switched vs. packet switchedسرعت lookup کردن یه مقداری موضوع تاریخی و تکنولوژی هستش. قبل‌ترها پیاده‌سازی جدول مسیریابی توی حافظه‌های معمولی اتفاق میفتاده. مثلا فرض کن که CPU داره یه پروتکل مسیریابی رو اجرا میکنه و نتیجه رو توی حافظه ذخیره میکنه. حالا هر ترافیکی که وارد روتر میشه، نیاز داره برای پیدا کردن مقصد خودش، توی کل این حافظه lookup کنه تا مقصد رو پیدا کنه. همیشه خدا هم که حافظه‌ها محدود کننده بودن و هستن. این از یه طرف، از یه طرف دیگه، اندازه جدول مسیریابی همیشه بزرگ بوده. اگر بخوایم به نرخ روز صحبت کنیم، امروز تعداد prefixهایی که توی دنیا وجود داره برای IPv4 از یک میلیون بیشتر هستش. البته همه این prefixها رو قرار نیست که همه روترها داشته باشن که خودش بحث مجزایی رو میطلبه. در هر صورت، یه روزی باید میرفتی و توی حافظه lookup میکردی ولی واقعیت اینه که با تکنولوژی الان، برای روترهای با ظرفیت بالا، دیگه کسی این کار رو نمیکنه. برای این کار الان از حافظه‌های با تکنولوژی TCAM استفاده میکنن که در یک کلاک، کار lookup رو انجام میده.داخل پرانتز یه ذره درباره TCAM توضیح بدم، کلا این حافظه‌ها به خاطر قابلیت بالایی که دارن، اول اینکه کلا خیلی استفاده میشن، دوم هم خیلی گرون هستن و خیلی گرما تولید میکنن. البته معمولا به اندازه نیاز استفاده میشن و یه سری قابلیت‌هایی مثل extend کردن و اینها هم برای این حافظه‌ها مطرح هستش. روش عملکردشون هم این طوریه که یه آدرس رو بهش میدی، نتیجه ۰ یا ۱ برمیگردونه که آیا در جدول وجود داره یا نه. دو تا مدل CAM و TCAM هم وجود داره که CAM برای جدول مک و TCAM برای جدول مسیریابی کاربردی هستش. فرقشون در این هستش که TCAM از قابلیت don’t care هم پشتیبانی میکنه و اصطلاحا حالت ternary رو داره. پرانتز رو ببندم.با توجه به وجود تکنولوژی TCAM دیگه سرعت lookup در جدول مسیریابی بالاست و اصلا توجیهی نداره که به این دلیل، کسی سراغ MPLS بره و اون دوران گذشته.بحث پشتیبانی از پروتکل‌های مختلف هم هست بالاخره ولی واقعیت اینکه امروزه روز، اغلب ترافیک Ethernetی شده و غیر از این نداریم و اصلا چرا باید داشته باشیم. (حداقل تا جایی که من بلدم و میدونم)اینها دلایلی بودن که توی فضای آکادمیک برای MPLS مطرح میشن، با این حال، در دنیای صنعتی، سه تا دلیل اصلی برای استفاده از MPLS در شبکه مطرح هستش. یکی مهندسی ترافیک، یکی برقراری سرویس های VPN و یکی هم امکان حفاظت که سعی میکنم توی پست بعدی درباره این سه تا عامل توضیحات بیشتری رو بیارم.محمد لبافمحمد لبافWed, 06 Oct 2021 16:11:34 +0330https://virgool.ir/@mohamad.labbaf/توضیحات-کلی-درباره-لایه-های-۲-و-۳-شبکه-danlu1qkxqnnتوی سه پست قبلی درباره فضای Open Networking توضیحاتی رو آوردیم. توی این پست میخوام یه ذره درباره خود شبکه صحبتی رو داشته باشیم (توی این پست نمیخوام خیلی وارد جزئیات بشم و سعی میکنم کلیات رو مطرح کنم و هدفم این هستش که بتونم یه تصویری رو از شبکه سوییچ و روتر و اینها ایجاد کنم)به طور کلی و آکادمیک دو جور لایه‌بندی برای شبکه عنوان میشه. یکی مدل OSI که هفت لایه است و یکی مدل TCP/IP که ۴ یا ۵ لایه است و یه جورایی مختصرترشده‌ی مدل OSI‌ هستش. توی این پست میخوام تمرکز کنم روی لایه‌های ۲ و ۳ از مدل OSI که در مدل TCP/IP هم حضور داره.لایه های شبکهکلا هر دستگاهی در سطح شبکه دو تا آدرس مک و IP رو داره (حالا هم IPv4 و هم IPv6) که متمایزکننده اون دستگاه هستش.وقتی صحبت از آدرس مک میکنیم، یعنی لایه ۲ شبکه و وقتی صحبت از آدرس IP میکنیم، یعنی لایه ۳ شبکه. توی تجهیزهای شبکه که این دو لایه رو پشتیبانی میکنن، برای ذخیره آدرس‌های لایه ۲ از جدول مک (MAC Table) استفاده میشه و برای ذخیره آدرس‌های لایه ۳ از جدول مسیریابی (Routing Table). مهم‌ترین تفاوت این دو تا جدول هم برمیگرده به موضوع LPM (Longest Prefix Match). یعنی چی؟ببین وقتی قراره مسیریابی در سطح لایه ۲ باشه، یعنی مک باشه، یعنی عملکرد سوییچی داشته باشیم، باید کل آدرس مقصد به طور کامل در جدول وجود داشته باشه. اگه نباشه چی؟ سوییچ اون ترافیک رو روی همه پورت‌هاش ارسال میکنه، در واقع flood میکنه.ولی وقتی قراره مسیریابی در سطح لایه ۳ باشه، یعنی IP باشه، یعنی عملکرد روتری داشته باشیم، به آدرسی ارسال میشه که بیشترین انطباق رو داشته باشه. اگر نداشت چی؟ میفرسته برای default gatewayش. هر چی رو ندونه میفرسته برای default gateway که یه entry هست توی این جدول. اگه default gateway نداشت چی؟ هیچی، dropش میکنه دیگه. کاری از دستش برنمیاد!بنابراین وقتی صحبت از جدول مک میشه، به تعداد آدرس‌های مورد استفاده باید entry اختصاص بدیم ولی توی جدول مسیریابی این طوری نیست و یه سری تجهیز با همدیگه، یه entry رو استفاده میکنن. این کار scaling رو امکان‌پذیر میکنه.حالا وقتی یه تعداد محدودی از دستگاه‌ها رو میخوایم در کنار همدیگه داشته باشیم، میتونیم از یه سوییچ استفاده کنیم و همه چیز اکی هستش. فقط احتمالا توی ارتباط بین این سوییچ‌هامون اگه حلقه (loop) داشته باشیم، اون flooding میتونه مشکل‌ساز بشه دیگه و کل شبکه رو down کنه. برای حل این مساله راه‌حل مرسوم استفاده از پروتکل‌های spanning tree هستش که حلقه رو از بین میبره و البته protection رو هم داره (البته در حد چندین و چند ثانیه!). هم‌چنین اگه تعداد سوییچ‌هامون از حدود ۷ تا برای STP و حدود ۱۵ تا برای RSTP فراتر بره، دیگه این پروتکل همگرا نمیشه و شبکه کار نمیکنه.وقتی میخوایم تعداد نودهای شبکه رو توسعه بدیم و scale کنیم، اینجاست که باید بریم سراغ جدول مسیریابی و عملکرد روتری.توی این متن چند بار از اصطلاح عملکرد سوییچ یا عملکرد روتر استفاده کردم که بی دلیل نبود. قبلترها، سوییچ و روتر دو تا تجهیز مجزا بودن و البته هنوزم محصولات مجزایی برای اونها وجود داره ولی با رشد تکنولوژی، الان data plane این دو تا مشابه با هم هستن و همون data planeی که کار لایه ۲ی رو انجام میده، لایه ۳ و حتی فراتر از اون رو هم انجام میده. به اینها میگن multi-layer switch. بنابراین الان اینجوریه که بیشتر از لحاظ مفهومی لایه ۲ و ۳ با هم فرق دارن و صدالبته نحوه استفاده از اونها در شبکه.خود مسیریابی در سطح لایه ۳ هم یه سری مشکلات داره که برای حل اونها، مسیریابی در لایه ۲.۵ (MPLS) به وجود اومد که البته خود اون هم مشکلاتی رو داره و بحث‌هایی مشابه با SD-WAN تعریف شدن که سعی میکنم توی پست های بعدی درباره‌شون توضیحاتی رو بگم، به امید خدا.محمد لبافمحمد لبافThu, 23 Sep 2021 17:28:05 +0330https://virgool.ir/@mohamad.labbaf/open-networking-و-فضای-استارتاپی-u1zkw1qwi3cpتوی پست قبلی درباره یه سری شرکت صحبت کردم که در فضای Open Networking مشغول به کار هستن و یه جورایی میتونن نیازمندی‌هایی رو پاسخ بدن که قبلا وندورهای بزرگ این کار رو انجام میدادن. بیشتر شرکت‌هایی که توی اون متن اسم بردم، شرکت‌های بزرگی محسوب نمیشن و تعداد نیروهاشون در قیاس با وندورها خیلی کمتر هستش ولی با این وجود در این حوزه مشغول هستن و جا پاشون رو باز کردن.توی این پست میخوام درباره سه تا شرکت Volta Network، DriveNets و UfiSpace یه توضیحاتی رو بیارم و اصل نوآوری که این شرکت‌ها دارن رو بگم.اول بریم سراغ Volta Networkاحتمالا همه‌مون تجربه استفاده از VMware یا Virtual Box رو داریم. هممون دیدیم که میشه از قابلیت مجازی‌سازی بر روی سیستم‌های x86 استفاده کرد و در واقع با استفاده از یک سخت‌افزار مشترک، چندین ماشین رو در کنار همدیگه داشت. این قابلیت تاثیر خیلی زیادی رو در حوزه های مختلف ایجاد کرد.ایده اصلی شرکت Volta Network هم مشابه با همین کار هستش. به عبارتی، این شرکت ادعای این رو داره که میتونه قابلیت مجازی سازی رو بر روی سخت‌افزارهای مختص به تجهیزات شبکه پیاده‌سازی کنه. این شرکت ادعا میکنه که امکان این رو فراهم کرده که بشه یک سخت‌افزار معمولی شبکه رو داشته باشیم و تا ۲۵۵ ماشین مجزا رو بر روی اون اجرا کنیم.شاید این سوال مطرح بشه که فرق رویکردی که Volta Network داره با رویکردی که VMware داشته در چی هستش. پاسخ در این هستش که VMware امکان مجازی سازی رو بر روی سخت‌افزارهای مبتنی بر x86 پیاده میکنه که سخت‌افزارهایی عام هستن ولی Volta Network این کار رو بر روی سخت افزارهای خاص منظوره انجام میده که کار پردازشی رو تراشه های سوییچینگ برعهده دارن و پیچیدگی‌های خاص به خودش رو داره.ساختار نرم‌افزار این شرکت به این گونه هست که قسمت اصلی نرم‌افزار اون خارج از سخت افزار، مثلا روی یه سیستم ابری اجرا میشه (اینجوری مشکل scalability رو هم حل کردن) و قاعدتا به تعداد ماشین‌های مجازی که مدنظر دارن، نرم‌افزار مجزا اجرا میشه. خروجی این نرم‌افزارها از طریق یه پروتکل اختصاصی این شرکت به سخت افزار منتقل میشه. بر روی سخت‌افزار یه agentی پیاده‌سازی شده که این اطلاعات رو میگیره و بر روی سخت‌افزار اجرا میکنه. اینجوری میتونیم که مجازی‌سازی رو مشابه با پردازنده‌های x86 بر روی تراشه‌های سوییچینگ خاص هم داشته باشیم.ساختار نرم‌افزار Volta Networkاما درباره DriveNets و UfiSpaceشرکت DriveNets در حوزه نرم‌افزار کار میکنه و UfiSpace‌ در حوزه سخت‌افزار. این دو شرکت یه پروژه POC (Proof Of Concept) با نرخ ۴۰۰ گیگ رو برای AT&T بین دالاس و آتلانتا انجام دادن که خبرهای زیادی درباره اون منتشر شده.نوآوری DriveNets یه قدری متفاوت هستش. محصول این شرکت دو تا رویکرد رو مطرح میکنه. یکی اینکه میشه از سخت‌افزار و نرم‌افزار یکسانی در قسمت‌های مختلف شبکه استفاده کرد و نیازی نیست که برای هر قسمتی از شبکه یه سخت‌افزار خاص و ویژه رو برای اون تهیه کرد. دوم هم اینکه، برای scaling بیشتر طرفدار horizontal scaling هستش تا vertical scaling.بذار یه قدری بیشتر توضیح بدم که شفاف‌تر بشه. وقتی صحبت از vertical scaling‌ میکنیم، یعنی یه سیستم خیلی قوی رو استفاده کنیم. توی ادبیات تجهیزات شبکه میشه یه شاسی بزرگ و قوی که کارت‌های قوی رو میشه روش استفاده کرد. در واقع، از همون اول باید یه شاسی خفن بگیری، حتی اگه الان نیاز نداشته باشی ولی horizontal scaling میگه که به اندازه نیازت، سیستم متوسط رو اضافه کن. توی ادبیات تجهیزات شبکه میشه یه سری سخت‌افزار کوچک که با توجه به نیاز، کنار همدیگه چیده میشن. در واقع، توی مدل vertical scaling صحبت از یه هالک بزرگ هست که همه کار میکنه ولی توی مدل horizontal scaling از یه سری مینیونز صحبت میشه که کنار هم، قدرت خیلی بالایی رو دارن.رویکرد horizontal scaling دربرابر vertical scalingشکل زیر، امکان استفاده از محصول‌های DrvieNets رو در قسمت‌های مختلف شبکه نشون میده. همون طوری که توی این شکل هم مشخص شده، ایده DriveNets این هستش که از یک سخت‌افزار و نرم افزار مشابه در قسمت‌های مختلف شبکه از last mile گرفته تا هسته شبکه میشه استفاده کرد.استفاده از نرم‌افزار DriveNets در قسمت‌های مختلف شبکهبرای این منظور، دو نوع سخت‌افزار نیاز هستش که یکی کار سوییچینگ رو انجام بده و یکی کار فبریک رو. اینجاست که سخت‌افزارهای UfiSpace قابل استفاده میشن. این شرکت دو تا سخت‌افزار (از جنس همون مینیونزها) داره که قابلیت scaling دارن و میتونن در کنار هم استفاده بشن.سخت‌افزار مربوط به سوییچینگ شرکت UfiSpace (مدل S9700-23D)سخت‌افزار مربوط به فبریک شرکت UfiSpace (مدل S9705-48D)چیزی که به نظر میرسه (البته جایی مستقیما این رو نخوندم) اینه که AT&T داره از این دو تا شرکت و یه سری کارهای مشابه با این حمایت میکنه و احتمالا چیزهای بیشتری رو از شرکت‌های نوآور در این حوزه خواهیم شنید.محمد لبافمحمد لبافWed, 15 Sep 2021 14:32:58 +0430https://virgool.ir/@mohamad.labbaf/open-networking-در-عمل-m5g2f6fvydyaتوی پست قبلی درباره فضای Open Networking صحبت کردم. اونجا گفتم که به دلایل مختلف از جمله سرعت بالای تغییرات و نیاز به نوآوری بیش از پیش، امکان این به وجود اومده که تجهیزات شبکه‌ی پرظرفیت (منظورم حدود ترابیت بر ثانیه هستش) رو داشته باشیم، درحالی‌که از وندورهای بزرگ خریداری نکردیم. توی این پست میخوام یه مقداری درباره این موضوع و شرکت‌هایی که در این حوزه مشغول هستن، صحبت کنیم.در ساختار disaggregation، سخت‌افزار از نرم‌افزار جدا شده و در واقع یه شرکتی سخت‌افزار (یا همون لایه داده) رو طراحی میکنه و یه شرکت دیگه‌ای نرم‌افزار (یا همون لایه کنترلی) رو که برای هر کدومشون گزینه‌های مختلفی توی دنیا وجود داره.سخت‌افزار تجهیز شبکهبیشتر شرکت‌هایی که روی طراحی سخت‌افزار کار میکنن، شرق آسیا قرار دارن و اونجا کار میکنن. معروف‌ترین‌هاشون هم Accton، Agema و Celestica هستن. یه شرکت دیگه‌ی سخت‌افزارساز هم UfiSpace هستش، اسمش رو میارم، چون بعدا میخوام درباره ارتباط بین UfiSapce و AT&T یه توضیحاتی رو در یه پستی بنویسم به امید خدا.این شرکت‌ها سخت‌افزارهای مختلفی رو با مشخصات مختلفی طراحی میکنن و در اختیار مشتری‌ها قرار میدن. با توجه به تیراژ بالا و روش‌های حرفه‌ای طراحی و ساختشون، قیمتشون هم خیلی پایین از آب درمیاد و عملا رقابت کردن با اونها غیر ممکنه. سخت‌افزاری که اون‌ها در اختیار قرار میدن، هیچ قابلیت شبکه‌ای نداره. به اصطلاح بهشون میگن Bare Metal Switch. حالا سوال پیش میاد که یه نفر وقتی این سخت‌افزار رو میخره، چجوری میتونه ازش استفاده کنه؟ این مساله رو هم گروه‌های Open Networking حل کردن و یه سیستم عامل خیلی کوچولو به اسم ONIE رو طراحی کردن که بر روی Bare Metal Switch نصب میشه. نرم‌افزار (که در واقع یه سیستم عامل شبکه هستش) رو با استفاده از این ONIE میشه روی سخت‌افزار به راحتی نصب کرد. اینطوری شما میتونی سخت‌افزار رو طراحی کنی و اصلا کاری نداشته باشی که چه کسی چه نرم‌افزاری رو میخواد روی سخت‌افزار شما اجرا کنه. همه چیز Abstract شده و به خوبی تعریف شده.نرم‌افزار تجهیز شبکهشرکت‌های نرم‌افزاری بیشتر کشورهای غربی هستن و اینجا هم گزینه‌های مختلفی وجود دارن. شرکت‌هایی مثل Cumulus (که اخیرا Nvidia خریدتش)، big switch، Arrcus و ... هستن. دو تا شرکت دیگه Volta Network و DriveNets هم هستن که درباره‌شون توی یه پست مجزا مینویسم به امید خدا. دو تا سیستم‌عامل ONL و OpenSwitch هم به صورت متن‌باز در دسترس هستن که خیلی محدودیت دارن و عملا خیلی کاربردی نیستن، حداقل تا الان. (ONL شاید آینده‌دار باشه. OpenSwitch رو هم Dell متن‌باز کرده ولی نسخه تجاری خودش رو داره و اون به درد بخورتره.)این نرم‌افزارها از قابلیت‌های مختلف تجهیزات شبکه پشتیبانی میکنن و تست‌های مختلف IXIA و Spirent (دو تا شرکتی که تجهیزات تست شبکه میسازن و کلا خیلی معروف هستن و معتبر) رو گذروندن.با توجه به توضیحات بالا، شاید این سوال پیش بیاد که چرا یه نفر با وجود این سخت‌افزارها و سیستم‌عامل‌های شبکه، بازم بره از یه وندور بزرگ مثل سیسکو با قیمت چند برابری تجهیز پرظرفیت شبکه رو خریداری کنه؟جوابش توی این ضرب‌المثل هستش، هیچ‌کسی بابت خرید از IBM اخراج نشده!شما وقتی از سیسکو تجهیزت رو میخری، دیگه خیالت راحته که از سیسکو خریدی و پشتیبانی سیسکو رو داری. منتها وقتی سخت‌افزار رو از شرکت ۱ و نرم‌افزار رو از شرکت ۲ خریدی، اگه مشکلی پیش بیاد، پشتیبانی از اون سخت‌تر میشه و ممکنه اذیت بشی.شاید یه سوال دیگه‌ای مطرح بشه که چرا بعد این همه سال، یه سری شرکت به این نتیجه رسیدن که سخت‌افزار رو طراحی کنن و چرا مثلا ۱۵ سال پیش این کار رو انجام نمیدادن؟جوابش در این هستش که وندورها از تراشه‌های مخصوص به خودشون استفاده میکردن و هنوز هم که هنوزه، اطلاعات زیادی درباره تراشه‌های اون‌ها در اختیار نیست (به جز تراشه silicon one جدید سیسکو که یه حرف‌های محدودی درباره‌اش زده شده و برای ساختش ۱ میلیارد دلار هزینه کرده، درست خوندید یک میلیارد دلار!). با این وجود، یه سری شرکت توی دنیا ایجاد شدن که تراشه‌های با امکانات و ظرفیت بالا رو طراحی کردن که این شرکت‌ها شامل Barefoot (بعدا Intel اون رو خرید)، Mellanox (بعدا Nvidia این رو خرید)، Nephos و Broadcom میشن. حالا دیگه این تراشه‌ها، کاملا رقیب تراشه‌های وندورهای بزرگ هستن و از اونها میشه در تجهیزات شبکه استفاده کرد.در کل، واقعیت اینه که مصرف‌کننده‌های بزرگ تجهیزات شبکه با انحصار غول‌های تکنولوژی راحت نبودن و نیستن و دارن فضای Open Networking رو توسعه میدن و به نظر میرسه این قصه ادامه داره.محمد لبافمحمد لبافWed, 01 Sep 2021 13:50:07 +0430https://virgool.ir/@mohamad.labbaf/مختصری-درباره-open-networking-jsvsezgqbsbdاز اواخر ۹۶ کار کردن در حوزه IP شبکه رو به اقتضای نیازمندی‌هایی که مطرح بود، شروع کردم. نکته‌ای که هست اینه که محتوای فارسی در بعضی از حوزه‌های اون عملا میشه گفت که نیست. در همین راستا، به نظرم اومد که متن زیر رو درباره فضای Open Networking آماده کنم و امیدوارم که جذاب بوده باشه.تا چند سال پیش از این، وقتی صحبت از تجهیزات پرظرفیت (با تکنولوژی الان، چند ترابیت بر ثانیه) میشد، ناخودآگاه ذهن‌ها میرفت به سمت وندورهای بزرگ مثل سیسکو، جونیپر، هواوی و نوکیا. در واقع کل این بازار بزرگ در انحصار این غول‌ها بود و البته قسمت عمده بازار در اختیار سیسکو.نتیجه قهری این انحصار، هزینه بالای تجهیزات و سرعت پایین innovation در این حوزه بود که نمیتونست متناسب با نیازمندی‌های جدید پاسخگو باشه. از طرفی دیگه، Google و Facebook نیازمند Data Centerهای بزرگی بودن که در اونها از این تجهیزات استفاده میشد و به نظر نمیتونستن با این انحصار کنار بیان.در نتیجه این تقابل، Open Compute Project (OCP) به وجود اومد که فضای Open Networking رو به این حوزه وارد کرد. در ضمن این پروژه، ساختار جدیدی برای طراحی این تجهیزات پرظرفیت پیشنهاد شد و این امکان به وجود اومد که شرکت‌های کوچک‌تر در جای جای دنیا بتونن در این حوزه فعال بشن.ایده اصلی این ساختار هم این بود که بیایم، سخت‌افزار یک تجهیز شبکه رو از نرم‌افزارش جدا کنیم و مفهوم Disaggregation تعریف شد. در واقع نرم‌افزار از سخت‌افزار disaggregate شد و بین اونها interfaceهای استانداردی رو تعریف کردن که در نتیجه اون شرکت اول میتونست فقط روی سخت‌افزار کنه و شرکت دومی روی نرم‌افزار.همون طوری که در شکل بالا نشون داده شده، ایده اصلی این هستش که در گام بعدی از disaggregation به سمت نرم‌افزار باز و ماژولار بریم که بین ماژول‌ها interfaceهای استانداردی تعریف بشه و امکان خلاقیت و نوآوری بیش از پیش. با این حال واقعیت اینه که تا سال ۲۰۲۱ در مرحله disaggregation هستیم و جلو نرفتیم.محمد لبافمحمد لبافMon, 16 Aug 2021 17:40:15 +0430