Friday, December 30, 2011

CompactFlash Memory Cards



تدوينة اليوم تدور حول ما يسمى بال CompactFlash Memory Cards او ما هو معروف بال CF فكما هو موضح بالصورة هذه هى ال CF ...... اذا ما هى ال CF ?
ال CF هى عبارة عن external memory وهى شبيهة بال memory card  العادية و تستخدم من قبل ال routers لتخزين نسخة ال ios عليها او لتخزين ال configuration  الخاصة بال routers .


ولكن ليست كل ال routers بت support التعامل بال CF فهى مدعومة من قبل كل من  :




 وغيرها  ,  ........  , Cisco 1800 series routers  ,  Cisco 2800 series routers, Cisco 3800 series routers


 و بما ان هذه ال series  من ال routers  لا تدعم ال integrated flash  و تعمل فقط مع ال CF فال ios  الخاص بها يخزن على ال CF ولكن قبل نقل او تحميل نسخة ال ios  عليها لابد من عمل formatting  لل CF  باستخدام احد ال classes التالية :


1- Class B و المعروف بال Low-end File Sys ( LEFS) a .
2- Class C و هو اقرب ما يكون لنظام ال DOS .


ويمكننا تشبيه هذه النقطة بال FAT32 & NTFS فى بيئة العمل مع ال partitions فى ال PC ... ولكن يجب الاخذ فى الاعتبار معاينة نوع ال router لان هنالك series تدعم او تستوجب ان تكون ال CF تكون formatted باستخدام Class C فقط و توجد series اخرى تدعم كلا من ال Class B & C  .


لعمل format لل CF باستخدام ال Class B :


:Router# erase flash


لعمل format لل CF باستخدام ال Class C :


Router# format flash:


ومع اختلاف ال class  المستخدم فى عمل ال formatting لل CF تختلف معه ايضا طريقة عرض او ال structure الخاصة بالخرج الخاص ببعض ال commands ... فعلى سبيل المثال لعرض محتويات ال CF فى حالة  Class B :




و عند تنفيذ نفس ال command فى حالة ال Class C formatting :




 ناتى الان لل configurations  الخاصة بنقل الملفات من والى ال CF  ... ففى حالة اذا اردنا نقل محتويات ملف خاص مخزن عليه configuration من ال CF الى ال system configuration 


Router# copy flash:FolderName startup-config 
والعكس صحيح ....


و لعمل اعادة تسمية لاى file على ال CF نستخدم ال command الاتى لتحويل اسم ال file من cisco.temp الى mohamed.temp:


Router# rename flash:cisco.tmp flash:mohamed.tmp


قبل ان انهى الموضوع احب ان انوه لشىئ هام ففى حالة تغيير ال CF او استبدالها و لم تعمل ال CF الجديدة فيجب التاكد من شيئين مهمين :


1- ان ال CF معمول لها formatting  ب Class مدعوم من قبل ال router سواء كان C او B كما ذكرت فى الموضوع .


2- التاكد من ال Size الخاص بال CF وهو يكون موضح على ال CF كما هو ظاهر بالصورة فليس كل ال routers تدعم جميع الاحجام لل CF فمثلا ال cisco 8200 ال max. supported CF size له هو 256MB .


ارجو ان يكون الموضوع نال اعجابكم ...

Thursday, December 22, 2011

Bidirectional Forwarding Detection (BFD) - Part II


تحدثت فى التدوينة السابقة عن خاصية ال PFD و فى هذه التدوينة سوف اتحدث عن كيفية عمل ال configuration الخاصة بهذه ال feature و عن ارقام ال ios و انواع ال routers اللى بت support هذه ال feature .

فى البداية سوف اتطرق لطرق عمل ال configuration لل BFD , فهنالك خطوتان رئيسيتين لعمل configure لل BFD :

الخطوة الاولى :

فى الخطوة الاولى سنقوم بتحديد ال baselines او الخطوط العريضة التى سنقوم بوضعها لل BFD لكى يتعامل على اساسها و يتبعها اثناء رحلة العمل الخاصة به :



config-if)#bfd interval <50-999> min_rx <1-999> multiplier <3-50
فكما نلاحظ :

1- هذا ال command يتم كتابته على مستوى ال interface المراد تفعيل ال BFD عليه .
2- القيمة التى تتبع كلمة interval تمثل الtime الذى من خلاله سيتم
ارسال ال BFD packets بصورة دورية لل BFD peer المجاور والواصل من خلال ال link الى connected بال interface . وتتراوح هذه القيمة من 50 : 999 وتكون ممثلة بال MSEC
3- قيمة ال min_rx وهى تمثل ال time المتوقع من خلاله
استلام ال interface لل BFD packets بصورة دورية من ال BFD peer و تتراوح بين 1 : 999 وتكون ممثلة ايضا بال MSEC .
4- قيمة ال multiplier عبارة عن عدد ال BFD packets
المتتالية التى اذا افتقدها ال interface يستطيع تحديد او الحكم بان ال BFD peeer هو Unavailable وهى تتراوح بين 3:50 .

الخطوة الثانية :

هى عبارة عن اشراك ال BFD feature لل Routing protocol المستخدم بال topology فكما اتفقنا من قبل ان ال routing protocols بتsupport هذه ال feature ولم تعد قاصرة على ال EIGRP .فى الcommands الاتية سوف اتطرق بالشرح على ال EIGRP :

router eigrp 123
bfd all-interfaces

فى هذه الحالة سيتم تطبيق ال BFD Feature على جميع ال interfaces التى ترتبط بال EIGRP . ولتخصيص interface محدد او عدة interfaces للاشتراك فى ال BFD :

router eigrp 123
bfd interface Gig1/0

وبالمثل فى حالة استخدام ال OSPF و ال ISIS .ولكن الامر مختلف قليلا فى ال BGP حيث لابد من تخصيص هذه ال feature ليتعامل بها ال Router مع neighbor محدد وليس لكل ال BGP neighbors كما نرى :


config-router)#neighbor IP_ADD fall-over bfd

انتهينا الان من طريقة عمل ال configuration لل BFD feature , للتاكد و لعمل verification من BFD feature نستخدم :

router#show bfd neighbors [details 


ولمتابعة ال BFD packets التى يتم ارسالها واستقبالها من قبل ال BFD peers :
router#debug bfd packet 

الان قد انتهينا من ال configuration و ال commands الخاصة بال BFD ناتى الان لسرد و تحديد نسخ ال ios و ال devices التى تدعم هذه ال fature :

Cisco IOS
12.0S and 12.2S: the Cisco 7600 Series Router and the Cisco 12000 Series Internet Router


ارجو ان اكون قد وفقت فى توضيح هذا الموضوع ...

Tuesday, December 6, 2011

Bidirectional Forwarding Detection (BFD) - Part I

هتكلم فى التدوينة اليوم عن Biodirectional Forwarding Detection او ما يسمى بال BFD ... حقيقتا اول مرة اشوف المصطلح دا كان فى ال official cert. guide لل CCNP-Routing وكان مكتوبة داخل Note فى ال chapter الخاص بال EIGRP وكان مكتوب ايضا انه Outside the ccnp scope بس حبيت اعرف ايه قصة ال BFD 

 كان الكتاب بتتكلم عن ان ال Eigrp بيبعت ال hello msg فى صورة تزامنية كل 5 ثوانى By default وان ال dead timer كما نعلم ايضا انه 15 ثانية By default وان ال Router اذا لم يستلم ال reply من ال Neighbor Router ففى هذه الحالة هيستنتج انه down و ال Adjacency بينهم هتصبح Fail ..... بعد الكلام دا كتب note معناها ان ال Eigrp ممكن يستخدم feature تسمى بال BFD تتيح له انه ي detect اى fail لل neighbor فى (( اجزاء من الثانية )) , فللوهلة الاولى قبل ما اعمل search حطيت تصور ان ال BFD عبارة عن feature خاصة بال EIGRP بيستخدمها عشان ي detect ال fail فى اجزاء من الثانية دون الانتضار فترة ال dead timer كاملة .

بعد الاطلاع والبحث اكتشفت ان ال BFD عبارة عن Lightweight Protocol ولا يقتصر بال EIGRP فقط بل هو protocol صمم خصيصا لكى ي detect الاخطاء والfail الحادث لل media بانواعها وال routing protocols عامة و ال topological errors بل وايضا بيdetect عملية ال Switch-over (SSO) a اللى تعرضتلها فى تدوينة سابقة و بذلك سيكون compatible وبيsupport ال NSF ( Non-Stop Forwarding ) a.

طب ايه الغرض من انى اشغل protocol يحددلى ال fail وانا ممكن اعمل reconfigure لل hello & dead timer values ????
 الرد كالتالى ان هذا ال protocol كما ذكرت هو Lightweight Protocol  و فى ال topology لل network لا نستطيع عمل decrease لكل ال Hello & dead timers وخاصة ان معظم ال routing protocols تصنف على انها heavy weighted Protocols  وعملية تعديل ال لhello & dead timers هتسبب headace عالى و ت waste ال processing وال resources 
وللتاكيد مرة اخرى فان جميع ال routing protocols تكون compatible وبت support التعامل مع ال BFD ايا كان نوع ال  routing protocol.

ال BFD له 2modes :

1-ِAsynchronous mode :
يتم ارسال echo packets فى هذا ال mode بصورة دورية للتاكد من سلامة ال interfaces و عند عدوم استلام اى echo reply سيعتبر ال link اصبح down ولن يتم ارسال اى packets اخرى ما عدا ال control packets فى حالات الضرورة .
2- Echo mode :
فى هذا ال mode يتم ارسال ال echo packets الى ان تصبح ال adjacency بين ال routers فى صورة established ..ولكن هناك ملحوظة هامة :
فى حالة عمل configure لل URPF على ال int .. لن يتوافق هذا ال mode مع هذه الخاصية وسيتسبب فى حدوث Flapping لل link .. لفهم ال URPF تستطيعوا الرجوع للعدد ال 19 من مجلة networkset فى مقال للاخ شريف مجدى .


بذلك سيوجد فى ال link الواحد 2 BFD sessions واحدة على كل طرف وكل session تكون منفصلة عن ال session الاخرى .

BFD Versions :

1- Version 0 
2- Version 1 ( The default Version ) z
فى حالة وجود 2 Routers وكل Router منهما يعمل على version غير الاخر سوف تحدث عملية negotiate بينهم و سيعملوا على ال version الاقل الا وهو Version 0 .

للحديث بقية فى الجزء الثانى للاعدادات الخاصة بال BFD .

ارجو ان الموضوع كان جديد ومفيد ....




Monday, December 5, 2011

Store-and-Forward vs. Cut-Through Swithcing

كما نعلم جميعا ان ال Hub ما هو الا مشترك يربط الاجهزة ببعضها وكان من عيوبه هو ان لو موصل به PC واراد ارسال Frame لاى PC اخر موصل معه بال Hub فان ال hub سيقوم بنشر ال Frame الى جميع ال Ports ومن ثم ستصل الى جميع ال PCs ولكن ليس هذا محور حديثنا اليوم فمحور حديثنا اليوم ان ال Hub عندما يستلم ال Frame من ال PC لن يفحص محتويات ال packet ولن يتاكد من خلوها من اى error او اى corrupted data فما عليه الا ان ينشرها الى كل ال PCs اللى connected بيه ...

جاء الينا ال L2 Switch لكى يقدم لنا تعديلات كثيرة كان من اهمها هو انه يقوم بفحص ال Frame  الى هيبعتها اى Host لاى Host اخر connected بال switch معاه ..وهذا هو محور حديثى اليوم هو الطرق المستخدمة من قبل ال switch لفحص ال incoming Frames .. تستخدم cisco switches طريقة من 2 لفحص ال incoming Frame :

1-  Store-and-Forward Switching 
2- Cut Through Switching
حقيقتا يوجد mechanism  ثالث وهو احد التطورات على ال mechanism الثانى الا وهو ال Fragment-Free Switching 
 والان سوف اتطرق بالشرح لكل mechanism باختصار على حدا 

1-  Store-and-Forward Switching 

فى هذا ال mechanism يستلم ال switch ال incoming Frame ويقوم بوضعها كاملة فى bufferخاص عنده وذلك سبب تسميته Store ومن ثم يقوم ال switch بفحص كامل محتويات ال Frame بغض النظر عن حجمها وي check ال Field الخاص بال FCS ويعمل مقارنة معه بمحتويات ال Frame اللى وصلته ويتاكد من صحة محتويات ال Frame قبل اخذ ال forwarding decision فاذا تاكد من خلو ال Frame من اى error يقوم بعمل Forwarding لها , و لو تاكد من انها corrupted او تحتوى على اى error هيعملها discard .

2- Cut Through Switching

فى هذا ال mechanism يقوم ال switch باستلام ال incoming frame و يقوم بهمل check فقط على ال destination MAC add. (DMAC) a ويقوم بعمل forwarding لل frame دون عمل اى check لل entire Fields الاخرى و بناء على ال CAM Table اللى مكونه هيطلعها من ال egress port اللى واصل بال destination وبذلك فى هذا ال mechanism ال switch لن يحتاج لكل ال time اللى كان بيستهلك من قبل ال mechanism الاول سواء فى التخزين فى ال buffer او فى الفحص الكامل لمحتويات ال frame وسيعتمد على ان ال receiving device هي check ال FCS field و يتاكد من صحة ال frame .

ومثال على الاجهزة التى تستخدم هذا ال mechanism : 

Cisco Nexus 5000 Series

وغالبا يتم استخدام ال switches التى تستخدم هذا ال mechanism فى ال data centers وذلك للاستفادة من جزئية ال low latency التى توفرها هذه ال switches .


يوجد mechanism ثالث وهو كما ذكرت احد انواع ال Cut-Through switching ويسمى بال Fragment-Free Switching :


يطلق عليه ايضا runtless switching وفى هذا النوع يقوم ال switch بتخزين اول 64bytes من ال packet وعمل check عليهم مع تجاهل باقى ال fields والسبب يرجع الى ان معظم ال errors فى ال frames توجد فى اول ال 64 bytes وبذلك قام بوضع small error check operation على ال normal cut-through التى كانت تقتصر على معاينة ال DMAC field وعدم فحص اى fields اخرى وايضا عدم استهلاك وقت فى الفحص الكامل لمحتويات ال frame . وبذلك جمع هذا ال mechanism بمميزات كل mechanism من ال 2 .



ارجو ان يكون الموضوع مفيد و مفهوم ...