Задний план
У меня есть 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, и поэтому телефон ожидает последнего ACK от Windows, что можно Продолжать.
Обходной путь
Я наконец смог заставить телефон снова работать. Для этого мне пришлось сначала отключить компьютер. Затем я настроил порт коммутатора телефона на немаркированный телефонный vlan, без членства в vlan для ПК. Теперь телефон перезагрузится правильно. На этом этапе я могу вернуть конфигурацию порта коммутатора туда, где она должна быть, и до тех пор, пока никто не пытается позвонить по этому номеру, пока я сбрасываю порт, телефон никогда не промахивается. Затем я могу снова подключить компьютер. Очевидно, это не идеальный процесс, хотя, поскольку телефоны перезагружаются очень редко, я смогу использовать его, чтобы заставить людей снова работать, пока я не найду основную причину. Офисы сейчас закрыты на неделю, поэтому этот вопрос фактически будет разрешен на выходные (у меня нет ключей от отдельных офисов, где есть телефоны).
Этот телефон, который я починил, является служебным телефоном в серверной, подключенным напрямую к нашему базовому коммутатору. Возможно, проблема связана с тегами маршрутизации или обработки на основном коммутаторе, так что обходной путь не будет эффективным в удаленных офисах, где пакеты сначала проходят (помечаются) через другие коммутаторы, но я буду очень удивлен если это произойдет, учитывая, что я знаю, что он должен правильно обрабатывать обновления DHCP и фактические телефонные разговоры.
Хитрость заключается в том, что если оставить порт на влане ПК, помеченный тегом, это означает, что вместо этого телефон выдает сообщение "DHCP: Offer 1 ACC". Мне нужно полностью удалить этот vlan, чтобы это удалось.
Примечание. Теперь я подтвердил, что обходной путь эффективен в удаленных зданиях. Это заставляет меня подозревать, что мои устройства каким-то образом не привязаны к правильному vlan. Тот факт, что у меня возникла проблема на моем основном коммутаторе, и что это произошло в нескольких местах сети примерно в одно и то же время, указывает на то, что проблема может быть в основном коммутаторе. Не имея ничего особенного, я планирую перерыв на обслуживание ближе к концу недели, чтобы перезагрузить коммутатор. Я также могу обновить прошивку.
Окружающая среда
Наш основной коммутатор - HP 5406zl. Этот коммутатор обрабатывает маршрутизацию между vlan. DHCP-сервер Windows подключен непосредственно к коммутатору. Коммутаторы конечных точек подключены к базовому коммутатору через оптоволоконные SFP, и эти порты помечены для всех виртуальных локальных сетей на обоих концах. Основной коммутатор настраивает каждый 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, Назначить, 10.1.2.158`` 08000F197844`` 3189088995,0``, 11,03 / 06 / 15,12: 40: 40, Обновить, 10.1.2.158, , 08000F197844`` 3189088995,0`` 12,03 / 06 / 15,12: 40: 41, Выпуск, 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.x.x.x - это vlan для ПК (этот выбор появился раньше меня в этом месте). Телефоны сначала должны получать такой адрес, так что это ожидаемо. Однако после сообщения о выпуске я также ожидаю найти предложение для адреса в диапазоне 192.168.16.x, потому что я могу видеть по телефону, что предложение было принято (если я неправильно истолковываю "ACC"). Интересно, что я никогда не видел, чтобы сервер пытался выдать такой адрес, даже если телефон думает, что получил его.
Я рассматривал идею, что в сети есть мошеннический сервер DHCP (он выдает адрес перед сервером Windows, но без параметров DHCP, необходимых для продолжения работы телефона), но это не объясняет, почему телефоны работают тогда и только тогда, когда Я полностью удаляю любой путь к влану ПК. Я все равно протестирую это утром, подключив свой ноутбук к порту, установленному для телефонного vlan, но если у кого-то еще есть лучшее объяснение, я бы хотел его услышать.
Вот копия конфигурации коммутатора:
Сегодня я исправил проблему, удалив тег vlan для vlan телефона на порту, подключающемся к нашему dhcp-серверу. Мне очень странно, что это сработало, поскольку другие системы, использующие аналогичную схему (также известные как SSID Wi-Fi с использованием 802.1q), требуют тега, иначе клиенты не могут получить адреса. Это сработало, поэтому я не буду слишком усердствовать, но мне было бы интересно увидеть ответы с теориями для Зачем так оно и есть.
Если вы обнаружите, что эта проблема возникает снова, вы можете проверить размер области DHCP и количество используемых аренд. Если старые аренды DHCP не уничтожаются, ваш сервер может подумать, что в пуле не осталось адресов, и не сможет назначить новые адреса. Это верно, даже если в vlan нет отвечающих устройств. Если ваш диапазон DHCP составляет 7 дней, может пройти до 7 дней, прежде чем вы сможете получить новую аренду. Точно так же изменение вашей конфигурации решит проблему, потому что может появиться новый диапазон адресов, или это может сбросить аренду в зависимости от изменений конфигурации. Я бы посоветовал установить срок аренды на что-то очень низкое, например, на час для этой области, если это так. Вы можете подтвердить это, вручную удалив аренду и проверив, может ли телефон получить новый адрес, если проблема возникнет снова.
Вам следует подумать о том, чтобы запустить захват пакетов на любой стороне проблемного переключателя (-ов), а затем просмотреть это в Wireshark. Он сможет сказать вам: 1) если трафик перехватывается мошенническим DHCP-сервером (на основе MAC-адреса) и 2) что-то повреждено или сброшено (например, возможно, вам понадобится ретранслятор DHCP). Для этого может потребоваться зеркалирование портов, или 3com может поддерживать захват непосредственно на коммутаторе.