10Gbit stackelhető Layer2 switch

Hálózati eszközök

Sziasztok,

Keressük a következő feltételeknek megfelelő eszközt:

  • legalább 8 db SFP+ port (10Gbit) - vagy több
  • minnél több gigabit (réz) port
  • managelhető legyen - VLAN, SNMP, korlátlan LACP, etc ...
  • layer 2 elegendő
  • stackelhető legyen (mindenféle stack megoldás szóba jöhet)
  • CLI
  • megbizható legyen
  • jó ár / érték arány
  • nem gond ha használt (+egy tartalék eszközzel nem probléma)

Jellemzően Cisco eszközöket használunk, a fentiekre pl. kevesebb SFP+ port esetén jól bevállt 3750X.
De minden más márkára nyitottak vagyunk, de azért nem TP-Link-et szeretnénk! (nincsen TP-Link-el semmi gond kis SBS-be tökéletes)

  • 2493 megtekintés

( dzsambo | 2019. 01. 15., k – 21:47 )

Hát ha eddig Cisco vonalról használtatok eszközt akkor én most is onnét választanék.

Ilyen kritériumoknak legolcsóbban a 3850-es család felel meg C3850-NM-8-10G modullal.

( n.balazs v | 2019. 01. 15., k – 23:52 )

Mégis mennyi az a "minnél több gigabit (réz) port"? 12, 24, 48 vagy több?
Mert akár azt is megtehetnéd, hogy veszel 2 db stackelhető 24/48 portos switchet, amiknek van 4 db 10 Gb-s portja per switch.

Pl: 2 darab HP Aruba 2930F 24G 4SFP+ Switch (JL253A). A 2540 is jó lehetne, de arra nem írják a stackelést.

LACP elsődlegesen redundancia miatt kell, a sávszélesség „növekedés” csak extra.
Active-Passive bonding is jó lehet, idáig jellemzően Cisco vonalon stack-eltünk.
Annál egyszerűbb, és könnyebben kezelhető megoldás nem igazán van mint a HW stack (egy logikai switch), és LACP.
De ha tudsz active-passive bonding-al megbízható eszközt, szívesen meghallgatjuk.

active-passive bonding bármivel megy, mert ahhoz nem kell switch oldali támogatás. Fogsz két switchet, osszekötöd őket 1/2 ahány port kell, aztán a gép egyk lábát egyikbe, másik lábát másik switchbe dugod. A többi a szerveren beállítod, hogy legyen active-assing bonding és a linux kernel intézi.

De ved, mert azok olyan megoldasok hogy nem stack-elt switchek kozott tudsz kifesziteni lacp es tarsai megoldasokat.
Van 2 switched/routered stb amit tudja ezek valamelyiket (tobb ilyen feature is van, melyik gyarto hogy hivja, altalanos szabvany erre nemigazan sajnos), lenyege hogy nincs hagyomanyos ertelemben stack-elve a 2 switched ahol egyben kezelned a 2 switch konfigjat, firmware frissiteset, ujrainditasat stb. hanem tovabbra is 2 switchet konfigolsz, amik ossze vannak kotve es megfelelo mlag, vpc stb. (amit az eszkoz tud ha tud ilyet) beallitasokkal megoldhato hogy a 2 switch 1-1 portjara ha rakotsz egy szerver 1-1 portjat akkor szerver felol lacp-vel kezeled (redundancia, load-balance is tobbnyire meg van ilyenkor) es ha egyik switched megall konfighiba, taphiba stb miatt akkor masikon meg fog mukodni.

Bocsánat, de tudom, hogy mi a működés elve, már használtam is.
Szerintem kicsit félreértetted a mondanivalóm. Van n darab switched, amiket 1 stackbe teszel. Ekkor nem beszélhetünk MLAG/VTI megoldásokról, hiszen a switchek egy nagy közös switchet alkotnak.
Egyébként igen, a 2 switch így külön-külön kezelve megfelelően működik redundancia szempontjából a hálózat.

A topiknyito mondandoi alapjan, mint:
"mindenféle stack megoldás szóba jöhet"
"Pont LACP az egyik fontos paraméter"
Nem feltetlenul hagyomanyos stack erdekli, ellenben lacp fontos, igy akkor igenis jogos felvetes lehet az mlag es tarsai megoldas, mert lehet valojaban nincs szuksege a stack-re mint olyanra, csak lehet nem tudja hogy hivjak (vagy hogy van olyan eset is) amikor kulon konfigolt eszkozokon megosztva alkalmazol lacp-t.

Alapvetően, ahogy már fent is írtam, mi a tradicionális stackelés híve vagyunk.
Sokkal több előnyét látom annak ha egy logikai switch-ed van, mint annak ha külön kezeled őket.
Igen, előfordulhat az hogy újraindul, de ezeket alapvetően tervezzük.
A nem tervezett leállások esetén pedig ha leáll mindkét switch, semmivel sem vagyunk előrébb ha külön vannak. (max boot idő).
Swich-eken elég ritkán frissítesz szoftvert, kb. csak olyan esetben ha valamilyen hibát szeretnél vele megoldani.
Az hogy pl. Catalyst-on 15.x v. 15.y van fent, normál használat esetén jelentéktelen.
A switch-eket managment VLAN-ba(dedikált hálózatba) rakod, innentől a security kockázat is kicsi.

Szóval nekem a stackelt, egy logikai eszköz megoldás szimpatikusabb :)

Ti tudjátok, hogy mit hogyan szoktatok csinálni, mi a kényelmesebb.
Szoftverfrissítés: Én azért találkoztam olyan helyzettel, amikor CVE-k miatt frissíteni kellett a switcheket évente több alkalommal is. Volt rá példa, hogy a stack frissítése eléggé elhúzódott. Persze ti tudjátok, hogy mennyire akartok biztonságorientáltan működni.
Az ugye megvan, hogy a mgmt vlan nem véd mindentől? Pl: CVE-2018-0174. :)

Ahány ház annyi szokás :)
Managment VLAN mögé zárójelbe azért írtam hogy dedikált managment hálózat, persze az tényleg ritka.
Sajnos mindig abból főzünk ami van, pl. 1-2 éve 3750x lett nálunk nagyon felkapott, főleg az ára miatt (használtban). Jobban megéri ezt megvenni, mint újabbat/újat venni.
Jellemzően ezeket stackeljük, viszont itt már ritka az update.

De köszönöm, kaptam hasznos infókat!

Egyébként ezt úgy lehet megjegyezni, hogy az "annál" és a "minél" egyikét egy db n betűvel kell írni, a másikat pedig kettő darabbal. Na most próbáld leírni őket 1 darabbal! Segítek: az egyik kapott szó gyakran szerepel xxx videókban, na azt kell 2 db n betűvel írni -> így a másikat 1 db n betűvel kell :)

Egyébként az+nál=annál. Teljes hasonulás, ha jól emlékszem általánosból. A másik pedig mi+nél.

SG széria = SBS
Használunk SG szériából, főleg SG300, SG350, de nagyon érdekes dolgokat tudnak produkálni.
~2 hónapja egy SG350 attól hogy beraktál egy portot VLAN-ba újraindult, ~1 óra google után derült ki, hogy ez sajnos BUG.
Egy évvel korábbi firmware-t felrakva oldódott meg a probléma.

SG szériát kis irodába, max pár 10 számítógépre! :)

A környezetet és funkciót nem specifikáltad, a gazdaságosság domborodott ki a funkció mellett.
Nekem az a tapasztalatom, hogy stabilak, >10 számítógép esetén is, nem sok érdekes dologban volt részem. Ha egy bug miatt ki kellene zárni egy termékcsaládot, akkor most barlangban csiholnám a tüzet.

Igen, tényleg nem írtam le pontosan hova/mire keresünk eszközt.

Igazából technikailag nem tudom megindokolni miért nem szimpatikus erre a feladatkörre SG széria.
Használjuk mi is, van ahol 5+ db van összekötve, hibamentesen, stabilan csinálja azt amit kell.
Ahová olcsó switch kell, általában mindig SG szériát rakunk.
El még egy sem romlott, gond sem volt nagyon velük. Leszámítva néhány szoftveres „bakit”.

Nekem alapvetően CLI-je nem tetszik, hiába Cisco, valahogyan olyan mint a TP-Link eszközök CLI-je, mintha másolná catalyst-ok szintaxisát.
Nem igazi Cisco!

Nekem alapvetően CLI-je nem tetszik, hiába Cisco, valahogyan olyan mint a TP-Link eszközök CLI-je, mintha másolná catalyst-ok szintaxisát.
Nem igazi Cisco!

Nyilván mert ez a régi linksyses széria utódja, gondolom a hw is, a sw is, meg a fejlesztők is ugyanonnan jöttek. Aztán nyilván nem volt senkinek kedve átportolni az "igazi" Cisco sw-t rá eddig (végülis csak vagy 10-15 éve vásárolták fel a linksyst) :D

( PunishR v | 2019. 01. 16., sze – 14:42 )

Veszel egy regi 6500-ast es megpakolod annyi portal amennyivel szeretned, olcso lesz, hangos es sokat fog enni, de megy.

( _ventura_ v | 2019. 01. 16., sze – 19:08 )

Mi vettunk regebbi hasznalt arista switcheket, nem bantuk meg. a config kb mint a cisconak.
Van mindenféle kiszerelés, és a 7050 es sorozat, igaz már nem támogatott, de olcsó :>

Fedora 28, Thinkpad x220

( quash | 2019. 01. 17., cs – 19:16 )

dell N4000 szériával esetleg van valakinek tapasztalata ?

Van. Stabil. Megbízható és ami fontos, van gyors magyar support. Ha újonnan veszed 4 órás garanciával 7 évig, az annyi is lesz 0-24 onsite... Ezt azért más nem tudja.

Sfp vagy dac kábellel gondot sosem tapasztaltam, ment mindennel amit beledugtam.

Írták hogy lassú a gui, igen, lehet de használd cli-n, mert majdnem teljesen Cisco szintaktika és persze más is mint például snmp... Vagyis őszinte termék mert, mind broadcom, kivétel nélkül, csak a hab és a support más.

( quash | 2019. 01. 17., cs – 22:02 )

Köszönöm a sok infót, tényleg sokat segítettetek!

Tanultam egy pár új dolgot, és egy kicsit át gondoltam a koncepciót.
Idáig mereven ragaszkodtunk a fizikai stack megoldásokhoz, mert az milyen jó.
De egyre inkább úgy látom jó, de eljárt felette az idő.

Nem fizikai megoldásokkal gyakorlatban sajnos még nem találkoztam, így azokat kihagytam.
Többen is írtátok itt pl. VPC-t, és hasonló megoldásokat.
Utána járva, tényleg megoldható pl. vPC-vel minden amit szeretnénk.

És azt hiszem meg is találtam a megfelelő eszközt:
Cisco Nexus N3K széria.
Használtan elfogadható még az ára, 48 SFP+ port.
Így maradunk továbbra is Cisco vonalon.

Ez az eredeti kiírást bőven túlnövi, de jól bővíthető.
Egyedül a „minél több réz port”-ot nem teljesíti, de arra ott az SFP modul. Gigabit-es SFP modul, már tényleg filléres tétel.

A vpc jó, azonos az irf, vrf technológiákkal mert broadcom. Menni fog és jól, de cisco fw upgrade nem lesz hozzá, ha nincs élőfizetésed a termékhez. Az új árát nem éri meg de használtan már más a helyzet.

Ami még szóba jöhet, az moduláris hp 54xx zl, már régiek emiatt lehetnek bennek nagyon olcsók lifetime warranity-vel.