service timestamps debug datetime msec что это

Service timestamps debug datetime msec что это

To configure the system to time-stamp debugging or logging messages, use one of the service timestamps global configuration commands. Use the no form of this command to disable this service.

service timestamps type [uptime]

service timestamps type datetime [msec] [localtime] [show-timezone]

no service timestamps type

Syntax Description

Type of message to time stamp: debug or log.

(Optional) Time stamp with time since the system was rebooted.

Time stamp with the date and time.

(Optional) Include milliseconds in the date and time stamp.

(Optional) Time stamp relative to the local time zone.

(Optional) Include the time zone name in the time stamp.

Defaults

If service timestamps is specified with no arguments or keywords, default is service timestamps debug uptime.

The default for service timestamps type datetime is to format the time in UTC, with no milliseconds and no time zone name.

The command no service timestamps by itself disables time stamps for both debug and log messages.

Command Modes

Command History

This command was introduced.

Usage Guidelines

Time stamps can be added to either debugging or logging messages independently. The uptime form of the command adds time stamps in the format HHHH:MM:SS, indicating the time since the system was rebooted. The datetime form of the command adds time stamps in the format MMM DD HH:MM:SS, indicating the date and time according to the system clock. If the system clock has not been set, the date and time are preceded by an asterisk (*) to indicate that the date and time are probably not correct.

Examples

The following example enables time stamps on debugging messages, showing the time since reboot:

The following example enables time stamps on logging messages, showing the current time and date relative to the local time zone, with the time zone name included:

Источник

Service timestamps debug datetime msec что это

На этой странице даны несколько основных рекомендаций по использованию функций отладки, доступных на платформах Cisco IOS®, а также примеры правильного использования команды debug ip packet и условной отладки.

Примечание. Этот документ не объясняет, как использовать и интерпретировать специальные команды отладки debug и их выходные данные. Сведения о специальных командах debug см. в соответствующем документе «Справочник Cisco по командам debug».

Выходные данные привилегированных команд EXEC debug предоставляют диагностические сведения относительно множества событий межсетевого взаимодействия, относящихся к состоянию протокола и к сетевой активности в целом.

Предварительные условия

Требования

Использование данного документа требует наличия следующих знаний.

Подключение к маршрутизатору с помощью консоли, портов aux и vty.

Общие проблемы конфигурации IOS.

Интерпретация выводов команд debug IOS

Используемые компоненты

Настоящий документ не имеет жесткой привязки к устройству или какой-либо версии ПО.

Сведения, содержащиеся в данном документе, были получены с устройств в специальной лабораторной среде. Все устройства, используемые в этом документе, были запущены с чистой (заданной по умолчанию) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Предупреждения

Команды debug необходимо использовать с осторожностью. Обычно рекомендуется использовать эти команды только под руководством представителя технической поддержки своего маршрутизатора при выявлении конкретных неполадок.

Включение режима отладки может повлиять на работу маршрутизатора при высокой загрузке внутренней сети. Следовательно, если включена регистрация событий, сервер будет периодически недоступен, если порт консоли перегружен сообщениями о регистрации.

Используя команду debug, всегда принимайте во внимание объем выходных данных этой команды и время ее выполнения. Например, если имеется маршрутизатор с одним интерфейсом базового уровня (BRI), команда debug isdn q931 не повредит системе. Однако такая же отладка на AS5800 с полной конфигурацией E1 приведет к такому объему входных данных, что устройство может «зависнуть».

Перед использованием отладки определите степень загруженности процессора, применив команду show processes cpu. Перед началом отладки убедитесь, что имеющийся CPU обладает достаточной производительностью. Дополнительные сведения об управлении процессором в случае высокой загрузки см. в документе Устранение неполадок, связанных с высокой загрузкой процессора в маршрутизаторах Cisco. Например, при наличии маршрутизатора Cisco 7200 с интерфейсом ATM, использующего мост, – в зависимости от количества настроенных субинтерфейсов – перезагрузка маршрутизатора может вызвать высокую загрузку процессора. Здесь причиной является то, что для каждого виртуального канала необходимо создать пакет BPDU. Начало отладки в столь критический период может вызвать резкое увеличение загрузки CPU и привести к зависанию или потере сетевого соединения.

Примечание. При работе отладчика приглашение маршрутизатора обычно не видно, особенно в моменты интенсивной отладки. Однако в большинстве случаев для остановки процесса отладки можно использовать команды no debug all или undebug all. Дополнительные сведения о безопасном использовании отладки см. в разделе Получение выходных данных отладки.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. в статье Условные обозначения, используемые в технической документации Cisco.

До отладки

Помимо аспектов, упомянутых выше, следует понять, как отладка влияет на стабильность платформы. Также следует установить, к какому интерфейсу маршрутизатора необходимо подключиться. В следующем разделе приведено несколько инструкций.

Получение выходных данных отладки

Маршрутизаторы могут отображать результаты отладки для различных интерфейсов, в том числе для консольных, вспомогательных и VTY-портов. Маршрутизаторы могут также протоколировать сообщения, сохраняющиеся во внутреннем буфере, на внешнем syslog-сервере с ОС Unix. Инструкции и предупреждения относительно каждого метода обсуждаются далее.

Порт консоли

При стандартных настройках подключения к консоли дополнительных действий не требуется. Выходные данные отладки должны быть автоматически выведены на экран. Однако следует убедиться в том, что уровень регистрации при входе в консоль установлен с помощью команды logging console level так, как описано выше, и что вход не был запрещен с помощью команды no logging console. Дополнительные сведения см. в документе Использование команд debug.

Предупреждение. Избыток данных отладки в порте консоли маршрутизатора может вызвать зависание устройства. Это происходит потому, что маршрутизатор автоматически присваивает выходным данным консоли высший приоритет по отношению к другим своим функциям. По этой причине маршрутизатор может зависнуть, если он обрабатывает выходные данные отладки большого объема для порта консоли. Следовательно, если выходных данных отладки много, воспользуйтесь портами VTY (telnet) или буферами журнала для получения необходимых отладок. Подробнее об этом см. ниже.

Примечание. По умолчанию на порте консоли функция регистрации данных включена. Поэтому порт консоли всегда обрабатывает результаты отладки, даже если на самом деле для сбора результатов используется другой порт или метод (например, AUX, VTY или буфер). Следовательно, при нормальном рабочем состоянии рекомендуется, чтобы всегда была включена команда no logging console, и использовались другие способы сбора отладочных сведений. В ситуациях, в которых необходимо использовать консоль, временно включите вход в систему через консоль с помощью команды logging console.

Вспомогательный порт

Если соединение установлено через вспомогательный порт, введите команду terminal monitor. Убедитесь также, что команда no logging on не активирована на маршрутизаторе.

Примечание. Используя вспомогательный порт для отслеживания состояния маршрутизатора, помните, что при перезапуске вспомогательный порт не отображает данные последовательности загрузки. Чтобы увидеть последовательность загрузки, подключитесь к порту консоли.

Порты VTY

Если соединение установлено через вспомогательный порт или протокол Telnet, введите команду terminal monitor. Также убедитесь, что команда no logging on не использовалась.

Запись сообщений во внутренний буфер

Консоль является устройством записи данных по умолчанию; все сообщения отображаются в консоли при отсутствии специальных настроек.

Записать сообщения во внутренний буфер позволяет команда настройки маршрутизатора буферизованной регистрации. Полный синтаксис этой команды.

Команда logging buffered копирует сообщения регистрации во внутренний буфер вместо записи их в консоль. Буфер имеет кольцевую природу, поэтому более поздние сообщения записываются поверх более ранних. Чтобы отобразить сообщения, зарегистрированные в буфере, используйте привилегированную команду EXEC show logging. Первым сообщением, отображенным на экране, является самое старое сообщение из находящихся в буфере. Можно указать размер буфера, а также уровень важности регистрируемых сообщений.

Совет. Убедитесь в достаточном количестве доступной памяти модуля, прежде чем указывать размер буфера. Используйте команду IOS show proc mem, чтобы определить количество доступной памяти.

Команда no logging buffered отменяет использование буфера и записывает сообщения в консоль (по умолчанию).

Сообщения регистрации сервера системного журнала UNIX

Чтобы начать регистрацию сообщений на сервере системных журналов, используйте команду настройки маршрутизатора регистрации. Полный синтаксис этой команды выглядит следующим образом.

Команда logging определяет узел сервера системного журнала для получения сообщений регистрации. Аргументом является IP-адрес хоста. При использовании этой команды больше одного раза создается список серверов системного журнала, принимающих сообщения регистрации.

Команда no logging удаляет из списка системных журналов сервер системного журнала с указанным адресом.

Дополнительные сведения о настройке syslog-сервера см. в документе Использование команд debug.

Прочие задачи перед началом отладки

Настройте ПО эмулятора терминала (например HyperTerminal) для сбора данных отладки в файл. Например, в программе HyperTerminal щелкните Transfer, затем Capture Text и настройте соответствующие параметры. Дополнительные сведения см. в документе Запись текста выходных данных программы Hyperterminal. Для другого ПО эмуляторов терминала см. документацию к соответствующему ПО.

Включить метки времени в миллисекундах (мсек) с помощью команды service timestamps.

Эти команды добавляют метки времени в данных отладки в формате МММ ДД ЧЧ:ММ:СС, указывая дату и время в соответствии с системными часами. Если системные часы не настроены, перед датой и временем будет отображаться звездочка (*), указывающая на вероятность того, что дата и время указаны неверно.

Рекомендуется устанавливать значение метки времени в миллисекундах, что позволяет обеспечить больший уровень качества и наглядности представления выходных данных отладки. Метки времени в миллисекундах предоставляют более точное определение времени, в которое были произведены различные отладки по отношению друг к другу. Примечание. Если порт консоли выдает большое количество сообщений, они могут не совпадать с реальным моментом их появления. Например, если включена команда debug x25 для блока, содержащего 200 виртуальных каналов, а выходные данные регистрируются в буфере (с использованием команд no logging console и logging buffered), метка времени, отображаемая в выходных данных команд debug (в буфере), может не соответствовать точному времени прохождения пакета через интерфейс. Таким образом, метки времени MSEC предпочтительнее использовать не для определения проблем производительности, а для получения соответствующих данных во время совершения событий.

Прекращение отладки

Чтобы остановить отладку, необходимо использовать команду no debug all или undebug all. Убедитесь, что отладка была прекращена посредством использования команды show debug.

Запомните, что команды no logging console и terminal no monitor препятствуют только выводу выходных данных в порте консоли, вспомогательном или vty-порте. Это не останавливает отладку и поэтому истощает ресурсы маршрутизатора.

Использование команды debug ip packet

Команда debug ip packet позволяет получить информацию о пакетах, для которых маршрутизатор не использует быструю коммутацию. Однако так как он генерирует выход для каждого пакета, выход может быть пространным, и это приводит к зависанию маршрутизатора. По этой причине команду debug ip packet следует использовать под жестким контролем, как описано в этом разделе.

Самый эффективный способ ограничить выходные данные команды debug ip packet – создать список доступа, связанного с операцией отладки. Только пакеты, которые совпадают с критериями списка доступа станут предметом обработки команды debug ip packet. Этот список доступа не следует применять ни к какому интерфейсу, но он может быть применен к операции отладки.

Перед отладкой IP-пакетов с помощью команды debugging ip packet учтите, что маршрутизатор выполняет по умолчанию быструю коммутацию или, при соответствующей настройке, коммутацию CEF. Это означает, что когда будет задействован этот метод, пакет не передается на процессор, следовательно, отладка не показывает никаких данных. Чтобы данная функция работала, необходимо отключить в маршрутизаторе быструю коммутацию с помощью команды no ip route-cache (для одноадресных пакетов) или no ip mroute-cache (для многоадресных пакетов). Это должно применяться к интерфейсам, на которых предполагается поток трафика. Убедитесь в этом при помощи команды show ip route.

Предупреждения.

Отключение быстрой коммутации на маршрутизаторе, который обрабатывает большое количество пакетов, может привести к использованию CPU для всплеска загрузки таким образом, что устройство зависает или теряет соединения с одноранговыми узлами.

Не отключайте быструю коммутацию на маршрутизаторе, в котором используется многопротокольная коммутация с использованием меток (MPLS). MPLS используется совместно с методом коммутации CEF. Таким образом, отключение быстрой коммутации интерфейса может оказать разрушительное воздействие.

Рассмотрим примерный сценарий.

Сконфигурированный список доступа в маршрутизаторе_122:

Этот список разрешает доступ любому пакету протокола (ICMP) с главного маршрутизатора_121 (с IP-адресом 10.10.10.2) на главный маршрутизатор_123 (с IP-адресом 13.1.1.1), и в обратном направлении. Важно разрешить любое направление для пакетов, в противном случае маршрутизатор может отбрасывать возвратные ICMP-пакеты.

Отключим быструю коммутацию только в интерфейсе маршрутизатора_122. Это значит, что теперь видимы только данные отладки для пакетов, предназначенных для этого интерфейса (с точки зрения IOS с поддержкой перехвата пакеты). В данных отладки такие пакеты отображаются с «d=». Так как еще не отключена быстрая коммутация в другом интерфейсе, возвратный пакет не будет обрабатываться командой debug ip packet. Выходные данные, приведенные ниже, показывают, как отключить быструю коммутацию.

Теперь необходимо активировать команду debug ip packet с помощью списка доступа, определенного ранее (список доступа 105).

Теперь удалим быструю коммутацию на другом интерфейсе (на router_122). Это означает, что все пакеты между двумя интерфейсами находятся в сети с пакетной коммутацией (что необходимо для отладки ip-пакетов с помощью команды debug ip packet):

Заметьте, что выходные данные команды debug ip packet не отображают пакеты, которые не соответствуют критериям списка доступа. Дополнительные сведения об этом способе см. в документе Общие сведения о командах ping и traceroute.

Дополнительные сведения о создании списка доступа см. в документе Настройка списков IP-доступа.

Условно запускаемые отладки

Когда функция условно запускаемой отладки включена, маршрутизатор создает сообщения с данными об отладке для пакетов, принимаемых и отправляемых маршрутизатором через определенный интерфейс; маршрутизатор не создает выходные данные для пакетов, отправляемых и получаемых через разные интерфейсы. Дополнительные сведения об условных отладках см. в документе Условно запускаемые отладки.

Рассмотрим простую реализацию условных отладок. Рассмотрим следующий сценарий: маршрутизатор, показанный ниже (trabol) имеет два интерфейса (последовательные интерфейсы 0 и 3), использующие инкапсуляцию протокола HDLC

Используем команду debug serial interface для обзора сообщений об активности протокола HDLC, полученных на всех интерфейсах. Можно наблюдать сообщения об активности от обоих интерфейсов.

Используйте команду show debug condition для проверки активности условной отладки. Обратите внимание, что для последовательного интерфейса 3 имеется активное условие.

Обратите внимание, что теперь отображаются только отладки для последовательного интерфейса 3.

Теперь видно, что отображается отладка для обоих последовательных интерфейсов 0, а также для последовательного интерфейса 3.

Предупреждение. Некоторые операции отладки являются условиями сами по себе. Примером является отладка асинхронного режима передачи atm. При отладке ATM необходимо указать интерфейс, для которого следует включить отладку, а не включать отладку для всех ATM-интерфейсов, указывая условие.

Следующий раздел содержит описание корректного способа ограничения отладки ATM-пакетов одним субинтерфейсом.

При попытке включения отладки ATM на всех интерфейсах с помощью команды atm debugging (с примененным условием), маршрутизатор может «зависнуть», если у него имеется большое число субинтерфейсов ATM. Показан пример неправильного метода для отладки atm.

В этом случае можно увидеть, что условие применено, но не имеет эффекта. Все еще остаются видимыми пакеты с другого интерфейса. В этом примерном сценарии используется всего два интерфейса, и передается незначительный объем трафика. Если количество интерфейсов высоко, количество выходных данных для отладки всех интерфейсов превысит допустимое значение, что может вызвать сбой в работе маршрутизатора.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.

Источник

Service timestamps debug datetime msec что это

Timestamps are useful for viewing when certain events happen on a router. Timestanps are also helpful for troubleshooting, because they allow the network administrator to compare simultaneous events on network routers and analyze whether one occurrence caused, or was a result of, another.

In this lab, you will practice configuring timestamps with different variables.

This lab has the following objectives:

enable
exit
help
ping 10.1.1.1
show clock
show version

clear logging
configure terminal
debug ip packet
disable
exit
help
no debug all
no debug ip packet
ping 10.1.1.1
show clock
show debugging
show ip route
show logging
show running-config
show version
undebug all
undebug ip packet

end
exit
help
service timestamps debug uptime
service timestamps debug datetime
service timestamps debug datetime msec
service timestamps debug datetime msec show-timezone
service timestamps debug datetime msec show-timezone localtime
service timestamps log uptime
service timestamps log datetime
service timestamps log datetime msec
service timestamps log datetime msec show-timezone
service timestamps log datetime msec show-timezone localtime

Click on the Configuration Lab icon to the right to open the interactive simulation environment window in a new browser.

To enter commands, activate the simulation environment Telnet window by clicking in it.

Источник

Cisco IOS функционал Archive

Я не буду писать большое введение, лишь скажу что Archive — удобный инструмент, который был введен в IOS 12.3(4) и может служить для решения нескольких задач:

Автоматическое сохранение конфигурации

1. Путь хранения конфигурации. Ротация

Указать путь хранения архивных конфигураций можно следующим образом:

Хранить можно, конечно, и на локальном сторадже (flash:, disk0:, sup-bootflash:, nvram:), но как тогда восстанавливать конфигурацию в случае смерти устройства?

Теперь попробуем создать архив вручную:

ВНИМАНИЕ:команда “archive config” архивирует именно текущую конфигурацию устройства (running-config), и не сохраняет running-config в startup-config.

Получился файл с таким именем:

Если все-таки решено использовать локальное хранилище для архивации файлов конфигурации, то имеет смысл ограничивать количество файлов. Максимум можно указать 14. В моем примере я использую хранилище unix: из-за того, что использую IOU/IOL в UnetLAB:

В данном случае после смены пути архивирования на локальный и установки лимита в 5 файлов, при попытке создания 6-го архива, наиболее старый файл архива будет удален.

А вот если бы я попробовал ограничить количество хранимых архивных конфигураций на удаленном TFTP-сервере:

Если путь архивирования сетевой, то ограничение поставить нельзя – ограничивать следует средствами того сервера, куда льются файлы.

2. Автоматическое архивирование. Kron

С путем все понятно, но нужно делать архивы автоматически. Команда “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 время указывается таким образом: . В моем примере выполнение ежедневное;
oneshot, recurring – выполнять один раз или регулярно соответственно. В документации, кажется, видел, что в некоторых версиях IOS доступна также опция system-startup, т.е. выполнение при старте устройства;
policy-list CONFIG_BACKUP – указание политики, с которой нужно работать.

Таким образом в моем примере команда “wr mem” будет выполняться ежедневно в 10:00, а это повлечет за собой архивирование конфигурации (согласно настройке archive).

Примерно такой будет конфигурация kron:

3. Переменные в имени архива конфигурации. Timestamp

Не очень удобочитаемое имя, а миллисекунда так явно не нужна. Это является следствием:

Чтобы настроить удобочитаемое отображение файла, нужно исправить формат timestamp (укажем также часовой пояс):

Теперь файл выглядит так:

Т.е. “месяц-день-год-час-минута-секунда-часовой_пояс-номер_файла”.
Из формата команды “service timestamps” вполне понятно, как убрать, например год или часовой пояс.

Что с именем хоста? Можно для ясности использовать такую форму:

Тогда, как видно, имя файла будет состоять из текста “SW1” и временного штампа. Станет понятно, от какого устройства конфигурация. Но если имя хоста изменится, придется вручную менять эту настройку в archive. Можно использовать переменную $h, которая хранит имя хоста. Кстати, переменная $t хранит timestamp, но сейчас ее использовать смысла не имеет, в IOS 15 автоматически подставляется в имя файла. В 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 разлогинивался, это означает лишь то, что он выходил из режима конфигурирования.

И еще пара примеров:

Сравнение конфигураций. Откат конфигурации

1. Сравнение конфигураций

Вместе с функцией 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 не откатим.

2. Откат конфигурации

При работе через 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”. Ответ должен быть таким:

Источник

• ← самый лучший маленький холодильник на сегодняшний день
• самый лучший день смотреть песня →