Есть DHCP сервер на Cisco Catalyst 3560. Нужно на нём сделать привязку IP-MAC для более чем 150 хостов. Я знаю, как это сделать, создав отдельный dhcp pool для каждого адреса. Но надеюсь никто не спорит, что гораздо удобнее было бы хранить и редактировать все привязки в текстовом файле на tftp-сервере.
Я знаю, как это сделать на Cisco881 (маршрутизаторе).
Создаётся файл вида:
*time* Dec 17 2005 06:52 AM
*version* 2
!IP address Type Hardware address Lease expiration
192.168.3.3 /24 1 0018.7178.cc16 Infinite pdc
192.168.3.4 /24 1 0016.e04c.17c0 Infinite switch-root
192.168.3.6 /24 1 00:05:1a:6b:46:18 Infinite switch-234
192.168.3.7 /24 1 00:05:1a:47:de:f8 Infinite switch-kc
*end*В пуле с помощью команды origin указывается путь к файлу:
ip dhcp pool vlan3
origin tftp://192.168.3.3/dhcp.txt
default-router 192.168.3.1
dns-server 192.168.3.200
и всё замечательно работает. При перезапуске маршрутизатора или dhcp-сервиса он читает файл и привязки появляются в памяти маршрутизатора с пометкой Static (в отличие от Manual, которые делаются созданием дочернего DHCP-пула в конфигурации).НО НА CISCO CATALYST 3560 НЕТ КОМАДНЫ ORIGIN!!!!!!
Есть команда ip dhcp database tftp://... в глобальном кофиге.
Везде написано, что эта команда призвана бэкапить динамические привязки. И действительно, при появлении новой динамической привязки (binding), коммутатор записывает файл по указанному пути (по дефолту через интервал в 300 секунд). Но что характерно, неизвестно, при каких обстоятельствах коммутатор будет читать из этого файла, и можно ли ему в этом файле подсунуть полную базу данных привязок. На сайте Cisco написано, что файл создаётся для того, чтобы при перезагрузке коммутатор не потерял динамические привязки. Но при перезагрузке коммутатор нихрена даже не пытается читать из указанного файла! Нафига такой бэкап, скажите мне?Что я делаю не так? :)
Спасибо.
В общем, отвечаю себе сам.
У меня получилось разобраться, как работает циска со вбитой командой ip dhcp database tftp://192.168.3.3/dhcp.databaseНе знаю, что я делал не так, но после перезапуска DHCP-сервера (Switch(config)#no service dhcp; service dhcp), циска читает базу данных из файла. Но формат, как для команды origin уже не подходит. Фишка в том, что коммутатор 3560 работает с версией файла 1, а для маршрутизатора я использовал версию 2. Это я понял, когда внимательнее посмотрел файл, который коммутатор сам создаёт, когда у него появляются новые динамические привязки.
В общем, залить базу привязок в циску удалось в таком формате:
*time* Dec 18 2009 11:52 AM
*version* 2
!IP address Type Hardware address Lease expiration
192.168.3.3 1 0018.7178.cc16 Infinite pdc
192.168.3.4 1 0016.e04c.17c0 Infinite switch-root
192.168.3.6 1 00:05:1a:6b:46:18 Infinite switch-234
192.168.3.7 1 00:05:1a:47:de:f8 Infinite switch-kc
192.168.3.8 1 00:06:ac:50:d4:78 Infinite switch-232
#192.168.3.11 1 00:0f:cb:f7:d9:00 Infinite switch-300
#192.168.3.13 1 00:e0:d8:12:c7:ef Infinite UPSPW
192.168.3.12 id 01:00:22:15:02:9a:57 Infinite 1
192.168.3.14 id 01:00:1a:80:64:3f:24 Infinite 1
192.168.3.15 id 01:00:1e:8c:27:03:6c Infinite 1
*end*
Может быть стоило поменять *version* на 1. Но у меня залилось в таком виде. При этом заметьте, mac-адрес может быть в любом стандартном формате, а после слова Infinite обязательно должно что-то быть, иначе строчка, например,
192.168.3.17 id 01:00:07:e9:0a:50:27 Infinite
не читается с ошибкой "cannot read month"
Закомментированные строчки не читаются. Маску сети нужно обязательно убрать, то есть строка
192.168.3.18 /24 id 01:00:18:f3:bc:e4:0a Infinite
не прочитается.
Также не читаются строчки с пропущенными нулями в мак-адресе, например:
192.168.3.23 id 01:0:1a:92:07:47:34 Infinite
(маршрутизатор с командой origin такие строчки понимает)
Type 1 значит hardware address, id значит client-identifier.Хранить файл можно как на файл-сервере, так и на флэшке самой циски.
Switch(config)#ip dhcp database flash:dhcp.database
После того как циска успешно засосала подложенный мной файл со статическими привязками, она сама после каждого изменения в базе данных перезаписывает файл в этом же месте.
Вот кратко, что у неё получается:
*time* Dec 18 2009 04:42 PM
*version* 1
!IP address Type Hardware address Lease expiration
192.168.3.23 id 0100.1a92.0747.34 Dec 18 2010 03:39 PM
192.168.3.43 id 0100.15f2.dd03.6b Dec 18 2010 03:37 PM
192.168.3.47 id 0100.1bfc.7303.6c Dec 18 2010 03:37 PM
192.168.3.68 id 0100.18f3.bfb0.38 Dec 18 2010 03:50 PM
192.168.3.145 id 0100.1e8c.e049.f9 Dec 18 2010 04:03 PM
192.168.3.223 id 0100.1c23.a266.36 Dec 18 2010 03:51 PM
192.168.7.3 id 0100.1c23.a266.36 Dec 19 2009 01:59 PM
!IP address Interface-index Lease expiration Server IP address Vrf
*end*
Lease expiration декабрь следующего года, потому что в пуле стоит lease 365. То есть те Infinite, которые циска изначально скачала, ей до лампочки. Но к счастью на прочитанный мак-адрес она обращает внимание. Если команду lease в пуле не вбивать, то lease expiration будет через сутки. Поэтому я попробую сделать write-delay 4294967295, что эквивалентно 136 годам :). И пусть циска только читает, но не пишет в базу данных.
Фактически с такойже ситуацией столкнулся.
Есть пользователи со статическими адресами, остальные динамически. Так если подключился пользователь с динамическим адресом write-delay 4294967295 - не работает. Все равно через некоторое вермя перезаписывает базу.
Сетевые карты меняются, пользвотели прибывают/убывают. Как заставить циску перечитать базу?. через CLI - как-то не спортивно. Ребут железяки тем более.
Помог snmp. Раз в сутки, ночью переписывается файлик dhcp.database (не забывая предварительно из него выдернуть уже существующие привязки)
далее/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.2.112 i 1
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.3.112 i 1
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.4.112 i 4
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.5.112 a 192.168.10.13
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.6.112 s "dhcp_stop"
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.14.112 i 1
sleep 20
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.14.112 i 6dhcp_stop файл на tftp с содержимым:
no serv dhcp
endзатем перезаписываю dhcp.database
и
так же запускаю dhcp/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.2.112 i 1
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.3.112 i 1
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.4.112 i 4
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.5.112 a 192.168.10.13
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.6.112 s "dhcp_start"
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.14.112 i 1
sleep 20
/usr/local/bin/snmpset -v 1 -c backup 192.168.10.5 .1.3.6.1.4.1.9.9.96.1.1.1.1.14.112 i 6содержимое dhcp_start:
serv dhcp
endнесколько секунд - загружены новые привязки
ну и копию базы держу на флеше
замена есть isc dhcpd, но там очень сложно ковырять файл db.lease на предмет кто какой ип получил.