🎙 جهت پخش ساده‌ی پادکست در تلگرام، روی تصویر کلیک کنید
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

در پست قبل معماری 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/