Cisco Vs Juniper Vs Hp

طبيعي يا سيدي ليس ضد جونيبر بل ايضا مع Aruba مثلا في مجال الوايرلس. Juniper تصميمها مبني على أسس أحدث من Cisco. طبعا ليس حديثا جدا، لكن على الأقل ليس كالـIOS الذي يرجع لأكثر من 20 عاما.

سوفتوير وهاردوير الراوترات:

قديما لم تكن لدينا ASIC حديثة لزيادة السرعة كالآن. فما فعلته Cisco هو نظام legacy mono kernel يقوم بتشغيل كل شيء كما لو كان جزءا من الـkernel في نفس الـmemory space. هذا أسرع قليلا. الميزة في الماضي كانت زيادة السرعة من خلال السوفتوير.

محدودياته أنه لا يدعم Virtual Memory فبالتالي جميع البرامج تعمل في نفس الـmemory space وأي bug في أي برنامج سيتمكن دون أي محدودية من العبث ببلوكات ميموري مستخدمة بواسطة برامج أخرى. بعبارة أخرى، أي خلل ممكن يتسبب بأي شيء. لذا الـavailability اسوأ بكثير. إضافة إلى ذلك non-preemptive scheduler لتخلفات تاريخية :D.

طبعا في الماضي كان هذا الأمر جيدا لأننا كنا نريد السرعة من خلال السوفتوير. لكن الآن، هذا ليس له أي معنى بالكلية. لأننا إذا أردنا السرعة سنقوم بإستخدام ASIC متقدمة متوفرة الآن لم تتوفر قبل 20 سنة. بعبارة أخرى، الإشكالية كانت أن الذكاء والسرعة كانا مدموجين في الـsoftware وهذا أدى إلى تضحيات في الـavailability والـreliability.

بينما أسس الأنظمة الحديثة، (نسبيا) ومن بينها Juniper كمثال، مختلف قليلا. هناك فصل أكبر بين الذكاء والسرعة:

- إذا اردنا الذكاء فسيكون من خلال modern mono kernel مع virtual memory و preemptive scheduler. وهذا سيعطينا توافرية واعتمادية أكثر.

- إذا اردنا السرعة، كعملية إرسال البكتس، فسيكون من خلال ASIC متخصصة للسرعة.

بينما Cisco مازالت تبيع السواد الأعظم من منتوجاتها بتصميمها الذي يرجع لأكثر من 20 سنة. فلا غرابة من تحول الناس العقلاء للبديل الأفضل، والذي أيضا في معظم الأحيان أرخص ولو بقليل. الـmargin في Cisco يعتبر 70-80% وأحيانا أكثر مع بعض المنتجات الأخرى.

Cisco لاحظت هذا الشيء منذ زمن قديم، ولذا بدأت بالإبتعاد عن IOS القديم. ومن هنا ظهرت أنظمة جديدة. كتلك المستخدمة مع راوتر CRS1 وسوتش Nexus. النظام المستخدم في CRS1 اسمه IOS XR، ونظام Nexsus اسمه NX-OS. الأول مبني على QNX وطبعا هذه النواة هي micro kernel وprotected memory و preemptive scheduler. بينما NX-OS فهو مبني على Linux.

هذا جيد، لكن تسببت لمشكلة أخرى. فمنتوجات Cisco تستخدم عدة أنظمة تشغيل لمنتوجاتها المختلفة. أحيانا واجهة الأوامر مختلفة، وإن تشابهت ستظل هناك اختلافات. هذا سيء من منظور الإدارة والـtotal cost of ownership.

بينما Juniper، فإنه يستخدم JUNOS مع راوتراته وسوتشاته على حد سواء. وهذا رائع ومتناسق.

نرجع للبروتوكلات:

بروتوكول EIGRP يقدم ميزات رائعة لكن لديه سلبياته الخاصة. OSPF و IS-IS يوفرون المطلوب والأخير يقدم scalability أكبر. صحيح EIGRP أسرع في بعض الأحيان، لكن في أحيان أخرى أيضا أبطأ وبعض الـrouters ربما تعلق في حالة STA - سيحتاج موضوعا منفصلا للنقاش عنه.

GLBP صحيح أنه يوفر per-user load balancing، لكن _عمليا_ لن يتمكن المستخدم بالإستفادة من هذا، لأنه أساسا الـSpanning Tree Protocol يقوم بـper-vlan tree. ومع الـSTP كل VLAN سيقوم باتباع مسار أقرب للـroot bridge. يعني المسار سيكون مشترك في النهاية للمستخدمين الموجودين في نفس الـVLAN. ناهيك أن الـtroubleshooting يكون أصعب، فحتى نكتشف الـgateway الحقيقي يجب علينا النظر إلى الـarp table ومعرفة الـmac address. لهذا السبب تصميمات Cisco تعتمد على HSRP وليس GLBP.

HSRP يعطينا مايوفره VRRP. لا توجد إيجابية واضحة سوى أن الـHSRP يقدم API يتم استخدامها في Stateful NAT. ولتطبيق الـstateful NAT ليس شرطا أن نستخدم HSRP، هناك أجهزة عديدة أخرى تقوم بتوفير هذه الخاصية بطرقها الخاصة.

خلاصة الكلام، الفائدة ليست واضحة، خاصة أنها مصحوبة بسلبيات عدم التوافق مع أجهزة الشبكات الأخرى، وهنا فخ الإحتكار الذي يحاول العالم الهروب منه، والذي من أجله أنشئت منظمات IEEE وغيرها. المستقبل هو multi-vendor. و Juniper مريحة دماغها و مركزة على الـopen standards أكثر من تركيزها على بروتوكولات تعمل مع أجهزة شبكات معينة.

اقتباس

بروتوكول EIGRP يقدم ميزات رائعة لكن لديه سلبياته الخاصة

الميزة الوحيدة التي أراها غير سهولة الإستخدام في unequal cost load balancing أجدها رائعة خصوصا في شبكات الوايرلس التي تتوزع فيها المسارات بشبكة Mesh .

بالنسبة لل HSRP وال VRRP سيسكو أحيانا تكذب في المقارنة وتقول أن VRRP لاتعطي إمكانية تفعيل interface tracking في حين أن اخاصية موجودة كما فهمت لكن بأرقام interface object أظن وليس بإسم ال Interface كما في HSRP .

هل لديك معلومات عن HP ؟

ليست لدي معلومات دقيقة عن HP للأسف يا سيدي.

اقتباس

بالنسبة لل HSRP وال VRRP سيسكو أحيانا تكذب في المقارنة وتقول أن VRRP لاتعطي إمكانية تفعيل interface tracking في حين أن اخاصية موجودة كما فهمت لكن بأرقام interface object أظن وليس بإسم ال Interface كما في HSRP .

انترفيس تراكينج بواسطة الأبجكتس أفضل في كل حال لأنه يتيح إضافة ابجكتس أخرى داخل أبجكتس وربطهم بواسطة or / and logic ومن خلاله تحديد الحالة النهائية للأبجكت هل داون ام لا. يعني ممكن نقول، إذا المنفذ "أ" و "ب" داون، حينها اعتبر الابجكت داون. وطبعا إذا "أ" داون لوحده، أو "ب" لوحده لن يعتبر داون.

بالنسبئة للـEIGRP والـunequal cost load balancing فی نظري هذه محدودية الراوتينج في أجهزة سيسكو. مثلا في اللينوكس ممكن تقوم بنفس الشيء دون الحاجة لهذا البروتوكول.

مسكوووووور الله يحفظك ويحفظ والديك