Jak řešíte páteřní switche

[hapi]

aha, tak po tom kouknu. To by pak bylo dost málo. Poslední firmware tam máš? koukám že za poslední rok tam maji fůru improved oprav i když se to týká max toho že ty čítače budou fungovat

ale tak jasně, cenovka odpovídá hardware. Je jasný že kvanta dat potřebuje kvanta paměti atd..

[stepan.benes]

Není trochu málo chtít po páteřních prvcích aby neztrátovaly ? Na to aby se dalo dát nějaké doporučení, je těch údajů sakra málo. Chcete full L3 nebo stačí L2 nebo s případnou L3 funkcinalitou ? Prospustnost v L2/L3. 802.1ad ? xSTP ? MPLS/VPLS ? Multicast routing ? Dyn. routing - OSPF nebo iBGP ? My jsem se teď třeba zamilovali do Trillu a po páteřních prvcích ho vyžadujeme.
Rozumných alterntiv je víc, výkřiky jenom Cisco (nahraď jakéhokoli výrobce) a nikdy jinak nemají jakékoli opodstatnění. Minimálně je možné uvažovat o Ciscu, Juniper, HP, Brocade, Extreme Networks, Huawei, pokud nebou požadavky L3 tak další.
Nejdřív je ale třeba si jasně definovat co po těch prvcích vůbec bude chtít.

[manius]

Využíváme pouze L2 routujeme linuxem.

PL měříme ze sondy, která pingá na jednotlivé hopy atp.

V tuto chvíli vše nasvědčuje tomu, že hlavní problém je ten, že nemáme Shapping, takže lidi po gigu mohou vytočit to, co linka zvládne.

na každém hopu je umístěn router, který přes vlanu routuje do tranzitní vlany a je propojen přes OSPF....


Chce to v první řadě zjistit, jaký switch by nám stačil v rámci našich možností - teď budeme zkoušet brocade, který by mohl zvládat pojítka, které v tuto chvíli máme.

Uvidíme, jak se projeví velikost bufferů... začneme monitorovat DISCARDED packets... a podle toho se odpíchneme dále. Je to boj na dlouho, ale alespoň začneme.



Michal

[hapi]

hmm, předpokládám že kdyby tyhle "normální" switche byly na konci řetězce např. v racku pro servery tak pojedou ok ale na takový to "metro" rozvod stačit nebudou. Co to třeba pokusně nahradit nějakým RB450G/951G/850Gx2 v softwarovém režimu? tam se dá velikost bufferu nastavit frontou. Třeba na heavy routing strojích se tyhle buffery zvětšují na ethernetech.

[manius]

Zase nejsme sebevrazi, cesta přes mikrotik sw switche... switch bude mít i daleko větší latenci (nebude to v us ale v ms)...


software switch nepřipadá v úvahu, to bych dokázal možná i tvrdit, že stávající řešení na tplinkách je furt lepší...

tato tabulka to vystihuje

rrt.png (8.72 KiB) Zobrazeno 3907 x

[hapi]

tak to myšleno taky nebylo, spíš mi šlo o to aby si zjistil, že opravdu dropujou switche a to docela levně. To že to dočasně navýší latenci není důležité. Lepší větší latenci než chybovost která TCP rychlost shazuje daleko rychleji.

[RAket]

hmm, předpokládám že kdyby tyhle "normální" switche byly na konci řetězce např. v racku pro servery tak pojedou ok ale na takový to "metro" rozvod stačit nebudou. Co to třeba pokusně nahradit nějakým RB450G/951G/850Gx2 v softwarovém režimu? tam se dá velikost bufferu nastavit frontou. Třeba na heavy routing strojích se tyhle buffery zvětšují na ethernetech.

Sorry ale tohle snad ani nemůžeš myslet vážně. Strkat defakto SOHO krabku na místo, kde tečou stovky Mb/s a už vůbec nemluvím o pps.
Tyhle hračky mají jeden switch chip připojenej jednou linkou do CPU a to i nová 850Gx2. Uroutuje to velký kulový a použít to jako switch s 5ti portama a jen přes to switchovat? Sry, ale pokud už ti někde teče 300, 500 nebo 1000Mb/s, tak už jsi s hw úplně někde jinde a s cenovkama samo taky.

[RAket]

Není trochu málo chtít po páteřních prvcích aby neztrátovaly ? Na to aby se dalo dát nějaké doporučení, je těch údajů sakra málo. Chcete full L3 nebo stačí L2 nebo s případnou L3 funkcinalitou ? Prospustnost v L2/L3. 802.1ad ? xSTP ? MPLS/VPLS ? Multicast routing ? Dyn. routing - OSPF nebo iBGP ? My jsem se teď třeba zamilovali do Trillu a po páteřních prvcích ho vyžadujeme.

Obávám se, že většina ze zdejšího osazenstva vůbec neví, co TRILL je a kde se používá. Nemluvě o cenovkách za boxy co to umí.
Každopádně je fajn, že to používá i tuzemský ISP.

[Bach]

Není trochu málo chtít po páteřních prvcích aby neztrátovaly ? Na to aby se dalo dát nějaké doporučení, je těch údajů sakra málo. Chcete full L3 nebo stačí L2 nebo s případnou L3 funkcinalitou ? Prospustnost v L2/L3. 802.1ad ? xSTP ? MPLS/VPLS ? Multicast routing ? Dyn. routing - OSPF nebo iBGP ? My jsem se teď třeba zamilovali do Trillu a po páteřních prvcích ho vyžadujeme.

Obávám se, že většina ze zdejšího osazenstva vůbec neví, co TRILL je a kde se používá. Nemluvě o cenovkách za boxy co to umí.
Každopádně je fajn, že to používá i tuzemský ISP.

Je pravda, že L3 switch s TRILLem je výrazně dražší,ale věříme v jeho postupnou implementaci do dalších prvků. Zatím ho máme jen na HP 5920AF
Jinak ten ten zmiňovaný tok zvládne Nedávno nám přes něj teklo 8,5Mpps a byl úplně v klidu

[tuxisko]

Neviděl bych to tak, aby nutně switch uměl Trill. Hlavně je to poměrně "nová věc", takže samozřejmě dražší, je to ale evoluce. Spíše bych to zatím viděl v hodně velkých sítí a nebo tam kde je třeba echt kvalita, zejména data centra. Ano SPT není ideální, má vady, ale mnohdy to stačí na sídlištní síť. Také to je trochu o tom jak tu síť mám stavěnou.

[patrik_]

my na switchích jedeme jenom VLANY, routuje se jinde.

Měli jsme kdysi 3comy, potom cisca 2950 a 2960, potom SF-300 a SG-300 (4ks) a do nich napíchaná radia, propojené optikou.

Možná to byla naše neschopnost, ale u 29xx řady nás dost trápila chytristika na portech po výpadku protistrany rádia, musel jsem to často ručně nahazovat a nepovedlo se nám to úspěšně vypnout (ani povolanému cisco specialistovi).
Tupější 300 už mě s tím nezlobí . V provozu každý switch nejméně 3 roky a nevím o nich nemusel jsem na to nikdy sáhnout nebo restartovat.

Neříkám že tohle řešení je nej a ideální, odpovídám na dotaz "Jak řešíte páteřní switche". My takhle.

[Dalibor Toman]

Možná to byla naše neschopnost, ale u 29xx řady nás dost trápila chytristika na portech po výpadku protistrany rádia, musel jsem to často ručně nahazovat a nepovedlo se nám to úspěšně vypnout (ani povolanému cisco specialistovi).

errdisable recovery cause all
?

podle mych zkusenosti akorat 2940tky nechaji port v shutdown stavu po nejakem karambolu (storm-control action shutdown apod)

[GRFS]

Flow control (rizeni toku dat) bude fungovat pouze do limitu velikosti bufferu, jak uz bylo receno. Po prekroceni bude packet loss pokracovat dal. Problem nesymetrie mezi linkovou rychlosti LAN a WAN portem, v meritku radiovych spoju, se tedy nejvice tyka rozhrani Gigabit ethernet. Tam pomuze obcas obycejna selska logika. Jestlize mam kapacitu radia do 100Mb, nema smysl pouzivat GE rozhrani na LAN portu.

Nad 100Mb je treba zapojit QoS a rizene vyprazdnovani bufferu pomoci QoS priority bitu, mapovani do front, nastaveni velikosti bufferu a aging time pro kazdou frontu, dale pak color mapping, WRED atp. Jsou tam veci jako chovani TCP a pokles prenosu o 50% pri chybe a opetovnem skokovem nabehu pri naslednem opakovani prenosu. To vse cvici neuveritelne s lajnou a bufferem a proto v nerizenych sitich existuje packet loss.