> 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 - - - - - ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd