[FUG-BR] RES: RES: RES: Aliases de IP no 7.x (era: FreeBSD 7.1 Release para AMD64)

[Trober]

> Que coisa grotesca, engraçado ele não ter se reproduzido aqui comigo, será
> que é quando são diversos aliases segmentando uma rede na mesma placa?
> Porque aqui uso no máximo 5 ou 6 /29 e está tudo OK.
>
> Bom... logo que você usa isto só para segmentar "logicamente" os clientes,
> não fisicamente(já que a interface é a mesma)...
>
> Nada impede que você coloque o IP
>
> 192.168.20.1, 20.5, 20.9, 20.13....
>
> Todos com mascara /24
>
> E o cliente com máscara /30
>
> Gambiarra terrível, mas até isto resolver.
>
> Alias, que bug medonho hein
>
>
>
>>
>> Olá Renato (na carona, também respondo ao Celso Viana).
>>
>> Sim, infelizmente. O problema persiste, mesmo na adição manual (no
>> "braço", via shell) de alias de IP :(
>>
>> Nas garimpadas que fiz em busca de uma solução, encontrei muita gente
>> com
>> este problema, e inclusive abandonando a série 7.x para voltar ao 6.4.
>>
>> Encontrei (se entendi certo) até um maluco sugerindo comentar[1] a
>> mensagem de erro! O problema não é só a exibição da mensagem, e sim a
>> inoperância do conjunto.
>>
>> Este problema atingiu tal proporção, que tem gente colocando uma placa
>> de
>> rede para cada subnet[2]!!
>>
>> E agora? hehe (rir para não chorar)
>>
>> [1]
>> http://blog.weithenn.org/2009/05/freebsdkernel-arplookup-ip-failed-
>> host.html
>>
>> [2] http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-
>> 07/msg00135.html
>>
>> Saudações,
>>
>> Trober
>>
>> -
>> -
>> -
>> -
>> -
>>
>>
>>
>>
>>
>>
>



Eita! Acredito que resolvi o problema! :D

Corrijam-me seu eu estiver errado na análise:

Como a mensagem "host is not on local network" é exibida na passagem do
primeiro pacote de dados da placa interna (re0) do servidor, isso remete à
compreensão de que esse host/rede não é local, resolvi ver o comportamento
da tabela de roteamento.

Destination       Gateway      Flags  Refs Use Netif
192.168.20.8/30   192.168.20.9 UGC    1    0   re0
192.168.20.10     192.168.20.9 UGCHW3 0    1   re0

Estudei um pouco mais o serviço router, e encontrei citações que
router_enable habilitado em /etc/rc.conf faz com que a tabela aprenda as
rotas que "ouve" por RIP[1]. No mesmo instante, lembrei que em PPP, o
router não pode estar habilitado, pois pode apagar deliberadamente[2]
apontamentos da tabela de roteamento.

Logo, imaginei o serviço router apagando os apontamentos que tenho na
minha tabela de roteamento. Então, desativei router no /etc/rc.conf.

E a tabela mudou para:

Destination       Gateway           Flags  Refs Use Netif
192.168.20.8/30   link#2            UC     0    0   re0
192.168.20.10     aa:bb:cc:dd:ee:ff UHLW   1    297 re0

Agora vem a parte punk:

No FreeBSD 6.x, independente de estar o serviço router habilitado ou não,
os apontamentos estáticos ou de interfaces locais (FLAG "S" e "C",
respectivamente) ficam intactos. No FreeBSD 7.x, com o serviço router
habilitado, acontece a bizarrice, criando e apagando rotas com critérios
que desconheço. Será um bug do 7.x?

Pois bem, galera, como dizem no jargão religioso: "contar o milagre e não
mostrar o santo". Não curto muito resolver um problema e não apontar a
origem, mas a solução está em desativar o serviço router no FreeBSD 7.x, e
ser feliz, como quando se usa o mesmo arquivo /etc/rc.conf igual ao
existente no FreeBSD 6.4 (mas com router_enable="NO").

Farei vários testes mais punks aqui e, obtendo êxito, postarei, daqui
alguns dias, a solução como "resolvida" (assim espero!), pois não a julgo
concluída.

[1] Absolute BSD - The Ultimate Guide to FreeBSD (Michael Lucas, p. 219).
[2] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/userppp.html

Saudações,

Trober
-
-
-
-
-