Dotaz: Latence routeru

[Flegmosmoke]

Zdravím,mám HW router jako poslední článek sítě k poskytovateli (Celeron 2,4GHz, Intel 865, 256MB DDR, 2 x síťovka RealTek RTL8139 - z toho jedna intergrovaná na MB). OS FC5,jádro 2.6.16.. Na eth1 jsou další dvě virt. rozhraní (eth1:0 atd.). Provádí se maškaráda a tr. shaping. Do 8Mbit/4Mbit nenašel jsem problém. Nyní po navýšení konektivity a toku kolem 11Mbit (download) se směrem do internetu zvýšila latence (cca o 20ms,občas se objeví i 2 s a podobné chování), přibyl packetloss. Nejdříve jsem to přikládal charakteristice bezdrátové technologie pro přivedení konektivity,samozřejmě malá reklamace.. Provider.. "vše je v pořádku". Chybu přikládám síťovým kartám (nicméně ping z vnitřní sítě je OK). Raději se ale chci zeptat zkušenějších než začnu dělát nějaké zásahy. Zde přikládám nějaké výpisy:

eth0      Link encap:Ethernet  HWadr 00:0A:EB:9D:9A:24
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:9198569 errors:7 dropped:2 overruns:1 frame:0
          TX packets:7585106 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000
          RX bytes:2259050437 (2.1 GiB)  TX bytes:2164422330 (2.0 GiB)
          Přerušení:17 Vstupně/Výstupní port:0x2000

(po hodině běhu stroje)

Chain INPUT (policy DROP)
target     prot opt source               destination
syn-flood  tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN
DROP       tcp  --  anywhere             anywhere            tcp flags:!FIN,SYN,RST,ACK/SYN state NEW
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     tcp  --  anywhere             anywhere            tcp dpt:auth reject-with tcp-reset

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             x.x.x.x/25
ACCEPT     all  --  anywhere             y.y.y.y/26
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere            state INVALID,NEW
TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state NEW,RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain syn-flood (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere            limit: avg 1/sec burst 4
DROP       all  --  anywhere             anywhere

cat /proc/sys/net/ipv4/route/max_size 65536
cat /proc/sys/net/ipv4/ip_conntrack_max 65535

Díky za za všechny rady!

Odpovědi

[Evka]

Dropni trafik a zkus pingat pokud objevis i tak packet loss, zkus vymenit sitovku pripadne misto bezdratu na druhou stranu nasadit jine zarizeni po kabelu s IP na ktere by jsi mohl pingat a pripadne odhalit zavadu HW. Zkontroluj contract tabulku jestli neni preplnena. Evka

[Flegmosmoke]

Jak jsem psal,ten problém se začne vyskytovat až při relativně větším provozu (tok 10Mbps/4Mbps). Do té doby je to OK. Ten bezdrát je profi.. (typu Alcoma atd.),žádné wifi.

[Evka]

Pouzivas shaper? nemas v nem chybu ?

[Tom]

Čistě náhodou- běží ti síťové karty v modu 100Mb/s full duplex ?

[Flegmosmoke]

Běží... eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

[Tom]

Zkusil bych zkontrolovat pocet a dobu conntracku - http://www.abclinuxu.cz/forum/show/133549 eventuelne nastav podle velikosti RAM ,pak me napada jestli nemuze byt zrada v shapingu- soucet rychlosti trid je vyssi nez rychlost poskytovana providerem. BTW,latence je zvysena trvale,nebo jen v pripade zatizeni site (vecer apod) Pro kolik klientu je ten router?

[Flegmosmoke]

echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max

echo 113000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established - 
to jsem nastavil teď

Jinak používám CBQ.. (Pro public IP je zde 15 pravidel,zbytek neomezuji - jsou to mé další routery,za nimi NAT a další shaping, dohromady cca 400 IP. Snad jen 10 privátních IP pro oba směry - upload pomocí iptables markování) - do internetu tedy relativně tedy připojuji 500 klientů. Součet tříd shaperu je trošku nad limitem poskynuté konektivity,ale problém se projevuje i když té rychlosti nedosahuji. A to opravdu jen po večerech při zatížení sítě stylem odezva stoupne cca 500 až 2000 ms (pingám z té gw),nějaký ten packetloss,rapidní pokles průtoku a pak zase v závislosti na provozu jede cca 5 min v pořádku. Přes den OK. Snad jsem to srozumitelně popsal. Díky za zájem!

[Opičák]

P2P máš omezené jak? Počet spojení pro jednotlivé klienty je nějak omezený? Mohlo by to být tím, že tyto aplikace dokáží svým vcelku nicotným provozem značně zaměstnat router. Ve večerních hodinách nepřibývá všeho trafficu ale i tohoto. Ale opravdu jen typuju.

[Flegmosmoke]

P2P je omezeno pouze na routerech,které se starají o bezdráty (tedy skoro všechny) a to tak, že každá IP má k dispozici 200 navázaných připojení. Tento problém se mi ale také projeví, pokud stahuji např. 100 MB soubor z FTP poskytovatele přímo na zmiňovaný router!?

[Opičák]

No a vytížení toho routeru je jaké? Na kolik je vytížený procesor? O co všechno se tento router stará a pro kolik klientů? Při kolika paketech za sekundu to ještě stíhá a při kolika už ne? Jinak osobně si myslím, že síťovkama to nebude. Mám na nich na vnitřní síti daleko větší provoz a nic nepozoruju.

[oron]

"Ten bezdrát je profi.. (typu Alcoma atd.)"

nepoznam tieto zariadenie, ale ak to nie je licencovany spoj,
tak by som hladal chybu tu.

aka je realna-skutocna priepustnost tych radii ?

[Opičák]

10-40Mbit ...stačí se podívat na stránky Alcomy. Asi záleží na modulaci. Ale až tak se v tom nevyznám.

[Tom]

Latence se ti zvyšuje i když pingáš jen na Alkomu co máš hned za routrem? Jinak bych nasadil iptraf,ten ukáže kolik a čeho se klienti dopouští......

[Flegmosmoke]

To pojítko nevlastníme... Je to Alvarion BreeznetB28 5,4 (nechtěl jsem to napsat rovnou,aby se nerozjela diskuze o rušení). Provider řekl,že jemu pingá bez problému (mám i graf toho pingu). Vytížení CPU zrovna zkoumám jak ho rychle zjistit, předpokládám že load average nestačí, ale:

cat /proc/loadavg
0.16 0.18 0.13 1/58 9364

Stará se opravdu jen o shaping (CBQ),pár pravidel iptables,routuje 5 segmentů veřejných IP. Nic víc. Počet klientů je myšleno jak? (připojených přímo na gw nebo celkově?). Přímo připojených je cca 30,další NATuji za dalšími routery. Ale při minimálním toku a připojených klientech pustí wget přímo na tom stroji a děje se úplně to samé. Začne to při downloadu 10Mbit a tak 1400 paketů za vteřinu

Total rates:      14349,2 kbits/sec        Broadcast packets:
x                    2667,6 packets/sec      Broadcast bytes:
x
x Incoming rates:    8540,7 kbits/sec
x                    1382,4 packets/sec
x                                            IP checksum errors:
x Outgoing rates:    5808,5 kbits/sec
x                    1285,2 packets/sec

Takto je to relativně ještě OK,odezva do 50ms, občas skočí 100ms.. Hodně to skáče,ale to bude tou 5,4G. Při 8/3 to jede 5ms.

[Opičák]

Tak máte tam Alvarion nebo Alcomu?? Pokud ten Alvarion, tak pokud vím, tak používá dynamickou změnu kanálů a proto odezva kolem 50ms, při zatížení i víc. Obávám se ale, že tak 16Mbit jsou stropem tohoto zařízení a víc bych se ani nepokoušel tím protlačit. Rovněž se obávám, že tohle pojítko je pouze Half-duplex. Takže na full-duplex 10Mbit potřebuješ 20Mbit half-duplex plus nějakou rezervu na rušení apod. Takže mě z toho vypadává jednožnačně to pojítko.

[Flegmosmoke]

Alvarion.. Ta Alcoma jen proto,abych neodváděl pozornost od toho routeru. Vydám se tam tedy s nb.. Zatím děkuju moc!!! P.S. Ten spoj je ISP

[Opičák]

Tak jsem si to našel. Je to nějaké Bridge zařízení schopné protlačit prý až 28Mbit/s. Ovšem jestli FD nebo HD, tak tomu jsem neporozumněl. Takže teoreticky se tam těch 10Mbit vejde. Ale jestli je to HD, tak se to velmi blíží horní hranici toho zařízení.

[Opičák]

PS: můžeš mi zde http://www.alvarion.com/products/BreezeMAX/ ukázat to zařízení?

[Opičák]

a jako vždy blbě, takže znovu ...je to tu http://www.alvarion.com/products/

[Flegmosmoke]

http://www.alvarion.com/solutions/backhaul/products/breezenet_b/.... Toto je úplně nové (údajně 30Mbit FD). Mě se tam prostě nelíbí to vyskočení 2000ms a náhlý pád průtoku na 1Mbit..

[...]

No, patrně nemáte ideální podmínky, jako je má výrobce, když píše údaje do reklamního letáku. Ta latence je určitě způsobna tím, že si jednotky mezi sebou začnou dohadovat, jak se nejlépe spojí. A když se ještě nedohodnou, že to půjde rychle, nýbrž pomaleji, máte tam rychlostní skok. Myslím, že vám zbývá jenom stěžovat si u ISP, vytěžovat linku, otravovat ISP a tak dokola. A mezitím zajistit, aby opravdu nebyl problém na vašem routeru. Vzhledem k tomu, že je to nová technologie, nebude to s ní umět ani ISP a budete pro něj pokusný králík.

[Flegmosmoke]

Nerad bych to zakřikl,ale nacpal jsem toto

echo 12000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 50>/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 5>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 120>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 120>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 60>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10>/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

do rc.local, udělal reboot. Hodinu testuji a chová se to zatím OK. Nikdy jsme tyto hodnoty neřešil. Pokud máte někdo ještě nějaké doporučení,budu rád!! K tomu ISP: Nemohu říct po 6 letech proti ani slovo..

[Opičák]

Tím že snížíš timeouty si sice pomůžeš, ale jen na jednu stranu. Nevím jestli tohle je ideální řešení. Hromada aplikací se ti může nenadále odpojovat, protože spojení bude zahozeno apod. Může to zkrátka nasekat spoustu problémů. Otestuj a uvidíš.

[Flegmosmoke]

Tak to nepomohlo.. :( Ze zoufalství ani upgrade jádra,zastavení služeb SNMP,CBQ.. Jinak vytížení CPU v okamžiku problému:

top - 10:52:08 up 34 min,  3 users,  load average: 0.25, 0.18, 0.11
Tasks:  56 total,   2 running,  54 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.3% us,  1.0% sy,  0.0% ni, 96.0% id,  0.0% wa,  0.0% hi,  1.7% si

Fakt už si nevím rady.

[Jirka Chráska]

Dobrý den,
podobný problém jsem kdysi řešil. Sítovky RTL8139 nemají nijak zvláštní výkon. Zkuste to vyměnit za 3Com 3c905 nebo Intel. Mě to tenkrát pomohlo.

[Opičák]

No to by ty síťovky musely být špatné i pro obyčejnou 10/100 Mbit LAN a tam nejsou zas tak tragické. Podle mě je nějakých 10 Mbit/s vůbec nemůže rozhodit.

[Jiří S.]

A velikost tabulky conntrack v okamžiku problému?

cat /proc/net/ip_conntrack | wc -l

[Flegmosmoke]

Velikost tabulky je 4642... Prostě toto nastalo po navýšení konektivity..

[Opičák]

Tak mě napadá a nač jsou tam ty dvě virt. rozhraní?? Kvůli čemu? Vytvořené čím? Fungují správně?

[Flegmosmoke]

Vytvořené mnou,2 x public IP (jeden rozsah už byl vyčerpán) + 1 privat IP. Myslím, že fungují správně nebo jak to bylo myšleno?

[Opičák]

No šlo mi o to jestli fungují správně. Byl to jen dotaz. Jinak přes co jste ty rozhraní vytvářel? Já totiž pojem virt. rozhraní moc neznám. Já prostě přes utilitu "ip" z balíku iproute2 přiřadím danému rozhraní další IP adresu z jiného rozsahu a upravím routování + firewall. Ještě mě napadá, že pokud jste je vytvářel přes ifconfig, tak je zrušit a zkusit to přes utilitu ip. Třeba je tam něco prohnilého.

[Petr Šobáň]

Pokud jsi virtuální rozhraní vytvářel pomocí ifconfig může to dělat problémy protože už se virtuální rozhraní nepoužívají a pouze se emulují.

Takže zrušte nastavení a nastavte sítovky příkazem ip a přidělte jim více ip adres.

Prostě na jádrech 2.6.x nepoužívejte ifconfig je to přežitek a jádro to už nepodporuje a pouze se to snaží emulovat a nastávají problémy.

[Tom]

Začal bych znova tím,že bych se ujistil,že je problem opravdu v routru a ne v rádiu.Před router PC,za router PC a pomoci programu iperf "prohánět" data přes router,co to ukáže. Dále bych pro jistotu zkontrolovat UTP kabel+konektory mezi routrem a rádiem,eventuelne přidal RAM do routru.

[Rockfire]

Dobry den, zkusil bych vymenit sitovky za nejake lepsi napr. 3com, nebo intel. Realtek daleko castej pouzije preruseni. Nekde tady na abicku jsem cetl ze realteky zvladnou konektivitu okolo 500 KB/s - samozrejme zalezi na stroji, ktery obsluhuje irq. (pokud se pletu nekamenujte me.)

[Flegmosmoke]

Tak rozhraní eth1:x jsem zrušil,vše vytvořil pomocí "ip addr add". Je to furt stejné. V rámci vnitřní síťovky jsem zkoušel tahat data jedním směrem přes mc (nejdříve k routeru - skoro 100Mbit/s, pak z něj na muj webserver - ani ne 10Mbit/s)? Iperf vypsal toto:

iperf -c mujwebserver -d

[  5]  0.0-10.0 sec  7.67 MBytes  6.43 Mbits/sec
[  4]  0.0-10.0 sec    109 MBytes  91.6 Mbits/sec

Jaký na to máte názor? Mě se to moc nezdá.

[Flegmosmoke]

Tak na to co jsem napsal si sám odpovím.. Měl jsem v CBQ z historického hlediska udělanou třídu pro rychlej ping na gw (10Mbit)..

[Petr Šobáň]

Takže to bylo v CBQ?

[Flegmosmoke]

Měl jsem hlupák omezený download na 10Mbit (jen některé rozsahy) a divil jsem se :) Ale problém přetrvává.. Zítra to otestuji na místě s NB a prověřím ty aktivní prvky. Objednal jsem si i síťovky (http://www.bgslevi.cz/produkt_detail.php?id=20729) - co si o ní myslíte? Jinak mám pocit, že je na vině ten bezdrát.. Když tahám data z toho routeru do vnitřní sítě,není problém.

[jurasek]

Dobry den Jsou to solidni sitovky, sam je pouzivam do nizkorozpoctovych serveru, kde je zapotrebi 1Gbit sitovka. Ale ve vasem pripade jsou to zrejme vyhozene penize. Jako mnohem levnejsi a velice spolehlive a bezproblemove karty pouzivam Intel PRO PCI 10/100

jurasek

[Flegmosmoke]

Tak problém opravdu nebyl v routeru! Ale v rušení spoje.. Stejně děkuji všem za příspěvky a snahu poradit! Dozvěděl jsem se spoustu nových věcí...

[Opičák]

Takže provider konečně začal opravdu hledat i u sebe?