Я не буду писать большое введение, лишь скажу что Archive — удобный инструмент, который был введен в IOS 12.3(4) и может служить для решения нескольких задач:
Указать путь хранения архивных конфигураций можно следующим образом:
Хранить можно, конечно, и на локальном сторадже (flash:, disk0:, sup-bootflash:, nvram:), но как тогда восстанавливать конфигурацию в случае смерти устройства?
Теперь попробуем создать архив вручную:
ВНИМАНИЕ:команда “archive config” архивирует именно текущую конфигурацию устройства (running-config), и не сохраняет running-config в startup-config.
Получился файл с таким именем:
Почему с таким? Потому что в качестве имени файла архива конфигурации по умолчанию используется “[string]-<timestamp>-№”:
Если все-таки решено использовать локальное хранилище для архивации файлов конфигурации, то имеет смысл ограничивать количество файлов. Максимум можно указать 14. В моем примере я использую хранилище unix: из-за того, что использую IOU/IOL в UnetLAB:
В данном случае после смены пути архивирования на локальный и установки лимита в 5 файлов, при попытке создания 6-го архива, наиболее старый файл архива будет удален.
А вот если бы я попробовал ограничить количество хранимых архивных конфигураций на удаленном TFTP-сервере:
Если путь архивирования сетевой, то ограничение поставить нельзя – ограничивать следует средствами того сервера, куда льются файлы.
С путем все понятно, но нужно делать архивы автоматически. Команда “write-memory” в контексте “archive” включит автоматическое архивирование при сохранении running-config в startup-config:
Не важно, что использовать: “wr mem” или “copy run start” – архив будет создан. В данном примере после использования команд было создано 2 файла.
Архивирование при копировании running-config в startup-config это хорошо, но если нам нужно регулярное копирование? Можно использовать команду “time period” с указанием интервала минут, через который будет производиться архивирование. Например, можно использовать значение 10080 для архивирования каждую неделю. Вот результат работы автоархивирования каждую минуту:
Что если нужно архивировать не через определенный интервал времени, а в определенное время? Ответ – kron. Kron определяется политикой и шедулером. Синтаксис интуитивно понятен, поэтому проще показать на примере.
Зададим политику:
^ это та команда, которая будет исполняться
Стоит учесть важный момент: kron не поддерживает в команде cli интерактивные команды, которые требуют некоторого диалога. Например, “copy run start” спросит имя файла для сохранения, поэтому не отработает в kron. Следовательно, нужно использовать “wr mem”.
Зададим шедулер:
Где:
CONFIG_BACKUP_SCHED – название шедулера;
at и in – очевидно, выполнение в определенное время или через определенный интервал соответственно. В случае at время указывается таким образом: {hh:mm [месяц] [день месяца] [день недели]}. В моем примере выполнение ежедневное;
oneshot, recurring – выполнять один раз или регулярно соответственно. В документации, кажется, видел, что в некоторых версиях IOS доступна также опция system-startup, т.е. выполнение при старте устройства;
policy-list CONFIG_BACKUP – указание политики, с которой нужно работать.
Таким образом в моем примере команда “wr mem” будет выполняться ежедневно в 10:00, а это повлечет за собой архивирование конфигурации (согласно настройке archive).
Примерно такой будет конфигурация kron:
Название файла архива кажется не особо говорящим. Выше я упоминал, что имя файла формируется так: “-<timestamp>-№”. Если разобрать:
Не очень удобочитаемое имя, а миллисекунда так явно не нужна. Это является следствием:
Чтобы настроить удобочитаемое отображение файла, нужно исправить формат timestamp (укажем также часовой пояс):
Теперь файл выглядит так:
Т.е. “месяц-день-год-час-минута-секунда-часовой_пояс-номер_файла”.
Из формата команды “service timestamps” вполне понятно, как убрать, например год или часовой пояс.
Что с именем хоста? Можно для ясности использовать такую форму:
Тогда, как видно, имя файла будет состоять из текста “SW1” и временного штампа. Станет понятно, от какого устройства конфигурация. Но если имя хоста изменится, придется вручную менять эту настройку в archive. Можно использовать переменную $h, которая хранит имя хоста. Кстати, переменная $t хранит timestamp, но сейчас ее использовать смысла не имеет, в IOS 15 <timestamp> автоматически подставляется в имя файла. В IOS 12 пришлось бы использовать запись “path tftp://10.0.5.1/$h-$t”, теперь достаточно такой:
И результат:
Функция “Archive” позволяет не только архивировать файлы конфигурации, но и архивировать введенные команды конфигурирования, т.е. те команды, которые изменили конфигурацию устройства и также команду “enable” (т.е. если кто-то перейдет в привилегированный режим, это тоже попадет в лог).
Отличие от “show history” очевидно (history листит только мои личные команды). Но лучше показать на примере:
logging enable – включает логирование конфигурационных команд;
logging size – максимальное количество хранимых команд;
hidekeys – скрывать пароли при просмотре логированных команд.
Как все это выглядит:
Т.е. мы видим имя пользователя (в моем случае mark и greg), линию, с которой совершены действия, видим даже команду “enable”, но НЕ видим пароль созданного greg`а (как и задумывалось).
Также будет уведомлять syslog-сервер (если он сконфигурирован, ну или будет сыпать в консоль и монитор) примерно такими сообщениями:
Можно также просмотреть информацию по каждому пользователю по сессиям:
Но здесь стоит учитывать, что сессия в данном контексте – это сессия входа в configure terminal. Т.е. 3 сессии вовсе не значит, что mark разлогинивался, это означает лишь то, что он выходил из режима конфигурирования.
И еще пара примеров:
Вместе с функцией Archive в IOS появилась полезная фича сравнения конфигураций. Например, сравним startup-config с конфигом на tftp-сервере:
+ означает, что строка есть во втором указанном файле конфигурации (т.е. в SW1-Jan-13-2017-10-00-00-Golf-3), но ее нет в первом (т.е. в startup-config);
- означает, что строка есть в первом файле конфигурации (в startup-config), но ее нет во втором (в SW1-Jan-13-2017-10-00-00-Golf-3).
Чтобы сравнить running-config с этим же файлом конфигурации на удаленном tftp-сервере, будет использоваться команда:
Чтобы сравнить running-config со startup-config, достаточно использовать короткую запись:
По факту это команда “show archive config differences system:running-config nvram:startup-config”.
Ну и в данном случае видно, что run отличается от start только тем, что интерфейс eth0/3 в текущей конфигурации административно отключен.
Команда “show archive config incremental-diffs” с указанием файла конфигурации покажет, какие строки будут добавлены в running-config при операции копирования из этого файла в run:
Но стоит помнить, что copy для running-config это совсем не то же самое, что configure replace.
Если посмотреть, например startup-config:
Т.е. “differences” показывает, что в run отключен eth0/3, но “incremental-diffs” говорит, что при копировании “copy start run” в текущую конфигурацию ничего не будет добавлено. Т.е. такой командой мы running-config к startup-config не откатим.
При работе через vty некоторые используют “reload in [min]” команду для того, чтобы если в текущей конфигурации совершены ошибки, и доступ до устройства потерян, устройство автоматически перезагрузилось через определенный интервал времени и изменения откатились до startup-config.
Archive позволяет решать такие проблемы без перезагрузки устройства – отложенным откатом running-config.
ВНИМАНИЕ: для использования откатов должно быть настроено архивирование конфигурации. Например такое:
a. Откат через определенный интервал времени
Приступаем к конфигурации оборудования. Предварительно задаем таймер отката командой “configure terminal revert timer ”:
Как видно, running-config заархвивировался в 10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1 и откат к этому файлу отложен на 20 минут.
Теперь для примера внесем изменения (отключим eth0/3):
Проходит время, когда остается 1 минута до отката, IOS предупреждает меня:
Минута истекает и происходит откат (по факту «configure replace»):
Проверяем:
Eth0/3 не отключен, т.е. откат успешен.
b. Сколько осталось времени. Моментальный откат
Информацию о том, сколько осталось времени до отката можно узнать с помощью команды “show archive config rollback timer”:
Сколько времени осталось не показано, но показано время, когда интервал был сконфигурирован и длину самого интервала, т.е. можно посчитать.
Как изменить интервал – уменьшить или увеличить? Командой “configure revert timer”:
Фактически эта команда ничего не добавляет и не убавляет, а просто задает новый интервал от текущего момента.
Как совершить моментальный откат? Командой “configure revert now”:
Ну, у меня в данном случае изменений не было. Это то же самое, что и “configure replace”, только конфиг, на который нужно откатываться, указать нельзя.
c. Как отменить откат
Предположим мы задали интервал отката, внесли изменения и нас устраивает текущая конфигурация. Как отменить откат running-config? Командой “configure confirm”:
Стоит четко понимать, что “configure confirm” это не сохранение run в start, это просто отмена отката.
ВНИМАНИЕ: после подтверждения конфигурации, т.е. отмены отката ОБЯЗАТЕЛЬНО нужно проверить “show archive config rollback timer”. Ответ должен быть таким:
P.S. на протяжении статьи я не раз это упоминал, но на последок все же повторю: rollback, так же как и configure replace, это откат именно running-config и никакого другого файла.
- Автоматическое сохранение конфигурации
- Логирование каждой введенной команды в режиме конфигурирования
- Сравнение и откат конфигураций
Автоматическое сохранение конфигурации
1. Путь хранения конфигурации. Ротация
Указать путь хранения архивных конфигураций можно следующим образом:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#archive
SW1(config-archive)#path tftp://10.0.5.1/
SW1(config-archive)#end
SW1#
Хранить можно, конечно, и на локальном сторадже (flash:, disk0:, sup-bootflash:, nvram:), но как тогда восстанавливать конфигурацию в случае смерти устройства?
Теперь попробуем создать архив вручную:
SW1#archive config
!
SW1#ВНИМАНИЕ:команда “archive config” архивирует именно текущую конфигурацию устройства (running-config), и не сохраняет running-config в startup-config.
Получился файл с таким именем:
Почему с таким? Потому что в качестве имени файла архива конфигурации по умолчанию используется “[string]-<timestamp>-№”:
SW1#show archive
The maximum archive configurations allowed is 10.
The next archive file will be named tftp://10.0.5.1/-<timestamp>-1
Archive # Name
1 tftp://10.0.5.1/-Jan-11-15-44-33.695-0 <- Most Recent
2
......
10
Если все-таки решено использовать локальное хранилище для архивации файлов конфигурации, то имеет смысл ограничивать количество файлов. Максимум можно указать 14. В моем примере я использую хранилище unix: из-за того, что использую IOU/IOL в UnetLAB:
SW1(config-archive)#path unix:
SW1(config-archive)#maximum 5
В данном случае после смены пути архивирования на локальный и установки лимита в 5 файлов, при попытке создания 6-го архива, наиболее старый файл архива будет удален.
А вот если бы я попробовал ограничить количество хранимых архивных конфигураций на удаленном TFTP-сервере:
SW1(config-archive)#maximum 3
Cannot set maximum when backing up to network path
Если путь архивирования сетевой, то ограничение поставить нельзя – ограничивать следует средствами того сервера, куда льются файлы.
2. Автоматическое архивирование. Kron
С путем все понятно, но нужно делать архивы автоматически. Команда “write-memory” в контексте “archive” включит автоматическое архивирование при сохранении running-config в startup-config:
SW1(config-archive)#write-memory
SW1(config-archive)#end
SW1#write mem
Building configuration...
Compressed configuration from 1177 bytes to 843 bytes[OK]!
SW1#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
Compressed configuration from 1177 bytes to 843 bytes[OK]!
SW1#
Не важно, что использовать: “wr mem” или “copy run start” – архив будет создан. В данном примере после использования команд было создано 2 файла.
Архивирование при копировании running-config в startup-config это хорошо, но если нам нужно регулярное копирование? Можно использовать команду “time period” с указанием интервала минут, через который будет производиться архивирование. Например, можно использовать значение 10080 для архивирования каждую неделю. Вот результат работы автоархивирования каждую минуту:
SW1(config)#archive
SW1(config-archive)#time-period 1
SW1(config-archive)#!
SW1(config-archive)#end
SW1#
Что если нужно архивировать не через определенный интервал времени, а в определенное время? Ответ – kron. Kron определяется политикой и шедулером. Синтаксис интуитивно понятен, поэтому проще показать на примере.
Зададим политику:
SW1(config)#kron policy-list CONFIG_BACKUP
SW1(config-kron-policy)#cli wr mem
SW1(config-kron-policy)#exit
^ это та команда, которая будет исполняться
Стоит учесть важный момент: kron не поддерживает в команде cli интерактивные команды, которые требуют некоторого диалога. Например, “copy run start” спросит имя файла для сохранения, поэтому не отработает в kron. Следовательно, нужно использовать “wr mem”.
Зададим шедулер:
SW1(config)#kron occurrence CONFIG_BACKUP_SCHED ?
at Date of kron occurrence eg. 14:30 Feb 13
in Delta time to kron occurrence
SW1(config)#kron occurrence CONFIG_BACKUP_SCHED at ?
hh:mm Time of day for occurrence (hh:min eg. 14:30)
SW1(config)#kron occurrence CONFIG_BACKUP_SCHED at 10:00 ?
<1-31> Day of month
DAY Day of Week eg mon, tue, etc
MONTH Month of year eg jan, feb, etc
oneshot Schedule kron occurrence exactly once
recurring Schedule kron occurrence repeatedly
SW1(config)#kron occurrence CONFIG_BACKUP_SCHED at 10:00 recurring
Clock currently not set it reads 16:25:44 UTC Wed Jan 11 2017
SW1(config-kron-occurrence)#policy-list CONFIG_BACKUP
SW1(config-kron-occurrence)#end
SW1#
Где:
CONFIG_BACKUP_SCHED – название шедулера;
at и in – очевидно, выполнение в определенное время или через определенный интервал соответственно. В случае at время указывается таким образом: {hh:mm [месяц] [день месяца] [день недели]}. В моем примере выполнение ежедневное;
oneshot, recurring – выполнять один раз или регулярно соответственно. В документации, кажется, видел, что в некоторых версиях IOS доступна также опция system-startup, т.е. выполнение при старте устройства;
policy-list CONFIG_BACKUP – указание политики, с которой нужно работать.
Таким образом в моем примере команда “wr mem” будет выполняться ежедневно в 10:00, а это повлечет за собой архивирование конфигурации (согласно настройке archive).
Примерно такой будет конфигурация kron:
SW1#show running-config | section kron
kron occurrence CONFIG_BACKUP_SCHED at 10:00 recurring
policy-list CONFIG_BACKUP
kron policy-list CONFIG_BACKUP
cli wr mem
3. Переменные в имени архива конфигурации. Timestamp
Название файла архива кажется не особо говорящим. Выше я упоминал, что имя файла формируется так: “-<timestamp>-№”. Если разобрать:
Не очень удобочитаемое имя, а миллисекунда так явно не нужна. Это является следствием:
SW1#show running-config | section timestamp
service timestamps debug datetime msec
service timestamps log datetime msec
Чтобы настроить удобочитаемое отображение файла, нужно исправить формат timestamp (укажем также часовой пояс):
SW1(config)#clock timezone Golf +7
SW1(config)#service timestamps log datetime year localtime show-timezone
Теперь файл выглядит так:
Т.е. “месяц-день-год-час-минута-секунда-часовой_пояс-номер_файла”.
Из формата команды “service timestamps” вполне понятно, как убрать, например год или часовой пояс.
Что с именем хоста? Можно для ясности использовать такую форму:
SW1(config)#archive
SW1(config-archive)#path tftp://10.0.5.1/SW1
SW1(config-archive)#end
SW1#show archive
The maximum archive configurations allowed is 10.
The next archive file will be named tftp://10.0.5.1/SW1-<timestamp>-0
.....
Тогда, как видно, имя файла будет состоять из текста “SW1” и временного штампа. Станет понятно, от какого устройства конфигурация. Но если имя хоста изменится, придется вручную менять эту настройку в archive. Можно использовать переменную $h, которая хранит имя хоста. Кстати, переменная $t хранит timestamp, но сейчас ее использовать смысла не имеет, в IOS 15 <timestamp> автоматически подставляется в имя файла. В IOS 12 пришлось бы использовать запись “path tftp://10.0.5.1/$h-$t”, теперь достаточно такой:
SW1(config)#archive
SW1(config-archive)#path tftp://10.0.5.1/$h
SW1(config-archive)#end
SW1#
И результат:
Логирование введенных команд
Функция “Archive” позволяет не только архивировать файлы конфигурации, но и архивировать введенные команды конфигурирования, т.е. те команды, которые изменили конфигурацию устройства и также команду “enable” (т.е. если кто-то перейдет в привилегированный режим, это тоже попадет в лог).
Отличие от “show history” очевидно (history листит только мои личные команды). Но лучше показать на примере:
SW1(config)#archive
SW1(config-archive)#log config
SW1(config-archive-log-cfg)#logging enable
SW1(config-archive-log-cfg)#logging size 200
SW1(config-archive-log-cfg)#hidekeys
logging enable – включает логирование конфигурационных команд;
logging size – максимальное количество хранимых команд;
hidekeys – скрывать пароли при просмотре логированных команд.
Как все это выглядит:
SW1#show archive log config all
idx sess user@line Logged command
1 1 mark@console | logging enable
2 1 mark@console | logging size 200
3 1 mark@console | hidekeys
4 2 mark@console |username greg privilege 1 secret *****
5 2 mark@console |!config: USER TABLE MODIFIED
6 0 greg@vty0 |!exec: enable
Т.е. мы видим имя пользователя (в моем случае mark и greg), линию, с которой совершены действия, видим даже команду “enable”, но НЕ видим пароль созданного greg`а (как и задумывалось).
SW1(config-archive-log-cfg)#notify syslog
Также будет уведомлять syslog-сервер (если он сконфигурирован, ну или будет сыпать в консоль и монитор) примерно такими сообщениями:
*Jan 12 2017 17:12:30 Golf: %PARSER-5-CFGLOG_LOGGEDCMD: User:mark logged command:interface Ethernet0/3
*Jan 12 2017 17:12:32 Golf: %PARSER-5-CFGLOG_LOGGEDCMD: User:mark logged command:no shutdown
Можно также просмотреть информацию по каждому пользователю по сессиям:
Но здесь стоит учитывать, что сессия в данном контексте – это сессия входа в configure terminal. Т.е. 3 сессии вовсе не значит, что mark разлогинивался, это означает лишь то, что он выходил из режима конфигурирования.
И еще пара примеров:
Сравнение конфигураций. Откат конфигурации
1. Сравнение конфигураций
Вместе с функцией Archive в IOS появилась полезная фича сравнения конфигураций. Например, сравним startup-config с конфигом на tftp-сервере:
SW1#$show archive config differences nvram:startup-config tftp://10.0.5.1/SW1-Jan-13-2017-10-00-00-Golf-3
Loading SW1-Jan-13-2017-10-00-00-Golf-3 from 10.0.5.1 (via Vlan1): !
[OK - 1483 bytes]
!Contextual Config Diffs:
+service timestamps log datetime localtime show-timezone year
+username greg secret 4 WGWXTgqyMqk91MhF3Gz5CQdMnLHU4clSthRczGfB2dY
+clock timezone Golf 7 0
+archive
+log config
+logging enable
+logging size 200
+hidekeys
+path tftp://10.0.5.1/$h
+write-memory
+kron occurrence CONFIG_BACKUP_SCHED at 10:00 recurring
+policy-list CONFIG_BACKUP
+kron policy-list CONFIG_BACKUP
+cli wr mem
-service timestamps log datetime msec
+ означает, что строка есть во втором указанном файле конфигурации (т.е. в SW1-Jan-13-2017-10-00-00-Golf-3), но ее нет в первом (т.е. в startup-config);
- означает, что строка есть в первом файле конфигурации (в startup-config), но ее нет во втором (в SW1-Jan-13-2017-10-00-00-Golf-3).
Чтобы сравнить running-config с этим же файлом конфигурации на удаленном tftp-сервере, будет использоваться команда:
SW1#show archive config differences system:running-config tftp://10.0.5.1/SW1-Jan-13-2017-10-00-00-Golf-3
Чтобы сравнить running-config со startup-config, достаточно использовать короткую запись:
SW1#show archive config differences
!Contextual Config Diffs:
interface Ethernet0/3
-shutdown
По факту это команда “show archive config differences system:running-config nvram:startup-config”.
Ну и в данном случае видно, что run отличается от start только тем, что интерфейс eth0/3 в текущей конфигурации административно отключен.
Команда “show archive config incremental-diffs” с указанием файла конфигурации покажет, какие строки будут добавлены в running-config при операции копирования из этого файла в run:
SW1#$ show archive config incremental-diffs tftp://10.0.5.1/SW1-Jan-13-2017-10-00-00-Golf-3
Loading SW1-Jan-13-2017-10-00-00-Golf-3 from 10.0.5.1 (via Vlan1): !
[OK - 1483 bytes]
!List of Commands:
service timestamps log datetime localtime show-timezone year
username greg secret 4 WGWXTgqyMqk91MhF3Gz5CQdMnLHU4clSthRczGfB2dY
clock timezone Golf 7 0
archive
log config
logging enable
logging size 200
hidekeys
path tftp://10.0.5.1/$h
write-memory
kron occurrence CONFIG_BACKUP_SCHED at 10:00 recurring
policy-list CONFIG_BACKUP
kron policy-list CONFIG_BACKUP
cli wr mem
end
Но стоит помнить, что copy для running-config это совсем не то же самое, что configure replace.
Если посмотреть, например startup-config:
SW1#show archive config differences
!Contextual Config Diffs:
interface Ethernet0/3
-shutdown
SW1#show archive config incremental-diffs nvram:startup-config
!List of Commands:
end
!No changes were found
Т.е. “differences” показывает, что в run отключен eth0/3, но “incremental-diffs” говорит, что при копировании “copy start run” в текущую конфигурацию ничего не будет добавлено. Т.е. такой командой мы running-config к startup-config не откатим.
2. Откат конфигурации
При работе через vty некоторые используют “reload in [min]” команду для того, чтобы если в текущей конфигурации совершены ошибки, и доступ до устройства потерян, устройство автоматически перезагрузилось через определенный интервал времени и изменения откатились до startup-config.
Archive позволяет решать такие проблемы без перезагрузки устройства – отложенным откатом running-config.
ВНИМАНИЕ: для использования откатов должно быть настроено архивирование конфигурации. Например такое:
SW1#show running-config | section archive
archive
log config
logging enable
logging size 200
hidekeys
path tftp://10.0.5.1/$h
write-memory
a. Откат через определенный интервал времени
Приступаем к конфигурации оборудования. Предварительно задаем таймер отката командой “configure terminal revert timer ”:
SW1#configure terminal revert timer 20
!Rollback Confirmed Change: Backing up current running config to tftp://10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#
*Jan 13 2017 16:16:30 Golf: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_BACKUP: Backing up current running config to tftp://10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1
*Jan 13 2017 16:16:30 Golf: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_START_ABSTIMER: User: mark: Scheduled to rollback to config tftp://10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1 in 20 minutes
Как видно, running-config заархвивировался в 10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1 и откат к этому файлу отложен на 20 минут.
Теперь для примера внесем изменения (отключим eth0/3):
SW1(config)#interface ethernet 0/3
SW1(config-if)#shutdown
SW1(config-if)#end
SW1#show running-config | section interface
.....
interface Ethernet0/3
shutdown
duplex auto
.....
Проходит время, когда остается 1 минута до отката, IOS предупреждает меня:
SW1#Rollback Confirmed Change: Rollback will begin in one minute.
Enter "configure confirm" if you wish to keep what you've configured
*Jan 13 2017 16:26:38 Golf: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_WARNING_ABSTIMER: System will rollback to config tftp://10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1 in one minute. Enter "configure confirm" if you wish to keep what you've configured
Минута истекает и происходит откат (по факту «configure replace»):
Минута истекает и происходит откат (по факту configure replace):
SW1#Rollback Confirmed Change: rolling to:tftp://10.0.5.1/SW1-Jan-13-2017-16-16-30-Golf-1
Loading SW1-Jan-13-2017-16-16-30-Golf-1 from 10.0.5.1 (via Vlan1): !
[OK - 1483 bytes]
Loading SW1-Jan-13-2017-16-16-30-Golf-1 from 10.0.5.1 (via Vlan1): !
[OK - 1483 bytes]
!Pass 1
!List of Rollback Commands:
interface Ethernet0/3
no shutdown
end
Total number of passes: 1
Rollback Done
Проверяем:
SW1#sh run | section interface
.....
interface Ethernet0/3
duplex auto
.....
Eth0/3 не отключен, т.е. откат успешен.
b. Сколько осталось времени. Моментальный откат
Информацию о том, сколько осталось времени до отката можно узнать с помощью команды “show archive config rollback timer”:
SW1#configure terminal revert timer 10
!Rollback Confirmed Change: Backing up current running config to tftp://10.0.5.1/SW1-Jan-13-2017-16-40-36-Golf-2
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#end
SW1#show archive config rollback timer
Time configured(or reconfigured): 16:40:36 Golf Fri Jan 13 2017
Timer type: absolute timer
Timer value: 10 min
User: mark
Сколько времени осталось не показано, но показано время, когда интервал был сконфигурирован и длину самого интервала, т.е. можно посчитать.
Как изменить интервал – уменьшить или увеличить? Командой “configure revert timer”:
SW1#configure revert timer 5
SW1#
*Jan 13 2017 16:43:50 Golf: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_RESET_ABSTIMER: User: mark: Reset Rollback Confirmed Change timer(absolute) to 5 minute
SW1#show archive config rollback timer
Time configured(or reconfigured): 16:43:50 Golf Fri Jan 13 2017
Timer type: absolute timer
Timer value: 5 min
User: mark
Фактически эта команда ничего не добавляет и не убавляет, а просто задает новый интервал от текущего момента.
Как совершить моментальный откат? Командой “configure revert now”:
SW1#configure revert now
Rollback Confirmed Change: rolling to:tftp://10.0.5.1/SW1-Jan-13-2017-16-40-36-Golf-2
Loading SW1-Jan-13-2017-16-40-36-Golf-2 from 10.0.5.1 (via Vlan1): !
[OK - 1483 bytes]
Loading SW1-Jan-13-2017-16-40-36-Golf-2 from 10.0.5.1 (via Vlan1): !
[OK - 1483 bytes]
Total number of passes: 0
Rollback Done
Ну, у меня в данном случае изменений не было. Это то же самое, что и “configure replace”, только конфиг, на который нужно откатываться, указать нельзя.
c. Как отменить откат
Предположим мы задали интервал отката, внесли изменения и нас устраивает текущая конфигурация. Как отменить откат running-config? Командой “configure confirm”:
SW1#configure confirm
SW1#
*Jan 13 2017 16:48:42 Golf: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_CONFIRM: User: mark: Confirm the configuration change
Стоит четко понимать, что “configure confirm” это не сохранение run в start, это просто отмена отката.
ВНИМАНИЕ: после подтверждения конфигурации, т.е. отмены отката ОБЯЗАТЕЛЬНО нужно проверить “show archive config rollback timer”. Ответ должен быть таким:
SW1#show archive config rollback timer
%No Rollback Confirmed Change pending
P.S. на протяжении статьи я не раз это упоминал, но на последок все же повторю: rollback, так же как и configure replace, это откат именно running-config и никакого другого файла.
denis_lx
Отличная статья.
Давно уже не выносил для себя столько полезного из одной статьи.