Протокол DHCP придуман для того, чтобы избавить сетевых администраторов от рутины: вместо ручной раздачи IP-адресов, масок подсети, шлюзов и адресов DNS-серверов устройства получают все настройки автоматически. Но иногда именно эта автоматизация превращается в источник головной боли. Сетевой администратор одной госорганизации-подрядчика Райан Уильямс (Ryan Williams) описал в NetworkWorld именно такой случай — с коммутаторами Cisco Catalyst 6500 и 9600, работавшими как распределительные (Layer 3) в разных группах зданий сети.
Зачем DHCP держали на коммутаторах
DHCP чаще всего разворачивают на отдельном сервере, но его функции умеют выполнять и сетевые устройства, включая коммутаторы и маршрутизаторы Cisco. Именно так было устроено в описываемой сети: DHCP-сервер на коммутаторах Cisco раздавал адреса устройствам беспроводной сети, отделяя тем самым Wi-Fi-трафик от проводной инфраструктуры, которая обслуживалась своим отдельным DHCP-сервером. Такой подход, особенно в небольших сетях, позволяет сэкономить — коммутатор выполняет двойную работу вместо покупки и обслуживания дополнительного сервера.
Cisco 6500 годами справлялся с этой задачей, но с переходом организации на программно-определяемые сети (SDN) пришло время его преемника — Cisco 9600, который поддерживает автоматизацию и более высокие скорости портов.
В чём заключался баг
Проблема проявлялась на обоих поколениях коммутаторов: пулы DHCP-адресов периодически «замерзали». Устройства не могли подключиться к сети, потому что не получали IP-адрес, а пользователи заваливали техподдержку заявками о том, что Wi-Fi не работает.
Состояние пула можно посмотреть командой show ip dhcp pool. В норме вывод выглядит примерно так:
Router# show ip dhcp pool 1
Pool 1:
Utilization mark (high/low) : 85 / 15
Subnet size (first/next) : 24 / 24 (autogrow)
VRF name : abc
Total addresses : 28
Leased addresses : 11
Pending event : none
Current index IP address range Leased addresses
10.1.1.12 10.1.1.1 – 10.1.1.14 11
10.1.1.17 10.1.1.17 – 10.1.1.30 0
Interface Ethernet0/0 address assignment
10.1.1.1 255.255.255.248
10.1.1.17 255.255.255.248 secondary
Со временем инженеры заметили закономерность: как только у пользователей начинались проблемы с получением адреса, в выводе той же команды «текущий индекс» (current index) показывал 0.0.0.0 — при этом в пуле оставались свободные адреса. Выглядело это так:
Current index IP address range Leased/Excluded/Total
0.0.0.0 172.30.52.97 – 172.30.53.128 0 / 7 / 30
Как жили с проблемой
Пулы были настроены около трёх лет назад и первое время работали без нареканий. Затем сбой начал повторяться без явного триггера — не на всех коммутаторах разом, а бессистемно, то на одном, то на другом устройстве в сети. Это совпало по времени с ростом сети: к беспроводной инфраструктуре добавлялись новые здания и помещения, а вместе с ними — новые подключаемые устройства.
Проблема стала настолько частой, что вошла в стандартный чек-лист поддержки: при жалобах на Wi-Fi инженеры сначала проверяли, работают ли точки доступа, а затем — не «завис» ли пул DHCP. При подтверждении зависания применялся способ, который порекомендовал техподдержка Cisco (TAC): удалить пул DHCP и создать его заново. После пересоздания пул сбрасывался, и раздача адресов возобновлялась — правда, временно.
Команды на удаление и повторное создание пула инженеры держали заранее скопированными, чтобы выполнять workaround удалённо за считаные секунды. Пул приходилось пересоздавать многократно ещё на коммутаторах 6500, и в компании надеялись, что переход на 9600 решит проблему. Не решил — сбои продолжились с той же непредсказуемой периодичностью, обычно фиксируясь как очередной сетевой сбой. По словам автора, схожие случаи с тем же обходным решением описывали и другие организации.
Несмотря на этот баг, DHCP на коммутаторах, по мнению автора, всё равно оправдывает себя: он позволяет сегментировать беспроводную сеть, и даже с учётом периодической необходимости пересоздавать пул это остаётся куда эффективнее полностью ручной раздачи адресов.
Источник: NetworkWorld.