|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (44)
просмотр истории страницыh2. Организация постоянных пакетов с запросом адреса |
{tip}{*}Время выполнения инструкции*: 60-120 минут{tip} |
|
в Windows создать bat файл с содержимым |
{toc} |
|
h2. Организация тестовой станции Windows В Windows создать bat файл с содержимым: {code} |
:label1 ping \-n 60 127.0.0.1 |
ipconfig /release * |
ipconfig /renew goto label1 |
{code} {note} Многие коммутаторы умеют кешировать lease. Поэтому при отладке их нужно перезагружать. {note} |
|
h2. Отладка получения IP адреса |
|
*Шаг 1.* Настраиваем релей на коммутаторе |
Проверьте, что dhcp-сервер [настроен|DHCP]. В примере использованы: * *Сервер* - 198.51.100.10 * *Клиент* - 198.51.100.20 |
|
*Шаг 2.* Временно для отладки, в менеджере тестовому абоненту ставим привязку по MAC. Галочку opt82 НЕ ставим. Эту опцию поставим после того как отладим прием opt82 опций от коммутатора. |
h3. DHCP в широковещательном домене |
|
*Шаг 3.* Пытаемся получить адрес тестовым абонентом по мак привязке. *Шаг 4.* Смотрим запрос адреса в логе {panel} rm \-f /app/collector/var/lib/dhcpd/\* dhcpd.leases\~ chroot /app/collector/ /etc/init.d/dhcpd restart tail \-f /var/log/messages {panel} Если видим |
# Просмотрите трафик на сетевом интерфейсе настроенном на приём DHCP запросов: |
{code} |
Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 via Leth1: network ISC: no free leases |
tcpdump -pnnei eth0 port 67 or port 68 |
{code} |
Значит релей не настроен или настроен неверно. При правильной настройке релея запрос будет приходить от ip адреса коммутатора(например 192.168.0.35): |
Вывод команды будет выглядеть следующим образом. В примере показан законченный dhcp диалог. |
{code} |
Aug 3 14:25:59 dhcpd: DHCPDISCOVER from 90:2b:34:14:75:48 via 192.168.0.35: network ISC: no free leases |
10:37:00.623329 08:00:27:97:c8:3c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:97:c8:3c, length 308 10:37:00.628647 08:00:27:ee:21:c8 > 08:00:27:97:c8:3c, ethertype IPv4 (0x0800), length 342: 198.51.100.10.67 > 198.51.100.20.68: BOOTP/DHCP, Reply, length 300 10:37:00.632202 08:00:27:97:c8:3c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:97:c8:3c, length 300 10:37:00.632403 08:00:27:ee:21:c8 > 08:00:27:97:c8:3c, ethertype IPv4 (0x0800), length 342: 198.51.100.10.67 > 198.51.100.20.68: BOOTP/DHCP, Reply, length 300 |
{code} |
Если вывод команды пуст, значит пакеты не доходят до интерфейса биллинга. Проверьте настройки вашей сети. {info} Если в широковещательном домене несколько dhcp клиентов, удобно отфильтровать пакеты тестовой станции по mac адресу: {code} tcpdump -pnnei eth0 '(port 67 or port 68) and ether host 08:00:27:97:c8:3c' {code} {info} # Просмотрите запрос адреса в логе DHCP сервера: #* Удалите данные по выданным адресам, чтобы они были взяты из конфигурационного файла: {code} rm -f /app/collector/var/lib/dhcpd/* {code} Перезапустите DHCP сервер: {code} chroot /app/collector/ service dhcpd restart {code} Проследите за логом DHCP сервера: {code} tail -f /app/collector/var/log/messages {code} #* Законченный dhcp диалог в логе сервера выглядит так: {code} Jul 12 10:30:11 localhost dhcpd: DHCPDISCOVER from 08:00:27:97:c8:3c (windows07) via eth0 Jul 12 10:30:11 localhost dhcpd: DHCPOFFER on 198.51.100.20 to 08:00:27:97:c8:3c (windows07) via eth0 Jul 12 10:30:11 localhost dhcpd: Jul 12 10:30:11 localhost dhcpd: DHCPREQUEST for 198.51.100.20 (198.51.100.10) from 08:00:27:97:c8:3c (windows07) via eth0 Jul 12 10:30:11 localhost dhcpd: DHCPACK on 198.51.100.20 to 08:00:27:97:c8:3c (windows07) via eth0 {code} # Проверьте, что *DHCPOFFER* доходит до абонента. То есть абонент получает выданный адрес. ## Посмотрите лог DHCP сервера: {code} tail -f /app/collector/var/log/messages | fgrep -i dhcpd {code} ## Если видим, что на запрос IP адреса DHCPDISCOVER биллинг отвечает DHCPOFFER и на этом dhcp диалог по этому абоненту заканчивается и начинается снова, значит DHCPOFFER до абонента от биллинга не доходит. {code} Jul 12 10:30:11 localhost dhcpd: DHCPDISCOVER from 08:00:27:97:c8:3c (windows07) via eth0 Jul 12 10:30:11 localhost dhcpd: DHCPOFFER on 198.51.100.20 to 08:00:27:97:c8:3c (windows07) via eth0 Jul 12 10:31:00 localhost dhcpd: DHCPDISCOVER from 08:00:27:97:c8:3c (windows07) via eth0 Jul 12 10:31:00 localhost dhcpd: DHCPOFFER on 198.51.100.20 to 08:00:27:97:c8:3c (windows07) via eth0 {code} ## Возможные причины: #* На промежуточном коммутаторе настроен dhcp-snooping; #* Проблема в настройках клиентской станции. |
|
*Примечание:* Если в логе запросов нет, значит проблема сетевая, т.е. широковещательный сегмент не включает в себя вашего тестового абонента. |
h3. DHCP-relay |
|
В этом случае анализируем пакеты на предмет использования релея на коммутаторе: |
Отладка проходит так же, как в широковещательном домене. Нужно убедиться, что relay доступен по IP для биллинга. |
{panel} |
tcpdump \-nvei any port 67 or port 68 |
h3. Возможные ошибки |
{panel} |
Вывод вида: |
h4. ignored (unknown subnet) {code:title=лог /app/collector/var/log/messages} Oct 7 07:02:04 Optimaset dhcpd: DHCPREQUEST for 10.90.163.133 from b0:be:76:6a:b3:55 via 10.90.163.129: ignored (unknown subnet). {code} Ошибка может возникать при выдаче IP-адреса абоненту, который подключен через dhcp-relay. Требуется проверить, что в файле конфигурации DHCP */app/collector/etc/dhcp/dhcpd.conf* есть запись об этой подсети. {code:title=Запрос для проверки}grep '10.90.163.128' /app/collector/etc/dhcp/dhcpd.conf{code} Если записи нет в списке, а в *http://ip-биллинга:8081/settings/collector/dhcp_subnets/* запись существует, требуется изменить, например, dns и нажать кнопку "Сохранить" внизу страницы. После этого вновь убедиться, что конфигурационный файл dhcp сервера создан корректно, со всеми сетями. h4. unknown network segment {code:title=лог /app/collector/var/log/messages} Jan 10 19:27:19 carbon dhcpd: DHCPDISCOVER from 34:0a:98:88:7a:d8 via 10.10.10.1: unknown network segment |
{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 адрес сервера. |
|
*Шаг 5.* После этих действий обратитесь в техническую поддержку для помощи в настройке разбора полей opt82. |
Ошибка может возникать при выдаче IP-адреса абоненту, который подключен через dhcp-relay или запрос проходит несколько релеев. |
|
Специалистам технической поддержки в заявке нужно будет сообщить: |
Убедитесь, что для IP релея, с которого поступает запрос (в примере 10.10.10.1) заведена подсеть. Можно добавить подсеть только на IP релея, например "10.10.10.1/32", если адреса для абонентов принаджежат другой подсети. |
|
\- id абонента; |
h2. Отладка opt82 |
|
\- vlan и порт в которые он включен на коммутаторе; |
# Для исключения сетевых проблем проведите [отладку получения IP адреса|Отладка DHCP#Отладка получения IP адреса]; # Проверьте, что *отключена* опция [OPT 82. Создавать статические mac привязки вместо vlan+port|DHCP#Настройка Option 82]; # Настройте на коммутаторе релей и OPT82; # В учётной записи абонента укажите MAC. {note} Галочку opt82 оставьте *пустой*. Поставим её после того, как отладим прием opt82 от коммутатора. {note} # Просмотрите лог dhcp сервера. В логе виден запрос на получение адреса и дальнейшая его обработка. DHCP сервер последовательно проходит по всем [типам коммутаторов|Добавление коммутаторов и их типов в биллинг] и разбирает DHCP указанными в них функциями. В конечном счёте адрес выдаётся по MAC адресу. {code} /app/collector/var/log/messages {code} Пример: #* aa:bb:cc:dd:ee:ff - MAC адрес клиента; #* 192.0.2.2 - адрес абонента в биллинге; #* 198.51.100.10 - адрес релэя; #* 198.51.100.20 - адрес биллинга. {code:title=лог DHCP сервера} May 19 14:01:32 TestBill dhcpd: RAW:: Lease for 192.0.2.2agent.circuit-id txt= May 19 14:01:32 TestBill dhcpd: agent.circuit-id bin8=0 100 0 7 1 May 19 14:01:32 TestBill dhcpd: agent.remote-id txt=<E0><E8><E6>#036#005k May 19 14:01:32 TestBill dhcpd: agent.remote-id bin8=224 232 230 30 5 107 May 19 14:01:32 TestBill dhcpd: binary-to-ascii: length of buffer 1 not a multiple of width 2! May 19 14:01:32 TestBill dhcpd: PARS_ALTER:: Lease for 192.0.2.2 SWIP=<E6>#036#005k VLAN=7 PORT=1 PARAM=none MAC=none GPON_MODEM_PORT=none SVLAN=none May 19 14:01:32 TestBill dhcpd: PARS_SNR2940:: Lease for 192.0.2.2 SWIP=198.51.100.10 VLAN=100 PORT= PARAM=none MAC=none GPON_MODEM_PORT=none SVLAN=none May 19 14:01:32 TestBill dhcpd: PARS_SNR2950:: Lease for 192.0.2.2 SWIP=<E0><E8><E6>#036#005k VLAN=#001 PORT= PARAM=none MAC=none GPON_MODEM_PORT=none SVLAN=none May 19 14:01:32 TestBill dhcpd: PARS_ELTEX_LTE2:: Lease for 192.0.2.2 SWIP=none VLAN= May 19 14:01:32 TestBill dhcpd: PARS_Cisco2950:: Lease for 192.0.2.2 SWIP=none VLAN=7 PORT=1 PARAM=none MAC=aa:bb:cc:dd:ee:ff GPON_MODEM_PORT=none SVLAN=none May 19 14:01:32 TestBill dhcpd: DHCPREQUEST for 192.0.2.2 (198.51.100.20) from aa:bb:cc:dd:ee:ff via 198.51.100.10 May 19 14:01:32 TestBill dhcpd: DHCPACK on 192.0.2.2 to aa:bb:cc:dd:ee:ff via 198.51.100.10 {code} # Убедитесь, что биллинг разбирает данные из opt82 DHCP запроса верно; # Заполните поля opt82 учётной записи. Установите галочку opt82. Биллинг сгенерирует конфигурационный файл dhcpd. {code} /app/collector/etc/dhcp/dhcpd.conf {code} В конфигурационном файле будет создан class и pull для каждой учётной записи с opt82. {code} class "match_vlan_0_port_2_ip_198.51.100.10__opt82_param_aa:bb:cc:dd:ee:ff_gpon_modem_port_NULL_svlan_NULL_hw_serial_<null>" { match if ((binary-to-ascii(16, 8, ":", option agent.remote-id) = "aa:bb:cc:dd:ee:ff")); } |
|
\- В идеале сообщать точную модель и марку коммутатора а также версию прошивки. |
pool { range 192.0.2.2; allow members of "match_vlan_0_port_2_ip_198.51.100.10_opt82_param_aa:bb:cc:dd:ee:ff_gpon_modem_port_NULL_svlan_NULL_hw_serial_<null>"; } |
|
*Примечание:* при настройке обратите внимание, чтоб [пул адресов|asrdocnew:Пулы IP-адресов] из которого вы отдаете адреса по dhcp не был зарезервирован для ручной раздачи. |
{code} # Проверьте, что клиентская станция получает адрес. {code} May 19 15:34:30 Avetel dhcpd: DHCPREQUEST for 192.0.2.2 (198.51.100.20) from aa:bb:cc:dd:ee:ff (TestPC) via 198.51.100.10 May 19 15:34:30 Avetel dhcpd: DHCPACK on 192.0.2.2 to aa:bb:cc:dd:ee:ff (TestPC) via 198.51.100.10 {code} |