Traffic shaping op VPN tunnel, beide kanten?

[Verwijderd]

Tja, lijkt een simpele vraag. Ik ga twee sites met elkaar verbinding via VPN. Ik wil een paar regels op de tunnel gaan toepassen op protocol niveau en de maximale bandbreedte instellen. Moet ik dit nu doen aan kant A én kant B of is één van de beide genoeg? Ik kom er even niet meer uit namelijk...

[Koffie]

Wat je er aan KantA in duwt, kan KantB nooit meer zijn.
Echter indien in je resticties legt op KantA kwa verzenden, zal dat KantB er niet van weerhouden om meer te verzenden.

WIl je het goed dichttimmeren moet je dus een packetshaper aan biede kanten van de tunnel neerzetten.
Da's toch niet zo'n moeilijke redenering

Als er vanwege smoggevaar , maar een beperkt aantal auto's per uur door de Coentunnel mogen, zet je toch ook aan beide kanten verkeersregelaars ?

[Countess]

simpler gezegt : je kan dus alleen de upload regelen.

download KAN ook maar dan moet je packets gaan droppen, en das zonden.

welk OS gebruik je?
als het linux is kan ik je HTB vanharte aanraden. om te shapen

[ Voor 9% gewijzigd door Countess op 12-08-2003 12:08 ]

[Verwijderd]

Als ik op site A een Cisco 1721 neerzet en die de tunnel laat shapen geld dit toch ook voor het inkomende verkeer? Of zie ik dat verkeerd? Het is toch één tunnel? De Router zorgt er toch gewoon voor dat de andere kant niet sneller kan verzenden?

Wil kant B wat verzenden, moet hij contact leggen met kant A. Als deze niet meer aanneemt kan kant B toch niet sneller verzenden? Of zie ik het niet goed?

[ Voor 25% gewijzigd door Verwijderd op 12-08-2003 14:58 ]

[Koffie]

Klopt, alleen gaan die pakketjes wel over je tunnel heen, waar ze er aan de andere kant achterkomen dat je aan het shapen bent.

Da's hetzelfde als op de server zeggen "Mailtjes groter dan 5 Mb verwijderen uit de inbox" , bij sommige software wordt die mail dan verwijderd, echter pas als die in zijn geheel binnen is

[Countess]

het shapen van inkoment verkeer geeft veel meer overhead. (dat heet trouwens Policing en geen shaping meer, inkomend verkeer kan je namelijk geen vorm geven)

B send een packetje naar A, A neemt dit niet aan omdat de limit is bereikt.
even later probeert B nog een keer. en krijgt weer geen andwoord.
en weer later probeert hij het weer, en nu mag hij wel.
dat zijn dus al 2 extra packetjes (3kbit max normaal) over je tunnel die helemaal niks bijdragen.
hoe lager je de limit legt tenopzichte van de echte bandbreedte hoe vaker dit zal voorkomen, en als bandbreedte schaars is, kan dit onacceptable zijn.

het werkt dus wel.
maar is nogal rommelig, verspillend en een niet erg elegante oplossing.
eigenlijk moet je het alleen overwegen het zo te doen als het bijna niet anders kan.

edit : reqfilr, die eerst zin klopt niet helemaal.
inkomend en uitgaand verkeer worden apart geshaped (met full deplex zitten ze elkaar toch niet in de weg)
kan zijn dat je router je de mogenlijkheid geeft om up en down samen te voegen en een totale limit in te stellen, maar dat doet hij dat software matig en gebruikt hij voor up and down 2 verschillende manieren van shapen (of shapen en policing eigenlijk)

administratief is het makelijk alles op 1 plek te shapen natuurlijk, maar als bandbreedte echt schaars is zou ik er toch voor het shapen om alleen het upload verkeer te shapen. en dan echt op de machine van de site zelf

[ Voor 22% gewijzigd door Countess op 12-08-2003 19:01 ]

[Koffie]

Countess schreef op 12 augustus 2003 @ 18:55:
het shapen van inkoment verkeer geeft veel meer overhead. (dat heet trouwens Policing en geen shaping meer, inkomend verkeer kan je namelijk geen vorm geven)

B send een packetje naar A, A neemt dit niet aan omdat de limit is bereikt.
even later probeert B nog een keer. en krijgt weer geen andwoord.
en weer later probeert hij het weer, en nu mag hij wel.
dat zijn dus al 2 extra packetjes (3kbit max normaal) over je tunnel die helemaal niks bijdragen.

Geen praktijk ervaring met die dingen, maar zou een goede shaper/policy daar niet iets mee doen (bijvoorbeeld al bij de voordeur tegen houden) ?

[Countess]

nee, een pakketje wat over de limit is word helemaal ontvangen door de netwerk kaart maar daarna door de OS niet meer verwerkt. zoiets als een pakketje bij de voordeur aan nemen en het dan laten vallen. het heet ook droppen.
de netwerk kaart zal ook geen ACK reply sturen (een ACK is een acknowlage packetje, het zegt tegen de andere kant, ja pakket goed ontvangen, stuur de volgende maar)

dit doen ze omdat dat precies is wat er gebeurt als een netwerk kaart meer data moet ontvangen dan het aan kan. dan weet de andere kant van, hee fff langzamer aan want de andere kant kan niet zo snel verwerken.

http://lartc.org/howto/lartc.qdisc.html
als je het 9.1 gedeelte leest geven ze een iets uitgebreidere beschrijving van wat er gebeurt en hoe het werk. wel in het engels.

[ Voor 15% gewijzigd door Countess op 12-08-2003 20:29 ]