classic.ISPforum.cz

chtel bych se vas optat na jednu vec, nikde jsem se zatim toho o tom moc nedocetl,
jak by fungovala komunikace po siti, kdyzby se zavedlo nasledujici pravidlo : Cim nizsi pocet paketu v siti z uricte ip adresy (a na) tim vyzsi priorita v QOS

markovani paketu podle mnozstvi paketu z urcite zdrojove/cilove ip adresy
nasledne frontovani do QOS, kde by nejnizsi pocet paketu mel co nejvyzsi prioritu (a obracene).

a v podstate se vyprdnout na l7?

V praxi by to fungovalo, jak dobre se chovas k siti (cim mene ji zahlcujes), tim lepe ti pojede (nizsi latence) v pripade zahlceni.

Jak by se to chovalo v praxi ?

Je to vyplod me bujne predstavivisti, chtel bych znat vas nazor.
Je to hovadina?

vsechny QOS fronty by byly typu pcq.src nebo pcq.dst

No clovece, to by nabilo spatny tohle nejakym zpusobem zprovoznit, byl by to celkem dobry bic na stahovace.....
To by se mi taky libilo mit to takhle nastavany......

rozchozeni neni az takovy problem, ba naopak, navic by to melo i efekt v tom, ze by se snizila zatez masin (pravdepodobne) .

Otazkou je, jaky by to melo negativni efekty.

Nastaveni nejakeho packet rate pro paketmarky p2p by asi nebyl problem nevim ja to neresim jen connlimity.

Maxik píše:Nastaveni nejakeho packet rate pro paketmarky p2p by asi nebyl problem nevim ja to neresim jen connlimity.

Mam pocit ze prave vela malych paketov zasiera APcka. Ked pozeram statistiku na R52jke s prevadzkou 1200 kbps down a 370 kbps upload tak pomer paketov na tom interface je 140 / 120 pps. A toto neni dobre... Snazim se to resit do obmedzenim connection ale to je dobre jen do urcitej urovne.

preto by som chcel vediet, ze ako viem obmedzit prevadzku malych paketov... Alebo obmedzovat rychlost nie na bity ale na pocet paketov/s

pocet paketu lze detekovat, omarkovat a nasledne zahazovat nebo radit do nizsich Q .
Je otazkou jaka je ta spravna hladina, aby komunikace, ktera ma byt prioritizovana, se nedegradovala.
Dobre je to navic zkombivonat s velikosti paketu.

zrovna v vcera jsem se setkal s tim, ze mi klient bombardoval sit jak pres UDP, tak i TCP. Ve vysledku 90% jeho komunikace delal torrent, ale sifrovanej, ..... sajrajtus

reset píše:zrovna v vcera jsem se setkal s tim, ze mi klient bombardoval sit jak pres UDP, tak i TCP. Ve vysledku 90% jeho komunikace delal torrent, ale sifrovanej, ..... sajrajtus

a co s tím když je to šifrované spojení?

Na takove hodne klienty pouzivam to, ze je pripisu na seznam podle ktereho se jim premarkuje ostatni - tam bohuzel spadne i sifrovanej torrent na p2p a na nem mam connlimit a nazdar.

to jsem kdysy mel na siti taky, jakmile nekdo zacal pouzivat p2p site, dynamicky se hodil do seznamu a pak jeho komunikace byla hodnocena jako p2p, .... vliv to na nej melo predevsim, kdyz zacal byt pretizenej inet.
Jenze to ma mensi nevyhodu v tom, kdyz ma doma nekdo nat (jako rodina) a synacek si pustil p2p klienta, pak vsechni sli do haje (na conn limit pujdou tak jako tak, kdyz to prepisknou). V realu mi tohle pravidlo slapalo dobre, ale nelibi se mi to.
Zacal jsem upravovat pravidla tak, aby sly pouzivat jak p2p, tak vsechno ostatni.
Diky packet limitu to jsem schopnej celkem uspesne zpomalovat. Je mi v podstate jedno, jestli klient pouziva i sifrovane p2p site a zaroven telefonuje, vse by melo fungovat bez problemu. Jeste to doladuju.
Moje nova pravidla funguji i velmi dobre treba i na tahani pres ssh, kde je nejvyzsi priorita (pri tahani se priorita snizuje).

Kolik máš nastavený ten paket limit? Osobně totiž řeším ve špičce 9500 konekšnů.