48x Gbit SFP switch / návrhy a zkušenosti / DCN?

[ludvik]

Právě z toho už mám strach. Ono také hledám switch jako náhradu právě za L3 DCN DCRS-5960. S ní by byla spokojenost, kdyby neměla packetloss ...

Cena za hubicku to je, kdyz nepocitas nakup dalsiho switche odjinud, kterej pak bude fungovat Koupil jsem tak pred rokem na testy jeden optickej gbit L2 bdcom a lezi v polici do ted.

Naopak DCN na L2 veci pouzivame a spokojenost, vyuziti na L3 chystame. Co je docela dobry, tak je podpora pro 100M a 1G SFP zaroven ve stejnych sachtach, fungujici vycitani diagnostiky apod.

[josefp]

Cena za hubicku to je, kdyz nepocitas nakup dalsiho switche odjinud, kterej pak bude fungovat Koupil jsem tak pred rokem na testy jeden optickej gbit L2 bdcom a lezi v polici do ted.

Naopak DCN na L2 veci pouzivame a spokojenost, vyuziti na L3 chystame. Co je docela dobry, tak je podpora pro 100M a 1G SFP zaroven ve stejnych sachtach, fungujici vycitani diagnostiky apod.

Muzu vedet jakej je to model ? Co na nem nefungovalo ?? Verzi fw ??

Diky

[klacek]

Potreboval jsem kombinaci 100M a 1G SFP a ta diagnostika, z ostatnich funkci jsem potreboval holej zaklad a ten tam byl. Mozna trochu neprehledny CLI, DCN je na tom lip ...

5960 v siti mam 2 a PL na nich nesleduju, co to reportovat smerem nahoru k tomu kde bylo koupeno a odtud vyrobci ? PL by delat nemel zadnej rozumnej switch ...

[ludvik]

Jim se to nedaří nasimulovat. Výsledek je zatím ten, že je problém všude jinde, než na tomhle jednom switchi. Akorát že jinde problém nemáme a tenhle switch je jen jeden ... Tak nevím co si o tom myslet. Ale už jsem se rozhodl, že půjde do pryč. Možná ho někdy zkusím jen jako čistý L2 a uvidím.

5960 v siti mam 2 a PL na nich nesleduju, co to reportovat smerem nahoru k tomu kde bylo koupeno a odtud vyrobci ? PL by delat nemel zadnej rozumnej switch ...

[klacek]

A jak přesně se to projevuje ? Nemá na to vliv např. nějaký radio přes kter to jde či tak něco ?

[ludvik]

Ne nemá.

Ze switche vede jeden trunk do edgecory (2Gbit, drátem, asi metr) a druhou stranou buď čistě ethernet sítě připojené optikou (tedy jen switche), případně i routery už přes rádia (a tedy RJ). Nakonfigurováno s MSTP, "druhá" strana jsou už jen RSTP samostatné větve. Momentálně bez backupů, tedy žádné kolečko, jen jeden výstup do zbytku sítě.
Projevuje se to tak, že když pingáš zkrz tento switch, čas od času se něco ztratí. Není to moc, ale na video se přes to koukat nedá. Zkusil jsem na zkoušku do jedné optiky vypnout STP - a blbnout to přestalo. Jenže vypnout ho globálně nemůžu. Zjevně špatně reaguje na pakety "STP Change topology" které odněkud přijdou, když uživatel zapne či vypne kompa (uživatelské porty na těch switchích jsou jako edge). Na tomto switchi nejsou žádní koncoví, vše přijde z nějakého dalšího. Výrobci většinou edgecore, ale jsou tam i netgeary a 3com.

Přes celou síť můžu pingat celé dny (tedy vydržel jsem to asi 14 hodin) až na tu poslední edgecoru před DCN. V pohodě. Jak to jde přes (nebo na) DCN, je loss. Chybovost nikde vidět není, ani na portech, ani v logách.

Včera jsem ještě dostal nezávisle názor, že některé switche mají špatně implementovanou MAC tabulku. Bez ohledu na VLAN. Takže pokud se odněkud naučí MACku a zjistí ji i na jiné vlan, flushnou tabulku a učí se znovu. Akorát zatím nemůžu vykoumat, zda se to může stát i na mé topologii. Neměl jsem tolik času.

A jak přesně se to projevuje ? Nemá na to vliv např. nějaký radio přes kter to jde či tak něco ?

[czu]

U nás se taky objevovaly chyby na trunku, a to konkrétně mezi dvěma ECS4610-24F... možná by stálo za to ten trunk někdy mimo špičku shodit a pozorovat, jestli to bude mít nějaký vliv na packet loss (my to nakonec vyřešili úplně jinak...).

[klacek]

Já mel za to, že link down/up na edge portu / portfast u dcn negeneruje zadnou udalost do rstp a dal do site. Kazdopadne jestli to takhle blbne, tak to ok neni, je otazka kde vznika problem, tj jestli se zbytek site chova tak jak ma a blbne to dcn nebo je to neco abnormalniho a problem je jinde. Podle popisu je to spis chyba v STP nez PL, takze mozna pustit na obou stranach debug na rstp a sledovat co si povidaj, pripadne port mirroring a zjistit co tam chodi. Vim ze je to casove narocny, ale zas se da zjistit kdo "zlobi"

[ludvik]

Ono to není jen v tom trunku. Ledaže by to mělo nějaký postranní efekt a ovlivňovalo to i ostatní porty nezávisle.

U nás se taky objevovaly chyby na trunku, a to konkrétně mezi dvěma ECS4610-24F... možná by stálo za to ten trunk někdy mimo špičku shodit a pozorovat, jestli to bude mít nějaký vliv na packet loss (my to nakonec vyřešili úplně jinak...).

[stepan.benes]

ach jo. a už to vypadalo tak nadějně... Bylo by možné trochu rozvést v čem konkrétně byl problém? Mluvil jsem teď s obchodníkem Alternetiva a zněl docela přesvědčivě (holt ti obchodníci...). Uvidíme co zápůjčka.

Já vím, že to není úplně koscher, ale STP ani L3 věci nepotřebujeme, jen hromadu SFP portů, vlany, igmp snooping a rozumné CLI. Co by na tom mohlo nefungovat?

občas to přestalo načítat multicast grupy a ty co byli načetlý to čase vysypalo. Sice jsme našli konfiguraci na který to jakž takž šlo, ale nebaví mě okolo toho běhat s vonnejma tyčinka a podřízlým kohoutem a modlit se, aby se to zase nezbláznilo. Máme výrazně kvalitnější řešení jen o něco dražší. Pokud bude zájem, pak SZ.