(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:
- VoIP (Avaya e Lync)
- Vídeo (Lync)
- RDP
- Serviços internos (servidores de arquivos, Active Directory, intranet etc.)
- 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.)
- 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 ..
- 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?
- 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?
- 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.
- 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.
show policy-map interface
,show proc cpu history
,show interface <your-interface-w-QOS-service-policy>
,show buff
, eshow runn interface <your-interface-w-QOS-service-policy>
do roteador e adicioná-lo para o fundo da questão?