QoS na VPN tunelu přes internet (pomocí broadband kruhů)?

VPN
1

Ahoj!
Kolik z vás používá řízení toku dat přes IPSEC VPN tunely přes internet (pomocí kabelových/DSL broadband kruhů)?

Například, předpokládejme, že mám gigabitový ethernet port na svém routeru/firewallu směřujícím k ISP, ale zakoupil jsem pouze 50 Mb/s přenosové rychlosti.

V minulosti bych připojil tvarovač a v rámci tohoto tvarovače implementoval nějaký typ frontování (voip nejdříve, poté vše ostatní) spolu s vhodným využitím
triků jako Cisco’s pre-fragmentation, pre-classification, atd. Takže nemluvím o super sofistikované politiky QoS, pouze o něčem velmi základním.

Diskutuji o výhodách a nevýhodách tohoto přístupu a jsem zvědavý, jestli ti, kteří to implementovali, zaznamenali výrazný rozdíl. A pokud ano, jak ho kvantifikujete? Tj., pokud se dívám na 500 lokalit, které to právě teď nemají, stojí za to čas/úsilí/náklady na implementaci?

Několik myšlenek/komentářů/otázek mi přišlo na mysl:

  1. Jsem si vědom, že na internetu nejsou žádná garance ničeho. Ale nějaké QoS je lepší než žádné QoS, že?
  2. Myslím si, že alespoň můžeme kontrolovat, který provoz přenášíme nejdříve, takže máme větší kontrolu nad tím, co je zahozeno, namísto toho, abychom to nechali na ISP?
  3. Nicméně, TCP by se měl přirozeně přizpůsobit (ale ne-TCP pravděpodobně ne)
  4. Pomáhá tvarování s odrazem tunelů? Chápu, že tunely přes kabel/DSL budou více odrážet než tunely přes dedikované okruhy, ale myslím, že rozumná politika tvarování/priority může pomoci -
    i když jen trochu (pokud kontrolujeme, co, kolik a kdy se přenáší, je pravděpodobnější, že keepalives dead peer detection dojdou do konce)
  5. Samozřejmě, to nepomáhá, když ISP přenáší provoz na druhé straně, ale znovu, nějaké QoS je lepší než žádné QoS, že?

Lennie J.
Ženeva, Švýcarsko

2

Můžeš použít QoS/Tvarování, aby ses ujistil, že neposíláš víc, než zvládne tvoje místní nebo vzdálený odkaz, ale nebude to mít žádný dopad na spolehlivost doručení mezi těmito dvěma body.

3

Můj názor je, že to přinese omezený užitek.

Ano, tvůj VoIP paket bude zařazen do fronty nejdříve na té skokové části cesty, ale tvé označení nemá žádný efekt, když prochází přes N skoků tunelu. Kromě okrajových bodů, nikoliv QoS.
Nelíbí se mi tvůj argument “některé QoS je lepší než žádné QoS”, protože je obvykle interpretován jako “no, stačí označit VoIP a nechat všechno ostatní bojovat o místo, jako by bylo 0”, ale v příkladu tunelu můžeš klasifikovat a označit veškerý svůj provoz, ale to nemá žádný efekt kromě na koncových bodech tunelu (a jakákoli síť na obou koncích, která s tím zachází podle),

Možná budeš chtít podívat se na to, jak QoS funguje u tvých platforem v tunelech. Tísňové rozhraní tunelu může mít různé fronty/pokračovací třídy a chování, POTÉ je přepnuto na fyzické rozhraní, kde označení QoS nemají žádný dopad. Hádej, které rozhraní je to, které zažívá zácpu a blokování na začátku fronty.

Proč tunely IPsec padají? Nejprve je třeba pochopit, že toto chování je třeba řešit, než lze říci, zda tvarování bude na toto chování mít nějaký vliv.

QoS přidává hodně složitosti na správu. Musíš zvážit náklady na vytvoření, sledování a údržbu toho proti jednoduše přidání další šířky pásma k uvolnění přetížení, které zažíváš. Pokud mají tvé odkazy dost místa, pravděpodobně si nevšimneš žádného rozdílu s nebo bez QoS (zácpa v čele fronty s hlasovým provozem může být výjimkou, v závislosti na vzhledu tvého provozu)

uprava: Měl bych pravděpodobně poukázat na to, že toto vidím z odlišné perspektivy než většina lidí: nabízíme QoS na naší síti MPLS VPN, která také přenáší telefonní hlas a vysílací video, takže žiji ve světě s příliš velkým QoS a spoustou konkurenčních a měnících se pohledů. Pro síť s malými, dobře definovanými (a zřídka se měnícími) požadavky na QoS, by náklady na QoS pravděpodobně byly mnohem nižší, než jak je popisuji.

4
5

Toto je něco, co jsem udělal pro nasazení MPLS a QinQ s failover IPsec. S tvarovačem na odchozím fyzickém rozhraní. Existuje však několik výhrad.

  1. Rychlost tvarovače musíte nastavit pod rychlostí vašeho okruhu. Frontování nebude vždy fungovat, zejména protože většina připojení coax/DSL nemá CIR.
  2. Pokud máte více tunelů, váš zařízení pro tvarování bude muset podporovat sdílený tvarovač
  3. Software musí podporovat kopírování DSCP do hlavičky tunelu
  4. Pokud jsou vaše tunely založené na směrování (samostatná rozhraní), což je obvykle případ, některé firewallové/směrovací programy to nebudou respektovat, pokud jsou tvarovače nastaveny na internetové rozhraní pro IPsec provoz–softwarové omezení jen na rychlost/QoS na rozhraní tunelu. To narušuje celý systém. Nemá smysl nastavovat malé tvarovače na každý tunel–zoufal bys výkon.
6

Ačkoli nedostáváte výhodu toho, že vaše upstreamová síť respektuje jakékoli diferenciální QoS, je stále důležité tvarovat a přiřadit správnou prioritu na vaše připojení.

Pokud netvarujete, pak vyšší šířka pásma (jako odchozí e-maily nebo nahrávání souborů) by způsobila mikro bursty, které by způsobily více zahození.
Pokud tvarujete, můžete řídit mikro bursty a zabránit jejich dopadu.

7

Přečtěte si o bufferbloat, použijte Google nebo jakékoliv dokumenty IETF. Začněte zde: Diffserv RFC - Bufferbloat.net

Když šifrujete provoz přes síť (MPLS, Frame Relay, Wireless nebo dokonce internet), omezuje to dostupná řešení “QoS”.

Existuje jednoduché řešení, pokud jsou všichni vaši klienti a servery blízko u sebe (<100 ms, záleží na aplikaci). Zahoďte všechny přetížené pakety. Toto je stručná verze konceptu bufferbloat. Pokud je router “zácpa” obvykle drží jakýkoli nový provoz v zásobnících/frontách na routeru, dokud není dostupná šířka pásma. Místo toho, aby tyto pakety uchovával a způsobil další zpoždění, je myšlenkou prostě zahoď všechny frontované pakety.

Pokud je latence mezi konci dostatečně rychlá, dává to smysl. TCP uvidí zahozený paket a zpomalí. Hlas a video přes IP by raději řešili zahozený paket než pakety s dodatečným jitterem (zpoždění způsobené přetížením). Takže pokud je latence <100 ms, nastavte fronty na cca 10 ms a všechno by se mělo skutečně zlepšit.

Pokud můžete, povolte spravedlivé frontování jako součást konfigurace.

Pokud je data šifrována, je to obvykle to nejlepší, co můžete udělat, pokud jsou vaše latence nízké. Pokud jsou vaše latence vysoké, pak je to složitější a je to téměř na celé knize, jak to opravit.

A šířka pásma je vždy dobrá v těchto situacích.