Отладка opt82

Время выполнения инструкции: 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 не был зарезервирован для ручной раздачи.