Új hozzászólás Aktív témák

• #6313 crok Topikgazda Akiii #6311

  Új Válasz 2014-04-12 16:55:37 #6313

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  crok

  Topikgazda

  válasz Akiii #6311 üzenetére

  A torrent baromi aggresszív tud lenni, lévén tompítatlanul zúgathatja a
  forgalmat (erre lett kitalálva: minél gyorsabban minél több helyre jusson
  el az adat). A torrentben nem cink a csomagdobás, nem szabályozódik
  a sebesség mint egy TCP alkalmazás esetében. Lehet a PPP keepalive
  nem fér be vagy DSLAM oldalon eldobódik mert már nem fér be a keret.
  Ilyen esetben ADSL-nél a DSLAM oldalon tudnál érdemben kezdeni valamit
  egress traffic controllal (police vagy shape).

  @Ferke: a traffic shape az ügyféloldalon segíthet de csak az upload
  irányt tudod így befolyásolni (egyébként se lehet shape-elni csak kifelé).
  TCP alkalmazásokra így lehetsz hatással, másra sajnos nem.

  Amivel hatni tudsz a dologra az az, hogyha csinálsz egy inbound service-
  policy-t amiben match-elsz a torrentre (NBAR.. ugye az nem olyan jól
  ismeri fel a torrentet, a titkosítottat meg méginkább nem..) és police-
  olod mondjuk 8Mbps-re (police-olni tudsz ki- és befelé is). Így talán jobb
  a helyzet, ám ha a DSLAM felől (tehát a peer-ektől) mindenképp nagyon
  sok a packet akkor ezt is megölheti sajnos de legalbb less likely.. csak
  marad az a 2Mbps az interface-eden, ha addig eljut a nem-torrent adat
  (pl. PPP keepalive, HTTP, DNS, megamikell'..)akkor minden okay - lehet.
  [Szerk.]
  Ja igen, IOS upgrade mehet 15-re esetleg, abban az NBAR kicsit már jobb.

• #6312 FeRkE őstag Akiii #6311

  Új Válasz 2014-04-12 07:32:54 #6312

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  FeRkE

  őstag

  válasz Akiii #6311 üzenetére

  Traffic shape a modem felé néző interface-re.

Új hozzászólás Aktív témák