De VPN-poort markeren geeft spraakoproepen geen prioriteit
De VPN-poort als prioriteit markeren laat het gesprek en de back-up in dezelfde tunnel voorgaan. Spraak vraagt om classificatie vóór versleuteling en een wachtrij die u beheert.
De UDP-poort van de VPN als hoge prioriteit markeren is de meest voorkomende QoS-wijziging voor spraak, en het scheidt een gesprek niet van de bestandsoverdracht die dezelfde tunnel deelt. Beide stromen verlaten dezelfde versleutelde socket. De markering vertelt de volgende hop dat alles even belangrijk is, wat hetzelfde is als niets vertellen. Wat een gesprek beschermt, is een betrouwbare classificatie vóór versleuteling plus een wachtrij die u echt beheert.
De tunnel verbergt de stroom die u wilde classificeren
Versleuteling vervangt de binnenste headers door één buitenste header per tunnel. Daarna tonen spraak en back-upverkeer dezelfde bron, bestemming en transportpoort, dus een classificeerder op basis van de tunnelpoort kan ze niet onderscheiden. Wat u ook voorrang geeft, u geeft het in bulk voorrang.
Een DSCP-waarde die de oorspronkelijke toepassing zet, overleeft alleen als iets die naar buiten kopieert. OpenVPN 2.6 heeft passtos, gedocumenteerd met IPv4-bereik; IPsec past zijn eigen kopieer- of mappingbeleid toe aan de tunnelgrens. Zonder die stap wordt het buitenste pakket gemarkeerd met welke standaardwaarde de tunnelinterface ook gebruikt, en de wachtrij stroomafwaarts leert nooit dat er een gesprek in zit.
Gekopieerde markeringen verdienen hetzelfde wantrouwen als elke door de client geleverde waarde. Een werkstation kan versnelde doorsturing claimen voor een back-uptaak, dus toelating en hermarkering aan de vertrouwensgrens horen in het ontwerp voordat de markering wordt geloofd.
Prioriteit telt alleen waar de wachtrij ontstaat
Een verzadigde uplink is wat een goede codec in een robotachtige stem verandert, en de wachtrij die volloopt zit meestal in het toegangsapparaat of in de buffer van de provider. De uitgaande route vormen naar de bruikbare snelheid, minus tunnel- en linkoverhead, houdt die wachtrij op hardware die u beheert in plaats van in andermans buffer.
Eerlijke wachtrijen en actief wachtrijbeheer helpen zelfs zonder spraakklasse, omdat ze voorkomen dat één bulkstroom de buffer vult. CAKE op Linux bundelt vormgeving, eerlijkheid per stroom en optionele Diffserv-klassen in één qdisc, en de uitgerolde netwerkbeheerder zou die configuratie moeten bezitten in plaats van een tweede concurrerende wachtrijopstelling. Zonder vormgeving wacht een klasse die bulkverkeer voorbijstreeft nog steeds achter een buffer die al vol is.
Behandeling van inkomend verkeer is niet nutteloos, maar werkt pas nadat het pakket de ontvangende link heeft gepasseerd. Het kan een responsieve zender beïnvloeden en kan al stroomopwaarts bestede vertraging niet terugbetalen, dus het is een verzachting en geen garantie.
| Stage | What you can control | What to verify |
|---|---|---|
| Application to client | Which flows are trusted for marking | The marked packets are the ones you intended |
| Tunnel boundary | Whether the inner mark is copied outward | Outer header carries the expected value |
| Your uplink | Shaping rate and class treatment | Queue counters move for the voice class |
| Provider path | Almost nothing | Whether the service enforces the marking at all |
| Receiving side | Local policy after arrival | Delay that is already in the past |
Wat het publieke internet overleeft
De Diffserv-architectuur beschrijft de behandeling binnen administratieve domeinen, daarom kan een provider een markering aan een grens negeren of herschrijven. De tegenovergestelde bewering, dat elk netwerk die altijd verwijdert, is even ongefundeerd. De eerlijke vraag is waartoe dit specifieke pad contractueel verplicht is en hoe daarop wordt toegezien. Test dat met een gemarkeerde probe in plaats van een regel te herhalen die u ergens las.
Vraag wat de provider met de klasse doet en meet het dan. Een markering die bewaard maar niet ingepland wordt, is decoratie; een pad dat inplant zonder de markering te zien is een ander probleem, en beide vragen om andere correcties.
Een meetplan dat de fase isoleert
Voer één gewoon gesprek met een gecontroleerde concurrerende upload en herhaal het dan op een bekabelde link. Kijk wat het gesprek verloor, wat de klassentellers vastlegden en hoe dicht de interface bij zijn echte grens loopt in plaats van bij de geadverteerde snelheid van het abonnement.
tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.netBlijft de teller van de spraakklasse op nul, dan zijn classificatie of markeringkopie stuk en geen enkele prioriteit helpt. Beweegt de klassenteller lokaal terwijl de vertraging blijft stijgen, dan ligt de flessenhals voorbij uw gateway. Geen van beide resultaten wordt verholpen door de prioriteitswaarde te verhogen.