Jump to content
Калькуляторы

Cisco DHCP-сервер

Есть одна 3750. На ней поднят DHCP-сервер с вот таким пулом:

 

!
ip dhcp pool ONT-Pool
  network 10.22.4.0 255.255.252.0
  default-router 10.22.7.254
  dns-server 91.197.107.200 91.197.104.182
!

Используем для доступа на ONT с целью отладки конфигов.

 

Проблема в том, что при рестарте ONT он получает не тот же адрес, а следующий. Даже при штатном рестарте ONT со всеми release адресов.

 

Вот так выглядит на циске:

3750.U63#sh ip dhcp binding | inc a8f9.4bc0.06d2
10.22.4.12          a8f9.4bc0.06d2          Feb 03 2015 04:01 PM    Automatic
3750.U63#sh ip dhcp binding | inc a8f9.4bc0.06d2
10.22.4.13          a8f9.4bc0.06d2          Feb 03 2015 04:19 PM    Automatic
3750.U63#[/size]
[size="2"]

 

Вот дебаг с циски:

[/size]

[size=2]000261: Feb  2 16:23:25.703: DHCPD: Sending notification of TERMINATION:[/size]
[size=2]000262: Feb  2 16:23:25.703:  DHCPD: address 10.22.4.13 mask 255.255.252.0[/size]
[size=2]000263: Feb  2 16:23:25.703:  DHCPD: reason flags: RELEASE 2[/size]
[size=2]000264: Feb  2 16:23:25.703:   DHCPD: htype 1 chaddr a8f9.4bc0.06d2[/size]
[size=2]000265: Feb  2 16:23:25.703:   DHCPD: lease time remaining (secs) = 86163[/size]
[size=2]000266: Feb  2 16:23:25.703:   DHCPD: interface = Vlan396[/size]
[size=2]000267: Feb  2 16:23:25.703:   DHCPD: out_vlan_id 0[/size]
[size=2]000268: Feb  2 16:23:25.703: DHCPD: dhcpd_deactivate_binding binding removed from mac hash 5CC056C[/size]
[size=2]000269: Feb  2 16:23:25.703: DHCPD: returned 10.22.4.13 to address pool ONT-Pool.[/size]
[size=2]000270: Feb  2 16:24:36.295: DHCPD: checking for expired leases.[/size]
[size=2]000271: Feb  2 16:25:08.843: DHCPD: Sending notification of DISCOVER:[/size]
[size=2]000272: Feb  2 16:25:08.843:   DHCPD: htype 1 chaddr a8f9.4bc0.06d2[/size]
[size=2]000273: Feb  2 16:25:08.843:   DHCPD: remote id 6d61343030302d706c35[/size]
[size=2]000274: Feb  2 16:25:08.843:   DHCPD: circuit id 454c54583546303030324143[/size]
[size=2]000275: Feb  2 16:25:08.843:   DHCPD: interface = Vlan396[/size]
[size=2]000276: Feb  2 16:25:08.843:   DHCPD: out_vlan_id 0[/size]
[size=2]000277: Feb  2 16:25:08.843: DHCPD: Sending notification of DISCOVER:[/size]
[size=2]000278: Feb  2 16:25:08.843:   DHCPD: htype 1 chaddr a8f9.4bc0.06d2[/size]
[size=2]000279: Feb  2 16:25:08.843:   DHCPD: remote id 6d61343030302d706c35[/size]
[size=2]000280: Feb  2 16:25:08.843:   DHCPD: circuit id 454c54583546303030324143[/size]
[size=2]000281: Feb  2 16:25:08.843:   DHCPD: interface = Vlan396[/size]
[size=2]000282: Feb  2 16:25:08.843:   DHCPD: out_vlan_id 0[/size]
[size=2]000283: Feb  2 16:25:10.857: DHCPD: Allocated binding 5CC056C[/size]
[size=2]000284: Feb  2 16:25:10.857: DHCPD: Adding binding to radix tree (10.22.4.14)[/size]
[size=2]000285: Feb  2 16:25:10.857: DHCPD: Adding binding to hash tree 5CC056C[/size]
[size=2]000286: Feb  2 16:25:10.857: DHCPD:dhcpd_binding_add_to_mac_hash: index- 146 add binding 5CC056C[/size]
[size=2]000287: Feb  2 16:25:10.857: DHCPD: assigned IP address 10.22.4.14 to client a8f9.4bc0.06d2. (2464 0)[/size]
[size=2]000288: Feb  2 16:25:10.857: DHCPD: DHCPOFFER notify setup address 10.22.4.14 mask 255.255.252.0[/size]
[size=2]000289: Feb  2 16:25:10.865: DHCPD: Sending notification of ASSIGNMENT:[/size]
[size=2]000290: Feb  2 16:25:10.865:  DHCPD: address 10.22.4.14 mask 255.255.252.0[/size]
[size=2]000291: Feb  2 16:25:10.865:   DHCPD: htype 1 chaddr a8f9.4bc0.06d2[/size]
[size=2]000292: Feb  2 16:25:10.865:   DHCPD: lease time remaining (secs) = 86400[/size]
[size=2]000293: Feb  2 16:25:10.865:   DHCPD: interface = Vlan396[/size]
[size=2]000294: Feb  2 16:25:10.873:   DHCPD: out_vlan_id 0[/size][size=2][size=2]

[/size]

 

Вроде никакого криминала нет..

Может есть какая-нибудь опция по повторному использованию адресов?

Edited by megahertz0

Share this post


Link to post
Share on other sites

сделайте жёсткую привязку к макам (раз вам это для отладки, а не для продакшн)

 

Ну как бы в продакшен тоже пойдет. Можно, конечно, сделать релей на dhcpd и выдавать адреса оттуда. Но хотелось бы оставить на циске. Не будем же делать статик биндинг под каждую ONT.

Share this post


Link to post
Share on other sites

DHCP-сервер на Cisco только для офисной сети для раздачи серых ip из пула.

Для провайдинга желательно отдельный DHCP-сервер соединенный с радиусом-биллингом.

Share this post


Link to post
Share on other sites

DHCP-сервер на Cisco только для офисной сети для раздачи серых ip из пула.

Для провайдинга желательно отдельный DHCP-сервер соединенный с радиусом-биллингом.

Этот DHCP-сервер нужен для доступа на менеджмент-интерфейс ONT. Для абонентов там отдельный влан с нормальным DHCP. Я не задаю же вопрос "зачем", а задаю вопрос "почему так происходит".

Share this post


Link to post
Share on other sites

Может быть это?

 

By default, the DHCP server pings a pool address twice before assigning a particular address to a requesting client. If the ping is unanswered, the DHCP server assumes (with a high probability) that the address is not in use and assigns the address to the requesting client.

 

Что-то вроде, ип на устройстве активен несмотря на release. Если заменить ont на ноутбук, ситуация такая же?

Share this post


Link to post
Share on other sites

ip dhcp database tftp://<куда нибудь>/<где можно записывать>/<Файлы>

 

В принципе, можно и на флешь

ip dhcp database flash:/leases

 

Или как-то так. Ему у вас лизы хранить негде. Вот и выдаёт каждый раз как в первый раз.

 

 

Share this post


Link to post
Share on other sites

Не могу сказать, как на Л3 свичках, а вот на роутерах NVRAM тоже флешко. EEPROM точнее. Так-же подвергается износу.

 

Так что лучше на внешний TFTP

Share this post


Link to post
Share on other sites

А в памяти ему лизы хранить сил не хватает что-ли?

А что тогда показывает sh ip dhcp binding? Случайно не лизы ли как раз? :)

 

Всё это сохранение нужно только на случа ребута железки, на рантайм работу влиять не должно совершенно.

Share this post


Link to post
Share on other sites

NVRAM тоже флешко

Заточенная под частое юзание ;)

 

 

Всё это сохранение нужно только на случа ребута железки, на рантайм работу влиять не должно совершенно.

Не помню точно (в доку лень лезть) но вроде бы там by default лизы нигде не хранятся, поэтому на 100500 устройств можно честно выдавать один и тот же адрес, т.к. состояние адреса не известно.

Share this post


Link to post
Share on other sites

А в памяти ему лизы хранить сил не хватает что-ли?

А что тогда показывает sh ip dhcp binding? Случайно не лизы ли как раз? :)

Памяти, может и хватает. Но, надо указать, ГДЕ ИМЕННО сетевой админ РЕШИЛ хранить лизы. Железко не готов решать это за вас.

А sh ip dhcp binding показывает не лизы а привязки. Адрес зарелизился - биндинг исчез. Смысл базы данных лизов в том, чтобы хранить привязки МЕЖДУ периодами аренды адреса.

Пруфлинк http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1cfdhcp.html#wp1018925

Даже буквами написано, что если вы не конфигурируете базу данных - то отключите логгирование конфликтов IP. Ибо, они будут.

 

Заточенная под частое юзание ;)

Как правило, это простая 28F256 А у неё - от 1000 до 10000 циклов гарантируется. Смотря по поколению.

Share this post


Link to post
Share on other sites

В продакшн, деньги освоить - CNR внедрить. Ну или ISC DHCP крутить. Не надо железку мучить :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.