По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сетевая инфраструктура (роутеры, коммутаторы, МСЭ, АТС и так далее) являются очень важными ресурсами организации, и поэтому очень важно корректно настроить доступ к данным устройствам – для достижения нужного уровня защиты.
Множество корпораций фокусируются на защите своих серверов, приложений, баз данных и прочих компонентов сети, но они могут совершенно забыть о том, что часть установленных у них устройств содержат, к примеру, дефолтные логин и пароль.
К примеру, скомпрометированный маршрутизатор может доставить гигантское количество проблем – злоумышленники могут получить доступ к информации, трафик может улетать на другое направление и так далее. Так что корректная настройка устройств с точки зрения сетевой безопасности является крайне важным моментом при обеспечении защиты информации вашей организации.
К примеру Cisco разделяет любое сетевое устройство на 3 функциональных плоскости, а именно:
Плоскость менеджмента – это все о том, как непосредственно управлять железкой. То есть данная плоскость используется для доступа, настройки и мониторинга устройства. В нашей статье мы непосредственно расскажем, как защитить данную плоскость;
Плоскость управления – данная плоскость содержит в себе сигнальные протоколы и процессы, которые отвечают за связность между устройствами – например такие известные вам протоколы как OSPF, EIGRP и так далее;
Плоскость данных – плоскость, ответственная за перемещение информации по сети от источника до ее назначения. В данной плоскости и происходит, как правило, обмен пакетами между устройствами;
Из этих трех плоскостей наиболее защитить первую и вторую плоскости, однако в нашей статье мы сконцентрируемся на плоскости менеджмента и обсудим 10 важных шагов по улучшению защищенности сетевого устройства Cisco с IOS.
Десять пунктов ниже не являются избыточными, но они включают в себя наиболее важные команды и настройки, которые позволят «закрыть» устройство от нежелательного доступа и повысить степень защищенности. Данные пункты применимы как к маршрутизаторам, так и к коммутаторам.
Создание секретного пароля
В целях предоставления доступа к IOS устройству только людям, имеющим право (например, сисадмину/эникею/инженеру) всегда нужно создавать сложный «секретный» пароль (enable secret). Мы советуем придумать/сгенерировать пароль минимум 12 знаков, содержащий цифры, буквы и специальные символы. Проверьте, что вы вводите именно enable secret - тогда в конфиге пароль будет отображаться в зашифрованном виде.
Router# config terminal
Router(config)# enable secret сложныйпароль
Зашифруйте пароли на устройстве
Все пароли, настроенные на устройстве (за исключением «секретного»), не шифруются от слова совсем и легко видны в конфиге. Чтобы зашифровать все пароли в конфиге, необходимо использовать глобальную команду service password encryption
Router# config terminal
Router(config)# service password-encryption
Используйте внешний сервер авторизации для аутентификации пользователей
Вместо использования локальных учетных записей на каждом устройстве для доступа администратора, мы рекомендуем использование внешнего AAA сервера (TACACS+ или RADIUS) для обеспечения Аутентификации, Авторизации и Учета (вольный перевод Authentication, Authorization, Accounting).
С централизованным ААА сервером гораздо проще управлять учетными записями, реализовывать политики безопасности, мониторить использование аккаунтов и многое другое.
Ниже на схеме вы можете видеть как настроить TACACS+ и RADIUS серверы с использованием enable secret пароля в случае отказа этих серверов.
TACACS+
Router# config terminal
Router(config)# enable secret K6dn!#scfw35 //создаем “секретный ” пароль
Router(config)# aaa new-model //включаем ААА службу
Router(config)# aaa authentication login default group tacacs+ enable //Используем TACACS сервер и обычный пароль на случай отказа
Router(config)# tacacs-server host 192.168.1.10 //указываем внутренний ААА сервер
Router(config)# tacacs-server key ‘secret-key’ //указываем секретный ключ для ААА сервера
Router(config)# line vty 0 4
Router(config-line)# login authentication default //применяем ААА аутентификацию для линий удаленного доступа (telnet, ssh)
Router(config-line)# exit
Router(config)# line con 0 //применяем ААА аутентификацию для консольного порта
Router(config-line)# login authentication default
RADIUS
Router# config terminal
Router(config)# enable secret K6dn!#scfw35 //создаем “секретный ” пароль
Router(config)# aaa new-model //включаем ААА службу
Router(config)# aaa authentication login default group radius enable //Используем RADIUS сервер и обычный пароль на случай отказа
Router(config)# radius-server host 192.168.1.10 //указываем внутренний ААА сервер
Router(config)# radius-server key ‘secret-key’ //указываем секретный ключ для ААА сервера
Router(config)# line vty 0 4
Router(config-line)# login authentication default //применяем ААА аутентификацию для линий удаленного доступа (telnet, ssh)
Router(config-line)# exit
Router(config)# line con 0 //применяем ААА аутентификацию для консольного порта
Router(config-line)# login authentication default
Создайте отдельные аккаунты для пользователей
Если у вас отсутствует возможность использовать внешний ААА сервер, по инструкции, описанной в предыдущем шаге, то как минимум, вам необходимо создать несколько отдельных локальных аккаунтов для всех, у кого должен быть доступ к устройству. Приведем пример создания трех локальных аккаунтов для троих системных администраторов.
Кроме того, в версии IOS начиная с 12.2(8)T и позднее, есть возможность настроить повышенную надежность паролей (Enhanced Password Security) для локальных учетных записей – это зашифрует пароли с помощью MD5 хэша.
Ниже пример настройки трех учетных записей:
Router# config terminal
Router(config)# username efstafiy-admin secret Lms!a2eZf*%_rete
Router(config)# username evlampiy-admin secret d4N3%sffeger
Router(config)# username vova-admin secret 54sxSFT*&_(!zsd
Настройте лимит возможных попыток подключения
Для того, чтобы избежать взламывания вашей учетной записи на маршрутизаторе с помощью брутфорса, вы можете настроить ограничение количества попыток подключения, когда после определенного предела система заблокирует пользователя. Это работает для локальных учетных записей.
Router# config terminal
Router(config)# username john-admin secret Lms!a2eZSf*%
Router(config)# aaa new-model
Router(config)# aaa local authentication attempts max-fail 5 //max 5 failed login attempts
Router(config)# aaa authentication login default local
Открытие доступа на управление устройством только для определенных IP – адресов
Данный пункт является одним из наиболее важных для сетевых устройств Cisco – необходимо оставить доступ к Telnel или SSH только для определенных сетевых адресов (например, рабочей станции системного администратора). В нашем примере сисадмин находится в пуле 192.168.1.0/28
Router# config terminal
Router(config)# access-list 10 permit 192.168.1.0 0.0.0.15
Router(config)# line vty 0 4
Router(config)# access-class 10 in //применить ограничения на все VTY линии (SSH/Telnet)
Включить логирование
Логирование является очень полезной функцией для отслеживания, аудита и контроля инцидентов. Вы можете включить логирование во внутренний буфер устройства или на внешний лог-сервер. Вторая опция является более предпочтительной, так как вы можете хранить там больше информации и проще производить различного рода аналитику.
Всего существует 8 уровней логирования (от 0 до 7), каждый из которых делает лог более насыщенным деталями. Лучше всего избегать 7 уровень логирования (дебаг), т.к это может легко потратить все ресурсы вашего устройства.
Ниже пример, как включить логирование и на внешний сервер, и на сам девайс (можно использовать два варианта одновременно).
Router# config terminal
Router(config)# logging trap 6 //Включить 6 уровень логирования для логов, отправляемых на внешний сервер
Router(config)# logging buffered 5 //Включить 5 уровень логирования для логов, хранимых на самом девайсе
Router(config)# service timestamps log datetime msec show-timezone //Включить таймстампы с милисекундной точностью
Router(config)# logging host 192.168.1.2 //Отправлять логи на внешний сервер
Router(config)# logging source-interface ethernet 1/0 //Использовать интерфейс Eth1/0 для отправки логов
Включение NTP (Network Time Protocol)
Данный шаг необходим для корректной работы логирования – т.к вам необходимо синхронизированное и точное системное время на всех сетевых устройствах, для правильного понимания ситуации при траблшутинге. Вы можете использовать как публичный, так и свой собственный NTP cервер.
Router# config terminal
Router(config)# ntp server 3.3.3.3
Router(config)# ntp server 4.4.4.4
Использование безопасных протоколов управления
По умолчанию, протоколом, с помощью которого можно управлять устройством является Telnet. Однако весь трафик передается в незашифрованном виде – поэтому предпочтительно использовать SSH.
Важно – для использования SSH необходимо настроить хостнейм и доменное имя, а также сгенерировать SSH ключи. Также следует разрешить только протокол SSH на VTY линиях
Защитить SNMP доступ
Про SNMP мы писали в одной из наших статей – это протокол для управления сетью, который, однако, также может служить «дырой» для доступа в вашу сеть. Для защиты данного направления, вам необходимо установить сложную Community String (что-то вроде пароля для SNMP) и разрешить доступ только с определенных рабочих станций.
Давайте настроим две Community String – одну с правами на чтение, и другую с правами на чтение и изменение. Также добавим ACL с нужными сетевыми адресами.
Router# config terminal
Router(config)# access-list 11 permit 192.168.1.0 0.0.0.15
Router(config)# access-list 12 permit 192.168.1.12
Router(config)# snmp-server community Mer!0nET RO 11 //создание community string с правами на чтение и использование ACL 11 для SNMP доступа
Router(config)# snmp-server community Mer!0NeTRules RW 12 //создание community string с правами на чтение/запись и использование ACL 12 для SNMP доступа
Команды выше позволят сети сисадмина 192.168.1.0/28 иметь доступ на чтение и хосту 192.168.1.12 иметь полный доступ на SNMP чтение / запись к устройствам.
YAML (YAML – Ain’t Markup Language, что можно перевести как "YAML – это не язык разметки"") считается языком сериализации по типу XML и JSON. Он представляет собой расширенную версию JSON, которая используется, в основном, для файлов конфигурации. Вы можете сохранить YAML-файл с расширением .yaml или .yml. Это удобочитаемый файловый формат, состоящий из пар «ключ-значение» и делающий акцент на отступы и отбивку строк. YAML активно используется в файлах конфигурации многих хорошо известных инструментов/технологий, по типу docker-compose, Kubernetes, Ansible и т.д.
Ниже приведено сравнение YAML с XML и JSON.
Теперь давайте обсудим синтаксис, типы данных и особенности YAML-файлов.
Пары «ключ-значение»
Пара «ключ-значение» – это базовая составляющая YAML. Каждый элемент в YAML-документе является членом как минимум одного словаря. Ключами чаще всего являются строки, а значением могут быть данные любого типа: число, логическое значение, строка, пустое значение, массив и объект.
name: John
age: 25
city: LA
Числа
Числа – это одни из скаляров, которые могут использоваться в качестве значения YAML-файлов. Числа бывают десятичными, с плавающей запятой, экспоненциальными, восьмеричными и шестнадцатеричными. Если добавлять их без одинарных или двойных кавычек, то они обрабатываются как строки.
decimal : 10
float : 2.5
exponential : 5.0e+12
infinity : .inf
octal : 0o12
hexadecimal : 0xF
Примечание: Будьте осторожны при представлении некоторых стандартных типов чисел (время, восьмеричные и шестнадцатеричные коды и т.д.). Они могут быть некорректно интерпретированы. Вот несколько примеров.
time : 6:00
hexval: 0x12
octval: 0o25
В этом примере время преобразуется в минуты, поэтому 6:00 интерпретируется как 360. 0x12 обрабатывается как шестнадцатеричный код, поэтому оно переводится в десятеричное значение 18, а 0o25 интерпретируется в десятеричное значение 21. Так что если вы не собираетесь использовать их в таком виде, то добавляйте эти значения в кавычках.
Примечание: Начиная со спецификации YAML 1.2, 0o представляет восьмеричные значения. В более ранних версиях для этих целей использовался 0.
Логические значения
Логические значения похожи на другие языки программирования/представления с двумя состояниями: true или false. Логическими значениями в YAML-файлах считаются не только стандартные true/false, но также yes/no и on/off (исключение: если они добавлены в кавычках).
Примечание: Следите за тем, как вы используете значения yes/no и on/off. Если добавлять их не в одинарных кавычках, то они будут интерпретироваться как логические значения true/false.
Комментарии
Вы можете комментировать содержимое YAML-файла с помощью символа #. Пример ниже:
# This a comment on the first.
# And this a commented second line.
Строки
В YAML-файле вы можете прописывать строки без кавычек. Либо добавлять их в одинарные или двойные кавычки. Можно даже пользоваться всеми тремя способами.
Если в строке содержатся специальные символы, которые нужно экранировать с помощью , то добавлять такую строку нужно в двойных кавычках. Пример:
signature: "John Williams
Sales Executive
XYZ Company LA."
Но при использовании любого из специальных символов ниже:
:, {, }, [, ], ,, &, *, #, ?, |, -, , =, !, %, @, `
не нужно ничего экранировать. Воспользуйтесь одинарными кавычками – с ними строка будет интерпретироваться как нужно.
Одиночная строка
Если вы хотите разбить одну строку на несколько строчек, но синтаксический анализатор должен будет интерпретировать их как одиночную строку, то сделайте следующее:
message: >
this is a normal string
which spans more than multiple lines
but needs to be treated
as a single line.
Начните код с символа > , а затем впишите содержимое строки в виде блока с отступами. В конце проанализированного содержимого добавляется
. Если вам не нужен символ новой строки, то воспользуйтесь символом >-.
Многострочное значение
При добавлении строки, которая разделяется на несколько строк и анализируется так же, как написана, воспользуйтесь схемой ниже.
message: |
this is a multi-line string
which spans across multiple lines
and needs to be treated
as a multi-line string.
| добавляет в конце проанализированного содержимого символ перехода на новую строку. Если вы не хотите видеть в конце проанализированного содержимого символ
, то лучше воспользуйтесь |-.
Нулевые значения
Вы можете представить нулевое значение с помощью ~ или null. Такие значения добавляются без кавычек.
foo: ~
bar: null
Массивы
В YAML значения можно представить в форме массивов/списков. Пример массива данных:
teams:
- name: Australia
rank: 3
- name: New Zealand
rank: 4
- name: England
rank: 1
- name: India
rank: 2
В примере выше представлен массив объектов с названием и рангом команды. Обязательно проверьте, что отбивка строк и отступы заданы единообразно. В противном случае, файл будет некорректным.
Каждый элемент массива обозначается через дефис -. Все элементы должны находиться на одном уровне с одинаковыми отступами.
Если вместо объектов в массиве используются примитивные элементы, то их можно представить следующим образом:
teams: [ Australia, New Zealand, England, India ]
Объекты
Объекты в YAML представляются так:
student:
name: John
age: 22
city: NY
college: NYU
gpa: 3.5
Все атрибуты внутри объекта должны находиться на одном уровне и с одинаковым отступом. Именно это условие указывает на принадлежность к одному объекту и гарантирует корректность YAML-документа.
Заключение
В данной статье вы познакомились с базовыми концепциями при работе с YAML-файлами. Разобравшись в них, вы поймете, как правильно прописывать файлы для своих собственных инструментов и технологий.
Из предыдущих статей (тут и тут) мы узнали, что очень немногие механизмы, учитывают изменения в топологии. Большинство этих решений ориентированы на вычисления loop-free пути через очевидно стабильную сеть. Но что происходит при изменении топологии? Как сетевые устройства создают таблицы, необходимые для пересылки пакетов по loop-free путям в сети?
В этой серии статей мы рассмотрим очередную подзадачу этой всеобъемлющей проблемы и ответим на вопрос: Как плоскости управления обнаруживают изменения в сети и реагируют на них?
На этот вопрос мы ответим, рассмотрев две составляющие процесса конвергенции в плоскости управления. Процесс конвергенции в сети может быть описан в четыре этапа. Рисунок 1 используется для справки при описании этих четырех стадий. Как только связь [C,E] выходит из строя, должны произойти четыре этапа: обнаружение, распространение, вычисление и установка.
Обнаружение изменения: будь то включение нового устройства или линии связи, или удаление устройства или линии связи, независимо от причины, изменение должно быть обнаружено любыми подключенными устройствами. На рисунке 1 устройства C и E должны обнаруживать отказ канала [C, E]; когда линия восстанавливается, они также должны обнаружить включение этой (очевидно новой) линии связи в топологию.
Распространение информации об изменении: каждое устройство, участвующее в плоскости управления, должно каким-то образом узнавать об изменении топологии. На рисунке 1 устройства A, B и D должны каким-то образом уведомляться о сбое канала [C, E]; когда линия будет восстановлена, они должны быть снова уведомлены о включении этой (очевидно новой) линии связи в топологию.
Вычисление нового пути к пункту назначения без петель: на рисунке 1 B и C должны вычислить некоторый альтернативный путь, чтобы достичь пунктов назначения за пределы E (или, возможно, непосредственно самого E).
Установка новой информации о пересылке в соответствующие локальные таблицы: На рисунке 1 B и C должны установить вновь вычисленные loop-free пути к пунктам назначения за пределами E в свои локальные таблицы пересылки, чтобы трафик мог коммутироваться по новому пути.
Далее мы сосредоточимся на первых двух из четырех шагов, описанных в предыдущем списке, размышляя в начале об обнаружении изменений топологии. Будут рассмотрены некоторые примеры протоколов, специализирующихся на обнаружении изменений топологии. Распределение топологии и информации о достижимости будет рассмотрена в конце этой серии статей. Поскольку эта проблема, по сути, является проблемой распределенной базы данных, она будет решаться с этой точки зрения.
Обнаружение изменений топологии
Первым шагом в реакции на изменение топологии сети является обнаружение изменения. Вернемся к рисунку 1. Каким образом два устройства, подключенные к каналу, C и E, обнаруживают сбой канала? Решение этой проблемы не так просто, как может показаться на первый взгляд, по двум причинам: информационная перегрузка и ложные срабатывания.
Информационная перегрузка возникает, когда плоскость управления получает так много информации, что просто не может распространять информацию об изменениях топологии и/или вычислять и устанавливать альтернативные пути в соответствующие таблицы на каждом устройстве достаточно быстро, чтобы поддерживать согласованное состояние сети. В случае быстрых, постоянно происходящих изменений, таких как отключение связи и подключение каждые несколько миллисекунд, плоскость управления может быть перегружена информацией, в результате чего сама плоскость управления потребляет достаточно сетевых ресурсов, чтобы вызвать сбой сети. Также возможно, что серия отказов вызовет петлю положительной обратной связи, и в этом случае плоскость управления “сворачивается” сама по себе, либо реагируя очень медленно, либо вообще отказывая. Решение проблемы информационной перегрузки состоит в том, чтобы скрыть истинное состояние топологии от плоскости управления до тех пор, пока скорость изменения не окажется в пределах, которые может поддерживать плоскость управления.
Ложные срабатывания - это проблема второго типа. Если канал отбрасывает один пакет из каждых 100, и каждый раз отбрасывается единственный пакет, который оказывается пакетом плоскости управления, используемым для отслеживания состояния канала, будет казаться, что канал выходит из строя и довольно часто возобновляет работу - даже если другой трафик перенаправляется по каналу без проблем.
Существует два широких класса решений проблемы обнаружения событий:
Реализации могут периодически отправлять пакеты для определения состояния канала, устройства или системы. Это опрос (Polling).
Реализации могут вызвать реакцию на изменение состояния канала или устройства в некотором физическом или логическом состоянии внутри системы. Это обусловлено событиями.
Как всегда, есть разные компромиссы с этими двумя решениями и подкатегории каждого из них.
Опрос (Polling) для обнаружения сбоев.
Опрос может выполняться удаленно или вне диапазона, или локально, или в группе. Рисунок 2 демонстрирует это.
На рисунке 2 A и B периодически отправляют приветствие или какой-либо другой пакет опроса по тому же каналу, через который они подключены, и по тому же каналу, по которому они пересылают трафик. Это внутриполосный опрос, который имеет преимущество отслеживания состояния канала, по которому пересылается трафик, передается информация о доступности и т. д. С другой стороны, D запрашивает у A и B некоторую информацию о состоянии канала [A, B] из другого места в сети. Например, D может периодически проверять состояние двух интерфейсов на канале [A, B] или, возможно, периодически отправлять пакет по пути [C, A, B, C] и т. д. Преимущество заключается в том, что информация о состоянии большого количества каналов может быть централизована, что упрощает управление сетью и устранение неполадок. Оба типа опроса часто используются в реальных сетевых развертываниях.
Для работы механизмов опроса часто используются два отдельных таймера:
Таймер для определения частоты передачи опроса. Он часто называется интервалом опроса в случае внеполосного опроса и часто называется таймером приветствия в случае внутриполосного опроса.
Таймер, чтобы определить, как долго ждать, прежде чем объявить связь или устройство отключенным, или включить сигнал тревоги. Это часто называют мертвым интервалом или мертвым таймером в случае внутриполосного опроса.
Цели внутриполосного и внеполосного опроса часто различаются. Внеполосный опрос для обнаружения изменений в состоянии сети часто (но не всегда - особенно в случае централизованной плоскости управления) используется для мониторинга состояния сети и позволяет централизованно реагировать на изменения в состоянии. Внутриполосный опрос наиболее часто используется (как и следовало ожидать) для локального обнаружения изменений состояния, чтобы управлять реакцией распределенных плоскостей управления.
Обнаружение сбоев на основе событий
Обнаружение сбоев на основе событий основывается на некотором локальном, измеримом событии для определения состояния конкретного канала или устройства. Рисунок 3 демонстрирует это.
На рисунке 3, который показывает одну из возможных реализаций элементов архитектуры между физическим интерфейсом и протоколом маршрутизации, есть четыре шага:
Связь между двумя микросхемами физического интерфейса (phy), расположенными на обоих концах связи, не работает. Микросхемы физического интерфейса обычно являются оптическими для электрических передач обслуживания. Большинство микросхем физического интерфейса также выполняют некоторый уровень декодирования входящей информации, преобразуя отдельные биты в сети в пакеты (десериализация) и пакеты в биты (сериализация). Информация кодируется физическим интерфейсом на носителе, который предоставляется двумя физическими микросхемами, подключенными к физическому носителю. Если канал не работает или один из двух интерфейсов отключен по какой-либо причине, микросхема физического интерфейса на другом конце канала увидит падение несущей почти в реальном времени - обычно в зависимости от скорости света и длины физического носителя. Это состояние называется потерей носителя.
Микросхема физического интерфейса при обнаружении потери несущей отправляет уведомление в таблицу маршрутизации (RIB) на локальном устройстве. Это уведомление обычно запускается как прерывание, которое затем транслируется в некоторую форму вызова интерфейса прикладного программирования (API) в код RIB, что приводит к тому, что маршруты, доступные через интерфейс, и любая информация о следующем переходе через интерфейс помечаются как устаревшие или удаляются из таблицы маршрутизации. Этот сигнал может или не может проходить через базу пересылаемой информации (FIB) по пути, в зависимости от реализации.
RIB будет уведомлять протокол маршрутизации о маршрутах, которые он только что удалил из локальной таблицы, на основе события отключения интерфейса.
Протокол маршрутизации затем может удалить любых соседей, доступных через указанные интерфейсы (или, скорее, через подключенные маршруты).
На рисунке 3 нет места, в котором бы присутствовал периодический процесс, проверяющий состояние чего-либо, а также не было бы пакетов, перемещающихся по сети. Весь процесс основан на том, что микросхема физического интерфейса теряет носитель на подключенной среде, следовательно, этот процесс управляется событиями.
Часто бывает, что состояние, управляемое событиями, и статус опроса совмещаются. Например, на рисунке 3, если бы станция управления периодически опрашивала статус интерфейса в локальном RIB, процесс от набора микросхем физического интерфейса к RIB был бы управляемым событием, а процесс от RIB на станцию управления будет направлен опросом.
Сравнение обнаружения на основе событий и на основе опроса
Таблица 1 отображает преимущества и недостатки каждого механизма обнаружения событий.
Внеполосный опросВнутриполосный опросУправляемый событиямиРаспределение статусовСтатус управляется централизованной системой; централизованная система имеет более полное представление об общем состоянии сетиСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСвязь состояния пересылки со связью или состоянием устройстваСообщение о состоянии связи и / или устройства может быть ложным; не проверяет возможность пересылки напрямуюСостояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Состояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Скорость обнаруженияПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиНекоторый таймер перед сообщением о сбоях может быть желательным, чтобы уменьшить сообщение о ложных срабатываниях, но этот таймер может быть очень коротким и подкрепляться двойной проверкой состояния самой системы; как правило, гораздо быстрее при сообщении об изменениях сетиМасштабированиеДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахНебольшие объемы текущего локального состояния; имеет тенденцию масштабироваться лучше, чем механизмы опроса
Хотя может показаться, что обнаружение, управляемое событиями, всегда должно быть предпочтительным, есть некоторые конкретные ситуации, когда опрос может решить проблемы, которые не могут быть решены механизмами, управляемыми событиями. Например, одно из главных преимуществ систем, основанных на опросе, особенно при внутриполосном развертывании, заключается в том, чтобы «видеть» состояние невидимых блоков. Например, на рисунке 4 два маршрутизатора соединены через третье устройство, обозначенное на рисунке как ретранслятор.
На рисунке 4 устройство B представляет собой простой физический повторитель. Все, что он получает по каналу [A, B], он повторно передает, как и получил, по каналу [B, C]. На этом устройстве нет какой-либо плоскости управления (по крайней мере, о том, что известно A и C). Ни A, ни C не могут обнаружить это устройство, поскольку оно не изменяет сигнал каким-либо образом, который мог бы измерить A или C.
Что произойдет, если канал [A, B] выйдет из строя, если A и B используют управляемый событиями механизм для определения состояния канала? A потеряет несущую, конечно, потому что физический интерфейс в B больше не будет доступен. Однако C будет продолжать принимать несущую и, следовательно, вообще не обнаружит сбой соединения. Если A и C могут каким-то образом общаться с B, эту ситуацию можно разрешить. Например, если B отслеживает все запросы протокола разрешения адресов (ARP), которые он получает, он может, когда канал [A, B] разрывается, каким-то образом отправить «обратный ARP», уведомляющий B о том, что A больше недоступен. Другое решение, доступное в этой ситуации, - это своего рода опрос между A и C, который проверяет доступность по всему каналу, включая состояние B (даже если A и C не знают, что B существует).
С точки зрения сложности, управляемое событиями обнаружение увеличивает поверхности взаимодействия между системами в сети, в то время как опрос имеет тенденцию сохранять состояние внутри системы. На рисунке 3 должен быть какой-то интерфейс между чипсетом физического интерфейса, RIB и реализацией протокола маршрутизации. Каждый из этих интерфейсов представляет собой место, где информация, которая может быть лучше скрыта через абстракцию, передается между системами, и интерфейс, который должен поддерживаться и управляться. Опрос, с другой стороны, часто может проводиться в рамках одной системы, полностью игнорируя существующие механизмы и технологии.
Пример: обнаружение двунаправленной переадресации
В этом подразделе будет изучен пример протокола, разработанного специально для определения состояния канала в сети. Ни один из этих протоколов не является частью более крупной системы (например, протокола маршрутизации), а скорее взаимодействует с другими протоколами через программные интерфейсы и индикаторы состояния.
Обнаружение двунаправленной переадресации (Bidirectional Forwarding Detection - BFD) основано на одном наблюдении: на типичном сетевом устройстве работает множество плоскостей управления, каждая со своим собственным механизмом обнаружения сбоев. Было бы более эффективно использовать один общий механизм обнаружения для всех различных плоскостей управления. В большинстве приложений BFD не заменяет существующие протоколы приветствия, используемые в каждой плоскости управления, а скорее дополняет их. Рисунок 5 демонстрирует это.
В модели BFD, скорее всего, будет по крайней мере два различных процесса опроса, работающих по одному и тому же логическому каналу (их может быть больше, если есть логические каналы, наложенные поверх других логических каналов, поскольку BFD также может использоваться в различных технологиях сетевой виртуализации). Опрос плоскости управления будет использовать приветствия (hellos) для обнаружения соседних устройств, выполняющих один и тот же процесс плоскости управления, для обмена возможностями, определения максимального блока передачи (MTU) и, наконец, для того, чтобы убедиться, что процесс плоскости управления на соседнем устройстве все еще работает. Эти приветствия проходят через соединение плоскости управления на рисунке 5, которое можно рассматривать как своего рода «виртуальный канал», проходящий через физический канал.
Опрос BFD будет выполняться под соединением уровня управления, как показано на рисунке, проверяя работу физического соединения и плоскостей пересылки (переадресации) на двух подключенных устройствах. Этот двухуровневый подход позволяет BFD работать намного быстрее, даже в качестве механизма опроса, чем любой механизм обнаружения на основе протокола маршрутизации.
BFD может работать в четырех различных режимах:
Асинхронный режим: в этом режиме BFD действует как облегченный протокол приветствия. Процесс BFD в A, потенциально работающий в распределенном процессе (или даже в специализированной интегральной схеме [ASIC]), отправляет пакеты приветствия в C. Процесс BFD в C подтверждает эти пакеты приветствия. Это довольно традиционное использование опроса через hellos.
Асинхронный режим с эхом: в этом режиме процесс BFD в A будет отправлять пакеты приветствия в C, поэтому пакеты приветствия будут обрабатываться только через путь пересылки, что позволяет опрашивать только путь пересылки. Для этого A отправляет пакеты приветствия в C, сформированные таким образом, что они будут переадресованы обратно в A. Например, A может отправить пакет C с собственным адресом A в качестве пункта назначения. C может забрать этот пакет и переслать его обратно к A. В этом режиме приветствия, передаваемые A, полностью отличаются от приветствий, передаваемых C. Подтверждения нет, только две системы посылают независимые приветствия, которые проверяют связь в двух направлениях с каждого конца.
Режим запроса: В этом режиме два одноранговых узла BFD соглашаются отправлять приветствия только тогда, когда подключение должно быть проверено, а не периодически. Это полезно в том случае, когда существует какой-то другой способ определения состояния канала—например, если канал [A, C] является каналом Ethernet, что означает, что обнаружение несущей доступен для обнаружения сбоя канала, - но этот альтернативный метод не обязательно является надежным для обеспечения точного состояния соединения во всех ситуациях. Например, в случае «коммутатора посередине», где B отключен от A, но не C, C может послать BFD привет, отметив любую проблему с подключением, чтобы убедиться, что его соединение с A все еще есть. В режиме запроса некоторые события, такие как потерянный пакет, могут вызвать локальный процесс для запуска события обнаружения BFD.
Режим запроса с эхом: этот режим похож на режим запроса - обычные приветствия не передаются между двумя устройствами, на которых работает BFD. Когда пакет передается, он отправляется таким образом, чтобы другое устройство переадресовало пакет приветствия обратно отправителю. Это снижает нагрузку на процессор на обоих устройствах, позволяя использовать гораздо более быстрые таймеры для приветствий BFD.
Независимо от режима работы, BFD вычисляет различные таймеры опроса (hello) и обнаружения (dead) отдельно по каналу связи. Лучший способ объяснить этот процесс-на примере. Предположим, что A отправляет управляющий пакет BFD с предлагаемым интервалом опроса 500 мс, а C отправляет управляющий пакет BFD с предлагаемым интервалом опроса 700 мс. Для связи выбирается большее число или, скорее, более медленный интервал опроса. Объясняется это тем, что более медленная система должна быть в состоянии идти в ногу с интервалом опроса, чтобы предотвратить ложные срабатывания.
Частота опроса изменяется при фактическом использовании, чтобы предотвратить синхронизацию пакетов приветствия в нескольких системах на одном и том же проводе. Если было четыре или пять систем, развертывающих Border Gateway Protocol (BGP) на одном канале множественного доступа, и каждая система устанавливает свой таймер для отправки следующего пакета приветствия на основе получения последнего пакета, все пять систем могут синхронизировать их передачу приветствия, чтобы все приветствия по сети передавались в один и тот же момент. Поскольку BFD обычно работает с таймерами длиной менее одной секунды, это может привести к тому, что устройство будет получать приветствия от нескольких устройств одновременно и не сможет обрабатывать их достаточно быстро, чтобы предотвратить ложное срабатывание.
Конкретная используемая модификация заключается в джиттере пакетов. Каждый передатчик должен взять базовый таймер опроса и вычесть некоторое случайное количество времени, которое составляет от 0% до 25% от таймера опроса. Например, если таймер опроса составляет 700 мсек, как в приведенном примере, A и C будут передавать каждый пакет приветствия примерно между 562 и 750 мсек после передачи последнего приветствия.
Последний момент, который следует учитывать, - это количество времени, в течение которого A и C будут ждать перед объявлением соединения (или соседа) отключенным. В BFD каждое устройство может вычислить свой собственный таймер отключения, обычно выраженный как кратное таймеру опроса. Например, A может решить считать канал (или C) отключенным после пропуска двух приветствий BFD, в то время как C может решить дождаться пропуска трех приветствий BFD.