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.
