سلام دوستان ،
در بخش قبل در رابطه با Normal Routing بر روی Multilayer Switch ها صحبت کردیم و در پایان اشاره کردیم برای اینکه بیان سرعت Routing و Performance رو افزایش بدن اومدن یکسری مکانیزم های دیگه ارائه دادن.
در این قسمت میپردازیم به یکی از اون مکانیزم ها یعنی Topology Based که در دیوایس های سیسکو از این روش استفاده میشه که با نام Cisco_Express_Forwarding یا به اختصار CEF شناخته میشه.
البته نه روی تمامی دیوایس ها بلکه دیوایس های زیر :
6500 Supervisor 720 (with an integrated MSFC3 RP)
6500 Supervisor 2/MSFC2 RP Combination
4500 Supervisor 111,1v,v and 6-E
Fixed-Configuration Switches,Such as the Catalyst 3750,3560,35,50,...
برای اینکه روتینگ با مکانیزم cef رخ بده سه تا structure وجود داره :
FIB Table
Adjacency Table
Rewrite Engin
و اما کاربرد هرکدوم :
Forward Inforation Base (FIB) Table :
یک جدول هستش که این جدول از روی جدول Routing Table ساخته میشه در نتیجه در مکانیزم های CEF تصمیم گیری بر اساس Routing Table اتفاق نمیفته و با استفاده از FIB Table اتفاق میفته.
اما مزایای FIB Table نسبت به Routing Table :
Hardware Lookup : لوک آپ FIB Table بصورت سخت افزای انجام میشه یعنی چیپ ست هایی جدا هستن برای FIB پس پرفومنس LOOKUP در FIB نسبت به Routing Table بیشتره.
از طرفی رکورد هایی که تو FIB قرار گرفته مرتب تر هستن پس در نتیجه لوک آپ بهینه تر انجام میشه.
در FIB ما HOST RECORD داریم که در Routing Table این رو نداریم :یعنی در Routing Table برای یک مسیر فقط نتورکش رو داریم مثلا 192.168.1.0/24 اما برای اون مسیر یک ip مشخص نداریم اما تو FIB دقیقا Host Record داریم پس بازم لوک آپ میتونه بهینه تر انجام شه.
در نهایت رکورد هایی که تو FIB Table هست Resolved میشه یعنی رکورد هایی که وجود داره رو هر مدت یکبار چک میکنه ببینه وجود داشته باشن و از بین نرفته باشن پس رکورد ها هر لحظه تو FIB هست و میتونیم مطمئن باشیم که این رکورد ها همیشه به روز و آپدیت هستن.
Adjacency Table :
از ترکیب ARP Table و MAC-Address Table جدول Adjacency بوجود میاد.
خصوصیت مفید Adjacency Table :
بعد از اینکه بسته از روتینگ گذشت Adjacency Table هدر های لایه 2 رو بصورت آماده داره در نتیجه بدون هیچ Process اضافه فوروارد میشه. پس Adjacency Table برا هر نتورک هدر لایه 2 رو بصورت اماده از قبل ایجاد میکنه که شامل source mac,dest mac, و ... هست رو داره.
Rewrite Engin :
گفتیم که در Adjacency Table هدر های لایه 2 بصورت آماده وجود دارن حالا برای اینکه اون هدر ها به بسته های دریافتی بایند بشن وظیفه ی بایند کردن هدرها در Adjacency Table به بسته ها رو Rewrite Engin به عهده داره.
#Multilayer_Switching
#Cisco_Express_Forwarding
🆔 : @notrobit
در بخش قبل در رابطه با Normal Routing بر روی Multilayer Switch ها صحبت کردیم و در پایان اشاره کردیم برای اینکه بیان سرعت Routing و Performance رو افزایش بدن اومدن یکسری مکانیزم های دیگه ارائه دادن.
در این قسمت میپردازیم به یکی از اون مکانیزم ها یعنی Topology Based که در دیوایس های سیسکو از این روش استفاده میشه که با نام Cisco_Express_Forwarding یا به اختصار CEF شناخته میشه.
البته نه روی تمامی دیوایس ها بلکه دیوایس های زیر :
6500 Supervisor 720 (with an integrated MSFC3 RP)
6500 Supervisor 2/MSFC2 RP Combination
4500 Supervisor 111,1v,v and 6-E
Fixed-Configuration Switches,Such as the Catalyst 3750,3560,35,50,...
برای اینکه روتینگ با مکانیزم cef رخ بده سه تا structure وجود داره :
FIB Table
Adjacency Table
Rewrite Engin
و اما کاربرد هرکدوم :
Forward Inforation Base (FIB) Table :
یک جدول هستش که این جدول از روی جدول Routing Table ساخته میشه در نتیجه در مکانیزم های CEF تصمیم گیری بر اساس Routing Table اتفاق نمیفته و با استفاده از FIB Table اتفاق میفته.
اما مزایای FIB Table نسبت به Routing Table :
Hardware Lookup : لوک آپ FIB Table بصورت سخت افزای انجام میشه یعنی چیپ ست هایی جدا هستن برای FIB پس پرفومنس LOOKUP در FIB نسبت به Routing Table بیشتره.
از طرفی رکورد هایی که تو FIB قرار گرفته مرتب تر هستن پس در نتیجه لوک آپ بهینه تر انجام میشه.
در FIB ما HOST RECORD داریم که در Routing Table این رو نداریم :یعنی در Routing Table برای یک مسیر فقط نتورکش رو داریم مثلا 192.168.1.0/24 اما برای اون مسیر یک ip مشخص نداریم اما تو FIB دقیقا Host Record داریم پس بازم لوک آپ میتونه بهینه تر انجام شه.
در نهایت رکورد هایی که تو FIB Table هست Resolved میشه یعنی رکورد هایی که وجود داره رو هر مدت یکبار چک میکنه ببینه وجود داشته باشن و از بین نرفته باشن پس رکورد ها هر لحظه تو FIB هست و میتونیم مطمئن باشیم که این رکورد ها همیشه به روز و آپدیت هستن.
Adjacency Table :
از ترکیب ARP Table و MAC-Address Table جدول Adjacency بوجود میاد.
خصوصیت مفید Adjacency Table :
بعد از اینکه بسته از روتینگ گذشت Adjacency Table هدر های لایه 2 رو بصورت آماده داره در نتیجه بدون هیچ Process اضافه فوروارد میشه. پس Adjacency Table برا هر نتورک هدر لایه 2 رو بصورت اماده از قبل ایجاد میکنه که شامل source mac,dest mac, و ... هست رو داره.
Rewrite Engin :
گفتیم که در Adjacency Table هدر های لایه 2 بصورت آماده وجود دارن حالا برای اینکه اون هدر ها به بسته های دریافتی بایند بشن وظیفه ی بایند کردن هدرها در Adjacency Table به بسته ها رو Rewrite Engin به عهده داره.
#Multilayer_Switching
#Cisco_Express_Forwarding
🆔 : @notrobit
سلام خدمت دوستان عزیز امروز قصد داریم تا در رابطه با پارامتر های Metric در روتینگ پروتکل EIGRP صحبتی داشته باشیم و به یک نکته ای بپردازیم که بعضا بهش توجه نمیشه.
در روتینگ پروتکل EIGRP برای انتخاب بهترین مسیر با استفاده از پارامترهای زیر بهترین Metric یا به عبارت بهتر کمترین Metric به عنوان بهترین مسیر شناخته میشود.
پارامترهای Metric برا انتخاب بهترین مسیر بصورت زیر می باشند :
EIGRP Metrics :
K1 = 1 (Bandwidth)
K2 = 0 (Load)
K3 = 1 (Delay)
K4 = 0 (Reliability)
K5 = 0 (MTU)
بصورت پیش فرض K1 و K3 فعال هستند و در فرمول محاسبه ی متریک نقش دارند اما میتوان دیگر پارامتر هارا نیز وارد بازیه متریک کرد.
نکته ای که وجود دارد این هست که بشدت سیسکو تاکید داره در لینک هامون Load و Reliability رو تو بازی متریک نیارید چرا که در مسیرهای بزرگ دیگر نمیتوان مسیر ترافیک را حدس زد.
و اما نکته ای که شاید خیلی از دوستان سر سری میگیرند و توجه چندانی بهش نمیکنن :
خیلی شده از یک متخصص شبکه میپرسیم پارامتر های دخیل در متریک رو نام ببر و آن شخص هم پنج پارامتر موجود رو نام برده اما باید توجه داشته باشیم که چهار پارامتر هستند که در انتخاب بهترین مسیر نقش دارند.
پارامتر MTU در فرمول محاسبه متریک EIGRP اصلا وجود ندارد تا بتوان با تغییر ضرایب آن را در محاسبه متریک دخالت داد. MTU می تواند در انتخاب بهترین مسیر EIGRP برای قرار گرفتن در جدول مسیریابی دخالت داشته باشد و این اتفاق زمانی رخ میدهد که برای یک مقصد مشخص چندین مسیر با متریک مشابه وجود داشته باشد در maximum-path اجازه نداده باشیم که همه این مسیرها در جدول بنشینند، در اینحالت اولویت با مسیرهایی است که MTU بیشتری داشته باشند. اگر MTU ها نیز مشابه باشند اولویت زمانی مطرح خواهد شد. بنابراین MTU در محاسبه متریک دخالت ندارد ولی در انتخاب مسیر برای قرار گرفتن در جدول مسیریابی می تواند دخالت داشته باشد.
همچنین اگر به فرمول محاسبه ی متریک نگاهی بی اندازید متوجه این موضوع خواهید شد :
EIGRP composite cost metric = 256*((K1*Scaled Bw) + (K2*Scaled Bw)/(256 – Load) + (K3*Scaled Delay)*(K5/(Reliability + K4)))
همانطور که مشاهده میکنید 4 پارامتر و 5 ضریب وجود دارد و برای MTU هیچ پارامتری موجود نیست.
#EIGRP
#Metric
🆔 : @notrobit
در روتینگ پروتکل EIGRP برای انتخاب بهترین مسیر با استفاده از پارامترهای زیر بهترین Metric یا به عبارت بهتر کمترین Metric به عنوان بهترین مسیر شناخته میشود.
پارامترهای Metric برا انتخاب بهترین مسیر بصورت زیر می باشند :
EIGRP Metrics :
K1 = 1 (Bandwidth)
K2 = 0 (Load)
K3 = 1 (Delay)
K4 = 0 (Reliability)
K5 = 0 (MTU)
بصورت پیش فرض K1 و K3 فعال هستند و در فرمول محاسبه ی متریک نقش دارند اما میتوان دیگر پارامتر هارا نیز وارد بازیه متریک کرد.
نکته ای که وجود دارد این هست که بشدت سیسکو تاکید داره در لینک هامون Load و Reliability رو تو بازی متریک نیارید چرا که در مسیرهای بزرگ دیگر نمیتوان مسیر ترافیک را حدس زد.
و اما نکته ای که شاید خیلی از دوستان سر سری میگیرند و توجه چندانی بهش نمیکنن :
خیلی شده از یک متخصص شبکه میپرسیم پارامتر های دخیل در متریک رو نام ببر و آن شخص هم پنج پارامتر موجود رو نام برده اما باید توجه داشته باشیم که چهار پارامتر هستند که در انتخاب بهترین مسیر نقش دارند.
پارامتر MTU در فرمول محاسبه متریک EIGRP اصلا وجود ندارد تا بتوان با تغییر ضرایب آن را در محاسبه متریک دخالت داد. MTU می تواند در انتخاب بهترین مسیر EIGRP برای قرار گرفتن در جدول مسیریابی دخالت داشته باشد و این اتفاق زمانی رخ میدهد که برای یک مقصد مشخص چندین مسیر با متریک مشابه وجود داشته باشد در maximum-path اجازه نداده باشیم که همه این مسیرها در جدول بنشینند، در اینحالت اولویت با مسیرهایی است که MTU بیشتری داشته باشند. اگر MTU ها نیز مشابه باشند اولویت زمانی مطرح خواهد شد. بنابراین MTU در محاسبه متریک دخالت ندارد ولی در انتخاب مسیر برای قرار گرفتن در جدول مسیریابی می تواند دخالت داشته باشد.
همچنین اگر به فرمول محاسبه ی متریک نگاهی بی اندازید متوجه این موضوع خواهید شد :
EIGRP composite cost metric = 256*((K1*Scaled Bw) + (K2*Scaled Bw)/(256 – Load) + (K3*Scaled Delay)*(K5/(Reliability + K4)))
همانطور که مشاهده میکنید 4 پارامتر و 5 ضریب وجود دارد و برای MTU هیچ پارامتری موجود نیست.
#EIGRP
#Metric
🆔 : @notrobit
سلامی گرم خدمت دوستان عزیز در طی این مقاله قصد داریم بصورت کلی به تفاوت های بین روتینگ پروتکل EIGRP و OSPF بپردازیم :
EIGRP Vs OSPF :
عمدتا در این بخش میپردازیم به Configuration هایی که میتونه باعث شه همسایگی بین دو روتر ایجاد نشه و در روز های آینده به دیگر تفاوت ها میپردازیم.
1. هر دو روتر چه در EIGRP و چه در OSPF باید بتوانند بهم پکت ارسال کنن.
2.جفت روتر ها در دو روتینگ پروتکل باید در یک Subnet باشند و یا به عبارت بهتر روتر با همسایش Connected باشه.
3.اینترفیس های روتر ها در جفت پروتکل نباید Passive باشند زیرا جریان ارسال و دریافت Hello قطع میشه.
4.در EIGRP الزما باید در دو روتر ASN ها یکی باشند تا همسایگی ایجاد شه اما در OSPF نیاز نیست که در دو روتر Process-ID ها یکسان باشند و اگر هم یکسان نباشند همسایگی ایجاد میشود.
5.تایم های Hello و Hold اگر در EIGRP عوض بشن و در دو طرف یکسان نباشن همسایگی باقی میمونه اما در OSPF اگر تایم های در دو روتر یکسان نباشند همسایگی Fail میشه.
6.در جفت روتینگ پروتکل ها در دو روتر الزما باید Authentication در دو طرف یکسان باشه.
7.در OSPF همسایه ها باید حتما در یک Area باشند که در EIGRP بحثی به نام Area وجود ندارد.
8. در OSPF الزما باید MTU در دو طرف یکسان باشند و اگر یکسان نباشند تشکیل همسایگی در فاز Exstart میماند و سپس Down میشود اما در EIGRP لزومی ندارد.
9.در OSPF الزما باید Router-ID (RID) بصورت یونیک باشد وگرنه همسایگی UP نمیشه اما در EIGRP اگر یونیک نباشد همسایگی UP میشه اما در Topology Exchange گیر میکنه.
10.در EIGRP باید K-Value ها یا همان پارامترهای Metric باید در دو طرف یکسان باشند و این مبحث در OSPF وجود ندارد.
خب دوستان بصورت کلی تفاوت و شباهت هایی که جلوی تشکیل همسایگی در دو روتینگ پروتکل EIGRP و OSPF رو میگرفت نام بردیم و توضیحی مختصری دادیم انشالله طی روز های آینده به بررسی جزئی تر در رابطه با هرکدام میپردازیم.
#EIGRP_VS_OSPF
#EIGRP
#OSPF
🆔 : @notrobit
EIGRP Vs OSPF :
عمدتا در این بخش میپردازیم به Configuration هایی که میتونه باعث شه همسایگی بین دو روتر ایجاد نشه و در روز های آینده به دیگر تفاوت ها میپردازیم.
1. هر دو روتر چه در EIGRP و چه در OSPF باید بتوانند بهم پکت ارسال کنن.
2.جفت روتر ها در دو روتینگ پروتکل باید در یک Subnet باشند و یا به عبارت بهتر روتر با همسایش Connected باشه.
3.اینترفیس های روتر ها در جفت پروتکل نباید Passive باشند زیرا جریان ارسال و دریافت Hello قطع میشه.
4.در EIGRP الزما باید در دو روتر ASN ها یکی باشند تا همسایگی ایجاد شه اما در OSPF نیاز نیست که در دو روتر Process-ID ها یکسان باشند و اگر هم یکسان نباشند همسایگی ایجاد میشود.
5.تایم های Hello و Hold اگر در EIGRP عوض بشن و در دو طرف یکسان نباشن همسایگی باقی میمونه اما در OSPF اگر تایم های در دو روتر یکسان نباشند همسایگی Fail میشه.
6.در جفت روتینگ پروتکل ها در دو روتر الزما باید Authentication در دو طرف یکسان باشه.
7.در OSPF همسایه ها باید حتما در یک Area باشند که در EIGRP بحثی به نام Area وجود ندارد.
8. در OSPF الزما باید MTU در دو طرف یکسان باشند و اگر یکسان نباشند تشکیل همسایگی در فاز Exstart میماند و سپس Down میشود اما در EIGRP لزومی ندارد.
9.در OSPF الزما باید Router-ID (RID) بصورت یونیک باشد وگرنه همسایگی UP نمیشه اما در EIGRP اگر یونیک نباشد همسایگی UP میشه اما در Topology Exchange گیر میکنه.
10.در EIGRP باید K-Value ها یا همان پارامترهای Metric باید در دو طرف یکسان باشند و این مبحث در OSPF وجود ندارد.
خب دوستان بصورت کلی تفاوت و شباهت هایی که جلوی تشکیل همسایگی در دو روتینگ پروتکل EIGRP و OSPF رو میگرفت نام بردیم و توضیحی مختصری دادیم انشالله طی روز های آینده به بررسی جزئی تر در رابطه با هرکدام میپردازیم.
#EIGRP_VS_OSPF
#EIGRP
#OSPF
🆔 : @notrobit
دانلود کتاب Implementing Cisco UCS Solutions - Second Edition
🔎 #DataCenter
#UCS
🆔 @Notrobit
💠 Manager: @taheri1990
👇👇👇👇👇
🔎 #DataCenter
#UCS
🆔 @Notrobit
💠 Manager: @taheri1990
👇👇👇👇👇
دانلود کتاب Implementing Cisco IP Switched Networks (Switch)
🔎 #CCNP
#Switch
🆔 @Notrobit
💠 Manager: @taheri1990
👇👇👇👇👇
🔎 #CCNP
#Switch
🆔 @Notrobit
💠 Manager: @taheri1990
👇👇👇👇👇
دوستان عزیز نظر به استقبال شما عزیزان از این پس هر یکشنبه شب اقدام به برگزاری کلاس های آموزشی به صورت لایو خواهیم نمود لذا درخواست دارم تا از دوستان خود برای حضور در این کلاس ها دعوت به عمل آورید.
ساعت برگزاری: 21:30
جهت شرکت در کلاس ها آدرس زیر را در اینستاگرام خود اضافه نمایید:
🆔 Taheri_mohammad
@Notrobit
ساعت برگزاری: 21:30
جهت شرکت در کلاس ها آدرس زیر را در اینستاگرام خود اضافه نمایید:
🆔 Taheri_mohammad
@Notrobit
سلام دوستان در این بخش قصد داریم با یک ترفند یاد بگیریم چگونه در کسری از ثانیه Wild Card Mask رو محاسبه کنیم امیدوارم که این بحث براتون جذاب باشه.
به نظره خوده من محاسبه ی وایلد کارد خیلی دردسر داره و من به شخصه حوصلم نمیکشه اما با این ترفند یاد میگیرم به راحتی هرچه تمام تر برای هر subnet mask بتونیم Wild Card Mask اون رو حساب کنیم.
این رو میدونیم که wild card برعکسه subnet mask هستش یعنی چی؟ یعنی اگه subnet mask ما به شکل زیر هستش :
255.255.0.0
وایلد کارد ما میشه :
0.0.255.255
این خیلی سادست اما تویه مثال های سخت تر یا به عبارت بهتر سابنت مسک های classless یکم محاسبه این دشوار میشه.
بصورت خیلی ساده هرگاه ما یک subnet mask دیدیم میایم هر اکتت رو از عدد 255 کم میکنیم و باقی مانده میشه wild card mask ما.
بذارید به یه مثال نگاه کنیم تا به راحتی درکش کنیم.
فرض کنیم ما سابنت مسک زیر رو داریم :
255.255.128.0
حالا تنها کاری که نیازه انجام بدیم این هستش که هر اکتت رو از 255 کم کنیم و wild card mask رو بدست بیاریم.
پس میشه :
255.255.128.0
-
255.255.255.255
=
0.0.127.255
به همین راحتی تونستیم وایلد کارد مورد نظر رو به دست بیاریم.
حالا سوال؟ ایا واسه ی همه ی سابنت مسک ها میشه؟ پاسخ مثبت هستش و برای تمامی سابنت مسک ها این ترفند جواب میده.
و اما این مثال برای شما 😉 :
وایلد کارد سابنت مسک زیر را بدست اورید :
255.255.255.192
#Wild_Card_Mask
🆔 : @notrobit
به نظره خوده من محاسبه ی وایلد کارد خیلی دردسر داره و من به شخصه حوصلم نمیکشه اما با این ترفند یاد میگیرم به راحتی هرچه تمام تر برای هر subnet mask بتونیم Wild Card Mask اون رو حساب کنیم.
این رو میدونیم که wild card برعکسه subnet mask هستش یعنی چی؟ یعنی اگه subnet mask ما به شکل زیر هستش :
255.255.0.0
وایلد کارد ما میشه :
0.0.255.255
این خیلی سادست اما تویه مثال های سخت تر یا به عبارت بهتر سابنت مسک های classless یکم محاسبه این دشوار میشه.
بصورت خیلی ساده هرگاه ما یک subnet mask دیدیم میایم هر اکتت رو از عدد 255 کم میکنیم و باقی مانده میشه wild card mask ما.
بذارید به یه مثال نگاه کنیم تا به راحتی درکش کنیم.
فرض کنیم ما سابنت مسک زیر رو داریم :
255.255.128.0
حالا تنها کاری که نیازه انجام بدیم این هستش که هر اکتت رو از 255 کم کنیم و wild card mask رو بدست بیاریم.
پس میشه :
255.255.128.0
-
255.255.255.255
=
0.0.127.255
به همین راحتی تونستیم وایلد کارد مورد نظر رو به دست بیاریم.
حالا سوال؟ ایا واسه ی همه ی سابنت مسک ها میشه؟ پاسخ مثبت هستش و برای تمامی سابنت مسک ها این ترفند جواب میده.
و اما این مثال برای شما 😉 :
وایلد کارد سابنت مسک زیر را بدست اورید :
255.255.255.192
#Wild_Card_Mask
🆔 : @notrobit