[GTER] PTT-SP, arp-request sem arp-reply

Tue Mar 19 23:02:31 -03 2013

Pessoal, como o assunto acabou voltando a ser levantado na lista e eu ainda
não havia postado nada até hoje, resolvi então escrever para  relatar nossa
situação atual.
Depois de muitas buscas acabei me deparando com este material do Amsterdam
Internet Exchange:

https://www.ams-ix.net/technical/specifications-descriptions/config-guide#11

Como eu havia dito, utilizamos linux como roteador, então, fiz as seguintes
configurações:

net.ipv4.neigh.IF_XXX.base_reachable_time = 14400
net.ipv4.neigh.IF_XXX.gc_stale_time = 1200

Depois disso não tive mais problemas com a Locaweb.
Minha teoria é a seguinte, como a configuração padrão traz um tempo muito
curto, o roteador acaba fazendo muitas requisições broadcast, com isso
algum filtro deve negar estas requisições, depois de um tempo ele acaba
aceitando novamente ou então minha entrada desaparece com o decorrer do
tempo no roteador remoto e quando ele precisa falar com minha rede ele gera
uma requsição e neste momento a tabela arp de ambos é atualizada. Durante
os testes chegamos a fazer isso com a equipe da locaweb e funcionou. Com o
tempo maior configurado em nosso roteador, as requisições broadcast
diminuem consideravelmente e com isso o problema praticamente desaparece.
Não obtive nenhuma confirmação da locaweb sobre a existência de tais
filtros, nem sei se estes filtros seriam realmente da Locaweb.

O Rubens havia comentando em uma de suas mensagens que estes tempos
"desajustados" poderiam causar comportamentos exóticos e pelo que pude ver
realmente eram eles os culpados pois desde o dia 04/03 não tive mais
problemas com a Locaweb.

Mais uma informação, a tabela arp de nosso roteador conectado ao ptt-sp
possuia em média cerca de 150 entradas até fazermos estas configurações,
depois disso ele passou a ficar com cerca de 250 entradas quase que direto
e em alguns momentos ele chega bem perto de 300 entradas.

Ainda tenho outros 2 problemas na comunicação via PTT, mas isso é assunto
para outra thread.

Obrigado a todos.

Att.

Em 28 de fevereiro de 2013 10:04, Douglas Fischer
<fischerdouglas at gmail.com>escreveu:

> Chegou a cogitar algum mecanismo de segurança implementado que leve ao
> bloqueio desse mac?
> Seja na sua estrutura(outer ou switch), no seu transporte, ou no PTT?
>
> Uma possibilidade seria o participante estar fazendo arps gratuitos
> excessivos e algum mecanismo acabar bloqueando ele.
>
> P.S.: Apenas para exemplificar, um amigo andou pegando broadcast com source
> 0.0.0.0 chegando pela interface dele ligada ao PTT-CWB.
>
> Em 28 de fevereiro de 2013 08:17, Paulo Henrique
> <paulohenriquef at gmail.com>escreveu:
>
> > Sim, você tem razão.
> > Deixei em teste desde ontem por volta das 17hs com 20 minutos mas mesmo
> > assim ainda não tenho o reply, por isso o mac não aparece na tabela arp
> do
> > roteador.
> > Ainda estou tentando encontrar o que pode estar causando este
> > comportamento.
> >
> >
> > Em 27 de fevereiro de 2013 13:26, Shine <eshine at gmail.com> escreveu:
> >
> > > Conforme MrGuga citou, o comportamento não é assim. ARP não é como um
> > OSPF
> > > hello, onde os timers devem ser idênticos.
> > > Se ele tem o valor de 4 horas (que é um padrão conhecido), não quer
> dizer
> > > que o equipamento não deva responder ao arp request, mas sim que ele
> não
> > > pede arp request até expirar a tabela dele.
> > > Por um outro lado, ter uma entrada arp com 30 a 60 segundos de tempo
> para
> > > expirar não parece fazer sentido. Talvez seja possível que exista algum
> > > elemento de segurança (IPS/IDS) que entenda que é um padrão de ataque e
> > > esteja matando o ARP request.
> > >
> > > Acho que não faria mal se vc alterar o timeout para um valor maior. Se
> > por
> > > algum motivo particular não pode ser 4 horas, tente algo como 5
> minutos,
> > > que é o tempo padrão para expirar uma entrada da tabela mac..
> > >
> > >
> > >
> > > Em 26 de fevereiro de 2013 11:20, Paulo Henrique
> > > <paulohenriquef at gmail.com>escreveu:
> > >
> > > > Pessoal, ao que me parece o que está havendo é o seguinte, segundo o
> > > > pessoal da Locaweb o timeout de cada entrada na tabela arp do
> roteador
> > > > deles é de 4hs, já do meu lado, estou com a configuração default, se
> > não
> > > me
> > > > engano 30 ou 60 segundos.
> > > > Então quando a entrada na tabela do nosso roteador expira a entrada é
> > > > removida, quando for necessário "falar" com a locaweb novamente um
> > > > arp-request será gerado, mas como a entrada ainda existe na tabela
> arp
> > do
> > > > roteador deles o arp-reply não é gerado.
> > > > Por isso, se eu coloco a entrada estática no nosso roteador, tudo
> > > funciona
> > > > normalmente.
> > > > Como debugamos junto com o pessoal da Locaweb e eles constataram que
> o
> > > > arp-request chega mas o reply não é enviado, acredito que isso faz
> > > sentido,
> > > > mas neste caso vem a pergunta: Este comportamento é o previsto ou é o
> > > > correto?
> > > > Aumentando o timeout em nosso roteador pode ajudar? Ter 4 horas dos
> > dois
> > > > lados pode nos ajudar, mas e no caso dos outros participantes?
> > > >
> > > > Pensando no caso em que um de nossos colegas passou por um problema
> > > > semelhante e o mesmo foi solucionado com shutdown na porta do switch
> do
> > > > lado do ptt, fiquei pensando se neste caso as duas entradas (ponta a
> e
> > b)
> > > > não expiraram pois realmente a comunicação foi interrompida e quando
> > elas
> > > > voltaram as duas tabelas arp foram atualizadas como o esperado.
> Fiquei
> > > > pensando nisso porque se o pessoal da locaweb remove a nossa entrada
> da
> > > > tabela arp do roteador deles, tanto o roteador deles quanto o nosso
> > > aprende
> > > > novamente como deveria acontecer, mas logo quando a entrada em nosso
> > > > roteador expira o problema volta a ocorrer. Neste caso aumentar o
> > timeout
> > > > iria garantir que o problema vai demorar mais para ocorrer, mas não
> > quer
> > > > dizer que não irá ocorrer nunca mais e pelo que o colega mencionou,
> ele
> > > já
> > > > passou por isso mais de uma vez.
> > > >
> > > > Obrigado a todos.
> > > >
> > > >
> > > >
> > > > Em 23 de fevereiro de 2013 12:43, Paulo Henrique
> > > > <paulohenriquef at gmail.com>escreveu:
> > > >
> > > > > Bom dia pessoal, a cerca de dois dias identificamos em nossa
> > estrutura
> > > > uma
> > > > > situação que ainda não sabemos a causa e não conseguimos resolver.
> > > > >
> > > > > Depois de receber a reclamação de um cliente que tentava acessar
> > algum
> > > > > site hospedado na Locaweb e não conseguia, constatamos que nosso
> > > roteador
> > > > > não aprendia o endereço MAC do equipamento da Locaweb plugado ao
> > > PTT-SP,
> > > > > onde também estamos conectados.
> > > > > Ao debugar o problema junto ao pessoal do PIX onde estamos ligados
> e
> > > > > também junto ao pessoal da Locaweb (que nos atendeu muito bem),
> ainda
> > > não
> > > > > foi possível resolver o problema. Por isso recorro aos colegas para
> > > > tentar
> > > > > encontrar o que poderia estar causando isso.
> > > > >
> > > > > Utilizamos como roteador uma caixa com Linux + Quagga.
> > > > >
> > > > > Quando faço um tcpdump na interface/vlan de nosso roteador ligada
> ao
> > > ptt,
> > > > > vejo os arp-request saindo mas nada de resposta. Ao debugar junto
> ao
> > > > > pessoal da locaweb, constatamos que o equipamento deles aprende o
> > > > endereço
> > > > > mac de nosso roteador, recebe nossos arp-request mas não envia os
> > > > > arp-reply. Quando nosso endereço é removido manualmente da tabela
> arp
> > > do
> > > > > equipamento da locaweb, ele aprende novamente nosso mac e desta vez
> > ele
> > > > nos
> > > > > envia o arp-reply. Com isso tudo funciona como o esperado, mas
> apenas
> > > > até o
> > > > > endereço aprendido por nosso roteador expirar, depois disso o
> > problema
> > > > > volta a ocorrer novamente.
> > > > >
> > > > > Se o endereço mac da locaweb for incluido estaticamente na tabela
> > arp a
> > > > > comunicação flui perfeitamente.
> > > > > Fiz este teste com outro particpante do ptt-sp do qual não
> recebemos
> > o
> > > > > arp-reply e também funcionou.
> > > > >
> > > > > Repeti todos os testes com 3 roteadores linux diferentes, todos
> > > plugados
> > > > > ao PTT-SP usando vlans diferentes (ASNs diferentes), um deles
> > > apresenta o
> > > > > problema raramente, outro apresenta o problema com mais frequência
> > mas
> > > > > funciona na maioria das vezes e o terceiro não funciona de forma
> > > alguma -
> > > > > este é o roteador onde o problema foi identificado.
> > > > >
> > > > > Hoje notei que na tabela arp dos dois roteadores que apresentam
> mais
> > > > > problemas, existem outros endereços de participantes do PTT-SP que
> > não
> > > > são
> > > > > aprendidos, são quase 10 endereços.
> > > > > Por isso fico pensando se não existe algum ajuste ou coisa do tipo
> a
> > > ser
> > > > > feito, mas não consigo imaginar o que seria ou onde fazer tais
> > ajustes.
> > > > > A tabela arp destes roteadores possui algo entre 100 e 150
> endereços
> > e
> > > os
> > > > > logs não apresentam nenhuma mensagem como overflow da tabela arp ou
> > > algo
> > > > do
> > > > > tipo.
> > > > >
> > > > > A placa de rede ligada ao PTT-SP é uma Marvel 88E8053.
> > > > >
> > > > > Gostaria de ressaltar que informei o nome da locaweb apenas porque
> > > foram
> > > > > muito atenciosos em me ajudar na solução do problema e não vejo
> > > problema
> > > > na
> > > > > divulgação do ocorrido pois acredito que o problema possa estar com
> > > > nossos
> > > > > equipamentos, mas não sei onde ou o que é.
> > > > >
> > > > > Att.
> > > > >
> > > > > --
> > > > > Paulo Henrique Fonseca
> > > > > paulohenriquef at gmail.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Paulo Henrique Fonseca
> > > > paulohenriquef at gmail.com
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> >
> >
> >
> > --
> > Paulo Henrique Fonseca
> > paulohenriquef at gmail.com
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Paulo Henrique Fonseca
paulohenriquef at gmail.com