Недавно обратился клиент с жалобой, что некоторые ПК не получают IP адрес от DHCP сервера после перезагрузки или выхода из спящего режима. При этом такая проблема фиксировалась только после включения DHCP snooping.
S5735-L24T4X-A1
V200R021C00SPC100
В логах и Wireshark снимках было видно, что ПК исправно отправлял DHCP discovery сообщения:
Однако Offer сообщения не поступало.
Однако информация в логах самого коммутатора говорила о том, что Offer от DHCP сервера прилетал, но по какой-то причине не доходил до ПК, или сам ПК, точнее DHCP клиент, отвергал, не принимал их.
Коммутатор фиксирует как запросы от клиента, так и ответы от DHCP сервера на эти запросы. И соответствующие записи появлялись в таблице dhcp snooping bind-table.
Вот запрос от ПК после перезагрузки в Wireshark, и в логах есть он и ответ на него от сервера:
Проблема не в конфигурации, иначе dhcp snooping bind-table не формировалась бы.
Проблемы начинались, когда сообщение Offer покидало или пыталось покинуть коммутатор.
Есть две типовые причины блокировки DHCP пакетов
1. Количество DHCP клиентов, подключенных к порту, превышает максимум.
2. Количество DHCP запросов превышает допустимый предел.
Но здесь это было неактуально, число DHCP bind пользователей было далеко от максимума:
dis dhcp sno
DHCP snooping global running information :
DHCPv4 snooping : Enable
DHCPv6 snooping : Enable
Static user max number : 2560
Current static user number : 0
Dhcp user(dhcpv4/dhcpv6/nd) max number : 9216
То, что формировалась таблица dhcp snooping и адрес, который должен быть на ПК, в ней присутствовал после перезагрузки, можно было считать доказательством работы протокола.
Если бы мы хотите убедиться, что сообщение Offer действительно покидает коммутатора, томогли настроить сбор исходящего трафика с порта например GE1/0/10, и на другом ПК (не на проблемном) собрать этот трафик и сделать снимок Wireshark.
Ранее клиент упоминали, что менял ОС на ПК, и использовали другую сетевую карту. Но не думаю, что это могло на что-то повлиять. Сетевая карта здесь не играет роль. DHCP это протокол верхнего уровня, а сетевая карта работает как L3 элемент TCP/IP стека. Она сама по себе не является DHCP клиентом и никаких решений принимать не может. DHCP клиентом выступать может программа, в данном случае это ОС (Windows, например). И если клиент переустановил Windows на Windows, то это ничего не меняло – DHCP клиент оставался тем же самым, и если в программе DHCP клиента был баг, то он с переустановкой вряд ли ушел (особенно если и версии ОС были одними и теми же).
Я упоминал ранее, что одной из причин проблем с DHCP snooping может быть достижение максимального количества пользователей. Клиент ответил, что у него по 3 пользователя на порт. Но по 3 пользователя у него было в настройках port-security. Port-security равное 3 лишь не допускается более 3 разных мак-адресов на порту. А максимальное количество DHCP снупинг пользователей – это именно связка IP и мак-адреса и является глобальным для всего коммутатора значением, и не привязано к какому-то порту. На данной модели поддерживается 9216 пользователей.
Наконец, было замечено, что порты доступа участвуют в STP процессе. Этого не должно быть, если за портами доступа (например, GE2/0/10) нет других коммутаторов. Было рекомендовано настроить порты доступа как edge и фильтровать bpdu трафика. В представлении интерфейса:
stp edged-port enable
stp bpdu-filter enable
После этого клиент подтвердил, что проблема исчезла.
То есть STP блокировал отправку сообщений, в том числе Offer DHCP, конвергируя порт из одного состояния в другое.
