Märkning av VPN-porten prioriterar inte röstsamtal

Att märka VPN:ens UDP-port som hög prioritet är den vanligaste QoS-ändringen för röst, och den skiljer inte ett samtal från filöverföringen som delar samma tunnel. Båda flödena lämnar samma krypterade socket. Märkningen säger till nästa hopp att allt är lika viktigt, vilket är samma sak som att inte säga något. Det som skyddar ett samtal är en tillförlitlig klassning före kryptering plus en kö som du faktiskt kontrollerar.

Tunneln döljer flödet du ville klassificera

Kryptering ersätter de inre rubrikerna med en yttre rubrik per tunnel. Efter det visar röst och säkerhetskopietrafik samma källa, destination och transportport, så en klassificerare som bygger på tunnelporten kan inte skilja dem åt. Vad du än lyfter fram, lyfter du fram det i klump.

Ett DSCP-värde som ursprungsprogrammet sätter överlever bara om något kopierar det utåt. OpenVPN 2.6 har passtos, dokumenterat med IPv4-omfång; IPsec tillämpar sin egen kopierings- eller mappningspolicy vid tunnelgränsen. Utan det steget märks det yttre paketet med vilket standardvärde tunnelgränssnittet än använder, och kön längre ned får aldrig veta att ett samtal finns inuti.

Kopierade märkningar förtjänar samma misstro som varje klientlevererat värde. En arbetsstation kan begära påskyndad vidarebefordran för ett säkerhetskopiejobb, så tillträde och ommärkning vid tillitsgränsen hör hemma i designen innan man litar på märkningen.

Prioritet räknas bara där kön bildas

En mättad upplänk är det som förvandlar en bra codec till en robotaktig röst, och kön som fylls finns oftast i åtkomstutrustningen eller i leverantörens buffert. Att forma den utgående vägen till den användbara hastigheten, minus tunnel- och länkoverhead, är det som håller kön på hårdvara du administrerar i stället för i någon annans buffert.

Rättvis köhantering och aktiv köhantering hjälper även utan röstklass, eftersom de hindrar ett stort flöde från att fylla bufferten. CAKE på Linux samlar formning, rättvisa per flöde och valfria Diffserv-klasser i en qdisc, och den utrullade nätverkshanteraren bör äga den konfigurationen i stället för en andra konkurrerande köuppsättning. Utan formning väntar en klass som rangordnas över bulktrafik fortfarande bakom en buffert som redan är full.

Behandling av inkommande trafik är inte värdelös, men den verkar först efter att paketet har passerat mottagningslänken. Den kan påverka en lyhörd avsändare och kan inte återbetala fördröjning som redan är spenderad uppströms, så det är en mildring och inte en garanti.

Vad som överlever på det öppna internet

Diffserv-arkitekturen beskriver behandling inom administrativa domäner, och därför kan en leverantör ignorera eller skriva om en märkning vid en gräns. Det motsatta påståendet, att varje nät alltid tar bort den, är lika obefogat. Den ärliga frågan är vad just den här vägen är avtalad och övervakad att göra. Testa det med en märkt probe i stället för att upprepa en regel du läst någonstans.

Fråga vad leverantören gör med klassen och mät det sedan. En märkning som bevaras men inte schemaläggs är dekoration; en väg som schemalägger utan att se märkningen är ett annat problem, och de två behöver olika åtgärder.

En mätplan som isolerar steget

Gör ett vanligt samtal med en kontrollerad konkurrerande uppladdning och upprepa det sedan på en kabelansluten länk. Titta på vad samtalet förlorade, vad klassräknarna registrerade och hur nära gränssnittet går sin verkliga gräns i stället för planens annonserade hastighet.

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

Om räknaren för röstklassen står kvar på noll är klassningen eller märkningskopieringen trasig och ingen mängd prioritet hjälper. Om klassräknaren rör sig lokalt medan fördröjningen fortsätter att stiga ligger flaskhalsen bortom din gateway. Ingen av de två resultaten åtgärdas genom att höja prioritetsvärdet.