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

[Paulo Henrique]

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