Фон
У меня есть DHCP-сервер Windows (Server 2008 R2), раздающий адреса для нескольких областей. Одна из этих областей применения предназначена для некоторых IP-телефонов Mitel. Телефоны настроены на использование опции 125 DHCP для получения информации о конфигурации. Когда телефон запускается, он не знает, какой vlan использовать, и поэтому он просто получает vlan по умолчанию (без тегов) любого порта, к которому он подключен. Сервер dhcp дает ему ответ, который включает в себя информацию о параметре 125, и телефон может прочитать из этого ответа, какой vlan он должен использовать. Затем телефон освобождает свой первоначальный адрес и запрашивает новую аренду dhcp, используя правильный тег vlan. Телефоны также обычно имеют компьютеры, подключенные к сквозному порту. Пакеты с компьютеров никогда не помечаются, поэтому компьютеры останутся в исходном (нетегированном) vlan для порта. Это работало для нас годами.
Проблема и симптомы
Где-то за последние несколько недель что-то изменилось, и я не уверен, что. Телефоны будут продолжать работать до тех пор, пока они не перезапустятся, то есть запросы на обновление dhcp должны обрабатываться правильно. Телефоны, подключенные к определенным коммутаторам, могут даже пережить перезапуск. Однако телефоны, подключенные к другим коммутаторам, не смогут завершить процесс при перезагрузке. Все наши телефоны используют PoE, резервное копирование которого осуществляется от ИБП, поэтому с момента перезапуска прошло много времени. Это означает, что я понятия не имею, когда проблема появилась впервые. Что я действительно знаю, так это то, что один телефон вышел из строя, когда он перезапустил вчера, и при устранении неполадок сегодня мы сбрасываем этот коммутатор. Теперь ни один из телефонов на этом коммутаторе не работает (к счастью, это все еще небольшое количество). Я также знаю, что все работало ближе к концу января,
Наблюдая за загрузкой телефона, я вижу, что он успешно получил первый адрес. Затем он успешно считывает информацию о параметре 125, устанавливает правильный тег vlan и освобождает первоначальную аренду IP. Он даже может получить и принять предложение по правильному VLAN с сервера . Однако на этом все и заканчивается. На экране телефона появляется сообщение « DHCP: Offer 2 ACC», но DHCP-сервер Windows не записал аренду, и телефон не включается. Я могу только догадываться, что пакет DHCP REQUEST никогда не достигает сервера Windows, и поэтому телефон ожидает окончательного подтверждения от Windows, который можно продолжить.
Временное решение
Я наконец смог заставить телефон работать снова. Для этого мне пришлось сначала отключить компьютер. Затем я установил порт коммутатора телефона без тегов на телефоне vlan, не имея членства на ПК vlan. Телефон теперь перезагрузится правильно. На этом этапе я могу вернуть конфигурацию порта коммутатора туда, где она должна быть, и до тех пор, пока никто не пытается набрать этот номер, пока я сбрасываю порт, телефон никогда не пропускает такт. Тогда я могу снова подключить компьютер. Очевидно, что это не идеальный процесс, хотя, так как телефоны перезагружаются так редко, я смогу использовать его, чтобы заставить людей работать снова, пока я не смогу найти основную причину. Офисы сейчас закрыты на неделю, и поэтому этот вопрос будет разрешен на выходных (у меня нет ключей для отдельных офисов, где есть телефоны).
Этот телефон, который я установил, является служебным телефоном в серверной комнате, подключенным напрямую к нашему базовому коммутатору. Возможно, проблема связана с маршрутизацией или обработкой тегов на основном коммутаторе, так что обходной путь не будет эффективным в удаленных офисах, где пакеты сначала проходят (помечены) другими коммутаторами, но я буду очень удивлен если это произойдет, учитывая, что я знаю, что он должен правильно обрабатывать обновления dhcp и фактические телефонные разговоры.
Проблема заключается в том, что оставление порта, помеченного на ПК, означает, что вместо этого произойдет сбой телефона с сообщением " DHCP: Offer 1 ACC". Мне нужно полностью удалить этот VLAN, чтобы добиться успеха.
Примечание. Теперь я подтвердил, что обходной путь эффективен в удаленных зданиях. Это заставляет меня заподозрить, что мои устройства как-то не привязаны к правильному vlan. Тот факт, что у меня возникла проблема с коммутатором ядра, и что это произошло в нескольких местах в сети примерно в одно и то же время, указывает на то, что проблема может быть в коммутаторе ядра. Не имея ничего конкретного, я планирую на конец недели окно обслуживания, чтобы перезагрузить коммутатор. Я также могу обновить прошивку.
Окружающая обстановка
Наш основной коммутатор - HP 5406zl. Этот коммутатор управляет межлановой маршрутизацией. DHCP-сервер Windows подключен напрямую к коммутатору. Коммутаторы конечных точек подключаются к базовому коммутатору через оптоволоконные SFP, и эти порты помечены для всех VLAN на обоих концах. Основной коммутатор настраивает каждый vlan с помощью ip helper-addressпараметра, указывающего его на наш DHCP-сервер, и dhcp relay-option 82 replaceлинии, чтобы сервер dhcp знал, какую область применения использовать. Эти конфигурации и конфигурации портов на коммутаторах конечных точек не изменились по крайней мере за 16 месяцев. У нас был другой переключатель и телефон сбрасывает в то время.
Большинство наших конечных коммутаторов серии HP 2530. Похоже, что эти переключатели работают правильно (телефоны на 3 разных 2530 перезапустились сегодня правильно). Это старые коммутаторы, которые имеют проблемы. У нас есть один старый 3Com 4200 и один 4210, который не будет работать. Служебный телефон, подключенный непосредственно к коммутатору ядра, упомянутому ранее, также не будет работать.
Вопрос
На данный момент я думаю, что обновление Windows на сервере DHCP изменило поведение, но я не понимаю, как это сделать. Или, возможно, основной коммутатор не обрабатывает этот пакет REQUEST правильно, но я уверен, что там ничего не изменилось, и это не объясняет, почему выполняются только определенные коммутаторы конечных точек. Как я могу решить эту проблему?
Обновить:
Вот выдержка из журнала dhcp с неисправного телефона:
10,03 / 06 / 15,12: 40: 40, Assign, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Renew, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Release, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,,
Адреса 10.xxx - это ПК vlan (этот выбор предшествует мне в этом месте). Телефоны должны сначала получить такой адрес, так что это ожидаемо. Однако после сообщения о выпуске я также ожидаю найти предложение для адреса в диапазоне 192.168.16.x, потому что по телефону я вижу, что предложение было принято (если я не неправильно понимаю «ACC»). Интересно, что я никогда не видел, чтобы сервер пытался выдать такой адрес, хотя телефон думает, что он его получил.
Я обдумал идею, что в сети есть мошеннический dhcp-сервер (он передает адрес перед сервером Windows, но без параметров dhcp, необходимых для продолжения работы телефона), но это не объясняет, почему телефоны работают тогда и только тогда, когда Я полностью удаляю любые пути к ПК vlan. Я все равно проверю это утром, подключив свой ноутбук к порту для телефона vlan, но если у кого-то еще есть лучшее объяснение, я бы с удовольствием его услышал.
Вот копия конфигурации коммутатора: