Por que temos alta flutuação no gráfico de cactos para medição de largura de banda?

Estávamos no teste de redundância de Etherchannel e Routing em nossa rede. Durante esta intervenção, fizemos algumas medições. Nossa ferramenta de monitoramento é o Cacti para gráfico. O equipamento monitorado é um 4500-X no VSS. Cada link está em um chassi físico diferente.

Esquema:

Cronologia do teste:
[t0] O link na porta te1 / 1/14 foi fisicamente removido. O Te2 / 1/14 está ativo. Po1 está operacional.
[t0 + 15] O link na porta Te1 / 1/14 retornou ao serviço e verificou se a porta de volta no etherchannel Po1
[t0 + 20] O link na porta te1 / 1/14 foi fisicamente removido. O Te2 / 1/14 está ativo. Po1 está operacional.
[t0 + 35] O link na porta Te1 / 1/14 retornou ao serviço e verificou se a porta volta no etherchannel Po1

Em nossos testes, monitoramos o etherchannel de tráfego Po1 através do Cacti (gráfico abaixo) e observamos uma mudança significativa no valor do fluxo quando desativamos o link te1 / 1/14 (link te2 / 1/14) bastante estável durante o reverso . Também verificamos os contadores no int Po1 e estes foram mantidos razoavelmente estáveis.

Duas interfaces de 10G são empacotadas em Etherchannels com o LACP configurado. Dentro do etherchannel, há 2 vlans. Um para tráfego Multicast e outro para Internet / Todo o tráfego.

Você conhece uma possível causa desse comportamento?

Para estender o comentário de ytti.

Seu intervalo de pesquisa parece muito pequeno, a cada 10 segundos, se eu estiver lendo direito. Existem algumas razões pelas quais você pode obter esse resultado.

Lado do equipamento:

• Má escolha de contadores, se você estiver usando contadores de 32 bits, eles poderão rolar a cada ~ 3,4 segundos se você estiver executando uma interface de 10g na taxa de linha
• Na atualização do contador, muitos dispositivos maiores atualizam os contadores apenas duas ou três vezes por minuto, e nunca se pode confiar que eles estejam sincronizados. A cada 30 segundos é tão baixo quanto eu incomodaria as pesquisas, e mesmo assim eu sempre desejaria pelo menos dois pontos antes de acionar qualquer alerta ou tomar uma ação
• Pode haver uma pegadinha, já que os pacotes enviados para o processamento da CPU (talvez netflow) podem ser contados imediatamente contra aqueles que não irão para o RE em lote (já viram isso no Juniper MX)

Lado de Poller:

• O pesquisador está pesquisando com precisão no intervalo e, se não, está injetando seu resultado com o tempo real de pesquisa (por exemplo, x bits em yz segundos) para que uma taxa sensata possa ser calculada
• O que acontece quando os contadores são redefinidos ou os SNMP GET não são respondidos, diferentes ferramentas respondem a eles de maneiras diferentes

Seu problema é que a amostragem do roteador e a sua própria pesquisa não estão no mesmo momento. Ou seja, mesmo que o intervalo de pesquisa seja estático, os intervalos de pesquisa contêm diferentes quantidades de amostras, que sua matemática não leva em consideração.
Considere que você pesquisou t1, t2, t3, mas o roteador não coletou nada no intervalo t1, t2; portanto, todo o tráfego entre t1, t3 terminou no valor de t2, t3. Fazendo com que sua taxa seja 0 em t1, t2 e acima da linha em t2, t3

Agora vou sugerir uma solução, mas verifique isso com alguém que tenha um entendimento superficial da matemática.

Primeiro, descubra a interface em que você está interessado (se ge-1/1/1):

snmpbulkwalk SWITCH ifDescr | grep ge-1/1/1

Então você verá o seu número ifIndex, vamos assumir que é '42'.

Então faça algo como:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Agora analise os resultados para determinar com que frequência, em média, os contadores estão sendo atualizados. (Eu posso produzir script para a análise, se necessário)

Depois vem a parte em que precisaríamos de matemática, mas vou sugerir uma solução ingênua.

Se o seu intervalo de atualização for 10s, faça uma pesquisa a cada 5s, ou seja, duas vezes mais que a atualização. Então suas amostras seriam

t0, t5, t10, t15, t20, t25, t30

Agora, esses seriam seus dados brutos, que você não usaria, mas você prefere recuperar amostras reais a partir dessa forma

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

A justificativa aqui é que queremos vazar além das fronteiras para reduzir o efeito de intervalos de pesquisa imprecisos no seu switch.

Você traçaria o s1, s2, s3 e deverá ter um resultado muito mais suave / preciso do que o que está vendo agora.

No entanto, tenho certeza de que esse não é um problema novo e tenho certeza de que existe uma solução formal para recuperar a precisão ideal, infelizmente produzir essa solução está fora do meu conjunto de habilidades. Algo matemático. As pessoas que trocam pilhas estariam melhor equipadas para enfrentar.

Como você está pesquisando na mesma taxa em que os contadores são atualizados, você provavelmente está fora de sincronia.

Ao configurar

snmp-server hc poll <<hundredths of a second>>

você pode reduzir o intervalo em que os contadores SNMP são atualizados para algo como 1 segundo. Isso deve resultar em um valor mais preciso para a taxa de transferência quando você estiver pesquisando a cada 10 segundos.

Para sua informação, este é um comando oculto.