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

[Shine]

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
>