Фон
У мене є сервер Windows DHCP (Server 2008 R2), який роздає адреси для кількох областей. Один із таких областей - це деякі IP-телефони Mitel. Телефони налаштовані використовувати dhcp варіант 125 для отримання інформації про конфігурацію. Коли телефон запускається, він не знає, який vlan використовувати, і тому він просто отримує стандартну (без тегів) vlan будь-якого порту, до якого він підключений. Сервер dhcp надає йому відповідь, що включає інформацію 125 опції, і телефон може прочитати, який vlan він повинен використовувати з цієї відповіді. Потім телефон звільняє свою оригінальну адресу і вимагає отримання нового оренди dhcp, використовуючи правильний тег vlan. У телефонах зазвичай також є комп'ютери, підключені до прохідного порту. Пакети з комп'ютерів ніколи не позначаються тегами, і тому ПК залишатиметься на оригінальній (без тегів) vlan для порту. Це працювало на нас роками.
Проблема та симптоми
Десь за останні кілька тижнів щось змінилося, і я не впевнений, що. Телефони будуть працювати до тих пір, поки вони не перезапустяться, тобто запити на оновлення dhcp повинні бути оброблені правильно. Телефони, підключені до певних комутаторів, можуть навіть пережити перезавантаження. Однак телефони, підключені до інших комутаторів, не зможуть завершити процес під час їх перезавантаження. Всі наші телефони використовують PoE, який підтримується UPS, тому минуло давно, коли будь-який перезавантажився. Це означає, що я не маю уявлення, коли проблема з’явилася вперше. Що я знаю, це те, що один телефон не вдався, коли він перезавантажився вчора, і при усуненні несправностей сьогодні ми скинули цю шафу комутатора. Зараз жоден телефон на цьому комутаторі не працює (на щастя, це все-таки невелика кількість). Я також знаю, що все працювало наприкінці січня,
Під час перегляду завантаження телефону я можу побачити, як він успішно отримує першу адресу. Потім він успішно зчитує інформацію про параметр 125, встановлює правильний тег vlan та звільняє оригінальну IP-оренду. Він навіть може отримати та прийняти пропозицію на правильний vlan від сервера . Однак на цьому справи зупиняються. На екрані телефону є повідомлення, яке говорить " DHCP: Offer 2 ACC", але сервер Windows DHCP не записав оренду, і телефон ніколи не рухається. Я можу лише здогадуватися, що пакет DHCP REQUEST ніколи не доходить до сервера Windows, і тому телефон чекає остаточного ACK від Windows, що це добре, щоб продовжувати.
Обхід
Нарешті мені вдалося знову запустити телефон. Для цього мені довелося спочатку відключити комп’ютер. Тоді я встановив порт комутатора телефону, щоб він не був позначений на vlan телефону, без членства в ПК vlan. Тепер телефон буде перезавантажено правильно. У цей момент я можу повернути конфігурацію порту комутатора туди, де вона повинна бути, і доки ніхто не намагається зателефонувати на цей номер, коли я скидаю порт, телефон ніколи не пропускає такт. Тоді я можу знову підключити комп’ютер. Очевидно, що це не ідеальний процес, хоча, оскільки телефони перезавантажуються так рідко, я зможу використовувати його, щоб знов працювати людей, поки я не зможу знайти першопричину. Офіси зараз закриті на тиждень, і тому це питання фактично буде дозволено сидіти у вихідні (у мене немає ключів для окремих офісів, де є телефони).
Цей телефон, який я зафіксував, - це службовий телефон у серверній кімнаті, підключений безпосередньо до нашого основного комутатора. Можливо, проблема полягає в проблемі з маршрутизацією або обробкою тегів на основному комутаторі, таким чином, що вирішення проблеми не буде ефективним у віддалених офісах, де вперше передаються пакети (помічені) іншими комутаторами, але я буду дуже здивований якщо це трапиться, враховуючи, що я знаю, що він повинен правильно обробляти поновлення dhcp та фактичні телефонні розмови.
Поворот полягає в тому, що залишення порту, позначеного на ПК vlan, означає, що натомість телефон не працює з повідомленням " DHCP: Offer 1 ACC". Мені потрібно повністю видалити цей vlan, щоб це вдалося.
Примітка. Зараз я підтвердив, що обробка ефективна у віддалених будинках. Це змушує мене підозрювати, що мої пристрої якимось чином не призначені для правильної vlan. Той факт, що я зіткнувся з проблемою на своєму основному комутаторі, і що це сталося в декількох місцях мережі приблизно в один і той же час, свідчить про те, що проблема може бути в основному комутаторі. Не маючи нічого конкретного для перегляду, я планую вікно обслуговування на кінець тижня, щоб перезавантажити комутатор. Можу також оновити прошивку.
Середовище
Наш основний комутатор - HP 5406zl. Цей комутатор обробляє маршрутизацію між вланами. Сервер Windows DHCP підключений безпосередньо до комутатора. Кінцеві вимикачі підключаються до основного комутатора за допомогою волоконних SFP, і ці порти позначені для всіх вланів на обох кінцях. Основний комутатор налаштовує кожну vlan з ip helper-addressналаштуваннями, які вказують її на наш DHCP-сервер, і dhcp relay-option 82 replaceлінією, щоб сервер dhcp знав, яку область використовувати. Ці конфігурації та конфігурації портів на перемикачах кінцевих точок не змінювалися протягом щонайменше 16 місяців. У нас у цей час були інші перемикачі комутаторів та перезавантажень.
Більшість наших кінцевих вимикачів - це серія HP 2530. Ці комутатори, здається, працюють коректно (телефони 3-х різних 2530-х перезапущені сьогодні правильно). Це старші комутатори, які мають проблеми. У нас є один старий 3Com 4200 і один 4210, який не працюватиме. Службовий телефон, підключений безпосередньо до основного комутатора, згаданий раніше, також не працюватиме.
Питання
На даний момент я найкраще здогадуюсь, що оновлення Windows на сервері dhcp змінило поведінку, але я не можу зрозуміти як. Або, можливо, основний комутатор не обробляє цей пакет ЗАПИТУВАННЯ правильно, але я впевнений, що там нічого не змінилося, і це не пояснює, чому здійснюються лише певні перемикачі кінцевих точок. Як я можу вирішити цю проблему?
Оновлення:
Ось уривок журналу 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.xxx - це комп'ютерний vlan (цей вибір заздалегідь наводить мене тут). Телефони повинні отримувати таку адресу спочатку, тому це очікувано. Однак після повідомлення про реліз я також розраховую знайти пропозицію щодо адреси в діапазоні 192.168.16.x, тому що я можу побачити по телефону, що пропозиція була прийнята (якщо я неправильно трактую "ACC"). Цікаво, що я ніколи не бачу, щоб сервер намагався видати таку адресу, хоча телефон вважає, що він отримав.
Я вважав ідею, що в мережі є негідний сервер dhcp (він роздає адресу перед сервером Windows, але без параметрів dhcp, необхідних телефону для продовження), але це не пояснює, чому телефони працюють, якщо і лише якщо Я повністю видаляю будь-який шлях до ПК vlan. Я все одно перевіряю його вранці, підключивши ноутбук до порту для телефонного влану, але якщо хтось ще має кращі пояснення тим часом, я хотів би почути це.
Ось копія конфігурації перемикача: