QoS na VPN tunelech přes internet (použití broadband okruhů)?

VPN
1

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

Například, pokud mám gigabitový Ethernet port na svém routeru/firewalle facing ISP, ale koupil jsem jen 50 Mb/s propustnost.

V minulosti bych připojil shapér a v rámci tohoto shapéru implementoval nějaký typ frontování (voip nejdříve, pak vše ostatní) spolu s vhodným využitím
triků jako Cisco pre-fragmentace, pre-klasifikace atd. Takže nemluvím o super fancy QoS politice, jen o něčem velmi základním.

Diskutuji o výhodách a nevýhodách tohoto řešení a jsem zvědav, zda ti, kteří to implementovali, zaznamenali nějaký rozdíl. A pokud ano, jak ho měříte? Tj., pokud sleduji 500 lokalit, které to zatím nemají, stojí za to čas/výkon/náklady na implementaci?

Několik myšlenek/dotazů/poznámek mě napadlo:

  1. Vím, že není žádná záruka na cokoli přes internet. Ale nějaké QoS je lepší než žádné QoS, že?
  2. Myslím, že alespoň můžeme řídit, který provoz posíláme jako první, takže máme větší kontrolu nad tím, co je zahozeno místo toho, abychom to nechali na ISP?
  3. TCP by se měl přirozeně přizpůsobit (ale non-TCP pravděpodobně ne)
  4. Pomáhá tvarování s tunely odrážejícími se? Chápu, že tunely přes kabel/DSL se odráží více než tunely přes dedikované okruhy, ale myslím, že rozumná politika tvarování / priorit může pomoci -
    i když jen trochu (pokud kontrolujeme, co, kolik a kdy je provoz přenášen, udržování alive paketů dead peer detekce je pravděpodobnější, že dorazí na druhý konec)
  5. Samozřejmě, to nepomůže, pokud ISP přenáší provoz na druhou stranu, ale opět, nějaké QoS je lepší než žádné QoS, že?

Lennie J.
Ženeva, Švýcarsko

2

Můžeš používat QoS/Shaping pro zajištění, že nepošleš více, než zvládne tvůj lokální nebo vzdálený odkaz, ale nebude to mít žádný vliv na spolehlivost doručení mezi body.

3

Můj názor je, že to bude mít omezený přínos.

Ano, tvůj VoIP paket bude frontován prvně na tomto hopu, ale tvé označení nemá žádný efekt, když se pohybuje přes N hopů tunelu. Kromě koncových bodů, neexistuje žádné QoS.
Nemám rád tvůj argument “nějaké QoS je lepší než žádné QoS”, protože je to obvykle interpretováno jako “takže jen označ VoIP a zbytek nechej, ať si to rozdělí sami”, ale v příkladu tvého tunelu, můžeš klasifikovat a označit všechna svá data, ale to nemá žádný efekt kromě na okrajových bodech tunelu (a jakákoli síť na obou koncích to dodržuje).

Možná bys měl podívat se, jak QoS v tunelech funguje na tvých platformách. Rozhraní tunelu může mít různé fronty/třidy přenosu a chování, PAK je předáno fyzickému rozhraní, kde označení QoS nemusí mít žádný vliv. Hádej, které rozhraní je to, které zažívá kongesci a zablokování na začátku fronty.

Proč tvé IPsec tunely padají? Je třeba to pochopit, než můžeš říct, jestli by tvarování mělo na toto chování vliv.

QoS přidává hodně složitosti na správu. Musíš zvážit náklady na vytvoření, sledování a údržbu versus jednoduše přidání více pásma, aby se uvolnila zátěž, kterou zažíváš. Pokud máš na svých odkazech více než dost, pravděpodobně si nevšimneš žádného rozdílu s nebo bez QoS (zablokování kvůli zpoždění s hlasovým provozem může být výjimka, záleží na tom, jaký máš provoz).

poznámka: Pravděpodobně bych měl poukázat na to, že to vidím z jiného pohledu než většina lidí: nabízíme QoS v naší MPLS VPN síti, která také přenáší telefonní hovory s poplatky a vysílací video, takže žiji ve světě s příliš velkým QoS a hodně konkurenčním a měnícím se názory. Pro síť s malými, dobře definovanými (a málo měnícími se) požadavky na QoS, náklady na QoS by pravděpodobně byly mnohem nižší, než si myslím.

4
5

To je něco, co jsem dělal pro MPLS a QinQ nasazení s IPsec zálohou. S shapérem na vycházejícím fyzickém rozhraní. Existuje však několik upozornění.

  1. Musíš nastavit svůj shaping rate pod rychlost okruhu. Frontování nebude vždy fungovat, zejména protože většina coax/DSL připojení nemá CIR.
  2. Pokud máš více tunelů, tvé zařízení pro shapování musí podporovat sdílené shapování
  3. Software musí podporovat kopírování DSCP do záhlaví tunelu
  4. Pokud jsou tvé tunely založené na směrování (samostatná rozhraní), což je běžné, některé firewally/routingové software nebudou respektovat shapér nastavený na internetovém rozhraní pro IPsec provoz–software bude hledět pouze na rychlost a QoS na rozhraní tunelu. To celý systém naruší. Neexistuje smysl nastavovat malé shapéry na každý tunel–jen tím zničíš výkon.
6

I když nepřinášíš výhodu, že tvá vrchní síť respektuje nějaké diferenciální QoS, je stále důležité tvarovat a přiřadit správnou prioritu na tvém připojení nahoru.

Pokud nebudeš shapovat, vyšší datové toky (jako odchozí e-maily nebo nahrávání souborů) způsobí mikropřerušení, což povede k několika ztrátám.
Pokud shapuješ, můžeš řídit mikropřerušení a vyhnout se jejich vlivu.

7

Přečti si o bufferbloat, používejte Google nebo dokumenty IETF. Začněte zde: Diffserv RFC - Bufferbloat.net

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

Existuje jednoduché řešení, pokud jsou všichni vaši klienti a servery blízko sebe (<100ms, záleží na aplikaci). Zahazujte všechny zahlcené pakety. Toto je zkrácená verze konceptu bufferbloat. Pokud je router “zalcený”, obvykle bude držet nové provozy v sadě bufferů/front, dokud nebude dostupná šířka pásma. Místo toho, aby tyto pakety držel a způsobil další latenci, ideální je prostě zahodit všechny frontované pakety.

Pokud je latence mezi cíli dostatečně nízká, má to smysl. TCP uvidí zahození paketu a zpomalí. Voice a video přes IP by raději řešili zahozené pakety než pakety s přidaným jitterem (zpoždění způsobené zahlcením). Takže, pokud jsou latence <100 ms, nastavte fronty na cca 10 ms, a vše by se ve skutečnosti zlepšilo.

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

Pokud jsou data zašifrována, je to obvykle nejlepší, co můžete udělat, pokud jsou latence nízké. Pokud jsou latence vysoké, je to složitější a je třeba to velmi podrobně analyzovat.

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

8
  1. Vím, že není žádná záruka na cokoli přes internet. Ale nějaké QoS je lepší než žádné QoS, že?

Špatné QoS je horší než žádné QoS.

9

Nová otázka, nemělo by to způsobit šílené zatížení CPU při QoS přes VPN tunel u většiny průměrných Cisco ISR?

10

Heh, z stránky 139:

Při nastavování WAN-edge QoS definujete, jak provoz odchází z vaší sítě. Je zásadní, aby klasifikace, označení a alokace šířky pásma byly v souladu s nabídkou poskytovatele služeb, aby bylo zajištěno konzistentní zacházení s QoS na koncových bodech.

Vzhledem k tomu, že internetový provoz je na straně SP nuceně na nule, divím se, kolik je vlastně vidět rozdílu s QoS v tomto scénáři použití.

11

Proč omezuješ platnost svých předpokladů na zpoždění méně než 100 ms?

12

Technicky vzato správně. Prioritní fronta pro všechny tvé vysokokapacitní toky a VoIP v základní třídě s upraveným RED by pravděpodobně přinesla horší zážitek než žádné QoS.

13

Skvělá otázka. Krátká odpověď: ANO

14

Jediné, co můžeš udělat, je nakonfigurovat svůj router tak, aby řadil pakety odchozím směrem v pořadí a objemu, která dávají největší smysl pro tvůj byznys.

Protože také shapuje na síťové straně (kde má pravděpodobně větší šířku pásma) a dává přednost paketům podle tvé QoS politiky, děláš vše, co je možné, aby se minimalizovala ztráta paketů způsobená nárůstem provozu.

Označení paketů by mělo zůstat nedotčeno během průchodu tunelem DMVPN, takže tvůj router na vzdálené straně by měl přejít k prioritizaci paketů podle tvé celkové architektury.

To je mnohem lepší než žádná struktura nebo organizace. Ale samozřejmě ne tak dobré jako L3 MPLS s carrierem vynucenou QoS politikou uprostřed.

15

S ohledem na zabezpečené spojení, Spojené státy mají přísnou kontrolu exportu silné kryptografie z hlediska technologií i výkonu. Jako u mnoha dalších produktů, i Cisco ISR jsou předmětem této regulace. Aby bylo možné dodržovat tuto politiku, jsou dočasné a trvalé licence Security (SEC) omezené jak na výkon, tak na počet tunelů. Limit je aplikován na kumulativní počet šifrovaných tunelů a současný přenosový výkon. Šifrované tunely jsou definovány jako IPSec, SSL VPN nebo Secure Real-Time Transport Protocol (SRTP). Tento limit je současný 170 Mbps (85 Mbps v obou směrech) a 225 tunelů. Tento limit je vynucen a nelze jej překročit s licencí SEC. Licenc HSEC umožňuje plnou škálovatelnost jak výkonu, tak spojení.

(!) Něco, co mě znepokojuje. Proč je omezen výkon v souvislosti s šifrovanými kanály?

16

Díky za odpověď, ale nemohu otevřít ten zatracený odkaz

17

Jo, je to hloupost.

Ale pokud chceš jet rychleji než 85 Mbps v jednom směru přes šifrovaný tunel, potřebuješ licenci HSEC od Cisco.

Měl bys také zvážit modul ISM na routerech řady 1900, 2900 a 3900, aby se šifrování přesunu provedlo na dedikované CPU.

Licenc HSEC není příliš drahá - asi 300 dolarů za 2951, jestli si správně pamatuji.

18

Měl bys také zvážit modul ISM na routerech řady 1900, 2900 a 3900, aby se šifrování přesunu provedlo na dedikované CPU.

Všechny ISR (určitě 1800/1900 a +) mají vestavěný čip pro odlehčení šifrování, není to prováděno v CPU. Existuje jen několik výjimek (například pokud spouštíš šifrovací algoritmus nepodporovaný čipem).
S výjimkou nižších modelů je omezení způsobeno softwarovým komponentem.
Takže ano, můžeš investovat do ISM/AIM pro lepší výkon, ale ne pro odlehčení CPU per se. :slight_smile: