Juniper vs. Cisco – Pro és kontra


A legutóbbi “Így mentem át a Juniper JNCIA-Junos vizsgán” bejegyzésben ígértem egy Juniper – Cisco összehasonlítást, pro és kontra.

Mielőtt belevágnánk, ajánljanék egy ingyenes Juniper labor környezetet (Juniper Virtual Labs). Felpakoltam EVE-NG-ben is SRXv-t, de a hivatalos Juniper labor környezet sokkal kényelmesebb volt a szoftverrel való ismerkedéshez. Hasonló egyébként, mint a Cisco dcloud.

 

Ami tetszik a Juniperben/Junos-ben

Beépített help rendszer

Van a Junosben egy beépített help rendszer, mondhatni dokumentáció, amely segít a parancsok értelmezésében, szintaktikájában. Ez jól jöhet, ha nincs internet elérés, és ki kell “puskázni” valamit.

 

 

 

 

Rollback

Ha vissza akarunk állítani egy régebbi konfigurációt (maximum utolsó 50), ezt egy paranccsal könnyen megtehetjük.

 

Commit

Mielőtt a konfiguráció érvényre jutna, meg kell erősíteni, jóvá kell hagyni (commit), ellentétben az IOS-szel, ahol a running konfig van mindig érvényben (XR-en is van commit). Amíg nem ütsz commit-ot, nem érvényesül a konfiguráció változás.

 

Deactivate

Konfiguráció adott részeit inaktívvá tehetünk törlés helyett.

 

 

Rename

Adott konfigurációt/paramétert átnevezhetünk, ahelyett hogy törölnénk.

 

 

Configure exclusive/private

Ellentétben az IOS-szel, ahol “egymás ellen” tudtok konfigurálni, a Junos-ben lehetőség van többféle konfigurációs módra, pl. exclusive, ahol csak egy ember tud bármit módosítani.

 

Show | display xml

Automatizáláshoz, scripteléshez tökéletes kimenet nyerhető xml formátumban.

 

 

Kezdetektől API ready

A Junos-t úgy tervezték már 1997-ben, hogy könnyen hozzáférhető, automatizálható legyen a belső API-val. Érdekes cikk erről itt. Ami manapság (értsd: pár éve) sláger és szabvány (NETCONF), azt ők már eredetileg így csinálták.

 

Platform független alapok

Minden Juniper eszközön Junos fut, nyilván persze vannak eltérések a tűzfalas és a router image között (nem egy universal image van természetesen), de az alap kernel ugyanaz. Ezen az úton elindult a Cisco is egyébként az NX-OS-szel és az IOS-XE-vel.

 

Segítenek átállni

A Juniper is tisztában van azzal, hogy a hálózati piacon a csúcsragadozó a Cisco. Ha piacot akar nyerni egy gyártó, akkor alternatívát kell a Cisco megoldásai mellé tenni, és könnyíteni a szakemberek átképzését, akik Cisco CLI-n “nőttek fel”. Ezt helyesen felismerte a Juniper, és kitalálták pl. a “Junos as a second language” kurzust, amely jó IOS alapokkal bíró mérnökök számára mutatja fel a Junos-t, mint alternatívát, konfigurációs példákkal illusztrálva. 90 perces, érdemes végignézni.

 

 

Ami nem tetszik a Juniperben/Junos-ben

Operational és configuration mode

Jó, ez jön abból is, hogy Cisco CLI-n élek, de nagyon megkavar, hogy a Junipernél a # mód a konfigurációs mód és  nem a privileged EXEC, illetve a > mód nem az exec, hanem az operational.

Azaz most operational módban vagyunk, ez a Cisconál az EXEC:

 

Most pedig konfigurációs módban vagyunk, Cisconál ez privileged EXEC:

 

 

Interface elnevezések

Ezen kiakadtam és nagyon nehezen értettem meg. Jobbról balra számolják a portokat, és a fizikailag első port az logikailag a 0. Ez nem egyedi, mert más gyártó is csinál ilyet, de nekem nagyon zavaró, meg gondolom a helyszíni Field supportnak is, hogy az első portot kábelezi fizikailag, ami logikailag a 0. 🙂

Csatolok három példát a “Junos as a second language” anyagból.

 

 

 

 

 

Route preference értékek

Amit a Cisco administrave distance (AD) néven hív, az a Junipernél Route Preference. És a legjobb, hogy teljesen más értéket használnak, mint a Cisco.

Pl. az OSPF a Cisconál 110, a Junipernél 10 (vagy 150). Szóval ezt (is) újra kell tanulni.

És ott van még a HP, a Huawei és a többiek, akik szintén másképp csinálják, lásd alábbi ábra. Ebből csinálhatnának közösen egy RFC-t, mert ez brutális.

 

 

 

Hozzászólás

Ez a weboldal az Akismet szolgáltatását használja a spam kiszűrésére. Tudjunk meg többet arról, hogyan dolgozzák fel a hozzászólásunk adatait..