Автоматичне збереження конфігурації пристроїв Cisco
Вирішила написати невелику посаду про автоматичне збереження конфігураційних файлів cisco.
Навіщо зберігати конфігурацію? Прикладів багато - може згоріти залізниця - її ви можете поміняти без проблем, а бекапу конфігураційного файлу немає - доведеться налаштовувати з нуля. Добре, якщо у вас хороша пам'ять (і ви пам'ятаєте всі налаштування) або у вас повністю описано система. Але що, якщо файл конфігурації займає тисячі рядків?
Або, наприклад, один із співробітників випадково почистить файл конфігурації або видалить. Можливо навмисно.
Можна зберігати конфігурацію не у flash - а на зовнішньому носії або віддаленому сервері - але втратити конфігурацію можна і в цьому випадку. Бекап конфігурації робити потрібно обов'язково — і постійно.
Я опишу, як можна автоматизувати цей процес.
Спочатку потрібно підняти TFTP сервер (так само можна використовувати FTP або інший спосіб, я зберігаю в конфігурації по локальній мережі в окремому менеджменті VLAN - тому використовую TFTP без аутентифікації).
Під TFTP-сервер можливо використовувати як Linux - так і Windows сервера, у мене для цих цілей є сервер з ОС Windows 2012. Під нього потрібно завантажити TFTP сервер - я для цих цілей використовую безкоштовну tftpd32 service edition, вона встановлюється та піднімається як сервіс у системі. Запускаємо програму, вказуємо їй папку, в якій буде збережено конфігураційні файли, вказуємо який IP вона буде використовувати і перевіряємо доступність TFTP-сервера з маршрутизатора простим копіюванням файлу з внутрішнього flash:
RT-01#copy flash: tftp:
Source filename []? 3.txt
Address or name of remote host []? 192.168.10.24
Destination filename [3.txt]?
.
11335 bytes copied in 0.044 secs (257614 bytes/sec)
RT-01#
У мене у внутрішній пам'яті маршрутизатора лежав файл «3.txt» — і його успішно скопіював на TFTP-сервер.
Спосіб перший. Створення завдання kron.
1) Створення скрипта-політики для бекапу:
Router(config)#kron policy-list (ім'я)
Router(config-kron-policy)#cli copy (звідки копіювати) (куди копіювати)
Router(config-kron-policy)#exit
де такі параметри:
сli – визначення EXEC CLI команди у завданні політики.
policy-list - визначення політики, яка асоціюватиметься із завданням в інструкції.
RT-01(config)#kron policy-list conf_to_tftp
RT-01(config-kron-policy)#cli copy system:/running-config tftp://192.168.10.24/rt-01.txt
2) Створюється інструкція для пристроїв з часом та інтервалом виконання завдання:
Router(config)#kron occurrence (name) at (hh:mm)
(day/month/oneshot/reccuring)
Router(config-kron-occurrence)#policy-list (ім'я)
RT-01(config)#kron occurrence daily at 4:00 recurring
RT-01(config-kron-occurrence)#policy-list conf_to_tftp
3) Перевірка конфігурації командою show kron.
RT-01#sh kron schedule
Kron Occurrence Schedule
daily inactive, will run again in 0 days 15:04:22 at 4 :00 on
Спосіб другий.
Архівування з'явилося в пристроях з версії 12.3 — тому, можливо, доведеться оновлювати iOS.
Подивимося параметри цієї команди:
RT-01(config)#archive
RT-01 (config-archive) #?
Archive configuration commands:
default Set a command to its defaults
exit Exit from archive configuration mode
log Logging commands
maximum maximum number of backup copies
no Negate a command or set its defaults
path path for backups
rollback Rollback parameters
time-period Period of time in minutes to automatically archive the running-config
write-memory Enable автоматичний backup generation during write memory
опишу кожен параметр:
log - налаштування логування;
maximum - максимальна кількість резервних копій конфігурації (за замовчуванням 10);
path - шлях, який вказує, де зберігаються резервні копії. При завданні імені файлу можна використовувати змінні $H - ім'я пристрою, і $T - поточний час;
time-period — період часу через який автоматично виконуватиметься архівування поточної конфігурації (хв), якщо виставити значення 1440 (24 години), то зберігатиметься щодобово і при збереженні конфігурації пристрою;
write-memory - включає автоматичну генерацію резервної копії конфігурації після виконання збереження конфігурації;
hidekeys - приховувати паролі при архівації (хоча ніхто не скасовував використання secret замість password).
подивимося можливі шляхи для збереження архівів:
flash0: Write archive on flash0: file system
flash1: Write archive on flash1: file system
flash: Write archive on flash: file system
ftp: Write archive on ftp: file system
http: Write archive on http: file system
https: Write archive on https: file system
rcp: Write archive on rcp: file system
scp: Write archive on scp: file system
tftp: Write archive on tftp: file system
Команда також дозволяє зберігати конфігурацію в різні місця.
Налаштування збереження на TFTP буде виглядати так:
RT-01(config)#archive
log config
logging enable
logging persistent reload
hidekeys
path tftp://192.168.10.24/$H-$T
write-memory
Тепер при кожному виконанні команди збереження конфіга на пристрої створиться файл на віддаленому сервері tftp.
Перевіряємо працездатність, зберігаємо конфігурацію:
І дивимося збережені архіви:
RT-01#sh archive
Максимальна архівна установка дозволяється 10.
The next archive file will be named tftp://192.168.10.24/RT-01-Mar--5-13-17-00.303.txt-1
Archive # Name
1 tftp://192.168.10.24/RT-01-Mar--5-13-16-56.343.txt-0 < — Most Recent
2
3
4
5
6
7
8
9
10
Видно, що створено один архів.
У команди ще одна корисна фіча – порівняння архівів.
Зробимо (зберігши конфігурацію) ще один архів та перевіримо їх відмінності командою:
Router# sh archive config differences (name1) (name2)
RT-01#sh archive config differences -13-20-30.647.txt-1
Loading RT-01-Mar--5-13-16-56.343.txt-0 from 192.168.10.24 (via Port-channel1):!
[OK - 6663 bytes]
Loading RT-01-Mar--5-13-20-30.647.txt-1 from 192.168.10.24 (via Port-channel1):!
[OK - 6663 bytes]
!Contextual Config Diffs:
!No changes were found
Відмінностей немає – архіви однакові.
Також є спосіб відновлення попередньої версії архіву командою:
Другий спосіб зручніший, тому що дозволяє зробити бекап при кожному збереженні конфігурації - а значить і можливість відкотитися до останньої (навіть десяти останніх) конфігурацій, але його мінус - не підтримується старими iOS. Для мене ця проблема не є актуальною — оскільки я використовую archive.
Cisco IOS: збереження конфігурації
Конфігурація мережі Cisco зберігається у двох основних місцях: одне знаходиться в ОЗП, а інше - в поточній конфігурації (running configuration). Коли ви вводите команди, вони негайно активуються і зберігаються в поточній конфігурації, яка зберігається в ОЗУ.
Тому при вимкненні живлення конфігурація втрачається. Щоб зберегти цю конфігурацію, скопіюйте її в конфігурацію завантаження (startup-configuration), що означає, що вона зберігається в енергонезалежній ОЗП (NVRAM), щоб конфігурація зберігалася при вимкненні живлення.
Ви можете використовувати дві команди для збереження конфігурації: команду запису або команду копіювання. Команда запису застаріла, але виглядатиме так:
Router#write memory Building configuration. [OK]
Новіша версія команди - це команда копіювання, яка виглядає як:
Router#copy running-config startup-config Destination filename [startup-config]? Building configuration. [OK]
Команда копіювання пропонує більше гнучкості та можливостей.Ви можете не лише скопіювати дані поточної конфігурації у файл початкової конфігурації, але й скопіювати їх у файл на флеш-пам'яті або на сервер TFTP у вашій мережі.
Для будь-якої команди потрібно набрати стільки букв, скільки потрібно IOS для однозначної ідентифікації команди. Наприклад:
