[GTER] Problema estranho de rede com arp e ndp

[Marcelo Gondim]

Em 06/05/14 23:18, Shine escreveu:
> Oi Gondim,
>
> No caso eu não sabia se era um ou mais switches Datacom. Como você sabe, o
> Datacom é um metro switch, então ele faz desde um encaminhamento comum em
> cima de VLANs e portas como também poderia carregar os pacotes de um lado
> para o outro usando pseudo wires em cima de uma rede MPLS, por exemplo.
>
> Acho que pelo seu teste fica claro que o problema está mesmo no
> encaminhamento dos frames. Os routers não têm esse discernimento de saber
> que existe um switch no meio ou não para alterar pacotes, ainda mais sendo
> uma rede de camada 2. ;)
>
> Acredito que seja mesmo um problema relacionado com alguma configuração
> específica na porta ou alguma policy que faz com que o broadcast arp seja
> barrado e apenas em um sentido. Eu não sei os detalhes da configuração, mas
> se for algo padrão (isto é, mesma VLANs nas portas, mesmas propriedades de
> acesso, etc.) vc poderia inverter a ordem das portas para ver se o problema
> se inverte, observar se nessa caso o router A é que deve começar a pingar
> para assim o ARP ser reconhecido no router B. Se não inverter, você pode
> partir para uma análise mais voltada para fluxo, por exemplo revisar alguma
> eventual política de QoS, ACLs...
Opa Shine,

Pois é muito sinistro. A operadora inclusive está abrindo o chamado na 
Datacom para resolvermos isso.
Vamos ver qual será o desfecho disso.  :)

>
>
> Em 6 de maio de 2014 22:10, Marcelo Gondim <gondim at bsdinfo.com.br> escreveu:
>
>> Em 06/05/14 18:02, Shine escreveu:
>>
>>   O ARP Request é mac broadcast, então existe uma chance do router B não
>>> estar recebendo o ARP Request do router A por algum bloqueio de mac
>>> broadcast na porta do router A. Quando você faz o ping na direção
>>> contrária, o broadcast parte de B para o router A, passa OK e o router A
>>> responde por unicast, o que provavelmente passa pelo switch.
>>> Bem, é uma teoria... só mesmo fazendo um sniffer e vendo a troca de frames
>>> para entender o que realmente acontece.
>>>
>>> Um workaround simples, seria usar uma entrada ARP estática no router A.
>>> Não
>>> é o ideal, pq qdo você mudar a interface física do router B essa entrada
>>> teria que ser alterada manualmente...
>>>
>> Olá Shine,
>>
>> Adicionando mais um dado: se eu ligo o Router A direto com o Router B sem
>> passar pelo Datacom, funciona para ambos os lados.
>> O problema está no Datacom pelo visto mas não faço ideia do que seja.
>>
>>
>>> Em 6 de maio de 2014 17:04, Marcelo Gondim <gondim at bsdinfo.com.br>
>>> escreveu:
>>>
>>>   Prezados,
>>>> Uns anos atrás isso aconteceu comigo mas não lembro como resolvi e por um
>>>> acaso hoje ocorreu o mesmo problema só que com IPv6 também.
>>>> Vou descrever o que acontece... Tem um router na ponta A, outro router na
>>>> ponta B e no meio um Switch Datacom.
>>>>
>>>> Router A ------ Datacom ------ Router B
>>>>
>>>> Eu estou conectado remotamente em A. Quando tento um ping ou ping6 para
>>>> os
>>>> IPs IPv4 e IPv6 do Router B, simplesmente não pinga. Vão as solicitações
>>>> de
>>>> arp e ndp mas não retorna resposta alguma de B. Aí do Router B tento
>>>> fazer
>>>> o mesmo para o Router A e nesse momento consigo pingar tanto v4 quanto
>>>> v6.
>>>> Depois que faço isso, passo à conseguir pingar também do Router A para o
>>>> B.
>>>> Ou seja, só consigo pingar de A para B se B me pingar antes.
>>>>
>>>> Depois que B pinga A o mac address vai para as tabelas arp e ndp pelo
>>>> tempo de expiração e fica funcionando até expirar. Depois disso só
>>>> pedindo
>>>> pra B novamente uma ajuda.  :(
>>>>
>>>> Alguém faz ideia do que seja isso? Não lembro o que fiz no passado para
>>>> resolver isso, mas tenho quase certeza que era hardware.