RomanCh Опубликовано 17 марта, 2011 · Жалоба Мельком глянул сейчас, не удержался. По идее такое может происходить только при соблюдении условия: if(*requested_ip != offered_ip) opt_pt = set_dhcpnak(&dhcp_packet->dhcp_data, server_id); Т.е. получается что клиент запрашивает не то что ему предложили. Дамп обязательно надо посмотреть. И наверное надо внимательно мне посмотреть что в RFC по этому поводу написано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[-Alt-] Опубликовано 17 марта, 2011 (изменено) · Жалоба Т.е. получается что клиент запрашивает не то что ему предложили.Дамп обязательно надо посмотреть. И наверное надо внимательно мне посмотреть что в RFC по этому поводу написано. Прям в точку, на порту действительно в базе висят 2 адреса, 62.140.228.186 и 62.140.228.211, просто isc их раздал2 компам, и теперь клиент запрашивает 62.140.228.186 а получает 62.140.228.211 Изменено 17 марта, 2011 пользователем [-Alt-] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[-Alt-] Опубликовано 17 марта, 2011 · Жалоба Не выдаются адреса некоторым виндовым клиентам, не поиму причину: db2dhcp tcpdump: listening on vlan500, link-type EN10MB (Ethernet), capture size 65535 bytes 18:06:58.497567 00:1e:58:a7:2f:70 > 00:1b:21:86:a5:66, ethertype IPv4 (0x0800), length 359: (tos 0xfc, ttl 128, id 2252, offset 0, flags [none], proto UDP (17), length 345) 10.254.0.15.68 > 10.254.0.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:1a:92:08:1b:71, length 317, hops 1, xid 0xf63a793, secs 1024, Flags [Broadcast] (0x8000) Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover NOAUTO Option 116, length 1: Y Client-ID Option 61, length 7: ether 00:1a:92:08:1b:71 Requested-IP Option 50, length 4: 169.254.109.202 Hostname Option 12, length 6: "Sergey" Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 11: Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery Static-Route, Classless-Static-Route-Microsoft, Vendor-Option Vendor-Option Option 43, length 2: 220.0 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 18:06:59.304277 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 344: (tos 0x10, ttl 64, id 19044, offset 0, flags [none], proto UDP (17), length 330) 10.254.0.1.67 > 10.254.0.15.67: [udp sum ok] BOOTP/DHCP, Reply, length 302, xid 0xf63a793, Flags [Broadcast] (0x8000) Your-IP 10.200.5.247 Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 10.200.0.1 Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3 Lease-Time Option 51, length 4: 14400 Server-ID Option 54, length 4: 10.254.0.1 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 18:07:06.497176 00:1e:58:a7:2f:70 > 00:1b:21:86:a5:66, ethertype IPv4 (0x0800), length 359: (tos 0xfc, ttl 128, id 2290, offset 0, flags [none], proto UDP (17), length 345) 10.254.0.15.68 > 10.254.0.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:1a:92:08:1b:71, length 317, hops 1, xid 0xf63a793, secs 3072, Flags [Broadcast] (0x8000) Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover NOAUTO Option 116, length 1: Y Client-ID Option 61, length 7: ether 00:1a:92:08:1b:71 Requested-IP Option 50, length 4: 169.254.109.202 Hostname Option 12, length 6: "Sergey" Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 11: Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery Static-Route, Classless-Static-Route-Microsoft, Vendor-Option Vendor-Option Option 43, length 2: 220.0 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 18:07:07.304097 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 344: (tos 0x10, ttl 64, id 58986, offset 0, flags [none], proto UDP (17), length 330) 10.254.0.1.67 > 10.254.0.15.67: [udp sum ok] BOOTP/DHCP, Reply, length 302, xid 0xf63a793, Flags [Broadcast] (0x8000) Your-IP 10.200.5.247 Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 10.200.0.1 Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3 Lease-Time Option 51, length 4: 14400 Server-ID Option 54, length 4: 10.254.0.1 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 isc 10.254.0.15.68 > 10.254.0.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:1a:92:08:1b:71, length 317, hops 1, xid 0x6d28eace, secs 3072, Flags [Broadcast] (0x8000) Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover NOAUTO Option 116, length 1: Y Client-ID Option 61, length 7: ether 00:1a:92:08:1b:71 Requested-IP Option 50, length 4: 169.254.109.202 Hostname Option 12, length 6: "Sergey" Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 11: Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery Static-Route, Classless-Static-Route-Microsoft, Vendor-Option Vendor-Option Option 43, length 2: 220.0 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 18:09:22.702861 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70, ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 21605, offset 0, flags [none], proto UDP (17), length 330) 10.254.0.1.67 > 10.254.0.15.67: [bad udp cksum 30d2!] BOOTP/DHCP, Reply, length 302, hops 1, xid 0x6d28eace, secs 3072, Flags [Broadcast] (0x8000) Your-IP 10.200.5.247 Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.254.0.1 Lease-Time Option 51, length 4: 3600 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 10.200.0.1 Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 18:09:22.705502 00:1e:58:a7:2f:70 > 00:1b:21:86:a5:66, ethertype IPv4 (0x0800), length 375: (tos 0xfc, ttl 128, id 2732, offset 0, flags [none], proto UDP (17), length 361) 10.254.0.15.68 > 10.254.0.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:1a:92:08:1b:71, length 333, hops 1, xid 0x6d28eace, secs 3072, Flags [Broadcast] (0x8000) Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 00:1a:92:08:1b:71 Requested-IP Option 50, length 4: 10.200.5.247 Server-ID Option 54, length 4: 10.254.0.1 Hostname Option 12, length 6: "Sergey" FQDN Option 81, length 10: "Sergey." Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 11: Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery Static-Route, Classless-Static-Route-Microsoft, Vendor-Option Vendor-Option Option 43, length 3: 220.1.0 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 18:09:22.710295 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70, ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 21607, offset 0, flags [none], proto UDP (17), length 330) 10.254.0.1.67 > 10.254.0.15.67: [bad udp cksum 30cf!] BOOTP/DHCP, Reply, length 302, hops 1, xid 0x6d28eace, secs 3072, Flags [Broadcast] (0x8000) Your-IP 10.200.5.247 Gateway-IP 10.254.0.15 Client-Ethernet-Address 00:1a:92:08:1b:71 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.254.0.1 Lease-Time Option 51, length 4: 3600 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 10.200.0.1 Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3 Agent-Information Option 82, length 18: Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^V Remote-ID SubOption 2, length 8: ^@^F^@^^XM-'/p END Option 255, length 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[-Alt-] Опубликовано 17 марта, 2011 · Жалоба Нашел отличие: offer db2dhcp 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff offer isc 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 17 марта, 2011 (изменено) · Жалоба Нашел отличие: offer db2dhcp 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff offer isc 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70 Налицо косяк в обработке запроса с установленным флагом Broadcast пришедшим через relay. Хотя вроде прорабатывал ситуацию но видимо что-то недоглядел. Спасибо, поправлю. А про DHCPNAC - на самом деле очень интересно почему клиент на него не реагировал. Надо будет попробовать как-то воспроизвести эту ситуацию. У меня клиенты после получения DHCPNAK переставали использовать перезапрашивали адрес. Может опять что-то недоработано с использованием relay - без relay отправка DHCPNAK должна производиться на широковещательный адрес, возможно что и с relay броадкастит, потому ничего не получается. Не помню тестировал-ли такую ситуацию через него. UPD На счёт неправильной udp checksum от ISC - честно говоря не понимаю почему так у вас получается. По идее пакет с битой чексуммой должен быть отброшен клиентом (виндовый не проверял а dhcpcd действительно отбрасывает их). Если сервер её не рассчитал то он должен установить там 0. Ну да ладно, это к счастью чужие проблемы :) Изменено 17 марта, 2011 пользователем RomanCh Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 18 марта, 2011 (изменено) · Жалоба Сервер работает с функцией релей 82, я как понял выдача идёт по порту коммутатора, и по маку или ip коммутатора? а по id влана он работает?, удобно было бы использовать его. Это понятно что здесь обговариваются проблемы в работе сервера, но хоть кто нибудь написал бы с чём его тестируете, какой Биллинг?, какоя OS ?, релей с каким железом, а ёщё бы кто нибудь конфиг привёл, чтобы хоть легче опираться при тестировании было. p.s. использую UTM5, dhcp-relay option 82 на Centos и DGS-3612, топология vlan на дом Изменено 18 марта, 2011 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 18 марта, 2011 · Жалоба Сервер работает с функцией релей 82, я как понял выдача идёт по порту коммутатора, и по маку или ip коммутатора? а по id влана он работает?, удобно было бы использовать его.Вы можете получить любое поле из заголовка DHCP запроса клиента и любую опцию (а так же её часть по выбранному смещению) и использовать полученные данные в SQL запросе. Это значит что да - можно по ID VLAN работать, можно по MAC адресу клиента, можно по порту, можно по ID коммутатора, можно по IP адресу релея (коммутатора). Вообще по любым данным переданым в DHCP запросе клиентом (релеем).Почитайте документацию, не поленитесь :) Там написано как это делается. Раздел про "Пользовательские переменные". Кроме того есть встроенные переменные сервера в которые входят например имя, адрес, маска интерфейса на котором получен запрос, и их тоже можно использовать в SQL выражениях. На сайте нет в примере VLAN ID потому что при подобной гибкости функционала в принципе нереально наверное привести все возможные конфигурации. Нужно просто понять принцип по которому можно строить запросы. Остальное - зависит от вашей фантази. Это понятно что здесь обговариваются проблемы в работе сервера, но хоть кто нибудь написал бы с чём его тестируете, какой Биллинг?, какоя OS ?, релей с каким железом, а ёщё бы кто нибудь конфиг привёл, чтобы хоть легче опираться при тестировании было.Ну мой тестовый стенд - Linux (настоящий) или FreeBSD (в виртуалке), dhcrelay от ISC, для проверки работы с опцией 82 - свитч D-Link 3526. Конфиг - см. документацию. База разумеется строго тестовая. Как и конфиг - для демонстрации основных возможностей. Поняв принцип - сами с лёгкостью напишете и конфиг и запросы. У кого-нибудь есть результаты испытаний последней версии с включённым кэшом? На выходных будет время заниматься устранением багов, потому лучше о них сообщить сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 21 марта, 2011 · Жалоба К сожалению на этих выходных всё-таки не получилось серьёзно поработать над кодом. Но исправлена вот эта бага: Нашел отличие: offer db2dhcp 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff offer isc 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70 Результат: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.7.tar.bz2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[-Alt-] Опубликовано 21 марта, 2011 · Жалоба Исправление вроде помогло, сейчас поставил вместо isc пока все нормально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 22 марта, 2011 · Жалоба Исправление: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.8.tar.bz2 Нашёл и убрал багу которая иногда портила пакеты и отправляла в сеть случайные данные. Появилась после добавления "зеркалирования" опции 82 сервером обратно в relay. Больше пока вроде бы ни каких багов не находится. С кэшем кто-нибудь тестировал работу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
citramon Опубликовано 24 марта, 2011 · Жалоба Отличный проект! Запустил у себя, отдает - все замечательно) Появился вопрос: как правильно отдать виндовому клиенту статические маршруты? В isc делал так: option ms-classless-static-routes code 249 = array of unsigned integer 8; option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; потом в секции subnet или host прописывал: option ms-classless-static-routes 16, 172,16, 10,16,40,100; option rfc3442-classless-static-routes 16, 172,16, 10,16,40,100; А тут попробовал в базе добавить эти маршруты, type=3, а в value=16, 172,16, 10,16,40,100 И никак не отдает... Не подскажите как правильно прописывать все это дело? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 24 марта, 2011 · Жалоба А тут попробовал в базе добавить эти маршруты, type=3, а в value=16, 172,16, 10,16,40,100 И никак не отдает... value должно быть в 16тиричном виде. Т.е. все числа переводим в 16тиричное представление. Правильное значение можно получить например так: $ perl -e '@a = (16,172,16,10,16,40,100); foreach (@a) { printf("%02x", $_) } ; print "\n"' 10ac100a102864 Про работу с включённым кэшом - Voronok проверил, падает по прежнему. Буду переделывать на rbtree. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rupreht Опубликовано 29 марта, 2011 · Жалоба С кэшем кто-нибудь тестировал работу? Что то не так в работе кеша. Схема такая: Между сервером db2dhcp и клиентом стоит железяка с включенным dhcp_relay. Клиент получает (51 Address Time 4 IP Address Lease Time) code type value 51 2 60 UINT4 2 Четырёхбайтовое число. %cat db2dhcp.conf ... DHCPCacheTTL = 36000 DBType = MySQL DBServerAddress = localhost DBServerPort = 3306 ... log 2011-03-29 17:00:55 [40737:34376559296] Got DHCPDISCOVER (1) message from client 00:1B:11:B5:DE:D5 on em1/10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:00:55 [40737:34376559296] DEBUG: Adding DHCP message to empty queue 'DHCP requests' 2011-03-29 17:00:55 [40737:34376559296] DEBUG: Queue (DHCP requests) length now is: 1, new requests: 1 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Trying to get DHCP request from queue 'DHCP requests'. 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Parsing DHCP message and preparing SQL statement. 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found network device variable: DEV-NETWORK-INT = "167843072" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found DHCP header variable: CLI-GIADDR = "0A010102" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found DHCP header variable: CLI-ETHER-ADDR = "001B11B5DED5" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found DHCP options variable: OPT82-REMOTE-ID = "001E58A92983" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found DHCP options variable: OPT82-PORT = "0F" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found DHCP options variable: OPT82-REMOTE-ID = "001E58A92983" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Found DHCP options variable: OPT82-PORT = "0F" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Executing SQL statement "SELECT code, type, value FROM dhcp_subnets WHERE subnet = '167843072' and CONV('0A010102', 16, 10) = 0 UNION SELECT code, type, value FROM dhcp_clients_by_ether WHERE ether = '001B11B5DED5' AND '001E58A92983' = '' AND '0F' = '' UNION SELECT code, type, value FROM dhcp_clients_by_relay WHERE relay_id = '001E58A92983' AND relay_port = '0F' ORDER BY CODE" 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Fetched 4 rows, 3 fields from DB. 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Option 'DHCP server ID' is not set. Set server ID = 10.1.21.104 (interface IP address). 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Added response for client 00:1B:11:B5:DE:D5/10.1.1.252 (relay: 10.1.1.2) to DHCP cache. 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Adding DHCP message to empty queue 'Offers queue for device em1' 2011-03-29 17:00:55 [40737:34376865536] DEBUG: Queue (Offers queue for device em1) length now is: 1, new requests: 1 2011-03-29 17:00:55 [40737:34376865536] DEBUG: DHCP request removed from queue 'DHCP requests'. Queue len now is: 0, new requests: 0 2011-03-29 17:00:56 [40737:34376559296] Sending DHCPOFFER (2) to 00:1B:11:B5:DE:D5/10.1.1.252 via 10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:00:56 [40737:34376559296] DEBUG: DHCP request removed from queue 'Offers queue for device em1'. Queue len now is: 0, new requests: 0 2011-03-29 17:00:56 [40737:34376559296] Got DHCPREQUEST (3) message from client 00:1B:11:B5:DE:D5 on em1/10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:00:56 [40737:34376559296] DEBUG: Adding DHCP message to empty queue 'DHCP requests' 2011-03-29 17:00:56 [40737:34376559296] DEBUG: Queue (DHCP requests) length now is: 1, new requests: 1 2011-03-29 17:00:56 [40737:34376865088] DEBUG: Trying to get DHCP request from queue 'DHCP requests'. 2011-03-29 17:00:56 [40737:34376865088] Found response for client 00:19:5B:14:7D:82 from relay 10.1.1.2 in DHCP cache. 2011-03-29 17:00:56 [40737:34376865088] DEBUG: Adding DHCP message to empty queue 'Ack queue for device em1' 2011-03-29 17:00:56 [40737:34376865088] DEBUG: Queue (Ack queue for device em1) length now is: 1, new requests: 1 2011-03-29 17:00:56 [40737:34376865088] DEBUG: DHCP request removed from queue 'DHCP requests'. Queue len now is: 0, new requests: 0 2011-03-29 17:00:56 [40737:34376559296] DEBUG: Trying to get DHCP request from queue 'Ack queue for device em1'. 2011-03-29 17:00:56 [40737:34376559296] Sending DHCPACK (5) to 00:1B:11:B5:DE:D5/10.1.1.252 via 10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:00:56 [40737:34376559296] DEBUG: DHCP request removed from queue 'Ack queue for device em1'. Queue len now is: 0, new requests: 0 2011-03-29 17:01:57 [40737:34376559296] Got DHCPDISCOVER (1) message from client 00:1B:11:B5:DE:D5 on em1/10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:01:57 [40737:34376559296] DEBUG: Adding DHCP message to empty queue 'DHCP requests' 2011-03-29 17:01:57 [40737:34376559296] DEBUG: Queue (DHCP requests) length now is: 1, new requests: 1 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Trying to get DHCP request from queue 'DHCP requests'. 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Flushing cache: last flush ts - 1301396448, flush period - 60, now is 1301396517. 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Cache flushed. Total 0 nodes deleted. 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Parsing DHCP message and preparing SQL statement. 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found network device variable: DEV-NETWORK-INT = "167843072" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found DHCP header variable: CLI-GIADDR = "0A010102" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found DHCP header variable: CLI-ETHER-ADDR = "001B11B5DED5" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found DHCP options variable: OPT82-REMOTE-ID = "001E58A92983" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found DHCP options variable: OPT82-PORT = "0F" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found DHCP options variable: OPT82-REMOTE-ID = "001E58A92983" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Found DHCP options variable: OPT82-PORT = "0F" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Executing SQL statement "SELECT code, type, value FROM dhcp_subnets WHERE subnet = '167843072' and CONV('0A010102', 16, 10) = 0 UNION SELECT code, type, value FROM dhcp_clients_by_ether WHERE ether = '001B11B5DED5' AND '001E58A92983' = '' AND '0F' = '' UNION SELECT code, type, value FROM dhcp_clients_by_relay WHERE relay_id = '001E58A92983' AND relay_port = '0F' ORDER BY CODE" 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Fetched 4 rows, 3 fields from DB. 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Option 'DHCP server ID' is not set. Set server ID = 10.1.21.104 (interface IP address). 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Update cached data for client 00:1B:11:B5:DE:D5/10.1.1.252. 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Adding DHCP message to empty queue 'Offers queue for device em1' 2011-03-29 17:01:57 [40737:34376864640] DEBUG: Queue (Offers queue for device em1) length now is: 1, new requests: 1 2011-03-29 17:01:57 [40737:34376864640] DEBUG: DHCP request removed from queue 'DHCP requests'. Queue len now is: 0, new requests: 0 2011-03-29 17:01:57 [40737:34376559296] Sending DHCPOFFER (2) to 00:1B:11:B5:DE:D5/10.1.1.252 via 10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:01:57 [40737:34376559296] DEBUG: DHCP request removed from queue 'Offers queue for device em1'. Queue len now is: 0, new requests: 0 2011-03-29 17:01:58 [40737:34376559296] Got DHCPREQUEST (3) message from client 00:1B:11:B5:DE:D5 on em1/10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:01:58 [40737:34376559296] DEBUG: Adding DHCP message to empty queue 'DHCP requests' 2011-03-29 17:01:58 [40737:34376559296] DEBUG: Queue (DHCP requests) length now is: 1, new requests: 1 2011-03-29 17:01:58 [40737:34376864192] DEBUG: Trying to get DHCP request from queue 'DHCP requests'. 2011-03-29 17:01:58 [40737:34376864192] Found response for client 00:19:5B:14:7D:82 from relay 10.1.1.2 in DHCP cache. 2011-03-29 17:01:58 [40737:34376864192] DEBUG: Adding DHCP message to empty queue 'Ack queue for device em1' 2011-03-29 17:01:58 [40737:34376864192] DEBUG: Queue (Ack queue for device em1) length now is: 1, new requests: 1 2011-03-29 17:01:58 [40737:34376864192] DEBUG: DHCP request removed from queue 'DHCP requests'. Queue len now is: 0, new requests: 0 2011-03-29 17:01:58 [40737:34376559296] DEBUG: Trying to get DHCP request from queue 'Ack queue for device em1'. 2011-03-29 17:01:58 [40737:34376559296] Sending DHCPACK (5) to 00:1B:11:B5:DE:D5/10.1.1.252 via 10.1.21.104 (relay 10.1.1.2) 2011-03-29 17:01:58 [40737:34376559296] DEBUG: DHCP request removed from queue 'Ack queue for device em1'. Queue len now is: 0, new requests: 0 OS: FreeBSD 8.1-RELEASE %ldd db2dhcp libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x800658000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x8007ce000) libm.so.5 => /lib/libm.so.5 (0x8008e7000) libz.so.5 => /lib/libz.so.5 (0x800a06000) libpcap.so.7 => /lib/libpcap.so.7 (0x800b1b000) libthr.so.3 => /lib/libthr.so.3 (0x800c4c000) libc.so.7 => /lib/libc.so.7 (0x800d64000) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 29 марта, 2011 · Жалоба Rupreht, я правильно понимаю что вас смущают вот эти строки: 2011-03-29 17:01:58 [40737:34376864192] Found response for client 00:19:5B:14:7D:82 from relay 10.1.1.2 in DHCP cache. 2011-03-29 17:01:58 [40737:34376559296] Sending DHCPACK (5) to 00:1B:11:B5:DE:D5/10.1.1.252 via 10.1.21.104 (relay 10.1.1.2) requests: 0 Т.е. не соответствие MAC адресов? Посмотрел в код, там на самом деле логическая неувязка. После слов "for client" пишется не MAC адрес клиента, а MAC адрес хоста доставившего запрос непосредственно серверу. Т.е. в вашем случае - это адрес агента пересылки. В общем-то на работу ни как не влияет, в сеть уходит пакет с правильными данными. В коде багу поправил, в следующей версии её не будет. Или в чём-то ещё была проблема? Если да, то пожалуйста мне дамп трафика (tcpdump -i ... -nvvves0 port 67) на почту. Изучу. Но вообще - кэш действительно какой-то странный (хотя приведённая бага к этому не относится), заменяю механизм хранилища. Пока лучше работать без кэша. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
citramon Опубликовано 10 апреля, 2011 · Жалоба Появилась еще пара вопросов(включил сервера без кеша): 1. Запустил сервер командой: ./db2dhcp -o db2dhcp.conf eth0, а как его остановить без перезагрузки? 2. Как в конфиге выставить: authoritative Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 11 апреля, 2011 · Жалоба 1. Запустил сервер командой: ./db2dhcp -o db2dhcp.conf eth0, а как его остановить без перезагрузки? Ну, вероятно как и любой другой процесс в unix-like системе :) kill <process_pid> или killall db2dhcp Да, кстати надо будет не забыть сделать что бы демон pid свой писал в файл. 2. Как в конфиге выставить: authoritative Зачем? Если сервер не обслуживает запросы с какого-либо интерфейса, то он просто не должен находить для них данных в базе, а значит и ответов клиентам тоже не будет. Что-то я подзашился в делах своих, но вот выкроил ещё время. Новая версия: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.9.tar.bz2 Внешних изменений в общем-то ни каких нет. Но кэш теперь базируется на RBTree. Кажется помогло со странностями, хотя пока что мало тестировал, рано делать выводы. Всем заинтересованным просьба проверить работу сервера с кэшом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 апреля, 2011 · Жалоба Зачем? Возможно - для того, чтобы сервер не молчал на неизвестные ИП, а слал реджекты, дабы DHCP подсети сторонние не заводились? Хотя смысл от этого весьма небольшой ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 12 апреля, 2011 (изменено) · Жалоба Возможно - для того, чтобы сервер не молчал на неизвестные ИП, а слал реджекты, дабы DHCP подсети сторонние не заводились? Так их и не надо заводить. Сервер пойдёт в БД за данными, ничего там не найдёт и "промолчит" на запрос от неизвестного клиента. Или я не понял что всё-таки имелось ввиду :) Изменено 12 апреля, 2011 пользователем RomanCh Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NorthFighter Опубликовано 13 апреля, 2011 · Жалоба Роман, здравствуйте. В ввиду того, что по последним данным, адресов протокола v4 уже не хватит до конца года, не рассматриваете возможность поддержки протокола v6? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 13 апреля, 2011 · Жалоба адресов протокола v4 уже не хватит до конца года, не рассматриваете возможность поддержки протокола v6? Рассматриваю конечно :) Но только после того как будет в общих чертах всё работать правильно. Как раз к концу года надеюсь и до IPv6 дойдут руки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 21 апреля, 2011 · Жалоба Случаем не у кого не возникает сомнений в том, что использовать DHCP сервер напрямую обращающийся к БД немного некошерно, по отношению к БД? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 апреля, 2011 · Жалоба Случаем не у кого не возникает сомнений в том, что использовать DHCP сервер напрямую обращающийся к БД немного некошерно, по отношению к БД? А как кошерно? Обращаться сначала к радиус-серверу, а он к БД? Самой БД по барабану кто к ней обращается Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 22 апреля, 2011 · Жалоба Самой БД по барабану кто к ней обращается Согласен, но ей далеко не по барабану, как часто это делается. В случае выполнения тяжёлого запроса одним из клиентов БД, дополнительные маленькие запросы DHCP в этот момент могут тупо уложить сервак БД на несколько минут (может и дольше), нагрузка на проц будет возрастать по экспоненте, вы сами можете себе представить вероятные последствия этого. А как кошерно? DHCP сервер без прямого обращения к БД, но имеющий сгенерированный конфиг, на основе данных с БД. У себя я такое сделал на ISC DHCP, и мне глубоко похрен, какое количество запросов придёт в сервак, т.к. он напрямую к БД не обращается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 23 апреля, 2011 · Жалоба В случае выполнения тяжёлого запроса одним из клиентов БД, дополнительные маленькие запросы DHCP в этот момент могут тупо уложить сервак БД на несколько минут (может и дольше), нагрузка на проц будет возрастать по экспоненте, вы сами можете себе представить вероятные последствия этого. Не надо хранить базу DHCP в перегруженной базе биллинга на одном SATA винте с почтовым сервером там же и всё будет хорошо. А спорить "DHCP из базы" vs. "Генерить конфиг для ISC DHCP" вообще бессмысленно, все понимают плюсы и минусы каждого из подходов и делают свои серверы поверх БД не от хорошей жизни. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 23 апреля, 2011 · Жалоба ммм.... есть два сервера dhcp, на виртуалках. Есть отдельная машина, занимающаяся биллингом и скриптами. Есть отдельная БД на drbd кластере... Раз в 5 минут на биллинге запускается скрипт, генерящий конфиг dhcp. После окончания генерации конфиг подкладывается в каталог, откуда dhcp сервера раз в 5 минут его забирают rsync'ом. [root@dhcp1 ~]# cat /usr/local/sbin/sync.sh #!/bin/bash /usr/bin/rsync -az --password-file=/etc/rsync.password rsync://executor@10.0.0.1/dhcp/dhcpd.conf /etc/dhcpd.conf # dhcp /usr/bin/md5sum --check --status /var/lib/sync/dhcp RETVAL=$? if [ $RETVAL != 0 ]; then /etc/init.d/dhcpd restart /usr/bin/md5sum /etc/dhcpd.conf > /var/lib/sync/dhcp fi А где тут минусы? Новый mac попадает в систему в течении 10 минут максимум. Клиенты не жалуются.. Сбоев тут я не наблюдал ни разу. Особенно после того, как dhcp серверов стало два. Они же и dns резолверы для клиентов... А напрямую в базу... Да, красиво - поменяли мак, сразу перевыдалось... Но стоит ли? Мне как то проще использовать стандартный демон, чем писать свое ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...