دوستان خوب، همراهان گرامی،

به آخرین لحظات سال ۹۵ نزدیک میشیم.
مثه بانک ملت، ما هم آروز می‌کنیم سال ۹۶ رو خوب بسازیم تا سال ۹۷ بهتری داشته باشیم 😉

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

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

ممنون که همراه بودین و هستین و امیدواریم که باشید

نوروز بمانید که ایّام شمایید!
آغاز شمایید و سرانجام شمایید!
آن صبح نخستین بهاری که ز شادی
می آورد از چلچله پیغام، شمایید!

🎉🌹💐

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

روز اول سال جدید رو با IPv6 شروع کنیم 😬

میدونین در بدن انسان در حالت معمول چند اتم وجود داره؟ حتماً می‌پرسین خب چه ربطی داره به شبکه؛ حق دارین.

در بدن انسان 27^10 * 7 (7,000,000,000,000,000,000,000,000,000) اتم وجود داره.

اگر به هر اتم موجود در بدن تمام انسان ها!! یک آدرس IPv6 داده بشه، بازهم معادل 3e+38 آدرس باقی می مونه 😁

📡 @networkz
🌐 https://fa.ip.engineering/تعداد-ipv6

این مطلب صرفاً یک دیدگاه شخصی در پاسخ به این سوال هست و سعی میکنم با توجه به حوزه‌ی کاری خودم در زمینه شبکه و امنیت، توضیحات مختصری هم در این رابطه ارائه کنم.
...
من عقیده دارم اگر بتونیم به این خودشناسی برسیم که به چه تخصصی علاقه داریم، فارغ از بحث بازار اون رشته، در کنار داشتن پشتکار، همون علاقه باعث میشه که مسیر متخصص شدن در اون رشته رو خوب طی کنیم و به جایی برسیم که حرفی برای گفتن داشته باشیم. قطعاً وقتی کاری با علاقه باشه، انسان همیشه تشنگی به اون رو حس میکنه و دلش میخواد ادامه بده، یاد بگیره، یاد بده و حتی شاید بتونه نوآوری کنه!
...
در زمینه کاری خودم، شبکه و امنیت شبکه، بارها از من همین سؤال پرسیده میشه یا مثلا سؤال میشه که “چه Certification خوب هست”، یا “شما که الان خارجی بازار کارِ چی خوبه؟” و باز هم من همون جواب رو میدم: “بازار کار چیزی خوبه که شما بهش علاقه داری و میتونی درِش متخصص بشی“؛ همینطور معتقدم که هیچ کاغذی نیست که بتونه نشون‌دهنده‌ی دانش و سواد یک شخص باشه، بلکه فقط و فقط خود اون شخص هست. البته این رو هم کتمان نمی‌کنم که مدارک برای شروع کار می‌تونن مفید باشن
...
اما در دنیای امروز شبکه و امنیت شبکه، یکسری دانش‌ها هستن که یکجورایی دونستنشون برای هر مهندسی لازمه:

- استاندارد ITIL: این روزها در هر سازمانی که با فناوری اطلاعات سروکار داره نوعی از یک استانداردِ مدیریت روندها و اطلاعات IT وجود داره.

- آشنایی با لینوکس و مفاهیم پایه‌ای اون (در حد متوسط): خیلی از کارها هست که با لینوکس راحت‌تره، خیلی از نرم‌افزارهای خوب هستن که متن‌باز (OpenSource) هستن و تحت لینوکس اجرا میشن.

- آشنایی با مفاهیم پایه‌ای یک یا دو زبان برنامه نویسی (scripting): مهندسین شبکه با استفاده از کد میتونن خیلی از کارها رو راحت‌تر و خودکار انجام بدن. بجز اون، هدف دیگه از یادگیری کدزدن، تمرین ذهن در راستای ساختاریافتگی و انجام بهینه‌ی یک کار یا بهینه‌سازی یک روند هست.

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

حتی اگر در حال آماده شدن برای امتحانات یک شرکت هستید (از دست بد/خوب روزگار در ایران عمده‌ی شبکه ها سیسکو هست و مدارک CCNA، CCNP، CCIE و … طرفدارهای زیادی داره) شدیداً توصیه میکنم وقتی دارین برای یک پروتکل مطالعه میکنید حتماً RFC های مرتبط با اون رو مطالعه کنید،

لطفا جهت مطالعه مطلب کامل و درج نظرات ارزشمندتون به لینک ذیل مراجعه کنین.

📡 @networkz

https://fa.ip.engineering/chi-bekhoonam/

قراره پا در مهم ترین بخش سرزمین EIGRP بذاریم. تو این قسمت باید سعی کنیم که قدم به قدم جزئیات رو به خاطر بسپاریم چون فراموش کردن هرکدوم از این جزییات مساوی هست با گم شدن همیشگی در سرزمین EIGRP ! 😱
همراه ما در این بخش از سفر باشید 😉



📡 @networkz

👇👇👇
https://fa.ip.engineering/eigrp-dual/

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

📡 @networkz

👇👇👇
https://fa.ip.engineering/عملکرد-شبکه-delay-vs-packet-loss

"وقتی ادمین شبکه بعد از تعطیلات پاشو تو سازمان میذاره!"
#sysadmin #holiday

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

‼️⚠️⚠️⚠️‼️

این روزها انتشار خبری دوباره سیسکو را بر راس اخبار قرار داد، خبری که شاید چندان هم برای سیسکو خوشایند نبود و آن خبر، از کار افتادن سری های خاصی از ASA ها (Adaptive Security Appliance) و FTD ها (Firepower Threat Defense )، بعد از مدت زمان 213 روز و 12 ساعت از فعالیت آن ها بود!

📡 @networkz

👇👇👇
https://fa.ip.engineering/cisco-operational-bug-asa-firepower

نسل بعدی شبکه های موبایل 5G است که ترکیبی از چند تکنولوژی می باشد. در این ویدیوی کوتاه سعی شده تا بیشتر با این تکنولوژی ها و ویژگی های 5G آشنا شویم.

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

🎙 جهت پخش ساده‌ی پادکست در تلگرام، روی تصویر کلیک کنید
https://www.spreaker.com/user/moghaddas/forwarding

https://fa.ip.engineering/podcast-1-forwarding/

"برای معرفی EIGRP باید به زمانی برگشت که توسعه دهندگان پروتکل IGRP که یک پروتکل اختصاصی شرکت سیسکو بود تصمیم بر توسعه ی این پروتکل گرفته و در صدد تبدیل آن به یک پروتکل Classless برآمدند. اما همزمان با تلاش برای بهبود قابلیت های عملکردی پروتکل IGRP، بر آن شدند تا از الگوریتم های آکادمیکی که در رابطه با بهبود زمان همگرایی بودند نیز در راستای این توسعه کمک گیرند. در نتیجه آن ها نه تنها به هدف خود یعنی ارتقای IGRP دست پیدا کردند بلکه سبب ایجاد پروتکل مسیریابی جدیدی شدند که با وجود برخی شباهت ها در رفتار به IGRP، یک پروتکل کاملا مجزا محسوب می شود..."

این قسمت: EIGRP (بخش اول) :)
📡 @networkz

https://fa.ip.engineering/eigrp-1

همینطور که میدونین Automation بحث داغ این روزهای دنیای شبکه هست و شرکت Cumulus با محصول Cumulus Linux یکی از پیشروها در این زمینه و کلا بحث جدا شدن نرم افزار و سیستم‌عامل از سخت‌افزار هست.

اگر به این مباحث علاقمندید پیشنهاد می‌کنم وبینار زیر رو با عنوان
Automating Network Configuration — from Daft to Deft
از دست ندید
http://go.cumulusnetworks.com/l/32472/2017-03-28/912dlj

📡 @networkz

شنیدین میگن " ما گفتیم این کار انجام بشه ولی نه دیگه اینطوری! 😐"
این دقیقا عبارتی هست که Internet Society در واکنش به این خبر بانمک و البته نه چندان خوشایند گفته...

📡 @networkz

👇👇👇
https://fa.ip.engineering/اینترنت-برای-همه

📢 موقعیت کاری جذاب برای Network Engineer های متخصص Juniper

محل کار و حقوق: کاملاً بسته به سطح تخصص شما، در یکی از شهرهای استکهلم 🇸🇪، یا برلین🇩🇪

حداقل نیازمندی‌ها:
✅ تسلط خوب به زبان انگلیسی
✅ تسلط به JunOS حداقل در حد JNCIS (تفاوتی بین ENT یا SEC یا SP نیست)
✅ آشنایی با یک زبان برنامه‌نویسی مانند Python یا Perl
✅ آشنایی با Linux علی‌الخصوص سرویس‌های شبکه‌ای تحت لینوکس (مثلاً BIRD، ExaBGP و …)
✅ علاقمند به کار تیمی و یادگیری تکنولوژی‌های جدید
✅ آشنایی اولیه با مفاهیم Cloud Computing و SDN

📡 @networkz

👇👇👇
https://fa.ip.engineering/موقعیت‌های-کاری-شبکه-در-اروپا

📝 فرض کنین برای رسیدن به مقصدی چند مسیر فعال وجود داره که cost های یکسانی هم دارن. برخورد یک روتر برای ارسال ترافیک بر روی این مسیرهای فعال به سمت مقصد مورد نظر چطوری هست؟ آیا روش هایی وجود داره که روتر بتونه از تمام این مسیرهای فعال برای ارسال ترافیک مربوط به اون مقصد استفاده بکنه؟ این روش ها چی هستن و هرکدوم چه مزایا و معایبی دارن؟
تو این متن کوتاه سعی شده تا به این پرسش ها پاسخ داده بشه.

📡 @networkz

👇👇👇
https://fa.ip.engineering/ecmp-overview/

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

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

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

روش های مختلفی برای پیاده سازی ساختارهایی که همزمان قادر به پشتیبانی از هر دوی ورژن های IP باشن وجود دارن. اصطلاحا به این عمل همزیستی IPv4/IPv6 گفته میشه. این روش ها عموما در 4 دسته قرار میگیرن که عبارتند از:
1- Dual Stack
2- Manual Tunnels
3- Automatic Tunnels
4- Translators

یکی از روش های پر کابرد و رایج، استفاده از روش Dual stack هست که در عین کارایی و در ظاهر سادگی، معایب و سختی هایی رو هم در پی داره.
در این مقاله سعی شده تا یک معرفی خلاصه از هرکدوم از روش های بالا داشته باشه و سپس به سراغ روش Dual Stack بره و درباره ی مشکلات سر راه این روش توضیح بده.

این مقاله اولین مقاله از سری مقالاتی نسبتا قدیمی اما مفید هست که به بررسی روش های همزیستی IPv4/IPv6 می پردازه و به مرور سایر قسمت ها هم در کانال قرار خواهد گرفت.

📡 @networkz

http://www.networkworld.com/article/2235990/cisco-subnet/the-dual-stack-dilemma.html

📢
در این پست سعی میشه تا لینک هایی در رابطه با دوره های مختلف در حوزه ی IT که اکثراً رایگان یا بسیار کم هزینه هستن قرار داده بشه که مطمئنا میتونن برای علاقمندان این حوزه مفید باشن. خوشحال میشیم که اگر شما هم منبعی رو می شناسید که آموزش های مفید و رایگانی دارن، چه داخلی و چه خارجی، از طریق بخش نظرات این پست به ما معرفی کنین تا به این منابع اضافه بشه :)

📡 @networkz

👇
https://fa.ip.engineering/دوره-های-آموزشی-رایگان-در-حوزه-ی-it

اگر از پست قبل به خاطر داشته باشین، Dual Stack ساده ترین روش برای حرکت به سمت استفاده از IPv6 بود. در این روش، در صورتی که در یک ساختار IPv6، تمام دستگاه ها قابلیت پشتیبانی از هر دوی ورژن های IPv4/IPv6 را داشته باشن قادر خواهند بود تا با هر مقصدی؛ چه IPv4 و چه IPv6؛ ارتباط برقرار کنن. این روش زمانی که اکثر کاربران هنوز در حال استفاده از IPv4 باشند، روش مناسبی هست.

اما مشکل این روش این بود که شما نیاز داشتید به ازای هر اینترفیسی همزمان یک آدرس IPv4 و یک آدرس IPv6 داشته باشین و این در حالی هست که آدرس های IPv4 به پایان رسیدند و قرار بر پیاده سازی روشی برای توسعه ی IPv6 و نه افزایش نیاز به IPv4 ای هست که دیگه وجود نداره!

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

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

اما این روش هم مشکلی مشابه روش استفاده از DHCP داشت. تعداد آدرس های IPv4 Public محدود بودن و اگر همزمان تعداد زیادی دستگاه نیاز به اتصال به اینترنت داشتن، این روش جوابگو نبود. بنابراین عملکرد NAT44 به گونه ای تغییر داده شد که از شماره پورت ها در هنگام نگاشت آدرس ها استفاده بشه. همونطور که میدونید مشهورترین اصطلاح برای این روش Port Address Translation یا PAT بود که این روزها دیگه PAT یک روش جداگانه محسوب نمیشه و تبدیل به عملکرد نرمال NAT44 شده.

اول این مبحث مطرح شد که روش Dual Stack در واقع مشکل IPv4 رو حل نمی کرد چون نیاز به آدرس های IPv4 Public به تعداد زیاد داخل Service Provider ها هم چنان وجود داشت و بعد همونطور که مطرح شد کاری که NAT انجام میداد این بود که شما داخل ساختار می تونستید از آدرس های IPv4 Private استفاده کنید و بعد با داشتن چند تا آدرس محدود Public و استفاده از NAT، بین این آدرس ها نگاشت انجام بدید. خب چی میشه اگر این ایده ی استفاده از NAT به داخل سرویس پروایدرها منتقل بشه؟

در این مقاله به مسایلی که به اون ها اشاره شد پرداخته میشه و نهایتا به معرفی راهکار Carrier Grade NAT یا CGN ختم میشه.

📡 @networkz

http://www.networkworld.com/article/2237054/cisco-subnet/understanding-carrier-grade-nat.html

روزانه سوالات زیادی درباره بحث بازار کار در خارج از کشور میشه. در این کانال پادکستی منتشر شده که تا حدودی به بحث شبکه هم پرداخته شده.
👇
‏https://t.me/neveshtehaaye_man/122

دوستان علاقمند به مباحث امنیت اینترنت، علی‌الخصوص بحث DDoS، پیشنهاد میکنم در این وبینار رایگان که توسط شرکت Akamai برگزار میشه شرکت کنین.
📡 @networkz

Live Webinar: State of the Internet / Security Report – Q1 2017 Findings
Wednesday 17 May 2017, 2:00 pm BST / 3:00 pm CET

Akamai sees more than two trillion Internet interactions every day and has mitigated malicious attack traffic over 630 Gbps. Our security experts analyze this information and share trends, observations, and findings in the quarterly State of the Internet / Security Report .

Join us for an overview of Distributed Denial of Service (DDoS) and web application trends and data gathered from Q1 2017.

Key topics will include:
The continued threat of DDoS attacks leveraging IoT devices
Source and target regional data for web application and DDoS attacks
Significant increases in reflection DDoS attack traffic
Spotlight on financial services organizations targeted by new features within the Mirai botnet

👇
https://content.akamai.com/ME8911-q117-soti-security-webinar.html

اگر از پست قبل به خاطر داشته باشین، توضیح داده شد که چندین سال از 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