Bit-torrent a RouterOS
Napsal: 16 Jul 2007 15:31
Už delší dobu se potýkám s protokolem bit-torrent. Jeho užívání způsobuje na routerech značné problémy. Otevírá velké množství spojení
řádově tisíce na uživatele bit-torrentu. A hlavě po sobě spojení ani neuzavírá. Následkem je 100% vytížení CPU routerboardu při datovém toku 5 Mbit/s. Tento datový tok vysosají uživatlé výměnných sítí a na běžného uživatele potom zbyde jen pohled na pomalu se načítající webovou stránku . Problém se hlavně projevuje, na routeru kde je uživatel bit-torrentu připojen i když jeho spojení procházejí i routerem před ním, ale ten slouží jako retranslace a všesměr, tzn. že je na něm ještě více klientů a není zdaleka tak vytížen jako router za ním. Z toho soudím, že routeru dává zabrat udržet veké množství spojení na anténě s více klienty oproti PtP spoji. Nebo je možné že je to tím, že všesměry jsou v modu AP-bridge a PtP spoje v mode Bridge?
Řesení problému:
Vyzkoušel jsem toho už hodně, ale nic nebylo efektivní ba nekdy i horší než lepší. Napiši sem pár věcí, které jsem již vyzkoušel, možná někoho napadne jak to vylepšit nebo udělat jinak. Na všech routerech používám RouterOS!
Nějaký QOS na routeru kde je uživatel připojen se vůbec neosvedčil, protoze jakákoli pravidla ve firewallu routeru akorád přitíží a navíc v ip/firewall/mangle sice mohu znackovat packety P2P dokonce i samotných torrentu, ale ne se 100% učinností. Označkují se jen nějaké a zbytek se tváří jako jiný druh taficu a z routeru odchazí vesele dál pod jinou prioritou než P2P. Navíc nelze definovat max. propustnost, protože když je router bez bit-torrentu je schopen přenést 14 Mbit/s a s bit-torrentem 5 Mbit/s takže QOS nemůže fungovat správně.
Dále jsem zkoušel omezovat počet spojení na jednoho uživatele na 200 a to pravidlo bylo také hodně náročné na CPU. A hlavně ani moc nefungovalo.
Pak jsem zkoušel v ip/firewall/connections/tracking změnit parametr TCP Established Timeout na 2h misto 24h to počet spojení snížilo, ale stejně jich bylo pořád moc.
Pak jsem také zkoušel nastavit ve firewallu na hlavním routeru pravildla ze uživatel s vice spojeníma než 200 bude zařazen do skupiny, kde jsou povoleny je nějaké základní porty. A poté co spojení uvolní bude zařazen zpět do normální skupiny. To se také neosvědčilo, protože uživateli se sice omezil provoz, ale torrent protekal pořád, ale pouze pomaleji. Routerům se nijak neulehčilo.
Poslední věc kterou jsem proti torrentu vymyslel funuguje na 100%, ale zakazuje torrent úplně a donutí uživatele aby ho nepoužíval. Ale to nechci, ale v současné době nemám lepší řešení.
Hlavně uživatelům typu BFU a Lamy se to moc nelíbi, protože pod slovem stahovani si představuji jen Torrent.
Obdivuji toto kdo tento příspěvek dočetl až sem:)
A budu rád když někdo přispějete nějakým nápadem nebo radou.
řádově tisíce na uživatele bit-torrentu. A hlavě po sobě spojení ani neuzavírá. Následkem je 100% vytížení CPU routerboardu při datovém toku 5 Mbit/s. Tento datový tok vysosají uživatlé výměnných sítí a na běžného uživatele potom zbyde jen pohled na pomalu se načítající webovou stránku . Problém se hlavně projevuje, na routeru kde je uživatel bit-torrentu připojen i když jeho spojení procházejí i routerem před ním, ale ten slouží jako retranslace a všesměr, tzn. že je na něm ještě více klientů a není zdaleka tak vytížen jako router za ním. Z toho soudím, že routeru dává zabrat udržet veké množství spojení na anténě s více klienty oproti PtP spoji. Nebo je možné že je to tím, že všesměry jsou v modu AP-bridge a PtP spoje v mode Bridge?
Řesení problému:
Vyzkoušel jsem toho už hodně, ale nic nebylo efektivní ba nekdy i horší než lepší. Napiši sem pár věcí, které jsem již vyzkoušel, možná někoho napadne jak to vylepšit nebo udělat jinak. Na všech routerech používám RouterOS!
Nějaký QOS na routeru kde je uživatel připojen se vůbec neosvedčil, protoze jakákoli pravidla ve firewallu routeru akorád přitíží a navíc v ip/firewall/mangle sice mohu znackovat packety P2P dokonce i samotných torrentu, ale ne se 100% učinností. Označkují se jen nějaké a zbytek se tváří jako jiný druh taficu a z routeru odchazí vesele dál pod jinou prioritou než P2P. Navíc nelze definovat max. propustnost, protože když je router bez bit-torrentu je schopen přenést 14 Mbit/s a s bit-torrentem 5 Mbit/s takže QOS nemůže fungovat správně.
Dále jsem zkoušel omezovat počet spojení na jednoho uživatele na 200 a to pravidlo bylo také hodně náročné na CPU. A hlavně ani moc nefungovalo.
Pak jsem zkoušel v ip/firewall/connections/tracking změnit parametr TCP Established Timeout na 2h misto 24h to počet spojení snížilo, ale stejně jich bylo pořád moc.
Pak jsem také zkoušel nastavit ve firewallu na hlavním routeru pravildla ze uživatel s vice spojeníma než 200 bude zařazen do skupiny, kde jsou povoleny je nějaké základní porty. A poté co spojení uvolní bude zařazen zpět do normální skupiny. To se také neosvědčilo, protože uživateli se sice omezil provoz, ale torrent protekal pořád, ale pouze pomaleji. Routerům se nijak neulehčilo.
Poslední věc kterou jsem proti torrentu vymyslel funuguje na 100%, ale zakazuje torrent úplně a donutí uživatele aby ho nepoužíval. Ale to nechci, ale v současné době nemám lepší řešení.
Hlavně uživatelům typu BFU a Lamy se to moc nelíbi, protože pod slovem stahovani si představuji jen Torrent.
Obdivuji toto kdo tento příspěvek dočetl až sem:)
A budu rád když někdo přispějete nějakým nápadem nebo radou.
.