Como posso evitar que o Mac OS X defina temporariamente seu IP no intervalo "link-local" (169.254.x.x) no momento da inicialização?

Question

Eu tenho um servidor DNS e DHCP (máquina Linux) gerenciando meus endereços e nomes de LAN.

Tudo está configurado e funcionando totalmente quando os clientes estão em funcionamento, tendo cada cliente do Mac OS X como um IP fornecido por DHCP na classe privada 192.168.1.x conforme determinado pelo servidor DHCP.

O problema aumenta com a reinicialização, uma vez que cada máquina parece inicializar no intervalo 169.x.x.x e somente depois de obter o IP do DHCP tudo gira em ordem ... isso é um problema temporário e leva apenas alguns segundos. Isso é muito chato para mim, porque no IDS o observador ARP inunda os logs com toneladas de 169.x.x.x "novas" máquinas

Alguma ideia para desativar este comportamento?

O suposto comportamento correto deve ser obter um endereço IP de link local se, e somente se, a máquina não conseguir obter com êxito um IP fornecido por DHCP.

Obrigado antecipadamente

EDITAR:

Eu acho que não há nenhum problema de cronometragem, como parece que as respostas do servidor DHCP de repente, sendo a estação macosx para não continuar a seqüência de pedidos DHCP.

Como mostrado pela seguinte saída do tcpdump, vemos que o macosx retorna ao link-local logo após ter pedido (e ter respondido) um DHCP, ele continua com link-local e somente após 8 segundos ele tenta novamente e finaliza uma nova solicitação DHCP.

TCPDUMP OUTPUT :

    19:49:32.373567 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:4b:ac:ae:be (oui Unknown), length 300
    19:49:32.373754 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc: BOOTP/DHCP, Reply, length 300


    19:49:32.374119 arp who-has 169.254.22.58 tell 0.0.0.0
    19:49:32.774285 arp who-has 169.254.22.58 tell 0.0.0.0
    19:49:33.174403 arp who-has 169.254.22.58 tell 0.0.0.0
    19:49:33.574622 arp who-has 169.254.22.58 tell 169.254.22.58
    19:49:33.974890 arp who-has 169.254.22.58 tell 169.254.22.58
    19:49:33.984227 IP 169.254.22.58 > 224.0.0.251: igmp v2 report 224.0.0.251
    19:49:34.978606 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 [5q] [4n] PTR (QM)? 58.22.254.169.in-addr.arpa.[|domain]
    19:49:35.078822 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 5/0/0 PTR[|domain]
    19:49:35.229123 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 [4q] [4n][|domain]
    19:49:35.479441 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 [4q] [4n][|domain]
    19:49:35.728759 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 11/0/0[|domain]
    19:49:35.981123 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 58.22.254.169.in-addr.arpa. (44)
    19:49:36.081741 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 4/0/0 PTR[|domain]
    19:49:36.729630 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 11/0/0[|domain]
    19:49:36.808274 arp who-has fw1.dearchstudio.lan tell Conference-Rooms-Mac-mini.local
    19:49:36.808290 arp reply fw1.dearchstudio.lan is-at 00:0e:0c:69:b6:10 (oui Unknown)
    19:49:36.808424 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:4b:ac:ae:be (oui Unknown), length 300
    19:49:36.808609 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc: BOOTP/DHCP, Reply, length 300
    19:49:37.656051 IP 169.254.22.58 > 224.0.0.251: igmp v2 report 224.0.0.251
    19:49:38.081483 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 15/0/0[|domain]


    19:49:40.264083 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:4b:ac:ae:be (oui Unknown), length 300
    19:49:40.264252 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc: BOOTP/DHCP, Reply, length 300
    19:49:40.264735 arp who-has Conference-Rooms-Mac-mini.local tell 0.0.0.0
    19:49:40.664952 arp who-has Conference-Rooms-Mac-mini.local tell 0.0.0.0
    19:49:40.696059 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
    19:49:40.796526 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 14/0/0[|domain]

dhcpd.log :

fw1:~# tail /var/log/dhcpd.log
Aug 11 19:45:52 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:45:56 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 from 00:25:4b:ac:ae:be via eth1
Aug 11 19:45:56 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:48:08 fw1 dhcpd: DHCPDISCOVER from 00:13:21:b8:46:e0 via eth1: network 192.168.1/24: no free leases
Aug 11 19:49:32 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 from 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:32 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:36 fw1 dhcpd: DHCPDISCOVER from 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:36 fw1 dhcpd: DHCPOFFER on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:40 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 (192.168.1.254) from 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:40 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1

Eu acho que STP não é uma questão para isso.

EDIT 2:

Eu definitivamente posso garantir que esse comportamento não tem nada a ver com qualquer protocolo ou configuração de switch , conectei um Mac mini com o Snow Leopard Server diretamente à minha interface arpwatcher e vi o mesmo comportamento que com o interruptor.

Acho que posso dizer definitivamente que este é um BUG da Apple na implementação do link local no OS X .

    

Answer 1

Parece que pode haver um problema com a solicitação DHCP não ser respondida com rapidez suficiente. Se configurado para DHCP, a máquina será inicializada com nenhum endereço IP (0.0.0.0) e enviará uma transmissão solicitando uma. Somente se não obtiver resposta no período de tempo necessário, será atribuído um endereço de link local.

Os comutadores que executam spanning-tree exibirão esse comportamento porque precisam passar primeiro pelo processo de detecção de loop de STP antes de permitir que o dispositivo transmita. Nos switches da Cisco, você pode ativar o "spanning-tree portfast" para permitir que o dispositivo tenha acesso mais rápido à rede.

    

Answer 2

Infelizmente, duvido que você encontre uma solução para isso. Parte da razão é que o Mac OS X, esp. 10.4 Tiger e mais tarde, é altamente assíncrono. A maior parte do gerenciamento de inicialização foi gerenciada por launchd , uma vez que Tiger e eu acreditamos que tudo isso é do Leopard.

launchd não tem nenhum suporte a dependências, então a maioria dos daemons e de tais pessoas tem que fazer sua própria pesquisa de serviços para ver quando estão prontos e prontos (veja Tópicos de programação de inicialização do sistema: o processo de inicialização , mas esteja ciente de que SystemStarter desapareceu do Leopard). Há várias estruturas que fazem o trabalho pesado, como Configuração do sistema , mas Eu suponho que, para fazer tudo funcionar, eles tiveram que tomar a decisão de que se a porta ethernet tiver um link, mas eles ainda não obtiveram uma resposta DHCP, eles precisam configurá-la para um IP de link local. / p>     

Answer 3

Como o bloco link-local 169.254.0.0/16 não pode ser roteado, por que é uma preocupação para o seu IDS? Simplesmente ignore isso. (Apenas certifique-se de que seus roteadores realmente bloqueiam).

Na minha opinião, todo host IPv4 deve obter e manter um endereço no bloco 169.254.0.0/16, assim como toda interface IPv6 já é necessária para ter um endereço local de conexão. Eles podem ser muito úteis quando as coisas quebram.

    

Answer 4

Em vez de tentar modificar o comportamento dos Macs (duvido que você possa, de qualquer forma), por que não simplesmente ajustar as regras do IDS ou os níveis de acionamento? Parece-me que o seu IDS é excessivamente sensível à atividade de rede normal e esperada.