По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущая статья из цикла про устранение неисправностей DHCP на Cisco доступна по ссылке.
Последняя статья будет посвящена некоторым проблемам с FHRP, мы начнем с VRRP!
Урок 1
В сценарии выше у нас есть проблема с HSRP. Сначала разберем топологию. С левой стороны находится клиент (мы используем маршрутизатор, чтобы иметь возможность воссоздать его в GNS3), который использует виртуальный IP-адрес в качестве шлюза по умолчанию. R2 и R3 настроены для HSRP. На правой стороне есть маршрутизатор с IP-адресом 4.4.4.4 на интерфейсе loopback0. К сожалению, наш клиент не может пропинговать 4.4.4.4. Что здесь происходит?
Сначала мы отправим эхо-запрос от клиента на IP-адрес 4.4.4.4. Вы видите символ U (недостижимый), поэтому мы знаем, что получаем ответ от шлюза по умолчанию.
Таблица маршрутизации была отключена на этом клиентском маршрутизаторе (нет ip-маршрутизации), но вы можете видеть, что шлюз по умолчанию был настроен. Давайте посмотрим, доступен ли этот IP-адрес.
Достигнуть шлюза по умолчанию не проблема, поэтому мы можем перенести фокус на R2 или R3.
Мы можем использовать команду show standby, чтобы убедиться, что R3 является активным маршрутизатором HSRP. Давайте проверим, может ли он достичь IP-адреса 4.4.4.4.
Увы ...пинг не проходит.
Его нет в таблице маршрутизации, и если вы посмотрите внимательно, то увидите, что FastEthernet1/0 не находится в таблице маршрутизации как непосредственно подключенный, это указывает на то, что что-то не так с этим интерфейсом.
Ну вот...интерфейс отключен.
R3(config)#interface fastEthernet 1/0
R3(config-if)#no shutdown
Включим его!
Ну вот, теперь он работает.
Проблема устранена ... теперь клиент может пинговать 4.4.4.4! Есть еще одна вещь, хотя ... мы используем HSRP, так что наш шлюз по умолчанию не является единственной точкой отказа, но в этом случае R3 имел сбой соединения...разве R2 не должен взять на себя управление?
interface tracking было включено, и вы можете видеть, что приоритет должен уменьшиться на 10, если интерфейс FastEthernet1/0 перейдет в состояние down. Это означает, что обычно R2 должен взять на себя управление, но preemption is disabled по умолчанию для HSRP.
R2(config)#interface fastEthernet 0/0
R2(config-if)#standby 1 preempt
R3(config)#interface fastEthernet 0/0
R3(config-if)#standby 1 preempt
Прежде чем отпраздновать нашу победу в устранении неполадок, мы должны убедиться, что эта проблема больше не возникнет в будущем. Мы включим приоритет на обоих маршрутизаторах. Теперь все готово!
Итог урока: убедитесь, что preemption включена для HSRP, если вы используете interface tracking
Урок 2
Вот та же топология, но на этот раз мы используем VRRP вместо HSRP. Однако проблема заключается в другом: клиент жалуется, что не все IP-пакеты попадают в 4.4.4.4.
Некоторые из IP-пакетов не поступают в 4.4.4.4.
IP-адрес шлюза: 192.168.123.254.
Шлюз пингуется без проблем.
R2 не может достичь 4.4.4.4, но у R3 нет никаких проблем. Прежде чем мы продолжим проверять, почему R2 не может достичь 4.4.4.4, мы взглянем на конфигурацию VRRP, чтобы увидеть, какой маршрутизатор является главным.
Вывод show vrrp интересен. Оба маршрутизатора считают, что они активны, и, если вы посмотрите внимательно, вы поймете, почему. Аутентификация включена, и в key-string имеется несоответствие. Поскольку оба маршрутизатора активны, половина пакетов окажется в R2, а остальные в R3. Вот почему наш клиент видит, что некоторые пакеты приходят, а другие нет. Давайте исправим нашу аутентификацию:
R2(config)#interface fa0/0
R2(config-if)#vrrp 1 authentication md5 key-string SECRET
Мы сделаем key-string одинаковыми.
Это сообщение в консоли R2 является многообещающим.
R3 был выбран в качестве главного маршрутизатора. Теперь давайте выясним, почему R2 не смог достичь 4.4.4.4, поскольку эта проблема устранена.
Странно, R2 показывает только одну запись в таблице маршрутизации, что-то не так с FastEthernet 1/0.
Кажется, кому-то нравится команда shutdown Имейте в виду, что это может быть что-то еще списки доступа, blocking traffic между R2 и R4, port-security (если был коммутатор в середине), интерфейсы в режиме err-disabled, неправильные IP-адреса и другое. Проверьте все!
R2(config)#interface fastEthernet 1/0
R2(config-if)#no shutdown
Включим интерфейс!
Проблема устранена!
Итог урока: убедитесь, что маршрутизаторы VRRP могут связаться друг с другом.
Если вы специалист по безопасности, то вам потребуется часто анализировать хосты, если будет замечена подозрительная активность. Чтобы дольше оставаться незамеченными, злоумышленники зачастую используют совершенно легитимные инструменты и процессы, которые можно найти в любой ОС Microsoft Windows.
Поэтому важно понимать, как Windows обрабатывает процессы и какие встроенные инструменты может использовать специалист по безопасности для анализа активностей на хосте.
Процессы, потоки и службы
В Windows, когда приложение запущено, оно создает процесс. Обычно приложение может иметь один или несколько выделенных ему процессов. Процесс - это все ресурсы, необходимые для обеспечения возможности выполнения/запуска приложения в операционной системе хоста. Представьте, что вы открываете диспетчер задач, чтобы проверить производительность вашего компьютера. Операционная система создаст процесс со всеми необходимыми ресурсами для этого приложения.
На следующем рисунке показаны текущие процессы на компьютере с Windows 10:
Как показано на предыдущем рисунке, диспетчер задач - это служебная программа, которая предоставляет информацию о процессах, службах и производительности устройства. На вкладке «Процессы» вы увидите список всех запущенных в данный момент приложений в операционной системе хоста, список фоновых процессов и ресурсы, которые выделяются каждому приложению (ЦП, память).
Фоновые процессы в Windows выполняются как службы. Служба - это программа, которая выполняется в фоновом режиме операционной системы, обеспечивая поддержку приложения и/или операционной системы. Эти службы можно настроить на автоматический запуск при загрузке Windows. Вы можете запускать, останавливать и перезапускать службу вручную.
На следующем снимке экрана показано окно панели управления службами в операционной системе Windows 10:
На предыдущем рисунке показан список служб в операционной системе хоста. Здесь вы можете настроить свойства службы в Windows. Дважды щелкнув на службу, откроется окно свойств.
На следующем рисунке показано окно свойств службы:
Как показано на предыдущем рисунке, вы можете настроить тип запуска службы.
Каждое приложение создает родительский процесс с одним или несколькими дочерними процессами, иногда называемыми потоком. Каждый дочерний процесс или поток отвечает за функцию, обеспечивающую выполнение приложения. Когда приложение выполняется в операционных системах Microsoft Windows, родительский процесс использует системный вызов fork(), который позволяет родительскому процессу для запущенного приложения создать один или несколько дочерних процессов. Однако имейте в виду, что у дочернего процесса может быть только один родительский процесс, а у родительского процесса может быть несколько дочерних процессов.
Когда приложение выполняется операционной системой или пользователем, операционная система задействует физическую память из оперативной памяти и создает виртуальную память для выделения запущенному процессу или дочернему процессу. Таким образом, процессы выполняются в виртуальном адресном пространстве операционной системы.
Важное примечание! Операционная система Windows управляет выделением виртуальной памяти процессу.
Иногда, когда приложение закрывается, родительский процесс и все дочерние процессы завершаются, тем самым высвобождая ресурсы обратно операционной системе. Однако родительский процесс может завершиться, пока дочерние процессы остаются активными. В этой ситуации виртуальная память и любые другие ресурсы по-прежнему выделяются каждому дочернему процессу. Дочерний процесс, у которого нет родительского процесса, называется сиротским процессом (orphan process). Пользователь может вручную завершить дочерний процесс в диспетчере задач или выполнить перезагрузку системы. Перезагрузка системы завершит все процессы и перезагрузит операционную систему.
На следующем рисунке показан список всех запущенных процессов на вкладке «Подробности» в диспетчере задач:
Как показано на предыдущем снимке экрана, мы можем видеть все процессы, идентификатор процесса (PID) для каждого процесса, статус, какой пользователь запускает процесс, и распределение ресурсов. Также в Microsoft Windows существует утилита Resource Monitor Монитор ресурсов предоставляет более подробную информацию обо всех процессах и о том, как они используют ЦП, память диск и сеть на устройстве.
На следующем рисунке показан интерфейс монитора ресурсов на компьютере с Windows 10:
Еще одним инструментом, который поможет вам определить адресное пространство и распределение памяти в Microsoft Windows, является инструмент RAMMap, который входит в набор инструментов Windows Sysinternals от Microsoft.
На следующем рисунке показан сводный список и список подкачки на хосте, использующем RAMMap:
Как показано на предыдущем снимке экрана, RAMMap показывает сводную информацию о выделении виртуальной памяти и ее использовании. Кроме того, вкладка Процессы содержит полный список всех процессов:
Как показано на предыдущем рисункеа, на этой вкладке вы можете увидеть каждый запущенный процесс и распределение виртуальной памяти. Этот инструмент действительно полезен для демонстрации того, как ваша операционная система распределяет физическую память и сколько памяти используется в качестве кэша для данных на устройстве.
Файл подкачки Windows=
По мере того, как в память загружается больше приложений, операционная система выделяет части физической памяти (ОЗУ) каждому процессу, используя виртуальную память. Каждый родительский процесс и его дочерние процессы выполняются в одном виртуальном адресном пространстве в операционной системе хоста. Как уже упоминалось, за выделение памяти отвечает операционная система, однако есть некоторые приложения, которым для бесперебойной работы требуется намного больше памяти, чем другим, и это может создать нехватку доступной памяти для других приложений.
Операционная система Windows использует часть памяти из другой области, с жесткого диска или SSD. Windows берет небольшую часть памяти с локального диска и преобразует ее в виртуальную память. Это называется файлом подкачки.
Файл подкачки позволяет операционной системе хоста использовать эту часть памяти для загрузки приложений и, следовательно, снижает нагрузку на физическую память (ОЗУ) в системе.
Чтобы получить доступ к настройкам файлов подкачки, выполните следующие действия:
Щелкните значок Windows в нижнем левом углу экрана и выберете Система. Откроется окно «Система». Слева выберите пункт «Дополнительные параметры системы».
Откроется окно «Свойства системы». Выберите пункт «Дополнительно» и нажмите «Параметры» в разделе «Быстродействие», как показано ниже:
Откроется окно параметров быстродействия. Чтобы изменить размер файла подкачки, нажмите «Изменить…»:
Вам будет предоставлена возможность настроить размер файла подкачки для всех дисков в локальной системе. Размер файла подкачки по умолчанию зависит от объема оперативной памяти хост-системы. Операционная система Windows 10 автоматически управляет размером файла подкачки в зависимости от конфигурации хоста и объема оперативной памяти в системе.
Windows использует файл подкачки в качестве виртуальной памяти в случае, если в ОЗУ недостаточно физической памяти.
Реестр Windows
Вся информация о конфигурациях и настройках операционной системы Windows и ее пользователей хранится в базе данных, известной как реестр (registry). Самый высокий уровень реестра известен как куст. В реестре Windows есть пять кустов, и каждое значение данных хранится в разделе или подразделе куста. Древо (куст) реестра — это подмножество разделов, подразделов и параметров реестра, которому сопоставлен набор вспомогательных файлов, содержащих резервные копии этих данных. Часто для обозначения конкретных путей в реестре применяют термин ветка. Например ветка реестра HKEY_LOCAL_MACHINESYSTEM.
Ниже перечислены пять кустов и их функции в Windows:
HKEY_CLASSES_ROOT (HKCR): этот куст отвечает за правильное выполнение всех текущих приложений в проводнике Windows. Кроме того, этот куст содержит сведения о ярлыках и правилах перетаскивания в операционной системе хоста.
HKEY_CURRENT_USER (HKCU): этот куст хранит информацию о текущей учетной записи пользователя в локальной системе. Эта информация будет включать настройки панели управления, настройки папок и настройки персонализации пользователя.
HKEY_LOCAL_MACHINE (HKLM): этот куст отвечает за хранение специфичных для оборудования деталей операционной системы, таких как конфигурация системы и подключенные диски.
HKEY_USERS (HKU): содержит данные конфигурации профилей пользователей в локальной системе.
HKEY_CURRENT_CONFIG (HKCC): содержит подробную информацию о текущих конфигурациях системы.
Для доступа к реестру используйте Registry Editor (regedit) в строке поиска Windows.
На следующем рисунке показан редактор реестра Windows:
Как показано на предыдущем рисунке, вы можете видеть, что каждый куст находится в верху своего уровня. Если вы развернете куст, вы увидите папки, а в каждой папке есть ключи, которые содержат сведения о конкретной функции или конфигурации в операционной системе.
Реестр может предоставить ценную информацию во время расследования. В каждом реестре есть значение, известное как LastWrite, которое просто указывает время последнего изменения объекта или файла. Эта информация может использоваться для определения времени инцидента или события, связанного с безопасностью. В реестре также содержатся сведения о приложениях, которые запускаются автоматически со стартом системы - AutoRun. Для закрепления в системе, злоумышленники часто модифицируют ветки реестра, которые отвечают за автоматический запуск процессов и сервисов и добавляют в них ссылки на вредоносные программы, чтобы они каждый раз запускались со стартом системы и могли пережить перезагрузку.
Ниже приведены основные ветки, отвечающие за автоматический старт приложений и сервисов:
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce]
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun]
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServices]
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServicesOnce]
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogonUserinit]
[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun]
[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnce]
[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunServices]
[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunServicesOnce]
[HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows]
Например, чтобы при каждом старте Windows запускался блокнот, в ветку [HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun] можно добавить новое значение и указать в нём ссылку на исполняемый файл на компьютере - "Notepad"="c:windows
otepad.exe"
Windows Management Instrumentation
Управлять несколькими компьютерами с ОС Windows в небольшой сети очень просто. Однако по мере роста сети и подключения все большего числа устройств на базе Windows управление политиками и службами на уровне приложений может стать сложной задачей. Windows Management Instrumentation (WMI) - это инструмент, встроенный в операционную систему Windows, который позволяет системному администратору или специалисту по безопасности управлять многими системами на базе Windows в корпоративной сети.
WMI - это функция администрирования Windows, которая обеспечивает единую среду для локального и удаленного доступа к системным компонентам Windows, а также позволяет собирать статистическую информацию об удаленных компьютерах в вашей сети. Вы сможете собирать статистику как по оборудованию, так и по программному обеспечению и даже отслеживать состояние каждого устройства.
Чтобы открыть WMI на компьютере с Windows, выполните следующие действия:
Откройте приложение Computer Management (управление компьютером) в Windows 10/Server 2019.
Слева разверните «Службы и приложения».
Щелкните правой кнопкой мыши элемент управления WMI и выберите «Свойства».
На следующем рисунке показан интерфейс свойств элемента управления WMI:
Злоумышленники могут использовать инструментарий управления Windows (WMI) для удаленного управления. WMI работает через протоколы SMB и службу удаленного вызова процедур (RPCS) для удаленного доступа. RPCS работает через порт 135.
WMI управляется через утилиту командной строки WMI command-line (WMIC). Пример команды - wmic process call create.
Использование WMI должно быть ограничено и ограничиваться только авторизованными пользователями, внимательно следя за его использованием.
Инструменты мониторинга
В операционной системе Windows существует множество инструментов мониторинга, которые специалист по безопасности может использовать для мониторинга различных ресурсов и действий на устройстве. Одним из таких инструментов является Performance Monitor, который позволяет пользователю собирать более подробные данные, чем ранее упомянутый Resource Monitor. Монитор производительности (системный монитор) - это основной инструмент, используемый как в Windows 10, так и в Windows Server. Специалист по безопасности может использовать этот инструмент для сбора статистики о системе за различные периоды времени, например, часы или дни. Затем собранные данные можно проанализировать на предмет любых аномалий.
На следующем рисунке показан монитор производительности в системе Windows 10/Server 2019:
Еще одним отличным инструментом, встроенным в Windows, является Монитор стабильности системы. Монитор стабильности системы позволяет специалисту по безопасности просматривать историю проблем, возникших в основной системе в течение нескольких дней или недель. Пользователь может нажать на событие в инструменте, чтобы получить подробную информацию о проблеме, и существует система оценок от 1 до 10, отражающая серьезность проблемы.
На следующем рисунке показан Монитор стабильности системы на компьютере с Windows 10:
Как показано на предыдущем рисунке, в системе произошел ряд критических событий за определенный период времени. Выбрав событие, монитор покажет подробную информацию о службе или приложении, вызвавшем событие, сводку и время его возникновения. Специалист по безопасности может использовать статистику и информацию, найденные здесь, чтобы лучше понять, вызвало ли вредоносное ПО или неавторизованные приложения нарушение безопасности в хост-системе.
Инструменты мониторинга
Когда в системе Windows происходит какое-либо событие, создается сообщение журнала о данном событии. Инструмент, позволяющий анализировать данные события - Event Viewer. Event Viewet содержит журналы безопасности, приложений и системных событий.
Представьте, что злоумышленник пытается войти в учетную запись пользователя с неверными учетными данными. Для каждой попытки создастся событие сообщения журнала, и по этим данным можно будет обнаружить атаку. Существует 4 основных журнала событий:
Security Безопасность - хранит события безопасности
Application Приложение - хранит журналы приложений в ситстеме и установленного ПО
Setup Установка - хранит сведения об установке ОС
System Система - хранит сведения о работе самой системы
На следующем рисунке показан инструмент просмотра событий в Windows (Event Viewer):
Если вы развернете категорию, такую как Безопасность, вы увидите список всех журналов, связанных с безопасностью. На следующем снимке экрана показаны сведения в окне просмотра событий входа в систему безопасности:
Информация, содержащаяся в сообщениях журнала, помогает специалисту по безопасности определить, что, когда и как произошел инцидент в системе.
Обратите внимание на код события - 4624. Этот код соответствует успешному входу в системе Windows. В случае неуспешного входа сгенерируется событие с кодом 4625. Данные события также будут содержать другую полезную информацию, такую как: имя пользователя, осуществляющего вход, информацию о системе с которой осуществляется вход, тип входа (интерактивный, удаленный, сетевой, вход сервиса), процесс входа, ID входа и другое.
Другие важные коды событий в системах Windows, хранящиеся в журнале Безопасности/Security (начиная с версии 7):
4725 - Отключение Учетной записи
4723 - Изменение пароля учетной записи
4724 - Сброс пароля для учетной записи
47204726 - Созданиеудаление пользователя
4648 - вход с явным указанием учетных данных
4698 - Создание задачи через планировщик задач
4697 - Создание службы в системе
46884689 - Созданиезавершение процесса
Первая часть тут
Как только изменение в топологии сети было обнаружено, оно должно быть каким-то образом распределено по всем устройствам, участвующим в плоскости управления. Каждый элемент в топологии сети может быть описан как:
Канал или граница, включая узлы или достижимые места назначения, прикрепленные к этому каналу.
Устройство или узел, включая узлы, каналы и доступные места назначения, подключенные к этому устройству.
Этот довольно ограниченный набор терминов может быть помещен в таблицу или базу данных, часто называемую таблицей топологии или базой данных топологии. Таким образом, вопрос о распределении изменений в топологии сети на все устройства, участвующие в плоскости управления, можно описать как процесс распределения изменений в определенных строках в этой таблице или базе данных по всей сети.
Способ, которым информация распространяется по сети, конечно, зависит от конструкции протокола, но обычно используются три вида распространения: поэтапное (hop-by-hop) распространение, лавинное (flooded) распространение и централизованное (centralized) хранилище некоторого вида.
Лавинное (flooded) распространение.
При лавинной рассылке каждое устройство, участвующее в плоскости управления, получает и сохраняет копию каждой части информации о топологии сети и доступных местах назначения. Хотя существует несколько способов синхронизации базы данных или таблицы, в плоскостях управления обычно используется только один: репликация на уровне записи. Рисунок 6 иллюстрирует это.
На рисунке 6 каждое устройство будет рассылать известную ему информацию ближайшим соседям, которые затем повторно рассылают информацию своим ближайшим соседу. Например, A знает две специфические вещи о топологии сети: как достичь 2001: db8: 3e8: 100 :: / 64 и как достичь B. A передает эту информацию в B, который, в свою очередь, передает эту информацию в C. Каждое устройство в сети в конечном итоге получает копию всей доступной топологической информации; A, B и C имеют синхронизированные базы данных топологии (или таблицы).
На рисунке 6 связь C с D показана как элемент в базе данных. Не все плоскости управления будут включать эту информацию. Вместо этого C может просто включать подключение к диапазону адресов 2001: db8: 3e8: 102 :: / 64 (или подсети), который содержит адрес D.
Примечание. В более крупных сетях невозможно уместить все описание подключений устройства в один пакет размером с MTU, и для обеспечения актуальности информации о подключении необходимо регулярно задерживать время ожидания и повторно загружать данные.
Интересная проблема возникает в механизмах распространения Flooding рассылки, которые могут вызывать временные петли маршрутизации, называемые microloops. Рисунок 7 демонстрирует эту ситуацию. На рисунке 7, предположим, что канал [E, D] не работает. Рассмотрим следующую цепочку событий, включая примерное время для каждого события:
Старт: A использует E, чтобы добраться до D; C использует D, чтобы добраться до E.
100 мс: E и D обнаруживают сбой связи.
500 мс: E и D рассылают информацию об изменении топологии на C и A.
750 мс: C и A получают обновленную информацию о топологии.
1000 мс: E и D пересчитывают свои лучшие пути; E выбирает A как лучший путь для достижения D, D выбирает C как лучший путь для достижения E.
1,250 мс: лавинная рассылка A и C информации об изменении топологии на B.
1400 мс: A и C пересчитывают свои лучшие пути; A выбирает B для достижения D, C выбирает B для достижения E.
1500 мс: B получает обновленную информацию о топологии.
2,000 мс: B пересчитывает свои лучшие пути; он выбирает C, чтобы достичь D, и A, чтобы достичь E.
Хотя время и порядок могут незначительно отличаться в каждой конкретной сети, порядок обнаружения, объявления и повторных вычислений почти всегда будет следовать аналогичной схеме. В этом примере между этапами 5 и 7 образуется микропетля; в течение 400 мс, A использует E для достижения D, а E использует A для достижения D. Любой трафик, входящий в кольцо в A или D в течение времени между пересчетом E лучшего пути к D и пересчетом A лучшего пути к D будет петлей. Одним из решений этой проблемы является предварительное вычисление альтернативных вариантов без петель или удаленных альтернатив без петель.
Hop by Hop
При поэтапном распределении каждое устройство вычисляет локальный лучший путь и отправляет только лучший путь своим соседям. Рисунок 8 демонстрирует это.
На рисунке 8 каждое устройство объявляет информацию о том, что может достигнуть каждого из своих соседей. D, например, объявляет о достижимости для E, а B объявляет о доступности для C, D и E для A. Интересно рассмотреть, что происходит, когда A объявляет о своей доступности для E через канал на вершине сети. Как только E получит эту информацию, у него будет два пути к B, например: один через D и один через A. Таким же образом у A будет два пути к B: один напрямую к B, а другой через E. Любой из алгоритмов кратчайшего пути, рассмотренные в предыдущих статьях, могут определить, какой из этих путей использовать, но возможно ли формирование микропетель с помощью лавинного механизма распределения?
Рассмотрим:
E выбирает путь через A, чтобы добраться до B.
Канал [A, B] не работает.
A обнаруживает этот сбой и переключается на путь через E.
Затем A объявляет этот новый путь к E.
E получает информацию об измененной топологии и вычисляет новый лучший путь через D.
В промежутке между шагами 3 и 5 А будет указывать на Е как на свой лучший путь к В, в то время как Е будет указывать на А как на свой лучший путь к В—микропетля. Большинство распределительных систем hop-by-hop решают эту проблему с помощью split horizon или poison reverse.
Определены они следующим образом:
Правило split horizon гласит: устройство не должно объявлять о доступности к пункту назначения, который он использует для достижения пункта назначения.
Правило poison reverse гласит: устройство должно объявлять пункты назначения по отношению к соседнему устройству, которое оно использует, чтобы достичь пункта назначения с бесконечной метрикой.
Если разделение горизонта (split horizon) реализованный на рисунке 8, E не будет объявлять о достижимости для B, поскольку он использует путь через A для достижения B. В качестве альтернативы E может отравить путь к B через A, что приведет к тому, что A не будет иметь пути через E к B.
Централизованное Хранилище.
В централизованной системе каждое сетевое устройство сообщает информацию об изменениях топологии и достижимости контроллеру или, скорее, некоторому набору автономных служб и устройств, действующих в качестве контроллера. В то время как централизация часто вызывает идею единого устройства (или виртуального устройства), которому передается вся информация и который передает правильную информацию для пересылки всем устройствам обработки пакетов в сети, это чрезмерное упрощение того, что на самом деле означает централизованная плоскость управления. Рисунок 9 демонстрирует это.
На рисунке 9, когда канл между D и F не работает:
D и F сообщают об изменении топологии контроллеру Y.
Y пересылает эту информацию другому контроллеру X.
Y вычисляет лучший путь к каждому месту назначения без канала [D, F] и отправляет его каждому затронутому устройству в сети.
Каждое устройство устанавливает эту новую информацию о пересылке в свою локальную таблицу.
Конкретный пример шага 3 - Y вычисляет следующий лучший путь к E без канала [D, F] и отправляет его D для установки в его локальной таблице пересылки. Могут ли микропетли образовываться в централизованной плоскости управления?
Базы данных в X и Y должны быть синхронизированы, чтобы оба контроллера вычисляли одинаковые пути без петель в сети
Синхронизация этих баз данных повлечет за собой те же проблемы и (возможно) использование тех же решений, что и решения, обсуждавшиеся до сих пор в этой статье.
Подключенным устройствам потребуется некоторое время, чтобы обнаружить изменение топологии и сообщить об этом контроллеру.
Контроллеру потребуется некоторое время, чтобы вычислить новые пути без петель.
Контроллеру потребуется некоторое время, чтобы уведомить затронутые устройства о новых путях без петель в сети.
Во время временных интервалов, описанных здесь, сеть все еще может образовывать микропетли. Централизованная плоскость управления чаще всего переводится в плоскость управления не запущенными устройствами переадресации трафика. Хотя они могут казаться радикально разными, централизованные плоскости управления на самом деле используют многие из тех же механизмов для распределения топологии и достижимости, а также те же алгоритмы для вычисления безцикловых путей через сеть, что и распределенные плоскости управления.
Плоскости сегментирования и управления.
Одна интересная идея для уменьшения состояния, переносимого на любое отдельное устройство, независимо от того, используется ли распределенная или централизованная плоскость управления, заключается в сегментировании информации в таблице топологии (или базе данных). Сегментация-это разделение информации в одной таблице на основе некоторого свойства самих данных и хранение каждого полученного фрагмента или фрагмента базы данных на отдельном устройстве. Рисунок 10 демонстрирует это.
В сети на рисунке 10 предположим, что оба контроллера, X и Y, имеют информацию о топологии для всех узлов (устройств) и ребер (каналов) в сети. Однако для масштабирования размера сети доступные места назначения были разделены на два контроллера. Существует множество возможных схем сегментирования - все, что может разделить базу данных (или таблицу) на части примерно одинакового размера, будет работать. Часто используется хеш, так как хеши можно быстро изменить на каждом устройстве, где хранится сегмент, чтобы сбалансировать размеры сегментов.
В этом случае предположим, что схема сегментирования немного проще: это диапазон IP-адресов. В частности, на рисунке представлены два диапазона IP-адресов: 2001: db8: 3e8: 100 :: / 60, который содержит от 100 :: / 64 до 10f :: / 64; и 2001: db8: 3e8: 110 :: / 60, который содержит от 110 :: / 64 до 11f :: / 64. Каждый из этих диапазонов адресов разделен на один контроллер; X будет содержать информацию о 2001: db8: 3e8: 100 :: / 60, а Y будет содержать информацию о 2001: db8: 3e8: 110 :: / 64. Не имеет значения, где эти доступные пункты назначения подключены к сети. Например, информация о том, что 2001: db8: 3e8: 102 :: / 64 подключен к F, будет храниться в контроллере X, а информация о том, что 2001: db8: 3e8: 110 :: / 64 подключен к A, будет храниться на контроллере Y. Чтобы получить информацию о доступности для 2001: db8: 3e8: 102 :: / 64, Y потребуется получить информацию о том, где этот пункт назначения соединен с X. Это будет менее эффективно с точки зрения вычисления кратчайших путей, но он будет более эффективным с точки зрения хранения информации, необходимой для вычисления кратчайших путей. Фактически, возможно, если информация хранится правильно (а не тривиальным способом, используемым в этом примере), чтобы несколько устройств вычислили разные части кратчайшего пути, а затем обменивались только результирующим деревом друг с другом. Это распределяет не только хранилище, но и обработку.
Существует несколько способов, с помощью которых информация о плоскости управления может быть разделена, сохранена и, когда вычисления выполняются через нее, чтобы найти набор путей без петель через сеть.
Согласованность, доступность и возможность разделения.
Во всех трех системах распределения, обсуждаемых в этой статье, - лавинной, поэтапной и централизованных хранилищ - возникает проблема микропетель. Протоколы, реализующие эти методы, имеют различные системы, такие как разделение горизонта и альтернативы без петель, чтобы обходить эти микропетли, или они позволяют микропетлям появляться, предполагая, что последствия будут небольшими для сети. Существует ли объединяющая теория или модель, которая позволит инженерам понять проблемы, связанные с распределением данных по сети, и различные сопутствующие компромиссы?
Есть: теорема CAP.
В 2000 году Эрик Брюер, занимаясь как теоретическими, так и практическими исследованиями, постулировал, что распределенная база данных обладает тремя качествами: Согласованностью, Доступностью и устойчивость к разделению (Consistency, Accessibility Partition tolerance-CAP). Между этими тремя качествами всегда есть компромисс, так что вы можете выбрать два из трех в любой структуре системы. Эта гипотеза, позже доказанная математически, теперь известна как теорема CAP. Эти три термина определяются как:
Согласованность: Каждый считыватель видит согласованное представление содержимого базы данных. Если какое-то устройство С записывает данные в базу данных за несколько мгновений до того, как два других устройства, А и В, прочитают данные из базы данных, оба считывателя получат одну и ту же информацию. Другими словами, нет никакой задержки между записью базы данных и тем, что оба считывателя, А и В, могут прочитать только что записанную информацию.
Доступность: каждый считыватель имеет доступ к базе данных при необходимости (почти в реальном времени). Ответ на чтение может быть отложен, но каждое чтение будет получать ответ. Другими словами, каждый считыватель всегда имеет доступ к базе данных. Не существует времени, в течение которого считыватель получил бы ответ «сейчас вы не можете запросить эту базу данных».
Устойчивость к разделению: возможность копирования или разделения базы данных на несколько устройств.
Проще изучить теорему CAP в небольшой сети. Для этого используется рисунок 11.
Предположим, что A содержит единственную копию базы данных, к которой должны иметь доступ как C, так и D. Предположим, что C записывает некоторую информацию в базу данных, а затем сразу же после, C и D считывают одну и ту же информацию. Единственная обработка, которая должна быть, чтобы убедиться, что C и D получают одну и ту же информацию, - это A. Теперь реплицируйте базу данных, чтобы была копия на E и еще одна копия на F. Теперь предположим, что K записывает в реплику на E, а L читает из реплики на F. Что же будет?
F может вернуть текущее значение, даже если это не то же самое значение, что только что записал К. Это означает, что база данных возвращает непоследовательный ответ, поэтому согласованность была принесена в жертву разделению базы данных.
Если две базы данных синхронизированы, ответ, конечно, в конечном итоге одинаковым, но потребуется некоторое время, чтобы упаковать изменение (упорядочить данные), передать его в F и интегрировать изменение в локальную копию F. F может заблокировать базу данных или определенную часть базы данных, пока выполняется синхронизация. В этом случае, когда L читает данные, он может получить ответ, что запись заблокирована. В этом случае доступность теряется, но сохраняется согласованность и разбиение базы данных.
Если две базы данных объединены, то согласованность и доступность могут быть сохранены за счет разделения.
Невозможно решить эту проблему, чтобы все три качества были сохранены, из-за времени, необходимого для синхронизации информации между двумя копиями базы данных. Та же проблема актуальна и для сегментированной базы данных.
Как это применимо к плоскости управления? В распределенной плоскости управления база данных, из которой плоскость управления черпает информацию для расчета путей без петель, разделена по всей сети. Кроме того, база данных доступна для чтения локально в любое время для расчета путей без петель. Учитывая разделение и доступность, необходимые для распределенной базы данных, используемой в плоскости управления, следует ожидать, что непротиворечивость пострадает - и это действительно так, что приводит к микропетлям во время конвергенции. Централизованная плоскость управления не «решает» эту проблему. Централизованная плоскость управления, работающая на одном устройстве, всегда будет согласованной, но не всегда будет доступной, а отсутствие разделения будет представлять проблему для устойчивости сети.