У меня есть DNS и DHCP-сервер (машина Linux), управляющий моими адресами и именами в локальной сети.
Все настроено и полностью работает после того, как клиенты запущены и работают, имея каждый клиент Mac OS X DHCP с заданным IP-адресом в частном классе 192.168.1.x, заданным DHCP-сервером.
Проблема возникает при перезагрузке, поскольку кажется, что каждая машина запускается в диапазоне 169.x.x.x, и только после получения IP-адреса DHCP все становится нормально ... это временная проблема, которая занимает всего несколько секунд. Меня это очень раздражает, потому что на IDS наблюдатель ARP заполняет журналы тоннами «новых» машин 169.x.x.x
Есть идеи отключить это поведение?
Предполагаемое правильное поведение должно заключаться в получении IP-адреса локальной связи, если и только если машина не может успешно получить IP-адрес, заданный DHCP.
заранее спасибо
РЕДАКТИРОВАТЬ:
Я думаю, что нет проблем с синхронизацией, поскольку кажется, что сервер DHCP внезапно отвечает, будучи станцией macosx, чтобы не продолжать последовательность запросов DHCP.
Как показано в следующем выводе tcpdump, мы видим, что macosx возвращается к link-local сразу после того, как запросил (и получил ответ) для DHCP, он переходит к link-local и только через 8 секунд пытается повторить попытку и завершит новый Запрос DHCP.
ВЫХОД TCPDUMP:
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
Я думаю, что STP не для этого.
РЕДАКТИРОВАТЬ 2:
Я определенно могу заверить, что такое поведение не имеет ничего общего с каким-либо протоколом переключения или конфигурацией, Я подключил Mac mini с Snow Leopard Server непосредственно к своему интерфейсу arpwatcher и увидел то же поведение, что и с коммутатором.
Я думаю, что могу определенно сказать, что это ошибка Apple в реализации локальной ссылки в OS X.
Поскольку локальный блок 169.254.0.0/16 не может быть маршрутизирован, почему это беспокоит вашу IDS? Просто игнорируйте это. (Просто убедитесь, что ваши маршрутизаторы действительно блокируют это.)
На мой взгляд, каждый хост IPv4 должен получить и хранить адрес в блоке 169.254.0.0/16, так же как каждый интерфейс IPv6 уже должен иметь локальный адрес канала. Они могут быть очень полезно, когда что-то ломается.
К сожалению, я сомневаюсь, что вы найдете решение этой проблемы. Отчасти причина в том, что Mac OS X, особенно. 10.4 Tiger и более поздние версии очень асинхронны. Большая часть управления стартапом осуществлялась launchd так как Тигр и я считаю, что все это как Леопарда.
launchd не имеет поддержки зависимостей, поэтому большинству демонов и им подобных приходится проводить собственный опрос служб, чтобы узнать, готовы они к работе или нет (см. Темы программирования при запуске системы: процесс загрузки, но имейте в виду, что SystemStarter ушел как Леопард). Есть ряд каркасов, которые делают тяжелую работу, например Конфигурация системы, но я предполагаю, что для того, чтобы все это работало, им пришлось принять решение, что если порт Ethernet имеет ссылку, но они еще не получили ответ DHCP, им необходимо установить его на IP-адрес локальной ссылки .
Похоже, что проблема в том, что на запрос DHCP не отвечает достаточно быстро. Если настроен для DHCP, машина запустится без IP-адреса (0.0.0.0) и отправит широковещательный запрос. Только если он не получит ответа в течение требуемого времени, он присвоит себе адрес локальной ссылки.
Коммутаторы, на которых запущено связующее дерево, будут демонстрировать такое поведение, потому что они сначала должны пройти процесс обнаружения петель STP, прежде чем разрешить устройству передачу. На коммутаторах Cisco вы можете включить "Spanning Tree Portfast", чтобы обеспечить устройству более быстрый доступ к сети.
Вместо того, чтобы пытаться изменить поведение Mac (в любом случае я сомневаюсь, что вы сможете), почему бы просто не настроить правила IDS или уровни запуска? Мне кажется, что ваша IDS слишком чувствительна к нормальной и ожидаемой сетевой активности.