Problemas de QoS: VPN IP administrada

(En primer lugar, lo siento por este muro de texto. No sé cómo acortarlo sin perder información importante. Originalmente quería usar la sala de chat para esto, como lo hacemos en serverfault para este tipo de preguntas, pero no hay nadie en la sala de ingeniería de redes).

Somos una corporación con varias compañías filiales, donde tenemos una IP-VPN administrada bastante grande con aproximadamente 70 ubicaciones diferentes, que varían desde 2Mbps SHDSL hasta 100Mbps de fibra. La IP-VPN lleva múltiples VPN (o túneles para ser exactos).

La prioridad del tráfico es esta, desde un punto de vista de gestión y diseño:

1. VoIP (Avaya y Lync)
2. Video (Lync)
3. RDP
4. Servicios internos (servidores de archivos, Active Directory, intranet, etc.)
5. Servicios internos no priorizados (servidores proxy para el uso de Internet, servicios de actualización de Windows, administración de configuración del centro del sistema, proxies de actualización de antivirus, etc.)
6. El tráfico no coincidente (internet)

VoIP solo se usa en ciertas oficinas, donde hay una baja cantidad de usuarios. La oficina remota más grande que usa VoIP en este momento tiene un SHDSL de 4mbps con 5 empleados y 5 teléfonos IP avaya que ejecutan el códec G.711 ALAW 64K. Esto nunca debería elevar el tráfico de datos voip a más de 320 kbps. Verifiqué que los teléfonos usan DSCP 46 para audio y, por lo tanto, coinciden correctamente como EF (consulte la configuración a continuación). Sin embargo, la señalización coincide con DSCP 24, que no estoy seguro de si nuestro perfil de QoS se recupera.

Todas las ubicaciones remotas usan RDP contra varias granjas de RDS en nuestra sede (fibra de 2x100Mbit). El ancho de banda utilizado para RDP no es tan fácil de calcular, ya que básicamente utiliza todo lo que obtiene. Tenemos ciertas limitaciones establecidas para asegurarnos de que no consuma demasiados recursos, pero eso probablemente esté fuera del alcance de este sitio. Tenemos algunos problemas bastante graves con RDP últimamente ( /server/515809/mouse-cursor-jumps-around-when-using-rdp ), por eso publico esto en ingeniería de redes.

Lync usa DSCP 46 para audio y DSCP 34 para video. Los servicios internos y los servicios internos no priorizados solo coinciden con subredes, y todo lo demás coincide con cualquiera.

Aquí hay una copia de la última revisión de configuración de QoS, que he modificado ligeramente para ocultar ciertos nombres y direcciones IP:

!
class-map match-any INTERNAL-PRI
 match access-group name CUST-INT-PRI
 match access-group name CUST-DMZ
class-map match-any INTERNAL-NOPRI
 match access-group name CUST-INT-NOPRI
class-map match-any REMOTEDESKTOP
 match access-group name RDP
class-map match-any ALL
 match any
class-map match-any NETWORK
 match ip precedence 6
 match ip precedence 7
class-map match-any EF
 match ip dscp ef
 match ip dscp cs5
class-map match-any AF-HIGH
 match ip dscp af41
 match ip dscp cs4
class-map match-any AF-MEDHI
 match ip dscp af31
 match ip dscp cs3
class-map match-any AF-MEDIUM
 match ip dscp af21
 match ip dscp cs2
class-map match-any AF-LOW
 match ip dscp af11
 match ip dscp cs1
class-map match-any BE
 match ip dscp default
!
!
policy-map setTos
 class EF
 class REMOTEDESKTOP
  set ip dscp af31
 class INTERNAL-PRI
  set ip dscp af21
 class INTERNAL-NONPRI
  set ip dscp af11
 class class-default
  set ip dscp default
policy-map useTos
 class EF
  priority percent 10
 class AF-HIGH
  bandwidth remaining percent 35
 class AF-MEDHI
  bandwidth remaining percent 25
 class AF-LOW
  bandwidth remaining percent 20
 class BE
  bandwidth remaining percent 10
 class NETWORK
policy-map QOS
 class ALL
  shape average 4096000
  service-policy useTos
!
!         
ip access-list standard CUST-DMZ
 permit 123.123.123.0 0.0.0.255
!
ip access-list standard CUST-INT-PRI
 permit 10.50.0.0 0.0.0.255
 permit 10.51.0.0 0.0.0.255
!
ip access-list standard CUST-INT-NOPRI
 permit 10.50.10.0 0.0.0.255
 permit 10.51.10.0 0.0.0.255
!
ip access-list extended RDP
 permit tcp any eq 3389 any
 permit tcp any any eq 3389
!

Como puede ver, es una configuración de QoS bastante grande. Tenga en cuenta que no creamos esta configuración nosotros mismos, todo fue realizado por un empleado anterior de nuestro proveedor de IP-VPN. Tenga en cuenta también que el valor de la forma cambia según el tipo de conexión que sea (2mbps, 4mbps, 8mbps y 10mbps).

A estas alturas probablemente te estés preguntando: ¿cuál es la pregunta aquí? Aquí va..

1. Como mencioné anteriormente, nos estamos ahogando en las quejas de los usuarios de RDP sobre el retraso / entrada del usuario que no se reconoce. ¿No lo estamos priorizando correctamente? ¿Es posible asegurarse de que RDP obtenga una cantidad mínima de pérdida de paquetes, latencia y jitter, pero que aún esté restringido en ancho de banda?
2. No veo ninguna mención de colas en esta configuración. He leído algo de la documentación de Microsoft, y me recomiendan usar cola prioritaria en VoIP y WRED en video. ¿Cómo hago que esto suceda?
3. Como muestra la configuración, ninguna de las clasificaciones de AF usa caída media o alta. ¿Qué tipo de servicios son seguros? RDP, video y voip no funcionan bien con gotas.
4. ¿Están en orden los porcentajes de ancho de banda? Suma hasta el 100% de uso

Cualquier otra sugerencia (s) son bienvenidas, ya que estoy desesperado por resolver esto. Si cree que es demasiado para responder en un sitio de preguntas y respuestas, voy a morder el polvo y contratar a un consultor de nuestro socio Cisco Gold, lo que está financieramente bien, solo quiero aprender esto si puedo.

Para responder tu pregunta:

• El tráfico RDP debería alcanzar hasta el 25% del ancho de banda restante. Donde el ancho de banda ya reservado es el 35% ( el valor predeterminado de la clase obtiene el 25% por defecto y EF obtiene el 10%). Entonces, si tengo razón, asignó ~ 665 Kbps a RDP. De todos modos, debe verificar si está descartando paquetes que emiten el siguiente comando:

show policy-map <your wan interface> output class REMOTEDESKTOP

y buscando paquetes descartados.

• Cisco asigna una cola a cada clase definida por el usuario que incluye el ancho de banda o la policía comandos . Para simplificar una larga historia, esos comandos definen la cantidad de ancho de banda asignado a cada cola durante las congestiones.

• En teoría, cada flujo basado en TCP debería estar bien con las caídas. En la práctica, algunos de ellos no lo son. Los bits de prioridad de descarte le indican a los enrutadores qué paquetes deben descartarse, dentro de una clase determinada, antes de que ocurra la congestión. Dado que RDP es el único tipo de tráfico definido en su REMOTEDESKTOP clase , no debe preocuparse por ello.

• El porcentaje de ancho de banda no está en orden (como dijo Jeremy).

Dicho esto, hay muchas cosas que cambiaría en su configuración:

• No hay coincidencias entre algunas de las clases de setTos y useTos policy-map. Por ejemplo, el llamado AF-HIGH no está procesando paquetes ya que no hay clase en setTos establece DSCP en AF41.

• La clase BE en setTos es de alguna manera autodestructiva ya que hace que la clase predeterminada sea inútil. Tenga en cuenta que class-default es la única clase definida por el sistema y obtiene el 25% del ancho de banda por defecto (100 - max-reserved-bandwidth).

• el porcentaje restante de ancho de banda no es la mejor opción (como explicó Jeremy). Lo cambiaría a porcentaje de ancho banda .

• Preferiría marcar los paquetes EF por mí mismo y no confiar en la configuración de los teléfonos.

Lo primero que me llama la atención es que pareces estar moldeando todo a 4 Mbps. Me imagino que la velocidad cambia en los enrutadores / sitios con diferentes velocidades de circuito, pero generalmente desea evitar la configuración cuando se trata de aplicaciones sensibles a la latencia como VoIP y RDP, ya que puede causar un almacenamiento en búfer excesivo y fluctuaciones durante los períodos de congestión.

Además, el bandwidth remaining percentcomando es un poco complicado: cada instancia en realidad asigna n% del ancho de banda disponible restante, no n% del total. Este gráfico de un artículo de Arden Packeer debería ayudar a ilustrar la idea:

Es importante tener en cuenta que cualquier clasificación que defina debe coincidir con la que admite su proveedor de WAN. La mayoría de los proveedores ofrecen solo un puñado de perfiles de QoS preconfigurados entre los que debe elegir el que mejor se adapte a sus necesidades. Puede clasificar como desee en el tráfico entrante en el borde de la WAN, pero los controles de QoS del proveedor son los que controlan el tratamiento del tráfico durante el tránsito a través de la WAN.