Hogyan szereted menedzselni a hálózati eszközeidet?

Hardver

"helyi" webes felületen
49% (163 szavazat)
cloudban futó webes felületen
1% (4 szavazat)
"natív" alkalmazásból (pl. checkpoint)
2% (8 szavazat)
cli-n
35% (117 szavazat)
nekem elég egy REST API
1% (4 szavazat)
jó az úgy, ahogy kijött a dobozból
6% (19 szavazat)
egyéb, éspedig:
5% (17 szavazat)
Összes szavazat: 332

( trey | 2012. 10. 17., sze – 07:52 )

(x) egyéb

Változó. Valamelyiknél éppen a webes felületet találták el, valamelyiknél a natív alkalmazás a használható, valamelyiknél pedig egyedül a CLI értelmes. A cloud teljesen kimaradt.

--
trey @ gépház

( mauzi v | 2012. 10. 17., sze – 08:27 )

A régi szép időkben, amikor a menedzselhető hálózati eszköz szinte az IOS-t futtató Cisco szinonímája volt, akkor CLI volt a nyerő.

A mai világban, amikor ritkán jön szembe két azonos gyártó által tojt hálózati eszköz, az esetek többségében nem akarom megtanulni a mindenféle egyedi CLI nyelvjárásokat, a webes felületen intuitív módon összekattintgatom magamnak, ami kell, aztán ha valami macerás benne, akkor megnézem a manualban, hogyan kell megcsinálni CLI-ben.

Szóval, Cisco, Mikrotik: -> CLI, jellemzően minden más: web

Ha n+1 ügyféllel van dolgod, akkor persze, hogy n+1 gyártó lomja jön szembe (bár lehet az üf.-nek javasolni új eszköz/eszközcsere esetén olyat, amiből már máshol is van), saját cég hálózatán viszont nem igazán jó dolog a falusi bazár kínálatát megszégyenítő sokszínűség :)

( iron v | 2012. 10. 17., sze – 08:30 )

(x) egyéb

Ha már menedzselni kell, akkor régen rossz. Egyébként webről, mivel böngésző minden rendszerre van. Vagy ssh+cli...

Csatlakoznek.

Egyeb: Nagy zold gomb. MUKOGY!

Lehet esetleg egy piros is, hogy alljon le. De nem gondolom, hogy meg kene allitani, ha mar megy...

De amugy komolyan. Mekkora amatorseg mar egyesevel CLI-rol, sajat webes feluletrol managelni egy rendszert. A fene akar minden nodeot kulon piszkalni.

Masreszt a legtobb hozzaszolasban (eddig) a management=konfiguralas. Pedig sokkal tobb idot toltenek egy rendszer monitorozasaval, felteve, ha atgondolta valaki es rendesen beallitotta. Ha feltesszuk, altalaban minden jol mukodik, akkor az idonk nagy reszet az alarmok es a counterek, KPI-ok figyelesevel toltjuk, es nem az egyes nodok hekkelesevel.

1. cluster ssh
2. ha ossze vannak stackelve nem kell kulon piszkalni feltetlen oket...
3. kozponti mgmt
4. snmp ha szeretsz jatszani/scriptelni -> ezzel vezereltunk mar tobb szaz halozati eszkozt is...

Tokon is szurnam magam ha pl 30 eszkoz eseten kezzel weben keresztul kellene bejelentkezni (captcha es tarsai) es kattogtatni...

( tetra | 2012. 10. 17., sze – 10:34 )

Ha hálózati eszköz alatt az otthoni routeremet értem, akkor weben. Ha a hálókártyák is bennevannak, akkor Winen GUI, Linuxon CLI.
----
India delenda est.
Hülye pelikán

Szerintem egyértelmű a kérdés: "hálózati eszközt" írtak. Ide szerintem az access, disztribúciós és core rétegbe tett switchek/ routerek értendők.

A soho kategóriát túlzásnak tartom "hálózat"-nak hívni: Azon managelni max annyit kell, hogy leméred a kábelt egy olcsó kábelteszterrel (ilyesmi szintre gondolok, mint ez: http://www.flukenetworks.com/datacom-cabling/copper-testing/MicroScanne… ) , hogy minden rendben van-e, ha meg megdöglött a switch, vagy natdoboz, akkor kidobod, és veszel másikat.

Ha nem érted a fentieket, abban sem vagyok biztos, hogy neked routered volt. Mármint igazi.
A soho nat-dobozt, szerintem hibás nevezéktan routernek hívni:
Routing protokollt nem beszél, bár csinál IP továbbítást, de egy routerhez képest elég mélyen belenyúl a forgalomba. Ami néhány ACL érvényesítésénél többet csinál a forgalommal, és aktívan bele is nyúl, azt rendszerint tűzfalnak szokás hívni.

De a legtöbb soho nat-doboz, meg tűzfalnak buta, hacsak nem egy openwrt-vel felülvágod a gyári firmware-jét.

Eddig szerintem a legjobb név rá: nat-doboz / szappanosdoboz.
Kíváncsi vagyok, van-e aki máshogy hívja ezeket. (Mármint olyan, aki router-t is látott már.)

Végülis szigorú értelemben a fent írt C6k pl. switch, a nexus7k meg DCE switch...
Aztán a C6k mégis routingban minden téren lenyom egy 1700-as sorozatba tartozó routert, ami pedig a "router" termékkategóriában kapható... :D

A NAT-BOX, SOAP-BOX kifejezést nem nagyon láttam még hálózatos doksiban, ellenberger azt az eszközt, ami L3-ban irányítja a forgalmat, azt az egyszerűség kedvéért routernek hívtuk eddig... Vagy valamit rosszul tudok...?

Hogy egykori kollégámat / tanáromat idézzem...:

* Repeater (L1 switch:-)
– egyetlen osztott közeg

* Bridge - L2 switch
– részleges forgalom irányítás (MAC), de egyetlen „Broadcast Domain”
– támogatja a VLAN-ok kialakítását

* Router - L3 switch
– Determining the forwarding path based on L3 information
– Validating the integrity of the L3 header via checksum
– Verifying packet expiration and updates accordingly
– Processing and responding to any option information
– Updating forwarding statistics in the Management Information Base (MIB)
– Applying security controls if required
– Implementing QoS (TOS - Type Of Service bitek)

* Gateway – L4 switch
– L3 hardware-based routing + L4 control information
– Az alkalmazások felismerése és ennek megfelelő prioritás, valamint számlázás
– Táblaméret ~ állomásszám * felügyelt protokollok

* Multilayer Switch
– L2-4 együtt, skálázhatóság, alacsony késleltetés
– Meghatározza a folyamokat "route once, switch many"

Szép felsorolás.

A "szappanosdoboz" itt egyik kategóriába sem illik bele. A NAT-olás miatt az integritás nem kicsit sérül...

De szerintem egyszer guglizd át csak a hup-ot, és mondjuk keress kadlec-től hozzászólásokat nat témában... ;-)

Ha már szemléletet formálunk, akkor válogassuk meg, kiktől, és mit tanulunk!

A soho dobozok valóban nem _csak_ routerek, tűzfal-funkciókkal is fel vannak vértezve, úgy mint csomagszűrés, csomagok átírása - de ettől még alapfunkciójuk L3-ban történő forgalomirányítás. A NAT használata nem kötelező, csak egy lehetőség - van olyan helyzet, ahol kell, és van olyan, ahol fölösleges.

"Routing protokollt nem beszél"

A statikus routing is routing, ne becsüljük le! Én routernek hívom ezeket is, elvégre két broadcast domaint mégiscsak elválaszt.

Az oké, hogy pl. egy C6509-E wirespeedben, port sűrűségben lenyom egy 1700-as vagy 1900-as routert, de attól még csak egy nagyratörő switch marad. :-) Nem is egy célra készülnek.
---
;-(

( carlcolt | 2012. 10. 17., sze – 12:52 )

"cloudban futó webes felületen"

Na attól mentsen meg a jóisten!

( Finder | 2012. 10. 17., sze – 14:05 )

CLI-t jelöltem, mert az IOS féle CLI-t preferálom, azonban ha valami nagyon szokatlan eszközről van szó, akkor inkább legyen hozzá valami GUI. A webes felületeket viszont annyiból nem szeretem, hogy azokat elég nehéz elérni ha eleve az a gond, hogy az IP hálózat nem is működik.

Igen, szeretem ha van. Amíg itthon egy Cisco 2610-es dolgozott, addig az egyik gépem fixen rá volt kötve a sorosporton. Ha valami miatt nem tudtam volna L3-on elérni a routert és úgy állítani (ez csak VPN-en keresztül, telnet-en ment), akkor a másik gépen keresztül (ami saját PPPoE kapcsolatot használt) még mindig el lehetett érni. Egyszer sem volt rá szükség szerencsére, de ott volt a lehetőség. Amikor még tanulgattam a konfigurálását akkor persze jó volt, hogy L3 még sehol, de a routeren mindent elértem.

Na most kedvet kaptam elővenni... :)

( lajos22 | 2012. 10. 17., sze – 18:24 )

"egyéb, éspedig:"
Attól függ miről van épp szó.
konfighoz: cli és / vagy webes cucc.
monitorozáshoz: saját webes cuccon az összes eszköz egyszerre.

--
openSUSE 12.2 x86_64

( hrgy84 | 2012. 10. 18., cs – 01:09 )

Van olyan halozati eszkoz, amihez van felhos management? :o
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( miq | 2012. 10. 18., cs – 19:55 )

A legtöbb dolgot egy saját kis menürendszeres felülettel, ami expect-et és CLI-t használ.
Meg mellé egy adatbázist, ami tartalmazza a switch-ek típusát, illetve a topológiát :)

Személyes kedvencem a Linksys SRV termékcsalád, az ActiveX-et használó webes managementjével, ami csak WinXP/IE6-ból kezelhető. Legszebb napjaim közé tartozik, mikor megtudtam, hogy lehet rajta "rendes" CLI-t is elérni...

( turul16 v | 2012. 10. 20., szo – 14:38 )

openflow :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.