Отладка opt82. Настройка DHCP клиента и диагностика dhcp_restart.bat

Skip to end of metadata
Go to start of metadata
Время выполнения инструкции: 20-30 минут

Организация постоянных пакетов с запросом адреса

в Windows создать bat файл с содержимым

:label1
ping -n 60 127.0.0.1
ipconfig /release *
ipconfig /renew
goto label1

Внимание! Многие коммутаторы умеют кешировать lease и поэтому при отладке их нужно ресетить

Отладка

Шаг 1. Настраиваем релей на коммутаторе и OPT82

Шаг 2. Временно для отладки, в учетной записи тестовому абоненту ставим привязку по MAC.(MAC адрес должен быть в формате 00:00:00:00:00:00) Галочку opt82 НЕ ставим. Эту опцию поставим после того как отладим прием opt82 опций от коммутатора.

Шаг 3. Пытаемся получить адрес тестовым абонентом по мак привязке.

Шаг 4. Смотрим запрос адреса в логе

rm -f /app/collector/var/lib/dhcpd/* dhcpd.leases~

chroot /app/collector/ /etc/init.d/dhcpd restart

tail -f /app/*/var/log/messages

Если видим

Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 via Leth1: network ISC: no free leases

Значит релей не настроен или настроен неверно.
При правильной настройке релея запрос будет приходить от ip адреса коммутатора(например 192.168.0.35):

Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 via 192.168.0.35: network ISC: no free leases

Примечание: Если в логе запросов нет, значит проблема сетевая, т.е. широковещательный сегмент не включает в себя вашего тестового абонента.

В этом случае анализируем пакеты на предмет использования релея на коммутаторе:

tcpdump -nvvei any port 67 or port 68

tshark -V -ni any -R "bootp.hw.mac_addr contains "MAC_ADDRESS""

Вывод вида:

tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: listening on any
12:47:02.633297 B 0:e:5e:a:ef:42 ip 394: 0.0.0.0.68 > 255.255.255.255.67: [no cksum]  xid:0xb2a4df25 [|bootp] (DF) (ttl 32, id 28219, len 378)
12:47:03.178477 B 90:2b:34:14:75:48 ip 344: 0.0.0.0.68 > 255.255.255.255.67:  xid:0x99b6d10d flags:0x8000 [|bootp] (ttl 128, id 14097, len 328)
12:47:06.178208 B 90:2b:34:14:75:48 ip 344: 0.0.0.0.68 > 255.255.255.255.67:  xid:0x99b6d10d secs:768 flags:0x8000 [|bootp] (ttl 128, id 14107, len 328)
12:47:15.178663 B 90:2b:34:14:75:48 ip 344: 0.0.0.0.68 > 255.255.255.255.67:  xid:0x99b6d10d secs:3072 flags:0x8000 [|bootp] (ttl 128, id 14127, len

Говорит о том, что адрес запрашивается без использования релея, броадкастом.
При верно настроенном релее пакеты будут приходить юникастовые от ip адреса коммутатора на ip адрес сервера.

Шаг 5. Проверить, что DHCPOFFER доходит до абонента
1) Смотрим лог /app/collector/var/log/messages | grep -i dhcpd
2) Если видим, что на запрос ip адреса DHCPDISCOVER биллинг отвечает DHCPOFFER и на этом dhcp диалог по этому абоненту заканчивается, значит DHCPOFFER до абонента от биллинга не доходит.

Jan 17 12:50:09 carbonsoft dhcpd: DHCPDISCOVER from a8:f9:4b:aa:dd:dd via 192.168.0.35
Jan 17 12:50:09 carbonsoft dhcpd: DHCPOFFER on 10.0.4.189 to a8:f9:4b:aa:dd:dd via 192.168.0.35

Возможные причины:
1) С биллинга недоступен адрес RELAY агента. В данном примере это 192.168.0.35
Проверить можно командой ping 192.168.0.35
2) Если адрес RELAY агента доступен, значит проблема в сети дальше. Необходимо проследить путь пакета от биллинга до абонента по всем промежуточным хостам вплоть до абонента.

Шаг 6. После этих действий обратитесь в техническую поддержку для помощи в настройке разбора полей opt82.

Специалистам технической поддержки в заявке нужно будет сообщить:

- id абонента;

- vlan и порт в которые он включен на коммутаторе;

- В идеале сообщать точную модель и марку коммутатора а также версию прошивки.

Примечание: при настройке обратите внимание, чтоб пул адресов из которого вы отдаете адреса по dhcp не был зарезервирован для ручной раздачи.

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.