Marcar o porto da VPN non dá prioridade ás chamadas de voz

Marcar o porto UDP da VPN como alta prioridade é o cambio de QoS de voz máis habitual, e non separa unha chamada da transferencia de ficheiros que comparte ese túnel. Os dous fluxos saen polo mesmo socket cifrado. A marca dille ao seguinte salto que todo importa por igual, o que é o mesmo que non lle dicir nada. O que protexe unha chamada é unha clasificación de confianza antes do cifrado máis unha cola que vostede controle de verdade.

O túnel oculta o fluxo que quería clasificar

O cifrado substitúe as cabeceiras internas por unha cabeceira externa por túnel. Despois, a voz e o tráfico de copia de seguridade presentan a mesma orixe, destino e porto de transporte, así que un clasificador baseado no porto do túnel non pode distingui-los. O que promova, promóveo en bloque.

Un valor DSCP establecido pola aplicación de orixe só sobrevive se algo o copia cara a fóra. OpenVPN 2.6 ten passtos, documentado cun alcance IPv4; IPsec aplica a súa propia política de copia ou de mapeo no límite do túnel. Sen ese paso, o paquete externo márcase co valor por defecto que use a interface do túnel, e a cola posterior nunca se decata de que hai unha chamada dentro.

As marcas copiadas merecen a mesma sospeita que calquera valor proporcionado polo cliente. Unha estación de traballo pode reclamar envío expeditivo para unha tarefa de copia de seguridade, así que a admisión e o remarkado no límite de confianza deben estar no deseño antes de crer a marca.

A prioridade só conta onde se forma a cola

Unha ligazón ascendente saturada é o que converte un bo códec nunha voz robótica, e a cola que se enche adoita estar no dispositivo de acceso ou no búfer do provedor. Modelar a ruta de saída á velocidade utilizábel, menos a sobrecarga do túnel e da ligazón, é o que mantén esa cola en hardware que vostede administra e non no búfer doutro.

A cola xusta e a xestión activa de colas axudan mesmo sen clase de voz, porque impiden que un fluxo masivo encha o búfer. CAKE en Linux agrupa modelado, equidade por fluxo e clases Diffserv opcionais nun só qdisc, e o xestor de rede despregado debería posuír esa configuración en lugar dunha segunda cola competidora. Sen modelado, unha clase que supera o tráfico masivo segue esperando detrás dun búfer que xa está cheo.

O tratamento de entrada non é inútil, pero actúa despois de que o paquete cruzou a ligazón receptora. Pode influír nun emisor reactivo e non pode devolver o atraso xa gastado augas arriba, así que é unha mitigación e non unha garantía.

Que sobrevive na internet pública

A arquitectura Diffserv describe o tratamento dentro de dominios administrativos, por iso un provedor pode ignorar ou reescribir unha marca nunha fronteira. A afirmación contraria, que todas as redes sempre a eliminan, está igual de infundada. A pregunta honesta é que está contratado e vixiado que faga este camiño concreto. Probe-o cunha sonda marcada en lugar de repetir unha regra que leu nalgún sitio.

Pregunte que fai o provedor coa clase e despois mídao. Unha marca que se conserva pero non se planifica é decoración; un camiño que planifica sen ver a marca é un problema distinto, e os dous necesitan correccións diferentes.

Un plan de medición que illa a etapa

Faga unha chamada normal cunha subida competidora controlada e repítaa nunha ligazón por cable. Mire que perdeu a chamada, que rexistraron os contadores de clase e como de preto vai a interface do seu límite real e non da velocidade anunciada do plan.

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

Se o contador da clase de voz queda en cero, a clasificación ou a copia da marca está rota e ningunha cantidade de prioridade axudará. Se o contador de clase se move localmente mentres o atraso segue subindo, o colo de botella está máis aló da súa pasarela. Ningún dos dous resultados se corrixe subindo o valor de prioridade.