اگر از پست قبل به خاطر داشته باشین، توضیح داده شد که چندین سال از NAT به عنوان راهکاری در ساختارهای شبکه ی مشتریان برای کاهش نیاز به آدرس های IPv4 Public استفاده می شد.

زمانی که آدرس های IPv4 Public به مرز اتمام نزدیک شدن، ISP ها به دنبال جواب این سوال بودن که چطور می تونن ارتباط خودشون با مشتریانشون رو حفظ بکنن. پاسخ این پرسش این بود که اگر NAT در لبه ی مرزی ساختار مشتریان با پروایدرها تونسته بود موفق عمل بکنه پس قطعا میتونه در لبه ی مرزی ساختار پروایدرها با مشتریانشون هم موفق عمل کنه. در واقع این پاسخ، ایده ی اصلی شکل گیری مفهومی با نام Large Scale NAT یا LSN بود.

معماری LSN به این صورته که، ISP ها برای لینک هایی که به سمت مشتریان خودشون دارن به جای تخصیص آدرس IPv4 Public از آدرس های IPv4 Private استفاده می کنن و برای لینک هایی که برای ارتباطشون با اینترنت هست از آدرس IPv4 Public.

بنابراین اگر مشتری در روتر مرزی خودش با سرویس پروایدر، از NAT استفاده کرده باشه، پکتی که از سمت ساختار مشتری به سمت ISP ارسال میشه ابتدا آدرس IPv4 Private اش به یک آدرس IPv4 Private دیگه که از سمت ISP به لینک بین اون و روتر مرزی مشتری اختصاص پیدا کرده نگاشت میشه و در هنگام خروج پکت از ساختار پروایدر به سمت اینترنت، آدرس اون به یک آدرس IPv4 Public ترجمه میشه. پس بنابراین میشه گفت دوبار ترجمه رخ میده: یک آدرس IPv4 Private به یک آدرس IPv4 Private دیگه و نهایتا به یک آدرس IPv4 Public ترجمه میشه. به همین دلیل به این عمل NAT444 گفته میشه.

خوبی این روش این هست که NAT ای که سمت مشتریان پیاده سازی شده هیچ نیازی به تغییر نداره چون که برای NAT اصلا مهم نیست که آدرس outside ای که نگاشت به اون باید انجام بشه، باید Private باشه یا Public. بنابراین از دید تجهیز سمت مشتری، هیچ تغییری رخ نداده.

اما این معماری قطعا مشکلاتی رو هم در پی خواهد داشت: مثلا تصور کنین که مشتری در ساختار خودش از همون رنج آدرس IPv4 Private ای استفاده کرده باشه که پروایدر اون رنج رو به لینک بین خودش و مشتری اختصاص داده باشه، در این صورت overlap رخ خواهد داد. یا مثلا تصور کنین که یک مشتری بخواد پکتی رو به یک مشتری دیگه که در پشت همون LSN ای که باهاش ارتباط داره، ارسال بکنه. خوب معمولا فایروال ها یا ACL هایی که در روترها تعریف میشن، مانع از ورود پکتی با آدرس IP Private به داخل ساختار میشن و این پکت ها رو drop میکنن.

در این پست سعی شده تا بیشتر با معماری LSN، مزایا و معایبش و هم چنین راهکارهایی که برای حل مشکلات این معماری ارائه شده آشنا بشیم.


📡 @networkz

http://www.networkworld.com/article/2231905/cisco-subnet/large-scale-nat-architectures.html

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

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

در پست زیر، نویسنده دقیقا همین عمل رو انجام داده. یعنی با یک مثال خیلی ساده، یک مکالمه ی روزمره ای که یک مهندس شبکه با یکی از کاربرانش داره رو توضیح داده. البته گاهی هم مورد پیش اومده که این مکالمه رو شما با یک کارشناس شبکه ی دیگه داشته باشین 🙊
در هر حال خوندن این پست خالی از لطف نیست :)

📡 @networkz

👇👇👇

https://www.linkedin.com/pulse/what-its-like-network-engineer-ron-buchalski

در پست قبل معماری Large Scale NAT یا LSN، به همراه مشکلاتی که سر راه این معماری وجود داشت و همینطور راه حل هایی که برای حل این مشکلات قابل استفاده بودن، توضیح داده شد. به طور خلاصه اگر بخوایم مروری داشته باشیم، قضیه به این صورت بود که:

ساده ترین روش پیاده سازی LSN، بهره گیری از NAT444 بود که یکی از مشکلات سر راه این روش، احتمال ایجاد overlap بین آدرس های IP Private مشتریان و رنج آدرس IP های Private ای بود که ISP به لینک بین دستگاه خودش و مشتری اختصاص داده بود. مشکل بزرگ بعدی زمانی پیش میومد که دو مشتری که هر دو با یک LSN ارتباط داشتن، قصد برقراری ارتباط با هم رو داشته باشن. در این صورت چون آدرس Private به آدرس Public ای نگاشت نمی شد،احتمال drop شدن پکت ها از سوی دستگاه هایی که در لبه ی ساختار شبکه ی مشتری قرار داشتند، افزایش پیدا می کرد.

یکی از راه حل های پیشنهادی برای حل این مشکل این بود که از یک بلوک از آدرس های IPv4 باقی مونده که با آدرس های RFC 1918 (یا همون آدرس های IPv4 Private) هم پوشانی نداشته باشند، به عنوان shared address استفاده بشن و از این طریق هم مشکل هم پوشانی آدرس ها حل بشه و هم از مشکل فیلتر شدن پکت های مشتریانی که در پشت یک LSN یکسان قرار دارند، جلوگیری بشه. اما این پیشنهاد تقریباً هیچ وقت عملیاتی نشد.

راه حل بعدی، استفاده از آدرس های IPv6 بین ISP و مشتریان، به جای آدرس IPv4 بود. در واقع استفاده از NAT464. این روش علاوه بر این که مشکلات NAT444 رو حل می کرد، به Provider ها هم این امکان رو میداد که سریعتر به سمت معماری IPv6-only که مد نظر داشتند، حرکت کنند. سختی این روش این هست که هم CPE NAT ( یا همون NAT سنتی مورد استفاده سمت ساختار مشتری) و هم معماری LSN، باید قابلیت ترجمه ی هردوی آدرس های IPv4 و IPv6 به همدیگه رو داشته باشند که همین موضوع باعث ایجاد پیچیدگی و بروز مشکلات جدیدی در عملکرد، مقیاس پذیری و افزونگی می شه.

روشی که برای حل این مشکلات پیشنهاد شد،
Dual-Stack Lite
نام داشت. در این روش به لینک بین مشتری و ISP، فقط آدرس IPv6 اختصاص داده میشه. پکت IPv4 ای که از جانب ساختار مشتری بخواد به مقصدی خارج از این ساختار، ارسال بشه، در یک پکت IPv6 کپسوله میشه و به سمت پروایدر ارسال میشه. روتری که در لبه ی ساختار پروایدر قرار داره، این پکت IPv6 رو باز می کنه و در قبال محتویات اون ( که در واقع یک پکت IPv4 هست) از NAT44 استفاده می کنه.
پس به این ترتیب با پیاده سازی یک تانل IPv4 بر روی لینک IPv6
بین ساختار مشتری و ISP، این هدف محقق میشه و علاوه بر این که پیاده سازی این تانل خیلی ساده تر از ترجمه ی آدرس هاست، نگرانی های مربوط به مباحث redundancy و performance هم برطرف میشن.

در این مقاله سعی شده تا بیشتر با Dual-Stacke Lite و انواع مدل های پیاده سازی اون آشنا بشیم.


📡 @networkz

👇👇👇
http://www.networkworld.com/article/2232181/cisco-subnet/understanding-dual-stack-lite.html

🎙تخصص شبکه؛ امروز و فردا!

در این پادکست با دو تن از متخصصین عزیز شبکه، جناب آقای مهندس حسین خسروی (CCIE# 55382, n*CCxP) و جناب آقای مهندس حامد ذوالقدری (CCDE #20150003, 3*CCIE36789) همراه بودیم.

مباحث اصلی صحبت شامل موارد زیر بودند:
✅ تعریفی از شبکه و به طور کلی بررسی این دیدگاه که شبکه چیست؟
✅ پیدا کردن تعریفی برای مهندس شبکه، یک متخصص یا مهندس شبکه کیست؟
✅ بررسی تخصص زیر ساخت شبکه یا اصطلاحا IP Networking یا Data Networking
✅ بررسی نقطه ی شروع برای ورود به دنیای شبکه و متخصص شبکه شدن، آیا این مسیر و به دست آوردن این تخصص ساده است؟ نکات اصلی در مسیر حرکت در این راه چه مواردی هستند؟
✅ آیا مدارک شبکه می توانند مفید باشند؟ این مدارک چه زمانی می توانند مثمر ثمر واقع شوند؟
✅ با مطرح شدن مباحثی چون SDN در سال های اخیر، آیا مهندسین شبکه باید به سمت Programming حرکت کنند؟ حداقل دانش های مورد نیاز برای یک مهندس شبکه در حال حاضر چه مواردی می توانند باشند؟

📡 @networkz

❕برای پخش ساده در تلگرام روی تصویر کلیک کنید
https://www.spreaker.com/user/moghaddas/podcast-2-takhasos-shabake-emrooz-farda

جهت سوال، پیشنهاد یا انتقاد برای پادکست‌های آینده👇
https://fa.ip.engineering/podcast-2-تخصص-شبکه-امروز-و-فردا/

وقتی به عنوان مدیر شبکه به تیم برنامه نویسی سازمان معرفی میشید!

📡 @networkz
🌐 https://fa.ip.engineering

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

📡 @networkz

👇👇👇
https://fa.ip.engineering/dnssec-history/

اپراتورهای شبکه با اتکا به ابزارها و فیچرهای مختلف همیشه سعی در آنالیز دقیق مسیریابی اینترنتی و بهینه سازی فرآیندهایی چون روند جریان ترافیک، تشخیص حملات DDoS یا Prefix hijacking دارند.

در IXP ها از اون جایی که معمولا از روترهای نرم افزاری چون BIRD و Qugga به عنوان BGP Server ها استفاده می شه، آنالیز ترافیک کمی دشواره دلیلش هم اینه که در این ابزارها اجرای فرآیندهای پردازش داده و استخراج نتایج حاصل از این پردازش کمی داراری محدودیت هست.

به منظور غلبه بر این محدودیت ها ابزاری با نام PCAP BGP Parser یا به اختصار pbgpp تولید و توسعه داده شده که یک تحلیل کننده ی داده های BGP محسوب میشه.

یکی از مزایای این ابزار، ساده سازی روند جمع آوری داده های BGP و تجزیه و تحلیل اون هاست. برای مثال یکی از ابزارهای مشهور برای خطایابی و جمع آوری داده های BGP، ابزار tcpdump هست که برای محدود کردن کپچر داده ها فقط به پکت های BGP، میشه این ابزار و محدود به شنود پورت 179 کرد. خب حالا فایل حاصل از این داده های جمع آوری شده توسط tcpdump می تونه به عنوان ورودی به pbgpp داده بشه.

از مزیت های دیگه این ابزار، قدرت زیاد اون در فراهم کردن گزینه های مختلف فیلترینگ هست. برای مثال pbgpp این امکان رو برای شما فراهم میاره که فیلترینگ رو تنها بر اساس فیلدهای BGP مثل: Community ها، Prefix، Message Type، Next Hop و ... انجام بدید.

هم چنین این ابزار فرمت های مختلفی رو برای دریافت خروجی فراهم می کنه که یکی دیگه از مزیت های اون محسوب میشه.

موارد گفته شده در بالا بخشی از معرفی ابزار pbgpp بود که متن کامل اون رو می تونید از طریق لینک زیر مطالعه کنید:

📡 @networkz

👇👇👇
https://blog.apnic.net/2017/06/02/pbgpp-makes-analysing-bgp-data-easier/

🎙Leaky Abstraction (انتزاع رخنه‌گر)

انتزاع رخنه گر یا Leaky Abstraction، تغییراتی در یک بخش هستن که میتونن به صورت غیر مستقیم به سایر بخش‌های ساختار [شبکه] نفوذ کنن و منجر به نتایجی ناخواسته در اون بخش ها بخشن.
در این پادکست به این مفهوم مهم در مهندسی، علی‌الخصوص مهندسی شبکه، همراه با بررسی مثال هایی از دنیای واقعی شبکه از جمله تجربه‌ای شخصی از یک رخداد در سرویس شرکت AT&T پرداخته شده.

📡 @networkz

❕برای پخش ساده در تلگرام روی تصویر کلیک کنید
https://www.spreaker.com/user/moghaddas/podcast-3-leaky-abstraction
ضمناً پادکست ها بصورت بخش-بخش تنظیم شده‌اند. بهنگام پخش در تلگرام، این امکان بوسیله علامت 📒 در دسترس است.

جهت خلاصه‌ی نوشتاری پادکست، سوال، پیشنهاد یا انتقاد برای پادکست‌های آینده👇
https://fa.ip.engineering/podcast-3-leaky-abstraction/

وقتی افزونگی درست کار می‌کنه و Fail-over با موفقیت انجام میشه 😎

📡 @networkz
🌐 https://fa.ip.engineering

📣 اینفوگرافیک
آشنایی با IP و IPv6 و ضرورت مهاجرت به IPv6

📡 @networkz

توضیح و دانلود کیفیت بالا👇
https://fa.ip.engineering/ipv6-infograf/

اگر می خواین هکر بشین، سعی نکنین هکر بشین

https://jadi.net/2017/06/how-to-become-a-hacker/

می گن روزی یک عاشق شمشیر بازی پیش استاد رفت. استاد ازش پرسید برای چی اومده و جواب داد «برای اینکه بهترین شمشیرباز ژاپن بشم». استاد لبخند زد و گفت «عالی! حالا اون جارو رو بردار و جارو بکش». بعد از کشمکش های مرسوم شاگرد اصرار کرد که لازمه زیاد تمرین کنه و اگر روزی ۴ ساعت تمرین کنه چقدر طول می کشه بهترین استاد بشه. استاد بهش گفت ۲۰ سال. گفت اگر روزی ۸ ساعت تمرین کنه چی؟ جواب شد ۱۵ سال. اما این هنوزم برای شاگرد زیاد بود پس گفت اگر روزی ۱۲ ساعت تمرین کنه و خیلی جدی و مستمر چی؟ استاد بهش گفت اونجوری تقریبا باید ۴۰ سال کار کنه.

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

در ضمن مستقیما حرکت کردن به سمت هکر شدن مثل اینه که شما بگین دوست دارین خط تون خیلی خوب باشه و بشینین دائم یک جمله رو تکرار کنین. روش درست تر اینه که الفبا رو درست یاد بگیرین و هر کدوم رو درک کنین و بنویسین و بعد با هم ترکیبشون کنین. در اصل اگر شما می خواین یک هکر خوب بشین بهترین کار اینه که پایه ها رو درست یاد بگیرین:

- سیستم عامل
- شبکه
- امنیت
- برنامه نویسی

و از اون پایینتر حتی چیزهایی مثل جامعه شناسی، روانشناسی، ریاضی، آمار و حتی زیست شناسی (: [ جامعه شناسی و روان شناسی برای مهندسی اجتماعی و زیست شناسی برای درک مغز و خطاهاش و در نهایت همشون برای داشتن سطح بالاتری از دانش در حوزه های مختلف بعلاوه لذت بردن از دونستن چیزهای جدید ].

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

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

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

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

@jadinet

این روزها حملات DDoS به بخش لاینفکی از دنیای اینترنت مبدل شده‌اند و روز به روز نیز در حال پیچیده‌تر و قوی‌تر شدن می باشند.
طبعاً شرکت‌های مختلفی وجود دارند که سرویس‌های DDoS Protection/Mitigation ارائه کرده و هر یک از آن‌ها نیز راهکارها و روش های خاص خود را دارند (گاهی نیز شبیه به هم).
📡 @networkz
جدای از بحث استفاده از تجهیزات مقابله با DDoS در شبکه‌ها، زمانی که از یک سرویس‌دهنده‌ی بیرونی استفاده می‌شود، بطور خیلی کلی، معمولا دو حالت پیاده‌سازی (با استفاده از BGP و Tunnel) وجود دارد (معروف به Diversion/Reinjection یا Offramping/Onramping):

✳️ کل ترافیک دائماً از طریق آن سرویس‌دهنده عبور داده شود و اگر حمله‌ای وجود داشته باشد، همانجا مانده و تنها (به اصطلاح) ترافیک پاک به شبکه برسد (Scrubbing).
✳️ فقط زمانی که شبکه تحت حمله قرار می‌گیرد، طی یکسری عملیات و تغییر routing، ترافیک ورودی به شبکه بجای آن که مستقیم از اینترنت به شبکه وارد شود، مانند مدل قبل به سمت یک سرویس‌دهنده هدایت شده و توسط آن بررسی شده و تنها ترافیک پاک به شبکه می‌رسد. این روش، به نوعی On-demand محسوب می شود و کل عملیات و تغییر روتینگ می تواند به صورت خودکار و یا بصورت دستی توسط یک اپراتور رخ دهد.

ادامه‌ی مطلب ⬇️
https://fa.ip.engineering/dots-حملات-ddos/

📝 در نوشته ها و گفته های متعدد در رابطه با IPv6 با این عبارت روبه رو می شویم که:

"‏IPv6‌‏ عملکرد بهتری نسبت به ‏IPv4‌‏ دارد."

و گاهی ‏در پی این عبارت دلایلی نیز آورده می شود. اما چه میزان این مطلب و دلایلی که در پی آن به عنوان مواردی برای ‏بهبود عملکرد ‏IPv6‌‏ مطرح می شوند، صحت دارند؟

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

در این مقاله قصد داریم تا نگاهی فنی تر به این دلایل داشته باشیم.

📡 @networkz

👇👇👇
https://fa.ip.engineering/ipv6-عملکرد

*در راستای سری داستان های ادمینی که تازه در یک مکان استخدام شده*

تصور کنین تازه در جایی به عنوان ادمین شبکه استخدام میشین. شبکه ی اون مکان قبلا پیاده سازی شده و ادمین قبلی بنا به هر دلیلی دیگه اونجا کار نمیکنه و حالا مسئول کل اون ساختار شبکه شما هستین.

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

گشتن و پرس و جوی شما نهایتا نتیجه میده و شما به این نتیجه می رسید که فایل کاملی از ساختار و پیکربندی ها وجود داره اما ...
"توی ذهن ادمین قبل از شما!! 😐"

مدیر شبکه ی قبلی بنا به هر دلیلی دوست نداشته یا نخواسته یا وقت نکرده که این مستندها رو روی کاغذ بیاره یا مثلا به شکل یک فایل جایی ذخیره کنه!

مطمئنا بعد از رسیدن به همچین نتیجه ی درخشانی تنها کاری که می تونین بکنین در بدترین حالت حدس اینه که چه پیکربندی هایی انجام شده و در بهترین حالت بررسی تک تک تنظیمات تمام دستگاههاست (که برای حالت دوم فقط میشه براتون آرزوی موفقیت کرد 😊 )

مستندسازی اطلاعات ساختار شبکه شاید یکی از مهم ترین کارهایی هست که متاسفانه اغلب یا به فراموشی سپرده میشه یا بنا به هر دلیل از عمد انجام نمیشه (که مطمئنم در محیط های کاملا حرفه ای ساختارهای شبکه ای که ما داریم این حالت دوم اصلا پیش نمیاد 😒) !

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

اما این که در یک مستندسازی خوب چه اطلاعاتی و در چه قالبی بیان بشن که در کم ترین زمان شما رو به مقصود خودتون برسونن، مساله ای هست که میتونه دغدغه ی خیلی از ادمین های شبکه باشه.

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

📡 @networkz

👇👇👇
https://www.auvik.com/media/blog/network-documentation-best-practices/

🎙تخصص شبکه؛ امروز و فردا!

در این پادکست با دو تن از متخصصین عزیز شبکه، جناب آقای مهندس حسین خسروی (CCIE# 55382, n*CCxP) و جناب آقای مهندس حامد ذوالقدری (CCDE #20150003, 3*CCIE36789) همراه بودیم.

مباحث اصلی صحبت شامل موارد زیر بودند:
✅ تعریفی از شبکه و به طور کلی بررسی این دیدگاه که شبکه چیست؟
✅ پیدا کردن تعریفی برای مهندس شبکه، یک متخصص یا مهندس شبکه کیست؟
✅ بررسی تخصص زیر ساخت شبکه یا اصطلاحا IP Networking یا Data Networking
✅ بررسی نقطه ی شروع برای ورود به دنیای شبکه و متخصص شبکه شدن، آیا این مسیر و به دست آوردن این تخصص ساده است؟ نکات اصلی در مسیر حرکت در این راه چه مواردی هستند؟
✅ آیا مدارک شبکه می توانند مفید باشند؟ این مدارک چه زمانی می توانند مثمر ثمر واقع شوند؟
✅ با مطرح شدن مباحثی چون SDN در سال های اخیر، آیا مهندسین شبکه باید به سمت Programming حرکت کنند؟ حداقل دانش های مورد نیاز برای یک مهندس شبکه در حال حاضر چه مواردی می توانند باشند؟

📡 @networkz

❕برای پخش ساده در تلگرام روی تصویر کلیک کنید
https://www.spreaker.com/user/moghaddas/podcast-2-takhasos-shabake-emrooz-farda

جهت سوال، پیشنهاد یا انتقاد برای پادکست‌های آینده👇
https://fa.ip.engineering/podcast-2-تخصص-شبکه-امروز-و-فردا/

یکی از اسلایدهای جالبی که هفته‌ی قبل در IETF99 پراگ دیدم؛
بقول یکی از شرکت‌کننده‌ها: "اینترنت از کلی تونل ساخته شده"
ارائه در Transport Working Group
📡 @networkz

شاید یکی از اصطلاحاتی که این روزا راجع بهش زیاد می شنویم و مطلب می بینیم تو دنیای شبکه، SDN یا همون Software Defined Networking هست.

اما این تکنولوژی چیه؟ از کجا ایده ی شکل گیریش مطرح شده؟ مهم ترین هدفش چی هست؟ مکانیزم عملکردش به چه صورت هست؟ چه حوزه هایی رو تحت تاثیر قرار میده؟

در این ویدیوی کوتاه سعی شده تا با معرفی اجمالی SDN به این سوالات پاسخ داده بشه.

📡 @networkz

👇👇👇
http://www.computerworld.com/video/79155/what-is-software-defined-networking-sdn

داستان Troubleshooting مشکلِ دانلود در دنیای واقعی!
اگر به اینکه TCP چطور کار می‌کنه و چجوری با packet capture میشه برخی مشکلات رو پیدا کرد، علاقمند هستین پس لینک زیر رو بخونین
📡 @networkz

https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/

در تاریخ 14 جولای 2017، نهاد IETF با انتشار RFC 8200 رسما اعلام کرد که IPv6، آخرین نسخه ی استاندارد IP هست.

البته باید اذعان کرد که اولین بار IPv6 در RFC 2460 و حدود 18 سال پیش معرفی شده بود اما این RFC صرفا یک Draft Standard بود ولی RFC 8200 برخلاف اون یک، Internet Standard هست.


اما مگه تفاوت این دو تا چی هست که انقد مهمه؟ برای دونستن تفاوت بین Draft Standard و Internet Standard باید مروری بر فرآیند استاندارد سازی فایل ها در IETF داشته باشیم، قضیه از این قرار هست که:

بر طبق RFC 2026، همه چیز با یک Internet Draft آغاز میشه. Internet Draft ها فایل هایی هستن که حاوی ایده های خام و اولیه در رابطه با یک موضوعن و هنوز روی این موضوع ها داره کار میشه. عمر اون ها هم معمولا 6 ماه هست و بعد شیش ماه منقضی میشن یا این که به روزرسانی میشن.

ممکنه یک ID توسط یک Working Group به تصویب برسه اما برای این که برسه به فاز بازبینی و تبدیل شدن به یک Request for Comment یا RFC باید انقد تغییر و اصلاح بشه تا سر تصویب اون موضوع یک توافق عام کسب بشه.

بر اساس اون چیزی که در RFC 2026 مشخص شده، موضوعات برای این که بتونن به Internet Standard یا به بیان دیگه Standards Track تبدیل بشن، اول در یکی از سه دسته ی زیر قرار می گرفتن:

1- Proposed Standard:
موضوعاتی که در این گروه قرار میگیرن، خوب تونستن توجیه، درک و فهمیده بشن، مورد توجه و بازبینی قابل توجهی هم از طرف نهادها قرار گرفتن اما هنوز نیازمند پیاده سازی و تجربیات عملی هستن و ممکنه بعد از کسب این تجربیات، تغییر کنن.

2- Draft Standard:
موضوعاتی هستن که تقریبا به مرحله ی پیاده سازی رسیدن و تونستن تجربیات موفقیت آمیز خوبی هم به دست بیارن اما باید بیشتر روی توسعه و پیاده سازی های اون ها کار بشه تا ثباتشون کاملا مشخص بشه.

3- Internet Standard:
موضوعاتی که در این دسته قرار میگیرن دیگه از همه جهت تونستن پیاده سازی و تجربیات عملیاتی موفقیت آمیزی رو کسب کنن و کاملا مورد تایید community قرار بگیرن. به موضوعاتی که در این دسته قرار بگیرن شماره ای تحت عنوان SID اختصاص پیدا می کنه.

در سال 2011 در RFC 6410 که در واقع نسخه ی آپدیت شده ی RFC 2026 هست، دسته بندی بالا به دو دسته ی Proposed و Internet Standard تبدیل شد و Draft Standard حذف شد بنابراین موضوعاتی که در دسته ی Draft Standard قرار میگرفتن، یکی از این دو عمل زیر در قبالشون انجام گرفت:

1- اگر در رابطه با یک draft standard هیچ errata یا غلطنامه ای وجود نداشته باشه که نیازمند یک پیاده سازی جدید باشه، اون draft standard به دسته ی Internet Standard منتقل میشه.
2- خود IESG تصمیم بگیره که یک Draft Standard در دسته ی Proposed قرار بگیره.

اتفاقی که برای IPv6 افتاد، مورد اول از موارد بالا بود. یعنی کارگروه 6MAN یا همون IPv6 Maintenance (6MAN) Working Group از سال 2015 تلاش کرد که تمام RFC ها (9 مورد) و همینطور Errata ها (2 مورد) در رابطه با IPv6 رو مورد بازبینی و تجدید نظر قرار بده و کل اون ها رو در قالب RFC 8200 معرفی کنه. در واقع این RFC شامل مفاهیم مطرح شده در RFC 2460 به همراه تمام RFC ها و Errata های مرتبط با IPv6 هست و تغییر چندانی رو شامل نمیشه.

اما اگر دقیق تر میخواید بدونید که چه مباحثی در RFC 8200 مطرح شدن که نسبت به RFC 2460 تغییر کردن، آقای راس وایت لطف کردن و در پست زیر این تغییرات رو توضیح دادن:


📡 @networkz

👇👇👇
http://www.circleid.com/posts/20170726_look_at_rfc8200_which_officially_made_ipv6_an_internet_standard/

اگر براتون سواله سراغ کدوم سیستم‌عامل لینوکسی برین، این دیاگرام دیدِ خوبی میده

📡 @networkz

https://twitter.com/moghaddas_it/status/892025106993754112

📝 از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.

به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.


📡 @networkz

👇👇👇
https://fa.ip.engineering/mpls-mpls-te