Cisco en CLI

[Ra_gdd]

Hi

Ben nu bezig met Cisco CCNA lessen en examens te volgen maar krijg geen bevredigende antwoord op mijn vraag.
Waarom blijft Cisco hun routers en switches via command line interface instellen?
Waarom stappen ze niet over naar een grafische firmware die in meeste home routers.
Dan bespaar je de gebruikers van commando's zoals in de tijd van MS-DOS.
Heb al managed switches ingesteld van HP en toch veel eenvoudiger via een grafische interface.

Mvg
Ragdd

[D4NG3R]

A: Iedereen die die dingen moet instellen is bekend met het bestaande systeem.
B: Een GUI kost meer rekenkracht en opslagruimte.

Daar komt bij dat je een switch over het algemeen niet meer aan hoeft te raken nadat deze is ingesteld.

[Rolfie]

Met een GUI weet je eigenlijk nooit wat je doet. Met een CLI weet je exact wat je doet.
GUI kost ruimte en moet onderhouden worden (security).
CLI kan je gemakkelijk script

Dus eigenlijk is CLI een stuk minder goed dan een GUI.

[dylan111111]

Met een CLI kost een stuk minder ruimte/rekenkracht.
Ook zijn hier amper beveiligings problemen mee.

[mrc4nl]

Niet alleen bij cisco routers en switches en routers ontbreekt de GUI.Linux servers hebben er namelijk ook geen.

Via de CLI lijkt misschien onhandig, maar je bent wel heel gericht naar hetgene wat je wil aanpassen.
Met een gui is het veel zoeken wat je moet aanklikken. "waar staat dit of dat"
voorbeeld:
bij een os met GUI moet je eerst een programma downloaden, dan opzoeken , openen ,paar keer op next klikken
en dan is het pas geïnstalleerd. bij ubuntu typ je in de cli gewoon een "apt-get install <programma>"

[Ra_gdd]

Thnx voor de antwoorden.

[Bl@ckbird]

Snap je CLI op een router, dan snap je het ook op bijvorbeeld een switch. Bovendien is CLI erg krachtig. Je kan dingen scripten. Daarom gebruikt Microsoft nu Powershell bijvoorbeeld. Je kan vrij eenvoudig wat naar een text bestand copy/pasten, wat aanpassen en dan weer terug plakken in de console.

Overigens worden op steeds meer devices een GUI gebruikt. Zo kan je WLAN controllers, ASA's, ISE appliance, UCS, ACI, etc. beheren via een GUI. De ASA gebruikt nog Java, maar nieuwe interfaces worden steeds vaker HTML5. Remote access SSL VPN wordt bijvoorbeeld zo complex, dat je dit via een GUI wil doen. Meraki cloud managed apparaten zijn volledig via een website te beheren. CLI bestaat hierbij niet. Met een paar klikken kan je 10.000 AP's, of switchpoorten beheren.

ACI en UCS kan je beheren via REST API. Zo zijn er apps om met je Smartphone een blade server te beheren. Iedereen kan dit in elkaar knutselen. NX-OS op de Nexus datacenter switches hebben ook een API. Je kan dan direct op de switch programmeren. Routers en high-end switches hebben de Embedded Event Manager (EEM). Hiermee kan je script op de router uitvoeren. Een engineer binnen Cisco gebruikt z'n 1841 router om op de webpagina van z'n printer de inktlevels van z'n inktpatronen te checken. Als deze te laag worden, krijgt hij via Twitter een update van z'n router dat het tijd is om inktpatronen te kopen. Ga je verder met Cisco, dan is het zeker interessant om een beetje Python te leren.

ff Geen zin om alle linkjes erbij te zoeken, dus daar mag je zelf op Googlelen

[_-= Erikje =-_]

Daarnaast is een cli prima bruikbaar over een high latency low bandwidth connectie. Zo beheer ik regelmatig apparatuur in Amerika en nieuw Zeeland, daarnaast is het mogelijk tekst gebaseerde configuratie op te nemen in svn of wat voor repository om zo versie beheer te doen

[magneet]

En als ik mijn collega's moet geloven dan is her eerste wat ze eruit slopen vaak de gui omdat die flinke bagger oplevert in config bestanden. Let wel ik heb er geen ervaring mee of kennis van, ben blij dat ik collega's heb die dat wel hebben. Doe mij maar powercli of esxcli

[Gillie]

Daarnaast zou een GUI met een configuratie zoals een service provider erg onoverzichtelijk worden. Zeker met een aantal vrf's, flinke hoeveelheid poorten. Access-list en route maps.

Ik ken routers welke >1.000 regels configuratie hebben.

[Hoteldebotel]

Op de wat zwaardere apparatuur waar meer op is geconfigureerd is het ook gewoon veel sneller. Als ik wat moet configureren ben ik door middel van efficiënt omgaan met de CLI sneller klaar dan met een GUI. Al dat geklik laten we wel over aan de systeembeheerders

[CAPSLOCK2000]

Ze zijn er mee begonnen omdat de CLI de standaar was toen Cisco begon, daar hebben ze vast niet lang over nagdacht.
Ze zijn het blijven gebruiken omdat Cisco-apparatuur over het algemeen gebruikt wordt door IT-professionals. Een GUI is heel handig voor software die je maar af en toe gebruikt; je kijkt een beetje naar de gui en met een beetje trail & error vind je het juiste knopje. Professionele beheerders gebruiken die software de hele dag door, die weten precies waar alles zit en die willen in één keer kunnen zeggen wat er moet gebeuren.
Met een CLI kun je dat heel eenvoudig doen. Bij een GUI moet je vaak door meerdere schermen heen klikken met knopjes die steeds op een andere plek zitten. Dat kost meer tijd dan een paar eenvoudige commando's die je zonder vertraging kan intikken.

Een ander belangrijk en gerelateerd aspect is automatisering. Als je een grote organisatie hebt met honderden of duizenden apparaten dan wil je die niet allemaal met de hand bedienen. Dat wil je automatiseren en met een CLI is dat makkelijk. Je verzamelt alle stukjes tekst, zet die in een filetje en die upload je naar alle apparatuur. Als je iets ingewikkelders wil kun je zelfs software maken om die configuraties voor je te genereren. Meer dan wat simpele tekst en een beginnerscursus scripten heb je niet nodig. Een GUI automatiseren is veel complexer.

Die automatiseringsfactor weegt heel zwaar. Bl@ckbird geeft al aan dat er tegenwoordig vaak een REST-API wordt gebruikt om het systeemprogrammeerbaar te maken.

Bij Cisco is de REST-interface eigenlijk de officiele interface. Zowel de CLI als de GUI doen niet meer dan tegen die API aan praten. Zo heb je het beste van drie werelden. Het is programmeerbaar voor de automatiseerders, er is een CLI voor de hard-core beheerders en er is een GUI voor incidentele beheerders.

[Koffie]

Move PNS > NT

[dion_b]

Verder hier nog aan toevoegend: vrijwel iedere CCNA cursusboek die ik gezien heb begint met uitleg van het waarom van de CLI. Heb je daar wel in gekeken?

[CAPSLOCK2000]

Ik zit nu met een gevalletje praktijk.

We hebben (vermoedelijk) een bug in onze firewall waardoor het hele netwerk onbetrouwbaar is en verbindingen at random blijven hangen.
Via RDP werken is haast niet te doen. Je krijgt er misschien 1 klik per minuut door en dan moet je maar hopen dat het de juiste klik is. Je weet niet of een klik wel is aangekomen dus ook bij een misklik zit je drie minuten te wachten of er nog iets gaat gebeuren.
Via de CLI werken is nog goed te doen. Het is wel een tikkie stroperig maar niet zo erg dat je er niet mee kan werken.