Configuración de QoS para Voz

[Translator]

HOLA.

Nos gustaría configurar QoS en nuestro router para el tráfico de voz. El enlace es de 10 MB y la tecnología de voz pidió un 60% de tráfico para voz.

¿Puede por favor alguien aconsejar si la configuración a continuación es correcta:

class-map match-any Voice
protocolo de coincidencia sip

QoS de mapa de directivas
Clase Voz
porcentaje de prioridad 60
clase predeterminada
cola justa
10M_Shaping de mapas de políticas
clase predeterminada
forma promedio porcentaje 40
QoS de directiva de servicio

interfaz GigabitEthernet0/0/0
Descripción Conexión a ********
dirección IP ****.*****
SFP de tipo multimedia
10M_Shaping de resultados de directivas de servicio

Gracias

[Translator · Accepted solution]

Oye, esto debería funcionar para usted, coincidirá con cualquier tráfico con un DSCP 46 EF para voz, todos los teléfonos Cisco marcarán allí paquetes con este y la mayoría de los demás, así como es el estándar, está limitado a 6mb y los otros 4mb van a todo lo demás, use ancho de banda en lugar de prioridad, ya que permite que las clases excedan la configuración cuando no hay congestión completa, prioridad lo restringe fijamente a la cantidad establecida

VOICE_ACL ampliada de la lista de acceso IP
Permitir IP cualquier DSCP EF

policy-map VOICE10Mb
VOICE_CLASS de clase
ancho de banda 6000
clase predeterminada
cola justa

class-map match-any VOICE_CLASS
hacer coincidir el nombre del grupo de acceso VOICE_ACL

interfaz GigabitEthernet0/0/0
salida de política de servicio VOICE10Mb

[Translator]

Renuncia

El Autor de esta publicación ofrece la información contenida en esta publicación sin consideración y con el entendimiento del lector de que no hay idoneidad o idoneidad implícita o expresada para ningún propósito. La información proporcionada es solo para fines informativos y no debe interpretarse como una prestación de asesoramiento profesional de ningún tipo. El uso de la información de esta publicación es únicamente bajo el propio riesgo del lector.

Descargo de responsabilidad

En ningún caso el Autor será responsable de ningún daño (incluidos, entre otros, daños por pérdida de uso, datos o ganancias) que surjan del uso o la incapacidad de usar la información de la publicación, incluso si el Autor ha sido advertido de la posibilidad de dicho daño.

Publicar

". . . use ancho de banda en lugar de prioridad, ya que permite que las clases excedan la configuración cuando no hay congestión total, la prioridad lo restringe a la cantidad establecida"

Por cierto, en muchas (¿la mayoría?) plataformas, el policía implícito de LLQ solo se activa cuando hay congestión (NB: Peter Paluch confirmó esto con algunas pruebas de laboratorio: hay un hilo que documenta lo que encontró).

Incluso si funcionó como usted postula, con VoIP, LLQ ayuda a minimizar la latencia de cola (especialmente importante para minimizar el jitter) en comparación con el uso de una clase de ancho de banda "rutinaria".

Por último, pre-HQF CBWFQ, FQ en clase-predeterminada (algo) niega las garantías de ancho de banda "ordinarias" en otras clases. LLQ, sin embargo, todavía tiene su prioridad.

Recomendaría no usar una clase que no sea LLQ para el tráfico portador de VoIP, aunque a menudo es una opción adecuada para el tráfico de señalización VoIP.

[Translator]

Eso es bueno saberlo gracias

[Translator]

Gracias Joseph/Mark por sus comentarios. Lo dejaré como está. ¿Es necesario aplicar esto en ambas interfaces?

La razón por la que pregunto es porque este enrutador está sentado en el medio entre dos conexiones externas en la red. Así que tenemos: > QoS Router-> conmutador habilitado para BGP 3850. El conmutador está conectado a servidores de CC, a servicios en la nube y a la WAN interna de la empresa.

La interfaz externa del enrutador está conectada al enrutador del proveedor externo y la interfaz interna está conectada al conmutador BGP 3850.

Gracias de nuevo

[Translator]

Renuncia

El Autor de esta publicación ofrece la información contenida en esta publicación sin consideración y con el entendimiento del lector de que no hay idoneidad o idoneidad implícita o expresada para ningún propósito. La información proporcionada es solo para fines informativos y no debe interpretarse como una prestación de asesoramiento profesional de ningún tipo. El uso de la información de esta publicación es únicamente bajo el propio riesgo del lector.

Descargo de responsabilidad

En ningún caso el Autor será responsable de ningún daño (incluidos, entre otros, daños por pérdida de uso, datos o ganancias) que surjan del uso o la incapacidad de usar la información de la publicación, incluso si el Autor ha sido advertido de la posibilidad de dicho daño.

Publicar

La respuesta del "libro" sería, debería tener QoS en cada interfaz. Pero donde realmente quieres QoS es en interfaces sujetas a congestión. Suponiendo que su entrada también es de 10 Mbps, y también asumiendo que su enlace interno desde su enrutador a 3850 es de 10 Mbps o mejor, ese enlace no puede congestionarse (bueno, excepto que su WAN se está formando, por lo que la entrada es en realidad un concierto, por lo que a menos que el enlace a 3850 también sea un concierto, puede congestionar, pero no debería ser un problema).

[Translator]

Eso tiene sentido. Gracias José.

Una última pregunta, ¿necesito dar forma a las interfaces a 10MB o cualquiera que sea la velocidad del enlace o eso se haría desde el router del proveedor?

La razón por la que pregunto, porque actualmente con el 60-40 por ciento que hemos configurado para QoS que está en una interfaz que es de 1GB.

Gracias

[Translator]

Renuncia

El Autor de esta publicación ofrece la información contenida en esta publicación sin consideración y con el entendimiento del lector de que no hay idoneidad o idoneidad implícita o expresada para ningún propósito. La información proporcionada es solo para fines informativos y no debe interpretarse como una prestación de asesoramiento profesional de ningún tipo. El uso de la información de esta publicación es únicamente bajo el propio riesgo del lector.

Descargo de responsabilidad

En ningún caso el Autor será responsable de ningún daño (incluidos, entre otros, daños por pérdida de uso, datos o ganancias) que surjan del uso o la incapacidad de usar la información de la publicación, incluso si el Autor ha sido advertido de la posibilidad de dicho daño.

Publicar

Debe dar forma cuando sepa que hay un cuello de botella posterior que no puede aplicar QoS en ese momento.

[Translator · Accepted solution]

Renuncia

El Autor de esta publicación ofrece la información contenida en esta publicación sin consideración y con el entendimiento del lector de que no hay idoneidad o idoneidad implícita o expresada para ningún propósito. La información proporcionada es solo para fines informativos y no debe interpretarse como una prestación de asesoramiento profesional de ningún tipo. El uso de la información de esta publicación es únicamente bajo el propio riesgo del lector.

Descargo de responsabilidad

En ningún caso el Autor será responsable de ningún daño (incluidos, entre otros, daños por pérdida de uso, datos o ganancias) que surjan del uso o la incapacidad de usar la información de la publicación, incluso si el Autor ha sido advertido de la posibilidad de dicho daño.

Publicar

Sí, eso es básicamente lo que quieres.

Idealmente, sería mejor si pudieras ejecutar la interfaz a 10 Mbps, para evitar la necesidad de un shaper, pero parece que es fibra gig.

Cisco recomienda que LLQ no exceda 1/3 del ancho de banda disponible. Esto para asegurarse de que tiene suficiente ancho de banda para otros fines, pero una vez que pasa alrededor del 50%, también comienza a arriesgarse a no tener suficiente ancho de banda para VoIP para evitar la autoupresión. Esto es más un problema si utiliza códecs comprimidos, cuya demanda de ancho de banda puede variar.

Deberá confirmar que el SIP de NBAR coincide con su tráfico VoIP. La marca es correcta, a menudo el tráfico VoIP (portador) está marcado con DSCP EF. Puedes enfrentarte a ambos, si quieres.

P. ej...

class-map match-any Voice

match dscp ef
protocolo de coincidencia sip

También tenga en cuenta que, con VoIP, generalmente desea "proteger" su tráfico de señalización, pero no necesita LLQ para eso.

Cuando un shaper está trabajando con VoIP, a menudo necesita asegurarse de que el shaper esté usando un pequeño Tc. (El Tc de las versiones más recientes de IOS es bueno, las versiones anteriores podrían no serlo).