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

[Shine]

Veja que "não deveria" é o comportamento esperado, mas não quer dizer que o
equipamento da localweb siga esse comportamento.
Sendo pragmático, se não dá certo, então melhor mudar mesmo o arp para 4
horas, pq segundo seu relato anterior, qdo expira o tempo na tabela da
localweb, o equipamento responde ao arp request. Sendo um valor padrão, vc
não deverá ter maiores problemas com demais equipamentos, a não ser que vc
tenha algum esquema de redundância ou clustering ou algo do gênero.


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
>