Проблема с ISC-DHCP

[scream]

Есть сервер под freebsd на нём установлен isc-dhcpd4-2,адрес в сервера 192.168.10.1, в нём описано много сетей для раздачи, пример:

 

# Vlan 205

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.2 192.168.1.254;

option routers 192.168.1.1;

option broadcast-address 192.168.1.255;

}

 

# Vlan 206

subnet 192.168.2.0 netmask 192.168.2.0 {

range 192.168.2.1 192.168.2.254;

option routers 192.168.2.1;

option broadcast-address 192.168.2.255;

}

 

и таких еще штук 10,

на сisco 7201 созданы соответствующие sub-интерфейсы , пример:

 

interface GigabitEthernet0/1.205

description --- ISG Subscribers (pool-1)

encapsulation dot1Q 205

ip address 192.168.1.1 255.255.255.0

ip helper-address 192.168.10.1

no ip redirects

no ip proxy-arp

service-policy type control ISG

ip subscriber routed

initiator unclassified ip-address

end

 

interface GigabitEthernet0/1.206

description --- ISG Subscribers (pool-2)

encapsulation dot1Q 206

ip address 192.168.2.1 255.255.255.0

ip helper-address 192.168.10.1

no ip redirects

no ip proxy-arp

service-policy type control ISG

ip subscriber routed

initiator unclassified ip-address

end

 

так вот , всё прекрасно работает, но бывает что в один клиент не может получить ip, в логах дхцп сервера видно только DHCPDISCOVER и DHCPOFFER, пример:

Feb 1 12:15:25 bill dhcpd: DHCPDISCOVER from 64:70:02:bf:81:1f (TP-LINK) via 192.168.1.1

Feb 1 12:15:25 bill dhcpd: DHCPOFFER on 192.168.1.25 to 64:70:02:bf:81:1f (TP-LINK) via 192.168.1.1

Feb 1 12:16:01 bill dhcpd: DHCPDISCOVER from 64:70:02:bf:81:1f (TP-LINK) via 192.168.1.1

Feb 1 12:16:01 bill dhcpd: DHCPOFFER on 192.168.1.25 to 64:70:02:bf:81:1f (TP-LINK) via 192.168.1.1

Feb 1 12:16:38 bill dhcpd: DHCPDISCOVER from 64:70:02:bf:81:1f (TP-LINK) via 192.168.1.1

Feb 1 12:16:38 bill dhcpd: DHCPOFFER on 192.168.1.25 to 64:70:02:bf:81:1f (TP-LINK) via 192.168.1.1

 

смотрю статистику порта в который включен абонент, и вижу что почему не доходят DHCPOFFER, ни перезагрузка дхцп, ничего не помогает, НО если я клиента кидаю в другой vlan , то он сразу же получает ip, хотя это один и тот же дхцп сервер и та же cisco, просто пул адресов другой!

[Cramac]

Была подобная проблема, решения не нашел, перешел на перловый сервер из соседних тем.

[Negator]

у меня подобное возникает иногда. Решается перегрузкой длинка на доступе.

Почему - не знаю.

[s.lobanov]

scream

На коммутаторе доступа dhcp snooping включен? Если да, то пробовали отключить и посмотреть дойдёт ли до абонента dhcp offer?

[scream]

scream

На коммутаторе доступа dhcp snooping включен? Если да, то пробовали отключить и посмотреть дойдёт ли до абонента dhcp offer?

snooping был включен, но я в первую очередь его отключил, но никакой реакции (((

[scream]

Наконец то разобрался в чем проблема!

Маршрутизатор (cisco 7201) не передавал через себя DHCPOFFER, потому что у него в arp таблице лежала запись с ip-шником который пытаеться получить клиент, ну а эта запись в arp таблице осталась от предыдущего клиента!

и еще , чтобы избавиться от таких вот записей в логах :

Feb 4 14:14:12 bill dhcpd: parse_option_buffer: malformed option vendor.<unknown> (code 808464739): option length exceeds option buffer length.

Feb 4 14:13:58 bill dhcpd: parse_option_buffer: malformed option vendor.<unknown> (code 808464739): option length exceeds option buffer length.

Feb 4 14:14:04 bill dhcpd: parse_option_buffer: malformed option vendor.<unknown> (code 1714435940): option length exceeds option buffer length.

Feb 4 14:14:05 bill dhcpd: parse_option_buffer: malformed option vendor.<unknown> (code 1714435940): option length exceeds option buffer length.

Feb 4 14:14:07 bill dhcpd: parse_option_buffer: malformed option vendor.<unknown> (code 1714435940): option length exceeds option buffer length

надо просто в конфиг dhcpd.conf добавить строчку

option option-125 code 125 = string;