Em muitos locais, temos apenas um Cisco ASA 5505 cada um e mais um ponto de acesso WiFi, além do roteador do provedor. Sem servidores ou PCs, apenas serviço WiFi para visitantes ocasionais. Desejo verificar remotamente se o provedor nos fornece a largura de banda contratada. Eu pude ver a largura de banda usada no monitoramento do ASA e testar uma direção enviando tráfego para o ASA usando o Iperf do meu lado.
Existe alguma maneira de deixar o ASA gerar tráfego substancial?
Respostas:
(Acabei de notar seu comentário sobre os Raspberrys e quero acompanhar)
Temos uma grande rede MPLS em que precisamos medir a largura de banda e o jitter nos sites para garantir que nossos aplicativos mais sensíveis não estejam prejudicando.
Uma ótima maneira de fazer isso é, como você mencionou, implantando Raspberrys. Eles são pequenos o suficiente, para que você possa instalá-los em praticamente qualquer lugar. Uma ótima ferramenta para testar a largura de banda / jitter é o iperf , que você pode configurar para executar como um daemon (filtrado!) Em cada PI. Em seguida, basta iniciar os testes em uma estação de gerenciamento central.
A jusante, você poderá fazer o download de algo nulo: no ASA, mas a montante, você ficará limitado ao quanto o disco flash pode transferir, o que geralmente não é muito.
Sua melhor aposta seria conectar um PC e executar os testes, mas isso exige que alguém esteja no local, é claro.
Talvez o monitoramento passivo seja uma abordagem melhor. Existem muitos sistemas por aí que rastrearão o estado da interface / erros / descarte / largura de banda. Um gráfico de largura de banda atende às suas necessidades?
Eu tinha um requisito semelhante há muitas luas atrás com um roteador remoto executando o IOS. Acabou usando o serviço tcp-small-servers chargen no roteador - roda em tcp / 19. Ele gera um fluxo de caracteres aleatórios, etc., e pode ser ampliado usando várias sessões de telnet do roteador remoto para outros roteadores executando o chargen. Em nenhum lugar perto do rico controle / funcionalidade dos testes iperf baseados em host. Também como sabemos, o ASA não suporta telnet localmente, portanto isso não funcionará aqui ...
O ASA possui esse utilitário de rastreamento de pacotes desde 7.0 para gerar tráfego interessante para configurações de túnel, mas não permite o ajuste de taxa. Essa funcionalidade também seria um vetor de ataque interessante se explorada remotamente e em escala ... Qualquer funcionalidade nativa do ASA provavelmente atrelaria o plano de controle e qualquer variedade de policiamento inerente ao plano de controle precisaria restringir a taxa de tráfego gerada.
Concordo acima que o Raspberry Pi é uma boa solução aqui. Acabamos de colocar algumas para orientar telas estilo NOC. Eles são incríveis.
Na verdade, fiquei com um pedido semelhante na semana passada (é claro que o site remoto estava do outro lado do país). O que acabei fazendo foi usar o mgen para enviar udp unidirecional e apenas verificar os contadores no dispositivo lateral remoto. Se você não se sentir confortável com o mgen , poderá fazer o mesmo com o nping ou com uma das ferramentas do nmap .
Como você apontou, o problema com o iperf , o IxChariot e muitas outras ferramentas é que elas requerem um atendedor remoto. mgen , nping e alguns outros não.
Se você possui o Solar Winds Engineering Tool Kit, pode usar o "WAN Killer" entre os dois locais. Certifique-se de que suas ACLs permitam que ambas as extremidades se comuniquem dessa maneira e inundem com o nível apropriado de eco ou descarte do ponto A ao B e vice-versa.
Usamos isso para testar a capacidade das redes de lidar com o tráfego nas conexões VPN e MPLS, seja medindo a taxa de transferência bruta de A para B e o PPS de A para B.