Markering af VPN-porten prioriterer ikke taleopkald

Markering af VPN'ens UDP-port som høj prioritet er den mest almindelige QoS-ændring for tale, og den adskiller ikke et opkald fra den filoverførsel, der deler tunnelen. Begge strømme forlader den samme krypterede socket. Mærket fortæller det næste hop, at det hele betyder lige meget, hvilket er det samme som ikke at fortælle det noget. Det, der beskytter et opkald, er en pålidelig klassificering før kryptering plus en kø, du faktisk kontrollerer.

Tunnelen skjuler den strøm, du ville klassificere

Kryptering erstatter de indre headere med én ydre header per tunnel. Derefter har tale og backup-trafik samme kilde, destination og transportport, så en klassificerer baseret på tunnelporten kan ikke skelne dem. Hvad du end fremmer, fremmer du samlet.

En DSCP-værdi, som det oprindelige program sætter, overlever kun, hvis noget kopierer den udad. OpenVPN 2.6 har passtos, dokumenteret med et IPv4-område; IPsec anvender sin egen kopierings- eller mappingpolitik ved tunnelgrænsen. Uden det trin markeres den ydre pakke med den standard, tunnelinterfacet bruger, og køen længere fremme får aldrig at vide, at der er et opkald indeni.

Kopierede mærker fortjener samme mistanke som enhver klientleveret værdi. En arbejdsstation kan kræve ekspederet videresendelse til en backup-opgave, så admission og omarkering ved tillidsgrænsen hører i designet, før mærket bliver troet.

Prioritet tæller kun, hvor køen dannes

Et mættet uplink er det, der gør en god codec til en robotagtig stemme, og den kø, der fyldes, er normalt i adgangsenheden eller udbyderens buffer. Formning af den udgående vej til den brugbare hastighed, minus tunnel- og linkomkostninger, er det, der holder køen på hardware, du administrerer, i stedet for i en andens buffer.

Retfærdig kødannelse og aktiv køstyring hjælper selv uden en taleklasse, fordi de forhindrer én stor strøm i at fylde bufferen. CAKE på Linux samler formning, fairness per strøm og valgfrie Diffserv-klasser i én qdisc, og den udrullede netværksmanager bør eje den konfiguration frem for et andet konkurrerende køopsæt. Uden formning venter en klasse, der overgår bulk-trafik, stadig bag en buffer, der allerede er fuld.

Behandling af indgående trafik er ikke ubrugelig, men den virker, efter pakken har krydset modtagerlinket. Den kan påvirke en lydhør afsender og kan ikke refundere forsinkelse, der allerede er brugt opstrøms, så det er en afbødning og ikke en garanti.

Hvad overlever det offentlige internet

Diffserv-arkitekturen beskriver behandling inden for administrative domæner, hvorfor en udbyder kan ignorere eller omskrive et mærke ved en grænse. Den modsatte påstand, at alle netværk altid fjerner det, er lige så uunderbygget. Det ærlige spørgsmål er, hvad netop denne vej er kontraktligt forpligtet og politimæssigt reguleret til at gøre. Test det med en markeret probe i stedet for at gentage en regel, du har læst et sted.

Spørg, hvad udbyderen gør med klassen, og mål det så. Et mærke, der bevares, men ikke planlægges, er dekoration; en vej, der planlægger uden at se mærket, er et andet problem, og de to kræver forskellige rettelser.

En måleplan, der isolerer trinnet

Kør ét almindeligt opkald med en kontrolleret konkurrerende upload, og gentag det så på et kablet link. Se på, hvad opkaldet mistede, hvad klasse-tællerne registrerede, og hvor tæt interfacet kører på sin reelle grænse i stedet for planens overskrifthastighed.

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

Hvis tælleren for taleklassen bliver på nul, er klassificering eller mærkekopiering i stykker, og ingen mængde prioritet hjælper. Hvis klassetælleren bevæger sig lokalt, mens forsinkelsen stadig stiger, ligger flaskehalsen uden for din gateway. Ingen af de to resultater rettes ved at hæve prioritetsværdien.