Первичная диагностика:

1. DHCP сервер запущен.
2. Убедиться, что в настройках SSID указан корректный VLAN ID.
3. Через систему мониторинга убедиться, что пользователь подключается к правильному SSID, на тестируемой точке доступа.
4. Если SSID с шифрованием, то по логам работы ТД, убедиться что пользователь успешно прошел авторизацию.
5. Проверить получение адреса на другой SSID этой же точки доступа (ТД)
6. Проверить получение адреса с другого устройства (смартфон/ноутбук)
7. В сетевых настройках пользовательского устройства выбран режим получать адрес по DHCP.
8. Установить статический IP  адрес на клиенте, проверить доступность шлюза при помощи отправки ping (icmp).

Если эти настройки верны, переходим к проверке настроек сервера и сетевой части. Для проведения диагностики необходимо знать MAC адрес клиентского устройства и иметь возможность инициировать получение адреса клиентом по протоколу DHCP.

Проверка DHCP сервера

Проверку DHCP сервера необходимо проанализировать логи работы DHCP сервера.

По логам возможно обнаружить три основные проблемы:

• Отсутствует Discover.
• Присутствует Discover, но отсутствует Offer.
• Присутствуют Discover и Offer, но отсутствует Request.

1. В логах отсутствует Discover от клиентского устройства.

На интерфейсе сервера, на который должен был прилететь Discover, необходимо запустить tcpdump и проверить, есть ли там Discover.

• Если Discover отсутствует в дампе, то нужно перейти к проверке настроек в сети, DHCP-relay и связи с ним.
• Если Discover присутствует в дампе, но не попал в логи, то необходимо проверить настройки сервера (пункт 1.1).

1.1 Discover присутствует в дампе, но не попал в логи.

Discover игнорируется из-за того, что прилетает на интерфейс, который не прослушивается сервером. Необходимо проверить, на какой интерфейс прилетает Discover и добавить этот интерфейс в конфигурацию DHCP сервера:

В файле /etc/default/isc-dhcp-server должны быть прописаны названия всех прослушиваемых интерфейсов, например:

INTERFACES="eth0 eth1"

2. В логах DHCP сервера присутствует Discover, но отсутствует Offer.

Для определения точной причины необходимо изучить логи DHCP сервера. Распространенные причины:

• не прописана одна из используемых подсетей
• неправильно прописаны классы
• в пулах закончились свободные адреса
• проблемы с файловером

2.1 не прописана одна из используемых подсетей

В файле /etc/dhcp/dhcpd.conf должны быть прописаны подсети, содержащие адреса прослушиваемых интерфейсов, а также адрес DHCP-relay (если он используется). Даже если адреса из этих подсетей не раздаются сервером, например:

subnet 192.168.1.0 netmask 255.255.255.0 {}

2.2 в пулах закончились свободные адреса

Одна из распространенных причин состоит в том, что сервер раздал все свободные адреса, для проверки этого следует использовать руководство: Мониторинг использования пулов в ISC-DHCP-server

3 В логах DHCP сервера присутствуют Discover и Offer, но не приходит Request.

Необходимо снять tcpdump на интерфейсе, на который приходит Discover и проверить, есть ли в этом же дампе Offer.

• Если Offer отсутствует в дампе, то это означает, что на сервере указан неправильный маршрут в пользовательскую подсеть, и из-за этого Discover прилетает на один интерфейс, а Offer отправляется на другой и не долетает до адресата. Необходимо проверить и исправить маршрутизацию на сервере.
• Если Offer присутствует в дампе, необходимо перейти к проверки DHCP-relay и связи между DHCP сервером и DHCP-relay.

4 Проверка связи между dhcp-сервером и dhcp-relay

Проверить пинг до dhcp-relay с сервера. Пинг должен выполняться с правильного интерфейса.

Проверка DHCP-relay

Отладка в Схеме с GRE

1. Проверка статуса GRE туннелей.

Для этого необходимо:

• Через cистему управления (СУ) EMS узнать «первичный» IP адрес ТД. Первичный адрес указан на вкладке «Доступ» и на вкладке «Мониторинг» в разделе «Общее».
• На ESR посмотреть список GRE туннелей принадлежащий данной ТД. Это можно выполнить командой:

show tunnels status | include <XXX.XXX.XXX.XXX> 

, где XXX.XXX.XXX.XXX – первичный IP ТД

Команда вернет список туннелей, построенных этой точкой доступа.

• Если туннелей нет, то необходимо проверить IP связность между ТД и ESR, а так же конфигурацию DHCP сервера
• Если туннель 1 – то проверятся конфигурация DHCP сервера и конфигурация ESR
• Если 2 туннеля, то проверяется что для второго туннеля подняты SUB-туннели с, соответствующими конфигурации ТД VLAN.

2. Снятие дампа трафика на SUB-GRE туннеле проблемной точки доступа.

Для получения дампа нужно выполнить подключение под учетной записью techsupport, перейти в режим su и запустить команду:

 tcpdump -i dygreХХХ.УУУ -evn -c100

 , где ХХХ номер GRE туннеля найденный в пп выше, УУУ – номер VLAN ID

В полученном дампе необходимо выполнить поиск Discover от клиента:

• Если Discover отсутствует в дампе - это означает, что возможно точка доступа не смогла корректно построить туннель. Необходимо выполнить проверку настройки DHCP сервера (43 опция , 12 подопция), а также проверить настройки ТД.
• Если Discover присутствует в дампе, но отсутствует Offer - следует перейти к проверке обмена с DHCP сервером (пункт 3).

3. Снятие дампа трафика при обмене пакетами с DHCP сервером.

Для получения дампа нужно выполнить подключение под учетной записью techsupport, перейти в режим su и запустить команду:

tcpdump -i te1_YYY.ZZZ -evn -c100

, где YYY – номер порта ESR, ZZZ – номер VLAN.

• Если Discover отсутствует в дампе – проблема в настройках ESR.
• Если Discover передается на DHCP сервер, но отсутствует Offer – проблема в связи между DHCP сервером и ESR.
• Если Discover и Offer присутствуют, но в обмене отсутствует Request – проблема в настройках ESR.

Отладка в Схеме без GRE

1. Снятие дампа трафика на интерфейсе в сторону клиента. При анализе дампа необходимо найти Discover от клиента.

• Если Discover отсутствует – необходимо проверить:

1. настройки файрвола на DHCP-relay,
2. настройки сети для связи с точкой доступа
3. настройки точки доступа,

• Discover присутствует, но отсутствует Offer – следует перейти к проверке обмена с DHCP сервером.

2. Снятие tcdump обмена с DHCP сервером.

• Если Discover отсутствует в дампе – проблема в настройках DHCP-relay. Необходимо проверить firewall и настройку маршрутизации на DHCP-relay.
• Если Discover передается на DHCP сервер, но отсутствует Offer – проблема в связи между DHCP сервером и DHCP-relay.
• Если Discover и Offer присутствуют, но в обмене отсутствует Request – проблема в настройках firewall на DHCP-relay.

Проверка точки доступа

На точке доступа необходимо настроить открытый SSID без авторизации, в том же VLAN, что и проблемный SSID. По инструкции о снятии дампа (pcap) с точки доступа, нужно снять дамп на радио интерфейсе, к которому подключается пользователь, а также на интерфейсе eth. Результаты следует интерпретировать в зависимости от используемой схемы подключения:

Для любой схемы:

• Если в дампе с радио интерфейсе Discover от пользователя отсутствует, то это означает, что есть проблема с клиентским устройством. Возможно оно не подключилось к сети, либо по каким-то причинам не запрашивает адрес.

Для схемы с GRE:

• Если на радио интерфейсе Discover от пользователя есть, а на eth его нет, то это означает, что GRE туннель для пользовательского трафика не построился из-за того, что при получении первичного адреса, точка получила неправильную 12 подопцию. Необходимо выполнить проверку настройки DHCP сервера (43 опция , 12 подопция)
• Если Discover есть в обоих дампах, то это означает, что пакет передается с ТД, нужно убедиться в получении .пакетов на ESR.

Для схемы без GRE:

• Если Discover зафиксирован в дампе с радио интерфейса и eth, но отсутствует на DHCP-relay, то это говорит о том, что на оконечном оборудовании не настроен пользовательский VLAN, либо он не прокинут до DHCP-relay.