Nové statistiky - rychlost připojení

Dne 2014-11-19 09:57 Upraveno 2014-11-19 10:10

u mě na VDSL lince to odpovídá a ty výkyvy mohou být způsobeny tím že zdejší grafy berou už 2 sekundový interval a hlavně taky mě zmátlo na první pohled ale chce to si vypnout první položku 1-99% aby nemátla. Tyto krátkodobé anomálie ale mouhou být způsobeny i nastavením limitace rychlosti poskytovatelem kdy limit platí jako "průměr" po dobu několika vteřin a krátký špičky pustí plnou rychlostí.

Od fojtp

Dne 2014-11-19 10:09 Upraveno 2014-11-19 10:14

ale moje maximum neklesne pod 65Mbps pri downloadu (upload byl 2x na cca 35Mbps, jinak cca 70Mbps), ty "globalni" statistiky na pozadi mam vypnuty..

http://www.imagehosting.cz/?v=uploadggg.png
http://www.imagehosting.cz/?v=downlodsd.png

Od digiman (>)

Dne 2014-11-19 10:16 Upraveno 2014-11-19 10:26

U UPu mam taky špičky které jsou téměř 2x takové než kolik mi může dát linka. Jsem zvědav jak bude měřit novou linku co si nadělím pod stromeček :twisted:

to bych asi z 1Gb/s linky vytáhnul 1,5Gb/s :twisted:

Edit1: teď mě napadá, že ta anomálie rychlostí může být dána komunikací se se servery poskytovatele kde ten limit není

Od Jan Čermák (>>)

Dne 2014-11-19 10:51

Důvody tady už zmínil digiman - je například možné, že za to může implementace QoS u poskytovatele. Jak bylo popsáno v článku, měření probíhá jednoduše tak, že se za maximální rychlost považuje maximum z nějakých dvousekundových okének a sleduje se veškerý provoz, který teče přes WAN. Pokud tedy dojde k nějaké anomálii (QoS naskočí po delší době než 2 s, přes WAN tečou data z nelimitované cachovací proxy u poskytovatele apod.), nemáme šanci to podchytit.

Od fojtp

Dne 2014-11-19 11:22

jestli se to tak chova i u ostatnich "turrisaku", tak bych rekl, ze ty statistiky jsou "k nicemu" a radsi bych je vubec neuvadel..

Od Jan Čermák (>>)

Dne 2014-11-19 13:08 Hlasů 1

Na jiných routerech, u kterých známe parametry připojení, jsme toto chování nepozorovali a statistiky byly v souladu s očekáváním. Jinak bychom je samozřejmě neuváděli.

Od JFila

Dne 2014-11-19 14:58 Hlasů 1

Proč neuvádíte v globálních statistkách přenesená data? Poskytovatel "běduje" nad naším trafikem, rád bych hodnoty porovnal s průměrným Turristou.

Od Jan Čermák (>>)

Dne 2014-11-19 17:33 Hlasů 1

Myslíte absolutní hodnoty objemů dat? Ty uvádíme, je to hned první graf - jen je pro tyto účely poněkud neprakticky vykreslen - musíte si najet nad konkrétní datum/čas, abyste viděl absolutní hodnotu. Průměrného Turristu pak dostanete vydělením této hodnoty cca 1000, včera to bylo třeba 6,8 GB na router. Pokud byste ale chtěl další statistické informace i tam (třeba právě nějaké kvantily), tak to možné bohužel není, ani to neplánujeme.

Od JFila

Dne 2014-11-19 18:59

Aha, moje chyba. Nebylo by možné data zobrazovat v lepších jednotkách (ale jinak nic proti Bajtu)? A co třeba zveřejňovat maximální a minimální grafy hodnoty Turristů. Hodnoty to jsou jednoho uživatele ale nikdo nebude tušit kterého. Ad souboj IPv6 vs IPv4, 0,5 %(IPv6) a 0,8 %(IPv6 tunel) je to možné? Myslel jsem, že IPv6 už představuje vetší podíl provozu (doma jsme nedáno oslavili nadpoloviční většinu přenesených dat prostřednictvím IPv6 tunelu než po čtyřce).

Od czlada

Dne 2014-11-19 19:29 Hlasů 1

S tím zobrazováním velikosti souhlasím, kolikrát je to nekonečné propočítávání. Ohledně toho provozu bych řekl, že ty statistiky IPv6 klesají jelikož hodně lidí jej prostě nemá.
Málokdo to potřebuje a zprovozňuje alespoň tunel. Já nedávno zrovna řešil přechod na v6 . ISP má přiřazené IPv6, akorát to prostě nepotřebuje dávat do provozu a ani datum zprovozňování jej nezajímá :) Hlavně že si nedávno "nafasoval" blok IPv4. Prozatím alespoň tunel.

Od Jan Čermák (>>)

Dne 2014-11-21 16:11 Hlasů 3

Dnes jsme pustili ven pár drobných úprav v grafech - mezi nimi i přepočítávání násobků jednotek nebo možnost přepnout procentuální graf v globálních statistikách na graf s absolutními hodnotami. V plánu to bylo už dlouho, ale čas se na to našel až nyní :)

Od NONES

Dne 2014-11-21 20:41

Super - po delší odmlce se teďko s novinkami přímo "roztrhl pytel". Tak se mi to líbí - máte u mne palec nahoru.

Od David K.

Dne 2014-11-24 18:20

asi by to chtelo este orezavat nejake spicky, z "beznych" 6.8 gb dosahuju trosku vetsich hodnot konkretne na cca 65gb/den down a cca 6-5gb/den up, a nebo pak napr minuli tyden 83 gb upload v jeden den, vetsina z toho je IP tv kterou tezko odfilturju pripadne kdyz by nekdo poradil jak tak muzu ale sam nevim jak na to

Od Jan Čermák (>>)

Dne 2014-11-25 10:19

Trochu se zde míchají jablka s hruškama - v tomto tématu se řeší statistiky rychlosti, vy zjevně mluvíte o statistikách přenosu dat. Ve Vašem případě "problém" asi nepůjde řešit - pokud přes WAN teče nějaký provoz, už nerozlišíme, zda se jedná o IPTV Vašeho poskytovatele nebo přenos z/do internetu (i proto, že to z námi sledovaných údajů prostě nejde, tohle už by bylo na DPI). Je možné, že ta IPTV může za ten enormní download, ale nevidím důvod, proč by měla vytvořit 83 GB upload - ten by měla mít minimální, takže bych problém hledal jinde (díra v systému, upload mezi uživateli v rámci sítě poskytovatele apod.).

Nicméně jsem si všiml, že u Vašich statistik jsou i další podivnosti, zejména u zablokovaných paketů na FW (blokujete pakety pro IPTV) - pokud to chcete řešit, napište mi na jan.cermak@nic.cz, jak máte síť přesně zapojenou a nakonfigurovanou a podíváme se, co by se s tím dalo dělat.

Od fojtp

Dne 2014-11-19 15:09

ok, tak tam bude lehka statisticka chybicka ode me ;-)

Od JFila

Dne 2014-11-19 15:37

Pokládám si tedy občas filozofickou otázku "Co je normální?".

Od lzita

Dne 2014-11-21 00:59

Jsem připojen přes "ubohé" ADSL a upload i download odpovídá.......

Od NONES

Dne 2014-11-21 20:40

Mě to také sedí - download přesně, upload jakž takž.

Od Michal Vaner (>>)

Dne 2014-11-19 15:10

Dobrý den

Na to, aby se to chovalo takto by musela být defaultní routa jak v tom tunelu, tak přímo na WAN. Umím si takovou situaci představit, ale asi není úplně obvyklá.

Případně, uměl bych ručně udělat takovou konfiguraci ucollectu, aby se to takto chovalo. Ale hádám, že do té jste nezasahoval.

Co je to za tunel?

Od milanroubal (>)

Dne 2014-11-19 16:04

Tak to bych řekl, že mám. Používám pro rozdělování trafficu script multiwan, který je nakonfigurován tak, aby data pro několik tisíc IP rozsahů poslal místo na ethernetové WAN rozhraní do openvpn tunelu, který pak ústí v jiném státě. Pro router se to má tvářit tak, že má vlastně 2 různé veřejné IP adresy, každou v jiném státě. A ten multiwan pokud je mi známo značkuje každý paket podle pravidel a pak pro každou značku má vlastní defaultní routu.

Od Michal Vaner (>>)

Dne 2014-11-20 11:24

Pak se vám opravdu ten traffic bude zobrazovat jakoby dvakrát, jednou jako paket uvnitř tunelu a jednou jako ta zašifrovaná data. S tím se dá, bohužel, dělat velmi málo (snažit se nějak automaticky poznávat ty pakety, které nesou to openVPN je poněkud těžší problém a určit, že je to zrovna to openVPN, přes které leze také defaultní brána, už asi ani nejde).

Co by v takovém případě šlo udělat je vyřadit ten „vnitřek“ z analýzy, tím že by se vypnula autodetekce WAN rozhraní v ucollectu. Ale pak to zase nebude mít moc šanci vidět cokoliv zajímavého v té tunelované komunikaci. Takže asi nechám na vás, jestli dáte přednost přesnějším statistikám rychlosti, nebo možnosti chytit útočníka, co leze tunelem.

Pro vypnutí autodetekce a nastavení, které rozhraní se má použít pro zkoumání dat se můžete inspirovat tímto /etc/config/ucollect. Těch sekcí pro rozhraní tam může být více.

config wan wan
  option autodetect 0

config interface
  option ifname 'eth2'

Od milanroubal (>)

Dne 2014-11-20 12:41

Děkuji za vysvětlení. Ještě jeden dotaz - jak se to bude chovat v případě tunelovaného IPv6 přes Sixxs? Také se to bude zobrazovat 2x?

Pro opravu by snad stačilo vyhodit ty 2 IP adresy, tedy konec VPN tunelu a konec Sixxs tunelu z toho monitoringu, pak by to mělo fungovat tak, jak se očekává. Jen mám trochu strach se do toho rýpat, neboť pro Turris platí jedno zlaté pravidlo - na monitoring se nesahá :) Vnitřek bych z analýzy vyřazoval velmi nerad, to raději oželím přesnější statistiky.

Od Michal Vaner (>>)

Dne 2014-11-20 13:04

Dobrý den

Teď si nejsem úplně jistý, ale myslím, že SixXS je jeden z těch tunelů, které to zvládá. Jednak je nešifrovaný, takže je vidět dovnitř toho tunelu a lze tedy zkoumat ty pakety uvnitř. Jednak, tyto průhledné tunely se autodetekce snaží přeskakovat, tedy by se neměly zkoumat dvakrát.

Od milanroubal (>)

Dne 2014-11-20 13:37 Upraveno 2014-11-20 14:29

Tak jsem to zkusil omrknout, podle ucollect.init se zdá, že to sixxs nezahazuje. Alespoň já mám v souboru /tmp/ucollect/ucollect všechny 3 interface, eth2, sixxs0 a tap0.

Tak to nezahazuje proto, ze pro IPv4 route -n ukaze obe defaultni brany, nebot kazda zvlast je videt jen v pripade prikazu
ip route show table 171
a
ip route show table 172
coz je tedy zalezitost toho multiwan scriptu.

V pripade IPv6 to ten tunel nezahazuje proto, ze interface sixxs0 nemam vubec v UCI :). A pro ty, kteri ho tam maji, jako zde doporucovana konfigurace, tak jejich protocol aiccu nebo tic jim take nepomuze, protoze script jako tunel bere pouze protokoly oznacene 6in4, 6to4, 6rd nebo dslite.

Od Michal Vaner (>>)

Dne 2014-11-24 10:37

Dobrý den

Poslal byste mi, prosím, jak ho nastavujete? A jako jaké rozhraní se potom objeví?

Myslíte, že byste mohl chytit několik paketů toho tunelu (tedy, jak vypadají ty pakety co lezou po fyzickém WAN).

Děkuji

S pozdravem

Od milanroubal (>)

Dne 2014-11-24 13:20

Urcite, to nebude problem. Zkusim to dat behem nejblizsich veceru dohromady.