xchaos
Samozvany gubernator
Registrován: 13.05.2002
Příspěvků: 3362
Team Member: MOD |
Jo, novou verzi by to chtělo, pár malých bugů je opravených, jenže jsem líný přepsat to z toho MARK na CLASSIFY (tedy, což o to, přepsat je to triviální, ale jsem líný testovat jestli to skutečně funguje...).
Počet connections na IP nebo na uživatele je velmi rozumný požadavek :-) geniálně by řešil třeba viry. Bohužel, není to tak jednoduché - vůbec netuším jestli něco takového ip_conntrack v kernelu umí a jestli ano, tak netuším jaké je k tomu API. Jinak u nás jsme to vyřešili rozložením QoS a NAT na 2 stroje - a i když ten kde běží QoS je cca 2x výkonější, tak při cca 30 Mbps/10 kpps, 2000+ IPček ve skoro 700 třídách je zatížení systému až 90%, zatímco NATovací stroj je vytiížený jen na 10-20%. Takže NAT překvpivě problém není: problém jsou požadavky algoritmu QoSu (HTB) ve chvíli, kdy se linka začíná opravdu zaplňovat.
Někam ukládat ty údaje, o tom jsem uvažoval - v zásadě by obnovu stavu počítadel dat v iptables (se kterými prometheus pracuje) mělo zvládat iptables-save/iptables-restore s nějakým extra parametrem. (V zásadě přepsání promethea aby pracoval s efektivnějším iptables-save je taky požadavek, který existuje dokonce i v rámci firmy, a když už se s tím bude pracovat, tak asi není problém tenhle formát dat použít i na uložení stavu mezi jednotlivými starty...).
Trochu to souvisí s nejčastějším požadavkem - totiž že většina ISP chce pouště Promethea několikrát denně, a oshapovat lidi okamžitě po vysosání denního limitu - ovšem to vázne i na tom, že mnohonásobné volání tc není vůbec efektivní a trvá spoustu minut, zvlášť na vytíženém routeru. (Řešením by bylo použít libqos nebo kdyby existovalo nějaké "htb-save, htb-restore", což ale pokud vím neexistuje.)
zdenek_dc: relative-limit je trochu obsolete na páteři která má dost kapacity, tam by bohatě stačilo relative-prio, které je daleko vychytanější a více bližší filosofii htb (v začátcích jsem ovšem o významu parametru prio ani nic nevěděl). Ovšem relative-limit je značnou nutností u sítí, které mají hodně propustnou linku, ale klienty přitom agregované na Wi-Fi APčkách: tam je pro změnu neetické, aby sosáci omezovali lidi, kteří platí úplně stejně, ale mají nižší nároky na využití kapacity sítě, a v podstatě jinak než shapování se to moc vyřešit nedá - v okamžiku, kdy na samotné bráně je pořád volno, a "dopravní zácpa" vzniká až po cestě...
__________________
|
05.06.2007 v 09:31
