{tip}{*}Время выполнения инструкции*: 20-30 минут{tip}
{toc}
h2. Организация постоянных пакетов с запросом адреса
В Windows создать bat файл с содержимым:
{code}
:label1
ping \-n 60 127.0.0.1
ipconfig /release *
ipconfig /renew
goto label1
{code}
{info}
Многие коммутаторы умеют кешировать lease. Поэтому при отладке их нужно перезагружать.
{info}
h2. Отладка
# Настройте релей на коммутаторе и OPT82
# Временно для отладки, в учетной записи тестовому абоненту ставим привязку по MAC.(MAC адрес должен быть в формате 00:00:00:00:00:00) Галочку opt82 НЕ ставим. Эту опцию поставим после того как отладим прием opt82 опций от коммутатора.
# Пытаемся получить адрес тестовым абонентом по мак привязке.
# Смотрим запрос адреса в логе
{panel}
rm \-f /app/collector/var/lib/dhcpd/\* dhcpd.leases\~
chroot /app/collector/ /etc/init.d/dhcpd restart
tail \-f /app/*/var/log/messages
{panel}
Если видим
Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 {color:#ff0000}{*}via Leth1:*{color} network ISC: no free leases
Значит релей не настроен или настроен неверно.
При правильной настройке релея запрос будет приходить от ip адреса коммутатора(например 192.168.0.35):
Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 {color:#ff0000}{*}via 192.168.0.35{*}{color}: network ISC: no free leases
*Примечание:* Если в логе запросов нет, значит проблема сетевая, т.е. широковещательный сегмент не включает в себя вашего тестового абонента.
В этом случае анализируем пакеты на предмет использования релея на коммутаторе:
{panel}
tcpdump \-nvvei any port 67 or port 68
{panel}
{panel}
tshark \-V \-ni any \-R "bootp.hw.mac_addr contains "MAC_ADDRESS""
{panel}
Вывод вида:
{code}
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
{code}
Говорит о том, что адрес запрашивается без использования релея, броадкастом.
При верно настроенном релее пакеты будут приходить юникастовые от ip адреса коммутатора на ip адрес сервера.
# Проверить, что *DHCPOFFER* доходит до абонента
1) Смотрим лог /app/collector/var/log/messages \| grep \-i dhcpd
2) Если видим, что на запрос ip адреса *DHCPDISCOVER* биллинг отвечает *DHCPOFFER* и на этом dhcp диалог по этому абоненту заканчивается, значит *DHCPOFFER* до абонента от биллинга не доходит.
{code}
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
{code}
Возможные причины:
1) С биллинга недоступен адрес RELAY агента. В данном примере это *192.168.0.35*
Проверить можно командой ping 192.168.0.35
2) Если адрес RELAY агента доступен, значит проблема в сети дальше. Необходимо проследить путь пакета от биллинга до абонента по всем промежуточным хостам вплоть до абонента.
# После этих действий обратитесь в техническую поддержку для помощи в настройке разбора полей opt82.
Специалистам технической поддержки в заявке нужно будет сообщить:
\- id абонента;
\- vlan и порт в которые он включен на коммутаторе;
\- В идеале сообщать точную модель и марку коммутатора, а также версию прошивки.
*Примечание:* при настройке обратите внимание, чтоб [пул адресов|asrdocnew:Пулы IP-адресов] из которого вы отдаете адреса по dhcp не был зарезервирован для ручной раздачи.
{toc}
h2. Организация постоянных пакетов с запросом адреса
В Windows создать bat файл с содержимым:
{code}
:label1
ping \-n 60 127.0.0.1
ipconfig /release *
ipconfig /renew
goto label1
{code}
{info}
Многие коммутаторы умеют кешировать lease. Поэтому при отладке их нужно перезагружать.
{info}
h2. Отладка
# Настройте релей на коммутаторе и OPT82
# Временно для отладки, в учетной записи тестовому абоненту ставим привязку по MAC.(MAC адрес должен быть в формате 00:00:00:00:00:00) Галочку opt82 НЕ ставим. Эту опцию поставим после того как отладим прием opt82 опций от коммутатора.
# Пытаемся получить адрес тестовым абонентом по мак привязке.
# Смотрим запрос адреса в логе
{panel}
rm \-f /app/collector/var/lib/dhcpd/\* dhcpd.leases\~
chroot /app/collector/ /etc/init.d/dhcpd restart
tail \-f /app/*/var/log/messages
{panel}
Если видим
Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 {color:#ff0000}{*}via Leth1:*{color} network ISC: no free leases
Значит релей не настроен или настроен неверно.
При правильной настройке релея запрос будет приходить от ip адреса коммутатора(например 192.168.0.35):
Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 {color:#ff0000}{*}via 192.168.0.35{*}{color}: network ISC: no free leases
*Примечание:* Если в логе запросов нет, значит проблема сетевая, т.е. широковещательный сегмент не включает в себя вашего тестового абонента.
В этом случае анализируем пакеты на предмет использования релея на коммутаторе:
{panel}
tcpdump \-nvvei any port 67 or port 68
{panel}
{panel}
tshark \-V \-ni any \-R "bootp.hw.mac_addr contains "MAC_ADDRESS""
{panel}
Вывод вида:
{code}
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
{code}
Говорит о том, что адрес запрашивается без использования релея, броадкастом.
При верно настроенном релее пакеты будут приходить юникастовые от ip адреса коммутатора на ip адрес сервера.
# Проверить, что *DHCPOFFER* доходит до абонента
1) Смотрим лог /app/collector/var/log/messages \| grep \-i dhcpd
2) Если видим, что на запрос ip адреса *DHCPDISCOVER* биллинг отвечает *DHCPOFFER* и на этом dhcp диалог по этому абоненту заканчивается, значит *DHCPOFFER* до абонента от биллинга не доходит.
{code}
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
{code}
Возможные причины:
1) С биллинга недоступен адрес RELAY агента. В данном примере это *192.168.0.35*
Проверить можно командой ping 192.168.0.35
2) Если адрес RELAY агента доступен, значит проблема в сети дальше. Необходимо проследить путь пакета от биллинга до абонента по всем промежуточным хостам вплоть до абонента.
# После этих действий обратитесь в техническую поддержку для помощи в настройке разбора полей opt82.
Специалистам технической поддержки в заявке нужно будет сообщить:
\- id абонента;
\- vlan и порт в которые он включен на коммутаторе;
\- В идеале сообщать точную модель и марку коммутатора, а также версию прошивки.
*Примечание:* при настройке обратите внимание, чтоб [пул адресов|asrdocnew:Пулы IP-адресов] из которого вы отдаете адреса по dhcp не был зарезервирован для ручной раздачи.