PPPoE Mikrotik - Tráfego Anormal - Alguem explica?

[ajack]

Pessoal,

Uso pppoe na minha rede há um bom tempo.
Hoje ocorreu algo muito, mas muito estranho.

Em um POP, os clientes começaram a pingar super alto.... trafego anormal..... perda de pacotes... de uma hora pra outra.

Após procurar problemas, me deparei com o seguinte.

Uma interface pppoe (dinamica) de um cliente, tava com tráfego anormal.... 25MB de UPLOAD... 0K de DOWNLOAD (alternando entre 10 e 25MB), porém a QUEUES desse PPPOE é de 3MB e 1MB para UPLOAD....

A QUEUES estava UP.... em vermelho, porém na QUEUES não mostrava tráfego acima do que era estipulado, porém na interface mostrava tráfego altissimo.

Tiramos esse cliente da rede e agora tudo normalizou.

Alguém tem alguma idéia?


Equipamentos:
RB1100AHX2

Cliente: WOM5000 MIMO



Abraços

[rubem]

O Wom5000 discando, ou em bridge?

Se for bridge, tem altas chances de ser malware, tráfego SNMP dependendo do cabeçalho não é barrado no limitador de tráfego, e o MK provavelmente não respondia esses pacotes por identificar ataque (Por isso 0KB de download), mas não tinha como evitar que os pacotes chegassem até ele.

Se a Wom5000 estava roteando, tinha senha não-padrão? Porque tem aqueles malwares que tentam mudar server DNS do que o sistema operacional do cliente enxerga, ou seja, tenta fuçar no primeiro roteador no caminho.

Pra mim isso está claro que era tráfego SNMP, se foi tentativa de ataque por malware ou bug em discador aí é outra estória, mas rede com AP compartilhado sempre vai sofrer com isso, o peso do pacote de dados do sistema operacional do cliente é pequeno, quem afoga os AP's e torna eles lentos (RocketM5 XM engasgando com 20 clientes de CCQ meia-boca) é o monte de pacote SNMP a toa, e reenvios de pacotes perdidos. Contra isso por enquanto não tem solução, só monitorar o tráfego como você fez.

(Digo, o que houver entre o cliente e o servidor de autenticação vai só trafegar tudo sem analisar, o servidor pode negar autenticação mas pra chegar até ele cada pacote já passou por parte da rede, já comeu tempo e processamento da etapa de RF)

[AndrioPJ]

trafego de 25Mb em qual porta/protocolo?

[ajack]

O Wom5000 discando, ou em bridge?

Se for bridge, tem altas chances de ser malware, tráfego SNMP dependendo do cabeçalho não é barrado no limitador de tráfego, e o MK provavelmente não respondia esses pacotes por identificar ataque (Por isso 0KB de download), mas não tinha como evitar que os pacotes chegassem até ele.

Se a Wom5000 estava roteando, tinha senha não-padrão? Porque tem aqueles malwares que tentam mudar server DNS do que o sistema operacional do cliente enxerga, ou seja, tenta fuçar no primeiro roteador no caminho.

Pra mim isso está claro que era tráfego SNMP, se foi tentativa de ataque por malware ou bug em discador aí é outra estória, mas rede com AP compartilhado sempre vai sofrer com isso, o peso do pacote de dados do sistema operacional do cliente é pequeno, quem afoga os AP's e torna eles lentos (RocketM5 XM engasgando com 20 clientes de CCQ meia-boca) é o monte de pacote SNMP a toa, e reenvios de pacotes perdidos. Contra isso por enquanto não tem solução, só monitorar o tráfego como você fez.

(Digo, o que houver entre o cliente e o servidor de autenticação vai só trafegar tudo sem analisar, o servidor pode negar autenticação mas pra chegar até ele cada pacote já passou por parte da rede, já comeu tempo e processamento da etapa de RF)

Grande Rubem

Então, a WOM5000 estava discando... PPPoE... ela era o roteador da rede do cliente.

com o problema atrapalhando todo mundo, optamos por desligar o cliente.

Hoje de manhã fomos no cliente... antena OK... computadores OK... CPE estava com senha, etc....

Ligamos o cliente e estamos monitorando pra saber se irá ocorrer novamente.

[ajack]

trafego de 25Mb em qual porta/protocolo?

Com o desespero de normalizar a rede, nem analisamos a conexão individualmente..... mas era um tráfego que não passava pelo controle de banda.... como o Rubem mencionou, deve ser SNMP ... estamos monitorando pra ver se irá ocorrer novamente.

Será um bug na CPE?

[Aurio]

Aconteceu comigo no sábado, na minha casa perdendo muitos pacotes achei muito estranho porque o AP onde pego sinal o ping excelente, entrei no AP e verifiquei que o TX estava com 8mega de trafego e o RX com 3mega neste AP o RX era sempre foi baixo, foi verificar os clientes conectados e achei um cliente com o upload no maximo, antena do cliente uma proeletronic, desconectei o cliente e o ping ficou normal, no domingo mesmo problema lá foi eu verificar o AP novamente, agora outro cliente com upload no maximo detalhe este cliente uma wom5000.

[rubem]

O ruim é que da base nunca tem como fazer aquela coisa super simples que é REINICIAR o equipto do cliente! Porque software mandando lixo acontece, você reinicia e o problema some, e não se repete por meses ou anos.

Nesses clientes acho que seria bom habilitar o acesso remoto, que seja via SSH, pra poder reiniciar a partir do provedor, e ver se depois de reiniciar esse cliente o problema continua.

Talvez resetar a CPE e configurar de novo, porque Rom teoricamente pode guardar lixo no meio dos dados igual Ram, o reset faz o software regravar algumas coisas, alguma biblioteca que pode estar corrompida (O software acho que não verifica o checksum de todo arquivo a cada boot. Eu tinha um Linksys barato que acho que fazia isso, porque era ligar ele, desligar antes de uns 2 ou 3 segundos, e ligar de novo, que ele dizia que o firmware estava corrompido (Ao entrar no setup ele pedia a imagem de recuperação (*.img pra atualização do firmware)). As urnas eletrônicas no brasil também tem disso, só boota direito depois de ver o checksum de cada arquivinho de 20 bytes, se 1 tiver erro ela não inicia. Os roteadores tem o mesmo kernel linux, mas não fazem isso, assim o boot é muito rápido, mas quando tem esses erros em arquivos menores a gente não fica sabendo, tem que resetar pra reparar tudo.

(No Windows tem o SFC, além do Scandisk. No Linux pra desktop tem coisa tipo o Tripwire, o RSyn tem verificação de checksum que pode escanear tudo, em RPM dá um rpm -a --verify. Em MacOS sei lá. Enfim, a verificação de integridade de cada arquivo existe em sistemas complexos, em CPE isso ia comer tempo e processamento, o cliente não ia entender nada do porque da demora, melhor deixar sem, e em caso de software em loop é só resetar)

[cicero19]

Olá amigo, tudo bem!
Também estou com esse mesmo problema em minha rede, vc encontrou o problema?
Conseguiu resolver?