Ip sla cisco настройка два провайдера
Обновлено: 05.07.2024
Два и более провайдера в Интернет на cisco 871
В данной статье мне хотелось бы рассмотреть настройку маршрутизатора cisco на предоставление доступа в Интернет по двум канаkам от разных провайдеров, с возможностью автоматического переключения, в случае отказа одного из каналов.
Итак, исходные данные:
Почему именно такие условия? Во-первых была поставлена именно такая задача, а я стараюсь в этом блоге описывать не какие-то условные задачи, а предалагать решения на основе своей практики. Во-вторых, такая схема намного удобнее простой балансировки нагрузки, так как балансировка основывается, как правило, на соединениях (то есть каждое отдельное соединение клиент-сервер обслуживается по отдельному каналу), что создает ряд проблем. Однако намного проще и правильнее, когда сетевой администратор может, на основе имеющихся данных по среднему потреблению трафика каким-либо клиентом, распределить между провайдрами нагрузку действительно равномерно.
Первоначальная настройка интерфейсов
Для простоты описания возьмем следующую топологию нашей сети:
Заходим на cisco, включаем режим enable (привелегированный режим, аналогично пользователю root в linux) и переходим в режим конфигурации
Настраиваем интерфейс Fast Ethernet 4 (WAN):
Директивы интуитивно понятны, но на всякий случай рассмотрим их подробнее:
По сути всего одна директива, которая вполне понятна и без описания. Но есть еще один немаловажный момент, с которым я в свое время очень долго мучался и перерыл кучу документации на официальном сайте cisco. Суть вот в чем: когда я первый раз настроил vlan на cisco и назначил ему адреса я попробовал с cisco пропинговать свой шлюз, но он никак не хотел пинговаться. Оказывается vlan у меня включался в режим trank, а провайдер мне давал обычный ethernet линк и вообще мало подозревал о том, что я хожу в Интернет из-за cisco. Так что нам, чтобы не наступать на эти же грабли надо в режиме конфигурации ввести следующую директиву:
Как вы видите конфигурация немного отличается, а именно: изменилась директива ip nat inside и добавилась директива ip policy route-map RouteSelect.
ip nat inside говорит нашему маршрутизатору, что на этом интерфейсе внутренняя сторона NAT, то есть здесь происходит преобразтование из приватных адресов в публичные. Другими словами -это наш внутренний интерфейс
Настройка списков доступа и пулов NAT
Мы решили что первые две сети из нашего примера, то есть 10.10.1.0/24 и 10.10.2.0/24 мы будем маршрутизировать через провайдера FirstTelecom, а соответственно сети 10.10.3.0/24 и 10.10.4.0/24 через провайдера SecondTelecom.
Для этого нам нужно создать списки доступа (access-list), делается это весьма просто. Итак, создадим два списка доступа First и Second:
Как мы видим, маска для наших сетей задается не обычным образом. Дело в том, что при задании списков доступа на cisco используется wildcard маска, ее еще называют обратной маской
Пул для NAT задается директивой ip nat pool <start-ip> <end-ip> netmask <netmask>, где <start-ip> это начальный адрес пула, <end-ip>, соответственно конечный адрес пула, ну и<netmask> - это маска сети. Так как для нашего примера мы используем по одному ip адресу от каждого провайдера, то start-ip и end-ip будут совпадать. Создаем два пула для нашего будущего NAT:
Так же нам надо создать два списка доступа для локальных сетей самих провайдеров, чтобы в данные сети пользователи маршрутизировались всегда через того провайдера, которому сеть принадлежит. Скажем каждый провайдер обладает сетью класса B из того же диапазона, который выдан нам, то есть это будут сети 91.100.0.0/16 и 91.1.0.0/16. Для этого создадим еще два списка доступа FirstTelecomNet и SecondTelecomNet:
В данном случае мы используем extended списки доступа, которые отличаются от standart тем, что мы можем указать явно ip источника и назначения (в stanrart листах указываются просто ip и они могут быть как адресами источника, так и назначения). Таким образом мы указываем правила для соединений с любого ip на адреса, принадлежащие сети того или другого провайдера.
Карты маршрутов и обеспечение резервирования канала
Теперь мы подошли вплотную к понятию карты маршрутов (route-map). Я не буду приводить ссылки на документацию от cisco, а постараюсь объяснить вам все своими словами.
По сути карта маршрутов похожа по своему действию на списки доступа, за тем лишь исключением, что в карте маршрутов можно не только определить принадлежность к ней по какому-то параметру (например по ip-адресу), но и изменить какие-то параметры маршрутизации, например указать шлюз (nexthop), через который нужно маршрутизировать попавшие под данную карту маршрутов пакеты. Карта маршрутов поддерживает метки (match) по которым можно указать условия принадлежности каких-то пакетов в данной карте маршрутов, и инструкции set, при помощи которых можно изменить параметры маршрутизации. Так же для каждой карты маршрутов можно указать несколько правил, которые будут обрабатываться по возрастанию иx номера (sequence).
Как мы уже указали вначале, мы будем использовать для маршрутизации всего одну карту маршрутов с именем RouteSelect, но у нее будет несколько номеров.
Итак, начинаем создавать нашу карту маршрутов. Для начала добавим правила для маршрутизации пакетов, которые идут в сети провайдеров только через их шлюзы:
Настройка резервирования канала
Теперь, прежде чем продолжить настройку карт маршрутов, нам нужно настроить резервирование каналов. Делается это через использование технологии IP SLA и механизма Track.
Track - это флаг состояния, который может иметь два значения: up или down. Этот флаг будет устанавливаться на основе данных полученных от IP SLA.
Для обоих провайдеров директивы аналогичны, рассмотрим их значение:
Окончание настройки route-map. Распределение пользователей
Так же надо создать еще две карты маршрутов, но они по сути будут вести себя, как обычные списки доступа, так как не будут иметь директивы set:
После чего нам остается только включить NAT и настроить маршруты по умолчанию с использованием track:
Автор: Яковлев А.В
Полезные ссылки
Быстрое и недорогое обучение за рубежом английскому языку. Различные варианты обучения для всех уровней подготовки.
Есть универсальное решение для подключения нескольких провайдеров, ip sla + track. Решение легкое для понимания и простое в управлении. Но когда дело доходит до одновременного использования двух и более каналов связи, данная технология в чистом виде не подходит.
Хочу поделится своим опытом. На узлах с несколькими провайдерами я использую конфигурацию содержащую виртуальные роутеры – VRF. Эта конфигурация взята из моей практики и хорошо себя зарекомендовала.
Предположим у нас есть 2 провайдера с параметрами:
ISP1 1.1.1.1 шлюз 1.1.1.2
ISP2 2.2.2.1 шлюз 2.2.2.2
И локальная сеть:
LAN 192.168.1.1/24
Приступим к конфигурации. Для начала нужно создать эти самые виртуальные маршрутизаторы, а будет их 3. Два на провайдеров и один на локальную сеть.
Сразу же настроим правила экспорта маршрутов, что бы не возвращается в раздел ip vrf. Логика следующая – нельзя обменивается маршрутами между VRF провайдеров (на самом деле можно, но при таких вариантах настройка усложнится). На пальцах: VRF провайдеров могут получать и отправлять маршруты только в/от VRF локальной сети. VRF локальной сети может отправлять свои маршруты и получать маршруты от любых других VRF.
Вводим данные о сетях в наш маршрутизатор, не забываем сразу включить NAT и назначить интерфейсам нужные VRF. Один интерфейс не может принадлежать сразу нескольким VRF. Представьте себе, что вы решили сделать из одного маршрутизатора несколько, распилив его на части и в каждой части остались свои интерфейсы.
Все, теперь у нас есть 3 маленьких, но гордых независимых маршрутизатора. Перед тем как сделать главное – прописать шлюзы провайдеров, надо настроить ip sla тест. Делается это так же, как и в стандартном решении, но с указанием VFR’а из которого предполагается проводит ip sla тест.
Добавляем маршруты в наши виртуальные маршрутизаторы, которые отвечают за связь с провайдерами. Обратите внимание на значения метрики, на резервном канале метрика выше и далее вы поймете почему.
В принципе этого уже достаточно, для того что бы к маршрутизатору можно было подключится из вне по публичному адресу любого из провайдеров (если, конечно, настроен SSH или telnet доступ).
Далее приготовим NAT, все делаем практически так же, как мы привыкли настраивать в стандартном решении без VRF. Делаем access-list который запрещает транслировать локальные адреса в локальные адреса:
Делаем карты маршрутизации для каждого провайдера:
И включаем NAT overload (обратите внимание, что правило настраивается на виртуальный маршрутизатор vrf lan):
Наше элегантное решение практически готово, но нужен финальный штрих, это BGP процесс который будет заниматься перераспределением маршрутов между VRF учитывая правила импорта\экспорта которые мы настроили в каждом VRF.
Команда default-information originate позволяет передавать через bgp маршрут по умолчанию. В результате, в кандидаты на маршрут по умолчанию для vrf lan попадут два маршрута до шлюзов разных провайдеров, но с помощью bgp будет выбран тот, у которого метрика меньше. Соответственно если вдруг надо переключить NAT с одного провайдера на другой, достаточно будет поменять метрику в таблице маршрутизации одного из VRF.
Из недостатков, хочу отметить необходимость почти в любую команду вставлять дополнительный текст vrf <название>. Так просмотр таблицы маршрутизации виртуального роутера локальной сети вызывается командой:
Пинг из vrf первого провайдера:
Спасибо за внимание. Подготовлено на роутере Cisco 881 IOS version 15.5
Рано или поздно, но каждая компания сталкивается с проблемой выхода из строя канала связи с интернет. И сразу же после этого встает вопрос об организации резервного канала. Но какие настройки нужно сделать для автоматического переключения на него в случае аварии?
В этой статье описаны настройки для маршрутизаторов Cisco 881 и подобных моделей. Если у вас Cisco ASA, то настройки для них написаны в статье Dual WAN на Cisco ASA.
Один из самых простых и эффективных способов для маршрутизаторов Cisco – использование ip sla monitor. Устройство будет отслеживать доступность основного интернет провайдера и, как только связь пропадет (некий адрес не будет отвечать на icmp запросы в течение нескольких секунд), начнет пересылать трафик через резервный канал.
Рассмотрим настройки на примере стандартной модели маршрутизаторов для небольшого офиса Cisco 881.
- В интерфейс 3 уровня Fa 4 подключен основной оператор связи;
- В интерфейс Fa 0 (Vlan 1) подключена локальная сеть офиса;
- В интерфейс FastEthernet 3 (Vlan 3) подключен резервный провайдер.
Если у вас иная модель, то отличие будет только в названии интерфейсов, но не в сути настроек.
Задача: настроить отказоустойчивое подключение к Интернет (dual wan).
Шаг 1. Проверка маршрутов
Проверяем текущие маршруты на устройстве. Для удобства командой sh run | inc route
выводим строки текущей конфигурации, содержащие слово «route»
Если переводить с языка устройства на «человеческий», то получится следующее:
«Перенаправлять все пакеты, о которых я не знаю, в сторону интерфейса outside через шлюз 10.10.10.1»
Маршрутизатор «знает» только о тех сетях, которые подключены к нему напрямую (connected) или для которых имеются подобные строки маршрутов.
Шаг 2. Настройка для резервного провайдера
На межсетевом экране уже настроен интерфейс outside (Ethernet 1/Vlan 2), к которому подключен Основной провайдер. В текущей конфигурации (просмотреть командой sh run) будут присутствовать подобные строки:
Добавим настройки для Резервного канала, который подключен к Ethernet 3/Vlan 3
Для этого сначала необходимо создать Vlan для подключения резервного оператора, привязать его к одному из свободных портов и после этого задать ip адрес.
Проверить текущие настройки можно командой sh current, не выходя из режима настройки Vlan. Достаточно, чтобы Vlan с порядковым номером 3 был в перечне существующих.
Для привязки Vlan 3 к интерфейсу FastEthernet 3 необходимо выйти из режима настройки Vlan и далее зайти в обычный режим конфигурирования conf t. После этого привязать Vlan 3 к интерфейсу FastEthernet 3 и активировать его командой no shut.
А после создания задать ip адрес и активировать интерфейс командой no shut
Если все провода подключены и настройки корректны, то для маршрутизатора должен быть доступен шлюз Резервного провайдера.
Шаг 3. Настройка отслеживания доступности провайдера
Для того чтобы маршрутизатор Cisco 881 следил за доступностью Основного канала, необходимо настроить функцию ip sla monitor. С ней через равные временные промежутки будет посылаться ping (icmp запрос) на адрес провайдера 1 (основного). Получение ответного пакета (icmp ответ) будет означать доступность канала.
Что проверять?
В большинстве случаев адрес внешнего интерфейса и шлюза провайдера заранее известны. Поэтому будет достаточно проверять доступность адреса шлюза провайдера. Но здесь есть один подвох. Что произойдет, если шлюз будет все так же доступен, но неисправность будет где-то дальше на сети провайдера? То есть «интернет не работает», но шлюз доступен. Ответ – ничего. Маршрутизатор не сможет распознать неисправность и не переключится на резерв. Сюда же подходят случаи, когда провайдер предоставляет динамический адрес, например, по технологии pppoe.
Чтобы это обойти, часто выбирается какой-то стабильно работающий адрес в Интернете, который вполне может быть в любой точке мира. Далее на маршрутизаторе задается статический маршрут до выбранного адреса через интерфейс основного провайдера. И уже наличие шлюза по умолчанию в сторону основного провайдера ставится в зависимость от доступности выбранного адреса. Тогда, что бы ни случилось со связью, будь то неполадки с настройками маршрутизатора, сбои у оператора связи и другие причины, механизм переключения сработает автоматически. При этом минусом такого подхода будет то, что заветный адрес будет всегда недоступен вместе с основным провайдером. Для этих целей советую использовать адрес 1.1.1.1, который стабильно доступен, но крайне редко используется в повседневной работе пользователей или устройств.
Сложно написано, не так ли? Давайте упростим до алгоритма действий маршрутизатора:
- Маршрутизатор, знай, что хост 1.1.1.1 всегда находится за шлюзом основного провайдера 10.10.10.1
- Маршрутизатор, проверяй доступность хоста 1.1.1.1 один раз в 10 секунд
- Если хост 1.1.1.1 доступен, то шлюз по умолчанию – адрес провайдера 1
- Если хост 1.1.1.1 недоступен, то шлюз по умолчанию – адрес провайдера 2
Задаем статический маршрут через основного провайдера до адреса 1.1.1.1
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
Для справки:
threshold 10000 – Запросы будут посылаться 1 раз в 10 секунд.
Шаг 4. Проверка работы механизма отслеживания
Для проверки работы отслеживания ip sla используется команда sh ip sla statistics
Number of successes: 15 – показывает количество успешных icmp запросов
Number of failures: 0 – показывает количество неудачных запросов
Перед выполнением дальнейших шагов обязательно проверьте вывод этой команды несколько раз, чтобы убедиться, что счетчик успешных срабатываний (successes) растет со временем. Это означает, что основной канал работает стабильно и можно продолжать настройку без риска потерять связь с Интернет.
Шаг 5. Шлюз по умолчанию для Резервного провайдера.
Для Резервного провайдера требуется указать шлюз по умолчанию, куда маршрутизатор Cisco 881 будет отправлять все пакеты, но с одним отличием – этот маршрут не должен учитываться, когда доступен Основной провайдер. Для этого следует понизить приоритет этого маршрута, который здесь называется «административным расстоянием». Необходимо сделать его больше (дороже).
По умолчанию значение административного расстояния для статического маршрута – 1. Зададим для Резервного канала значение, близкое к максимальному – 250
После добавления в конфигурации маршрутизатора Cisco 881 должно быть 2 маршрута по умолчанию
Шаг 6. Активация переключения
Финальный шаг – привязать основной маршрут к функции слежения за доступностью канала (ip sla).
Добавляем новую строку для шлюза по умолчанию с пометкой track 1 и удаляем старую
После этого в итоговой конфигурации останутся две строчки для шлюзов по умолчанию
Важно!
Если существуют строки маршрутов для каких-то сетей, кроме шлюза по умолчанию, то следует учесть их наличие при настройке, продумав логику переключения аналогично шлюзу по умолчанию.
Шаг 7. Корректировка NAT
Самое главное, чем отличается настройка dual wan на маршрутизаторах Cisco 881 и Cisco ASA – это необходимость перенастройки трансляции адресов NAT (преобразование внутренних «серых» адресов в «белый» адрес внешнего интерфейса). Если для Cisco ASA достаточно продублировать настройки NAT для резервного провайдера, то для маршрутизаторов Cisco необходимо перенастраивать логику команд.
«Обычные» настройки NAT для доступа в сеть Интернет для пользователей сводится к указанию диапазона внутренних адресов и добавления правила «транслируй «эти адреса» в адрес внешнего интерфейса». Фактически описывается трафик ДО попадания на внутренний интерфейс маршрутизатора.
ip access-list standard ACL_NAT
permit 192.168.10.0 0.0.0.255
Interface Vlan 1
ip nat inside
Interface Fa 4
ip nat outside
ip nat inside source list ACL_NAT interface fa4
В случае с реализацией отказоустойчивого переключения на резервный канал с помощью ip sla необходимо использовать route-map. Это расширенная функция управления потоком трафика, в настройках которой указывается условие (какой трафик) и действие (что с ним делать).
В нашем случае для каждого из провайдеров создается route-map только с «условиями», в качестве которых выступают:
- заранее созданный список доступа ACL_NAT, в котором отражен трафик для всех внутренних хостов)
- Выходной интерфейс (свой для каждого из провайдеров
route-map ROUTE_ISP_MAIN permit 10
match ip address ACL_NAT
match interface FastEthernet 4
route-map ROUTE_ISP_BACKUP permit 10
match ip address ACL_NAT
match interface Vlan 3
Далее необходимо добавить правила для NAT, в которых сослаться на route-map
ip nat inside source route-map ROUTE_ISP_MAIN interface FastEthernet 4 overload
ip nat inside source route-map ROUTE_ISP_BACKUP interface Vlan 3 overload
Важно!
не забудьте проверить, что на каждом из трех интерфейсов, через которые проходит трафик, есть строки о принадлежности к NAT
Interface Vlan 1
ip nat inside
Interface Fa 4
ip nat outside
interface Vlan 3
ip nat outside
ISP Failover-Failback using IP SLA ICMP Echo Operations, p.1
Подключение к двум провайдерам с помощью рутера Cisco и автопереключение каналов методом Cisco IP SLA ICMP Echo Operations
Часть 1: обеспечение автопереключения каналов.
Предположим, у вас есть рутер Cisco и вам надо подключиться сразу к двум провайдерам Интернета, ибо для вас наличие подключения к Интернет критично. Положим, вы можете или уже настроили свой рутер для подключения к одному провайдеру, и он у вас выполняет функции NAT\PAT, firewall и т.д. Т.е. как всё это сделать вы знаете. Но не знаете, как подключить второго провайдера и настроить рутер таким образом, чтобы переключение на резервный канал при “отсутствии Интернета” через основной канал и обратное переключении при нормализации основного канала осуществлялось автоматически. Отлично, данная статья поможет вам в этом.
Но сначала прочтите пару примечаний[1][2].
Вернемся к делу. Для начала давайте разберемся, что мы будем понимать под “пропаданием Интернета” и как его распознавать. Что касается распознавания, то, наверняка, большинство логически мыслящих обычных людей сразу подумают о пинге чего-то. Что ж, отличный вариант, причем у Cisco он представлен и называется “IP SLA ICMP Echo Operations”. Почитать в оригинале можно здесь (ссылка для IOS версии 12.4T, ибо я её и использую. Если у вас не эта, просто погуглите).
Корневые DNS сервера обеспечивают работу всего Интернета, так что они сверхнадежны. К тому же, они идентифицируются (и резервируются) по ip адресам, а не DNS именам с кучей разных адресов, отсюда не надо думать о предварительном разрешении имени в адрес.
Остался последний вопрос. При каких условиях переключаться на второго провайдера и когда обратно? Тут уже смотрите сами. Я считаю, что переключаться на резерв надо относительно быстро, а обратно, наоборот, с большей задержкой, убедившись в стабильности канала. Критерии тут, очевидно, стоимость и скорость\качество соединения через резервного провайдера. Но если его условия примерно эквивалентны условиям основного, то лучше перейти на резерв относительно быстро, а назад – относительно медленно. Для конкретики остановимся на таких числах:
пусть переход на резервный канал производится через 6 секунд после начала сбоя (в частности, при потере 3-х пингов подряд, идущих каждые 2 секунды),
а обратный переход – через 1 минуту восстановления стабильности основного канала (или успехе 30-ти пингов подряд).
Тут важно не перемудрить, иначе канал будет скакать туда-сюда, или, наоборот, никогда не переключиться на резерв (или никогда не переключиться обратно).
Итак, теперь всё ясно. Сформулируем задачу сухим языком и дадим решение.
Условия задачи.
Пусть ISP1 и ISP2 – наши провайдеры, причем ISP1 – основной провайдер.
GW1 и GW2 – ip адреса соответствующих шлюзов провайдеров.
DNS1 и DNS2 – ip адреса DNS серверов соответственно ISP1 и ISP2.
RDNS – ip адрес любого корневого DNS сервера (список можете посмотреть, например, здесь. Пропингуйте и выберите сервер, который пингуется для вас стабильно и с минимальными задержками).
Цель.
Обеспечить подключение к Интернет через обоих провайдеров, но так, чтобы основным был ISP1 и при недоступности соединения с Интернет через ISP1, происходило переключение на ISP2. Причем переключение на резерв должно происходить при 6-ти секундной недоступности\нестабильности основного канала, а обратно – при восстановлении и стабильности основного канала в течении 1 минуты.
1. Во-первых, подключаем и настраиваем второго провайдера точно так же, как сделали с первым. Настраиваем firewall и т.п. (кроме NAT, с ним разберемся позже)
2. Во-вторых, пишем для него маршрут по умолчанию, но с заданным вручную Administrative distance[3].
3. Самое главное, конфигурируем IP SLA в варианте ICMP Echo Operations.
А вот и конфиг с IP-SLA:
[1] Примечание 1. По ходу повествования я часто буду писать “переключение каналов”, “отключение линии” и т.п.. На самом деле, будет производиться не переключение каналов или даже отключение соответствующего интерфейса рутера (что тоже возможно сделать), а просто удаление и возврат маршрута по умолчанию для подключения через основного провайдера.
Возможны и другие неточности в терминологии, но тут уже не моя вина, ибо я вообще не специалист по Cisco, а вина Сергея Федорова (он же Sergey Fedorov, он же Fedia), жестокого инженера-мафиози, который отбирает у доверчивых русскоговорящих туристов документы и заставляет писать статьи про Cisco. При этом кормит он нас вкусной, но фальшивой красной икрой без хлеба и липовым, во всех отношениях, медом. Прошу передать родным, что я жив и даже поправился, но страдаю сильной изжогой.
[2] Примечание 2. Статья будет довольно подробной и покажется избыточной по наполнению для нормальных специалистов (скажем, уровня CCNP или даже CCNA), прошу меня простить. Виноватого указал выше.
[3] Примечание 3. Что такое Administrative distance очень хорошо и коротко описано здесь, если просто, считайте, что Admin distance определяет нечто вроде приоритета маршрута при прочих равных (sic!), и, чем меньше его значение, тем выше приоритет маршрута.
По умолчанию, каждый “источник” маршрута имеет предопределенное значение Admin distance для всех своих маршрутов. Под источником я понимаю: метод или протокол, порождающий маршрут: статический или полученный посредством одного из протоколов динамической маршрутизации. Так, статический маршрут через интерфейс имеет Admin Distance = 0, обычный статический маршрут через Next Hop – 1 и т.д. Подробности смотрите по ссылке.
Т.к. в нашем примере маршрут по умолчанию мы задаем статически через Next Hop, то согласно Cisco его Administrative distance равен 1, поэтому Administrative distance для маршрута через резервного провайдера надо задать больше единицы. Я выбрал “4” – больше 1, но меньше величины, предусмотренной для протоколов маршрутизации. Мне просто так показалось правильным (захотелось, короче).
[4] Примечание 4. Немного информации по параметрам ip sla. (Внимание! Информация верна только для использованного нами IP SLA ICMP Echo Operations, в IP SLA других типов, а их куча, параметры могут иметь другой смысл):
timeout – это время ожидания ответа на пинг, в msec. Я выбрал 1000, ибо большее значение, скорее всего, означает нестабильность канала. Однако, это может быть также вызвано перегруженностью канала. Рекомендую установить в пределах 1000-2000 msec. Если же вы уверены в достаточности ПС вашего канала, можете использовать значения поменьше.
frequency – это периодичность пингов, в sec
threshold – предельное время, после которого можно зафиксировать событие несоответствия канала желаемому \ декларируемому качеству (скажем, на лог-сервере с помощью SNMP и пр. дополнительных инструментов). В нашем примере, данный параметр не играет роли, не берите в голову. Задается в msec.
Читайте также: