[GTER] proxy arp terror

[Edv]

Creio que o modelo seja esse mesmo, roteamento vai-e-volta.

Inclusive a Telefonica alega que é necessário colocar um roteador conectado
à porta ethernet do roteador SDH, antes de encaminhar as subnets a uma
máquina que aplique o QoS, e distribua os serviços e endereços IP.

O fato de existir uma porta ethernet sorrindo para mim, no router SDH, me
levou a desconfiar dessa informação. Não dá pra acreditar em justificativas
do tipo "não pode e pronto"... Fiquei triste e surpreso ao constatar que, de
fato, os pacotes não atravessavam meu fw Mikrotik. Mas foi só plugar um
cisco com duas ethernets e voilá!!! Tudo fluiu perfeitamente!

RTFMs (da própria cisco inclusive), e procurando aqui e ali, observei esse
detalhe do proxy-arp habilitado por default, Rubens. Quando ele é
habilitado, ele "clona" o MAC do roteador da frente, e dessa forma tem
acesso às redes que circulam do outro lado. Montei novamente meu cenário com
Mikrotik, e habitei o proxy-arp na NIC (na época apenas uma) conectada à
ethernet do router SDH. Pronto! Funcionou lindo!

Não quero cair no abismo de comparações entre as
soluções high and low-end (leia cost-effectiveness), todavia ficou claro que
"pode sim" uma máquina PC fazer a função do roteador. Não havia nenhuma
necessidade de conversão de mídia, por exemplo, ou algo que realmente
justificasse a solicitação.

Voltando à vaca fria, ao
substituir a NIC desse router linux, começou a confusão com o proxy-arp.

De dentro da minha caverna, imagino que alguém dê um "clear arp cache", do
outro lado (Telefonica), para voltar a funcionar.

Essa renovação da tabela de ARPs poderia ser a vilã? O que levaria o
processo a ser demorado?

Obrigado a todos pela paciência. Desculpem se teclo demais...


E.


On 1/17/08, Rubens Kuhl Jr. <rubensk at gmail.com> wrote:
>
> Proxy-arp ser habilitado por default é uma crítica antiga de usuários
> Cisco; 10 de cada 9 templates e guias de configuração começam com "no
> ip proxy-arp".
>
> Dependendo das combinações de versões de software e configurações de
> todos os envolvidos e até mesmo de race-condition entre equipamentos
> do mesmo barramento pode até funcionar, mas não é surpresa algo que
> funcionava com proxy-arp deixar de funcionar.
>
> Há alguns cenários razoáveis para uso de proxy-arp (como o de sistemas
> que dependem de roteamento vai-e-volta, one-leg etc.), mas se você não
> precisa de proxy-arp, não use. Você será um engenheiro de rede mais
> feliz.
> [cut]