Standartni problem s propustnosti - VYRESENO zapnutim flowcontrol

[hapi]

asi nejefektivnější řešení by bylo vyhnout se na switchy přechodu gigo/fast jako že tam kde teče víc dat z něj na fast port tak ho předělat na gigo. Dobře to taky řeší třeba taková RB3011 v bridge. Tam je sw fronty 3x zadky.

[dagus]

A jakou frontu doporučuješ na přechod 1g/100m fifo a kolik paketu? Asi samo to musí byt i na eth toho 100m zařízení ne?

[hapi]

to chce zkusit, obecně nechat fifo kvůli malím nárokům na cpu a zvětšit jí třeba 10x od defaultu. A měla by bejt na výstupu pomalého portu. Tak by se mělo zajistit že to proteče routerem až na výstup pomalího ethernetu a tam se to zbrzdí v bufferu ale hlavně to nebude čekat na uplinku. Ono většinou stačí nepoužívat hw switch protože je prostě omezenej a funguje jinak. SW věc má kopec jiných možností jak se s tim 10 násobným rozdílem vyrovnat. Ale zase s tim nebejvá většinou problém takže stačí zapnout jenom flow control u hw switche. Ono to poznáš podle počítadel na portu jak moc se zahazuje což vlastně ukáže krásně tcp test.

[hol]

rychlost žere routing... bude se vyhlašovat nejlepší hláška roku? Nominuju ho, prosííím.

Zapni si všude flow control.
Chybovost UDP ti napoví.

No naše zkušenost je taková, že pokud se po cestě vícekrát routuje, tak to má na výslednou rychlost vliv. Nejde o to, kolik je rout na daným zařízení, taky jich tam máme přes OSPF mraky. Když měříme dílčí rychlosti, třeba z AP na klienta, na jednotlivých trasách, tak jsou rychlosti ok, ale ta výsledná rychlost z hlavního routeru na klienta je třeba jen poloviční, třetinová a závisí to práve i na počtu routování. Na switchované síti nic takovýho nepozorujeme. Když snížíme počet routování po trase, tak se výsledná rychlost zvedá. A to se bavím o profi spojích a jedné pětce na konci a mezitím nějaké RB2011, RB850, CCR36 apod a měření btestem. Že by to někde zahazovalo nebo chybovalo nepozorujeme.

Jinak na nominaci díky, ale myslím, že by jsme asi neměli šanci. Zas tak mimořádný to neni

[Dalibor Toman]

na 5500 (HI) pouzivam:

burst-mode enable

interface GigabitEthernet3/0/5
description nejaka radiova trasa o kapacite 620+ mbps
flow-control receive enable
qos lr outbound cir 620000 cbs 4000



a pak je dobry se podivat pomoci
display packet-drop interface GigabitEthernet3/0/5

co se zahazuje. Nechapu, proc to neni primo soucasti display interface.

[hapi]

rychlost žere routing... bude se vyhlašovat nejlepší hláška roku? Nominuju ho, prosííím.

Zapni si všude flow control.
Chybovost UDP ti napoví.

No naše zkušenost je taková, že pokud se po cestě vícekrát routuje, tak to má na výslednou rychlost vliv. Nejde o to, kolik je rout na daným zařízení, taky jich tam máme přes OSPF mraky. Když měříme dílčí rychlosti, třeba z AP na klienta, na jednotlivých trasách, tak jsou rychlosti ok, ale ta výsledná rychlost z hlavního routeru na klienta je třeba jen poloviční, třetinová a závisí to práve i na počtu routování. Na switchované síti nic takovýho nepozorujeme. Když snížíme počet routování po trase, tak se výsledná rychlost zvedá. A to se bavím o profi spojích a jedné pětce na konci a mezitím nějaké RB2011, RB850, CCR36 apod a měření btestem. Že by to někde zahazovalo nebo chybovalo nepozorujeme.

Jinak na nominaci díky, ale myslím, že by jsme asi neměli šanci. Zas tak mimořádný to neni

já to chápu ale píšeš o profi spojích takže tam nějaká stovečka megabitů poteče a pak to utneš tím že tam máš RB2011. Nechci to nějak hrotit ale z vlastní zkušenosti vím, že tyhle RBčka začínaji dělat problém na páteřích nad 100Mbit a pak se projevuje to co píšeš. To není problém routingu. Chápu, je třeba rozlišovat bridgování a switchování kdy bridgování se prakticky rovná routingu co se týče výkonu moderních mk routerů a posledních firmwarů s fast patchem. Nicméně ta RB2011 potažmo všechno s tim cpu 600/650MHz na silných páteřích vyhnijou a na cpu to nepoznáš. Pozná se to jenom na tý rychlosti skrz to jak píšeš. Doporučuju nahradit za RB3011 v exponovanějších oblastech. U nás jenom tahle změna uprostřed sítě vystřelila rychlost na 2x takovej průměr než bejval a dělal to jeden router typu RB951G což je starší brácha RB2011. Sedim za tim routerem i já a v nočních dobách sem na speedtest k nám naměřil jenom 200-300Mbit a po výměně routeru je rychlost i ve špičkách 400-500 + datový toky lidí. Nevim co se stane u těch RB2011, asi je na ně moc ten nával paketů z různých směrů. Do toho pytle házim i RB850ky.

[dagus]

Hapi a používáš na rb3011 ty sfp jako uplink? Právě v této konfiguraci se to nám chová divně, jiné chodí normálně. Když je link 1G a uplink 1G je třeba zapinat flowcontrol? Odkud je třeba mít zaplé? Už od gw po celé trase jen kvůli jednomu portu na desátém switchi?

[hapi]

SFP tam nevyužíváme ale chtěl bych. Pokud je to problém tak na něj kašlu. FC je třeba zapínat jeden skok před zpomalením což znamená na poslednim gigu v cestě. Switch kterej má uplink gigo a odesílá na fast odesílá po gigu pause rámce switchy před sebou takže tyhle dva to musí mít zapnutý.

[dagus]

Díky, na stole se mi to chovalo normálně. V realu jsem z toho rozpačitej sice naměřím v udp 500max skrz, ale večer jede skrz 850mbit reálného trafiku.

[okoun]

rychlost žere routing... bude se vyhlašovat nejlepší hláška roku? Nominuju ho, prosííím.

Zapni si všude flow control.
Chybovost UDP ti napoví.

chápeme jako že routovaná síť je náročnější na výkon routerů než neroutovaná síť... logické

[hapi]

jestli měříš btestem tak měř z tý strany co test přijímá, udp, omez v testu tx remote speed na reálnou hodnotu kterou to má dát a sleduj Lost Packets co ukazuje btest. Ukazuje to pouze v receive modu. Pokud někde něco bude dropovat nebo nebude stíhat přenášet tak tam budou lítat čísla. Pozor na to aby to byly dropy ale ne tím že jsi něco někde UDPčkem ucpal. Takhle se dá docela lehce najít problém.

[hapi]

rychlost žere routing... bude se vyhlašovat nejlepší hláška roku? Nominuju ho, prosííím.

Zapni si všude flow control.
Chybovost UDP ti napoví.

chápeme jako že routovaná síť je náročnější na výkon routerů než neroutovaná síť... logické

zajímal by mě důvod. Dřív bych tomu věřil ale jenom z pohledu toho co nešlo v routingu vypnout resp. bylo defaultně zapnutý jako je conn. tracking a u bridge nešlo zapnout resp. bylo defaultně vypnutý což je opět conn. tracking. Stačí se podívat na výsledky testů co dělá mikrotik a ty rozdíly nejsou skoro žádný. Ale chápu že zažraná špína je zažraná špína.


https://routerboard.com/RB1100Dx4

https://routerboard.com/RB750Gr3

https://routerboard.com/RB750r2


v čem je tedy náročnější? asi v tom že nemusí odchytávat všechen multicast/broadcast bordel v promiscuite režimu tak jak to musí dělat bridge? Ve větších bridge sítí se tohle to otočí protože jako bridge to řešit musí. Jako router ho to nezajímá protože co neni pro něj, zahodí.

[ludvik]

Ono je také dobré vědět, co je myšleno "neroutovanou" sítí ... Routovaná vyžaduje routery, proto je náročnější na routery, než neroutovaná, která routery nevyžaduje ...

I na testech od mikrotiku je vidět, že rozdíl mezi routingem a bridgem (tedy softwarové řešení) není nijak výrazný. Ono už je totiž vcelku fuk, jestli hledám v tabulce MAC nebo v routovací tabulce.

A abych byl pintlich: troufám si tvrdit, že moje routovaná síť na Brocade CER2024 je rozhodně výkonnější, než neroutovaná na libovolném routerboardu.
Čili otázka nezní, zda je lepší routing, nebo nerouting, ale spíš zda je to v obecném CPU, nebo specializovaném hardware.

[okoun]

obecně je prostě daleko náročnější průchod provozu routerem, kde se musí rozhodovat jakou cestu půjde než bridgem, to bylo vždycky, proto existuje například MPLS, aby to co nejvíce akcelerovalo provoz.
tady bych řekl že papír snese všechno a hlavně na klasickém btestu to vůbec není znát, začne to být znát hlavně v reálném provozu.
s nástupem fast pathu se to dost vyrovnalo použití mpls ten routing...

[ludvik]

I v bridge rozhoduješ, jakou cestou paket půjde ... jen jinak. A než namítneš, že jsou tabulky menší - za a) jak kdy ... a za b) adresa je delší, než ipv4.