Merking av VPN-porten prioriterer ikke taleanrop

Å merke UDP-porten til VPN-en som høy prioritet er den vanligste QoS-endringen for tale, og den skiller ikke et anrop fra filoverføringen som deler samme tunnel. Begge strømmene går ut gjennom samme krypterte socket. Merket forteller neste hopp at alt betyr like mye, noe som er det samme som å ikke fortelle det noe. Det som beskytter et anrop, er en pålitelig klassifisering før kryptering pluss en kø du faktisk kontrollerer.

Tunnelen skjuler strømmen du ville klassifisere

Kryptering erstatter de indre hodene med ett ytre hode per tunnel. Etterpå viser tale og sikkerhetskopitrafikk samme kilde, destinasjon og transportport, så en klassifiserer basert på tunnelporten kan ikke skille dem. Uansett hva du fremmer, fremmer du det samlet.

En DSCP-verdi som startprogrammet setter, overlever bare hvis noe kopierer den utover. OpenVPN 2.6 har passtos, dokumentert med IPv4-omfang; IPsec bruker sin egen kopierings- eller tilordningspolicy ved tunnelgrensen. Uten det trinnet merkes den ytre pakken med hvilken som helst standardverdi tunnelgrensesnittet bruker, og køen lenger ned får aldri vite at det er et anrop inni.

Kopierte merker fortjener samme mistanke som enhver klientlevert verdi. En arbeidsstasjon kan kreve ekspedert videresending for en sikkerhetskopijobb, så adgang og merking på nytt ved tillitsgrensen hører hjemme i designet før merket blir trodd.

Prioritet teller bare der køen dannes

En mettet oppstrømslinje er det som gjør en god kodek til en robotaktig stemme, og køen som fylles, er vanligvis i tilgangsenheten eller i leverandørens buffer. Å forme den utgående veien til den brukbare hastigheten, minus tunnel- og lenkekostnader, er det som holder køen på maskinvare du administrerer, i stedet for i noen andres buffer.

Rettferdig køing og aktiv køstyring hjelper selv uten taleklasse, fordi de hindrer én stor strøm i å fylle bufferen. CAKE på Linux samler forming, rettferdighet per strøm og valgfrie Diffserv-klasser i én qdisc, og den utrullede nettverksansvarlige bør eie den konfigurasjonen i stedet for et andre konkurrerende køoppsett. Uten forming venter en klasse som overgår bulk-trafikk, fortsatt bak en buffer som allerede er full.

Behandling av inngående trafikk er ikke ubrukelig, men den virker etter at pakken har krysset mottakslenken. Den kan påvirke en responsiv avsender og kan ikke refundere forsinkelse som allerede er brukt oppstrøms, så det er en demping og ikke en garanti.

Hva som overlever på det åpne internettet

Diffserv-arkitekturen beskriver behandling innenfor administrative domener, og derfor kan en leverandør ignorere eller skrive om et merke ved en grense. Den motsatte påstanden, at hvert nett alltid fjerner det, er like ubegrunnet. Det ærlige spørsmålet er hva denne konkrete veien er kontraktsfestet og overvåket til å gjøre. Test det med en merket probe i stedet for å gjenta en regel du leste et sted.

Spør hva leverandøren gjør med klassen, og mål det så. Et merke som bevares men ikke planlegges, er dekorasjon; en vei som planlegger uten å se merket, er et annet problem, og de to trenger ulike rettelser.

En måleplan som isolerer trinnet

Ta ett vanlig anrop med en kontrollert konkurrerende opplasting, og gjenta det så på en kablet linje. Se på hva anropet mistet, hva klassetellerne registrerte, og hvor nær grensesnittet går sin reelle grense i stedet for planens annonserte hastighet.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

Hvis telleren for taleklassen blir stående på null, er klassifisering eller merkekopiering i stykker, og ingen mengde prioritet hjelper. Hvis klassetelleren beveger seg lokalt mens forsinkelsen fortsatt stiger, ligger flaskehalsen utenfor gatewayen din. Ingen av de to resultatene rettes ved å heve prioritetsverdien.