Фон
У меня есть 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, но если у кого-то еще есть лучшее объяснение, я бы с удовольствием его услышал.
Вот копия конфигурации коммутатора:
источник
Ответы:
Я исправил проблему сегодня, удалив тег vlan для телефона vlan на порту, подключенном к нашему серверу dhcp. Мне очень странно, что это сработало, поскольку другие системы, использующие аналогичную схему (или Wi-Fi SSID, использующие 802.1q), требуют метки, или клиенты не могут получить адреса. Это сработало, так что я не буду выглядеть слишком усердно, но мне было бы интересно увидеть ответы с теориями, почему это так.
источник
Вы должны рассмотреть возможность перехвата пакетов с обеих сторон проблемного коммутатора (ов) и затем проверить это в Wireshark. Это будет в состоянии сообщить вам 1), если трафик перехватывается мошенническим сервером DHCP (на основе MAC-адреса), и 2), если что-то искажается или сбрасывается (например, возможно, вам нужна ретрансляция DHCP). Это может потребовать зеркалирования портов, или 3com может поддерживать захват непосредственно на коммутаторе.
источник
Если вы обнаружите, что эта проблема появляется снова, вы можете проверить размер вашей области DHCP и количество арендуемых помещений. Если старые аренды DHCP не уничтожаются, ваш сервер может подумать, что в пуле не осталось адресов, и не может назначить новые адреса. Это верно, даже если в vlan нет отвечающих устройств. Если ваша область действия DHCP составляет 7 дней, может пройти до 7 дней, прежде чем вы сможете получить новую аренду. Аналогично, изменение вашей конфигурации решит проблему, потому что появится новый диапазон адресов, которые могут быть выделены, или это может привести к сбросу аренды в зависимости от изменений конфигурации. Я бы предложил установить срок аренды на что-то очень низкое, например, час для этого объема, если это так.
источник