Recentemente, fui solicitado a fazer uma análise de um arquivo de rastreamento; ele tinha apenas 161 segundos de duração e continha pouco mais de 2,6 milhões de quadros. Fiquei surpreso ao descobrir que aproximadamente 75% desses quadros eram solicitações de ping ou respostas de ping. Se eu não tivesse reconhecido o endereço IP de origem, teria concluído precipitadamente que o alvo estava sofrendo um ataque de negação de serviço. Em vez disso, descobri que eles estavam usando o argumento “run_forever” no comando ping do STCP para monitorar a acessibilidade do alvo.
Ao contrário do comando ping na maioria dos sistemas UNIX ou Linux, o comando ping do STCP não faz uma pausa entre o recebimento de uma resposta de ping e a próxima solicitação de ping. Como o número padrão de pings é de apenas 4, isso não representa um problema significativo. Mas quando o número de solicitações é aumentado usando o argumento count ou o argumento run_forever é utilizado, isso pode criar uma carga significativa no sistema, no adaptador Ethernet e na rede. Isso torna o comportamento padrão do comando ping do STCP totalmente inadequado para o monitoramento de longo prazo de um host de destino.
Mas, só porque o comportamento padrão não é adequado, isso não significa que você não possa usar o comando ping para monitoramento de longo prazo. O segredo é executar o comando repetidamente, enviando uma solicitação de ping de cada vez, em vez de executá-lo uma única vez e enviar um fluxo contínuo de solicitações de ping. A macro a seguir fará isso.
& ping_forever begins here |
Como você pode ver, os dois primeiros argumentos são passados diretamente para o comando ping e correspondem aos argumentos host e timeout do ping. O tempo de espera padrão do ping é de 15 segundos, mas acho que é muito longo e, na macro, alterei esse valor para 1 segundo. É claro que você pode ajustá-lo na macro ou fornecendo um valor como argumento. O terceiro argumento é o número de segundos de pausa entre os pings; o padrão é 1 segundo. Como leva tempo para executar a macro e carregar e executar o comando ping, o tempo real entre os pings é um pouco maior. O Packet_monitor mostrou tempos entre 1,05 e 1,1 segundos. O argumento final é algo que o ping do UNIX ou do Linux não fornece – um carimbo de data/hora para cada ping, para que você possa saber quando o alvo para de responder e quando volta a responder. Se você não quiser os carimbos de data/hora, pode desativá-los com o argumento -no_timestamp.
ping_forever 164.152.77.6 *** 09-08-30.11:45:38 ***Pinging host 164.152.77.6 : 164.152.77.6ICMP Echo Reply:TTL 60 time = 2 msHost 164.152.77.6 replied to the ping *** 09-08-30.11:45:40 ***Pinging host 164.152.77.6 : 164.152.77.6ICMP Echo Reply:TTL 60 time = 2 msHost 164.152.77.6 replied to the ping *** 09-08-30.11:45:41 ***Pinging host 164.152.77.6 : 164.152.77.6ping: No reply. Time Out !!Host 164.152.77.6 didn't reply to the ping *** 09-08-30.11:45:44 ***Pinging host 164.152.77.6 : 164.152.77.6ping: No reply. Time Out !!Host 164.152.77.6 didn't reply to the ping *** 09-08-30.11:45:47 ***Pinging host 164.152.77.6 : 164.152.77.6ICMP Echo Reply:TTL 60 time = 4 msHost 164.152.77.6 replied to the ping *** 09-08-30.11:45:48 ***Pinging host 164.152.77.6 : 164.152.77.6ICMP Echo Reply:TTL 60 time = 3 msHost 164.152.77.6 replied to the ping |
