Problemas de QoS - VPN IP gerenciada

(Antes de tudo, desculpe-me por esse muro de texto. Não sei como abreviá-lo sem perder informações importantes. Eu originalmente queria usar a sala de bate-papo para isso, como fazemos no serverfault para esse tipo de perguntas, mas não há ninguém na sala de engenharia de rede).

Somos uma corporação com várias empresas filhas, onde temos uma VPN IP gerenciada bastante grande com cerca de 70 locais diferentes, variando de 2Mbps SHDSL a 100Mbps de fibra. A IP-VPN transporta várias VPNs (ou túneis para ser exato).

A prioridade do tráfego é esta, do ponto de vista de gerenciamento e design:

1. VoIP (Avaya e Lync)
2. Vídeo (Lync)
3. RDP
4. Serviços internos (servidores de arquivos, Active Directory, intranet etc.)
5. Serviços internos não priorizados (servidores proxy para uso da Internet, serviços de atualização do Windows, gerenciamento de configuração do System Center, proxies de atualização de antivírus etc.)
6. O tráfego não correspondido (internet)

O VoIP é usado apenas em determinados escritórios, onde há uma baixa quantidade de usuários. O maior escritório remoto que usa VoIP atualmente possui um SHDSL de 4 Mbps com 5 funcionários e 5 telefones IP da Avaya executando o codec G.711 ALAW 64K. Isso nunca deve elevar o tráfego de dados voip para mais de 320kbps. Eu verifiquei que os telefones usam o DSCP 46 para áudio e, portanto, é correspondido corretamente como EF (consulte a configuração abaixo). A sinalização, no entanto, corresponde ao DSCP 24, que não tenho certeza se nosso perfil de QoS é captado.

Todos os locais remotos usam RDP em vários farms RDS em nosso HQ (fibra de 2x100Mbit). A largura de banda usada para o RDP não é tão fácil de entender, pois basicamente usa tudo o que recebe. Temos certas limitações definidas para garantir que ele não consome muitos recursos, mas isso provavelmente está fora do escopo deste site. Ultimamente, temos problemas graves com o RDP ( /server/515809/mouse-cursor-jumps-around-when-using-rdp ), e é por isso que estou publicando isso na engenharia de rede.

O Lync usa o DSCP 46 para áudio e o DSCP 34 para vídeo. Serviços internos e serviços internos não priorizados são apenas correspondidos por sub-redes, e todo o resto é igual a qualquer outro.

Aqui está uma cópia da última revisão da configuração de QoS, que modifiquei um pouco para ocultar certos nomes e endereços 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 você pode ver, é uma configuração de QoS bastante grande. Observe que não criamos essa configuração por conta própria, tudo foi feito por um funcionário anterior do nosso provedor de IP-VPN. Observe também que o valor da forma é alterado de acordo com o tipo de conexão (2mbps, 4mbps, 8mbps e 10mbps).

Até agora você provavelmente está se perguntando - Qual é a questão aqui? Aqui vai ..

1. Como mencionei anteriormente, estamos nos afogando nas reclamações dos usuários do RDP sobre o atraso / a entrada do usuário não ser reconhecida. Não estamos priorizando isso corretamente? É possível garantir que o RDP obtenha uma quantidade mínima de perda de pacotes, latência e tremulação, mas ainda esteja restrito na largura de banda?
2. Não estou vendo nenhuma menção de filas nesta configuração. Eu li alguma documentação da Microsoft e eles recomendam o uso da fila de prioridade em VoIP e WRED em vídeo. Como faço isso acontecer?
3. Como mostra a configuração, nenhuma das classificações AF usa queda média ou alta. Que tipo de serviços é seguro? RDP, vídeo e voip não funcionam bem com quedas.
4. As porcentagens de largura de banda estão em ordem? Resume até 100% de uso

Quaisquer outras sugestões são bem-vindas, pois estou desesperado para resolver isso. Se você acha que é demais responder em um site de perguntas e respostas, vou morder o pó e contratar um consultor de nosso parceiro Cisco Gold, que é financeiramente bom - só quero aprender isso se puder.

Para responder suas perguntas:

• O tráfego RDP deve atingir os 25% da largura de banda restante. Onde a largura de banda já reservada é de 35% (o padrão da classe obtém 25% por padrão e EF obtém 10%). Então, se eu estiver certo, você atribuiu ~ 665Kbps ao RDP. De qualquer forma, você deve verificar se está descartando pacotes emitindo o comando abaixo:

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

e verificação de pacotes descartados.

• A Cisco atribui uma fila a cada classe definida pelo usuário que inclui a largura de banda ou comandos da polícia . Para simplificar uma longa história, esses comandos definem a quantidade de largura de banda atribuída a todas as filas durante os congestionamentos.

• Em teoria, todo fluxo baseado em TCP deve estar OK com quedas. Na prática, alguns deles não são. A queda dos bits de precedência informa aos roteadores quais pacotes devem ser descartados, dentro de uma determinada classe, antes que ocorra o congestionamento. Como o RDP é o único tipo de tráfego definido na sua classe REMOTEDESKTOP , você não deve se preocupar com isso.

• A porcentagem de largura de banda não está em ordem (como Jeremy afirmou).

Dito isto, há muitas coisas que eu mudaria na sua configuração:

• Não há correspondências entre algumas classes do setTos e o mapa de políticas useTos . Por exemplo, o nomeado AF-HIGH não está processando pacotes, pois nenhuma classe em setTos define DSCP para AF41.

• A classe BE em setTos é de alguma forma autodestrutiva, pois torna a classe padrão da classe inútil. Observe que o padrão de classe é a única classe definida pelo sistema e obtém 25% da largura de banda por padrão (100 - largura de banda máxima reservada).

• a porcentagem restante da largura de banda não é a melhor opção (como Jeremy explicou). Eu mudaria para porcentagem de largura de banda .

• Eu preferiria marcar pacotes EF sozinho e não confiar nas configurações dos telefones.

A primeira coisa que me impressiona é que você parece estar moldando tudo para 4 Mbps. Eu imagino que a taxa seja alterada em roteadores / sites com diferentes velocidades de circuito, mas geralmente você deseja evitar modelagem ao lidar com aplicativos sensíveis à latência, como VoIP e RDP, pois isso pode causar buffer e tremulação excessivos durante períodos de congestionamento.

Além disso, o bandwidth remaining percentcomando é um pouco complicado: na verdade, cada instância aloca n% da largura de banda disponível restante, não n% do total. Este gráfico de um artigo de Arden Packeer deve ajudar a ilustrar a idéia:

É importante observar que todas as classificações que você definir precisam corresponder ao que o seu provedor de WAN suporta. A maioria dos provedores oferece apenas um punhado de perfis de QoS pré-configurados, dos quais você deve escolher o que melhor se adapta às suas necessidades. Você pode classificar como quiser no tráfego de entrada na borda da WAN, mas os controles de QoS do provedor são os que controlam o tratamento do tráfego durante o trânsito pela WAN.