⚡ ѕ–ќ…ƒ» Ќќ¬џ… ќЌЋј…Ќ  ”–— ѕќ —≈“≈¬џћ “≈’ЌќЋќ√»яћ —ќ — »ƒ ќ… 50%

до конца скидки осталось

Ќачать обучение 🚀
ћерион Ќетворкс

16 минут чтени€

»з предыдущих статей (тут и тут) мы узнали, что очень немногие механизмы, учитывают изменени€ в топологии. Ѕольшинство этих решений ориентированы на вычислени€ loop-free пути через очевидно стабильную сеть. Ќо что происходит при изменении топологии?  ак сетевые устройства создают таблицы, необходимые дл€ пересылки пакетов по loop-free пут€м в сети?

¬ этой серии статей мы рассмотрим очередную подзадачу этой всеобъемлющей проблемы и ответим на вопрос:  ак плоскости управлени€ обнаруживают изменени€ в сети и реагируют на них?

ќбучайс€ в Merion Academy

ѕройди курс по
сетевым технологи€м

Ќачать

Ќа этот вопрос мы ответим, рассмотрев две составл€ющие процесса конвергенции в плоскости управлени€. ѕроцесс конвергенции в сети может быть описан в четыре этапа. –исунок 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 ѕроцесс конвергенции

ƒалее мы сосредоточимс€ на первых двух из четырех шагов, описанных в предыдущем списке, размышл€€ в начале об обнаружении изменений топологии. Ѕудут рассмотрены некоторые примеры протоколов, специализирующихс€ на обнаружении изменений топологии. –аспределение топологии и информации о достижимости будет рассмотрена в конце этой серии статей. ѕоскольку эта проблема, по сути, €вл€етс€ проблемой распределенной базы данных, она будет решатьс€ с этой точки зрени€.


ќбнаружение изменений топологии

ѕервым шагом в реакции на изменение топологии сети €вл€етс€ обнаружение изменени€. ¬ернемс€ к рисунку 1.  аким образом два устройства, подключенные к каналу, C и E, обнаруживают сбой канала? –ешение этой проблемы не так просто, как может показатьс€ на первый взгл€д, по двум причинам: информационна€ перегрузка и ложные срабатывани€.

»нформационна€ перегрузка возникает, когда плоскость управлени€ получает так много информации, что просто не может распростран€ть информацию об изменени€х топологии и/или вычисл€ть и устанавливать альтернативные пути в соответствующие таблицы на каждом устройстве достаточно быстро, чтобы поддерживать согласованное состо€ние сети. ¬ случае быстрых, посто€нно происход€щих изменений, таких как отключение св€зи и подключение каждые несколько миллисекунд, плоскость управлени€ может быть перегружена информацией, в результате чего сама плоскость управлени€ потребл€ет достаточно сетевых ресурсов, чтобы вызвать сбой сети. “акже возможно, что сери€ отказов вызовет петлю положительной обратной св€зи, и в этом случае плоскость управлени€ Усворачиваетс€Ф сама по себе, либо реагиру€ очень медленно, либо вообще отказыва€. –ешение проблемы информационной перегрузки состоит в том, чтобы скрыть истинное состо€ние топологии от плоскости управлени€ до тех пор, пока скорость изменени€ не окажетс€ в пределах, которые может поддерживать плоскость управлени€.

Ћожные срабатывани€ - это проблема второго типа. ≈сли канал отбрасывает один пакет из каждых 100, и каждый раз отбрасываетс€ единственный пакет, который оказываетс€ пакетом плоскости управлени€, используемым дл€ отслеживани€ состо€ни€ канала, будет казатьс€, что канал выходит из стро€ и довольно часто возобновл€ет работу - даже если другой трафик перенаправл€етс€ по каналу без проблем.

—уществует два широких класса решений проблемы обнаружени€ событий:

  • –еализации могут периодически отправл€ть пакеты дл€ определени€ состо€ни€ канала, устройства или системы. Ёто опрос (Polling).
  • –еализации могут вызвать реакцию на изменение состо€ни€ канала или устройства в некотором физическом или логическом состо€нии внутри системы. Ёто обусловлено событи€ми.

 ак всегда, есть разные компромиссы с этими двум€ решени€ми и подкатегории каждого из них.


ќпрос (Polling) дл€ обнаружени€ сбоев.

ќпрос может выполн€тьс€ удаленно или вне диапазона, или локально, или в группе. –исунок 2 демонстрирует это.

Ќа рисунке 2 A и B периодически отправл€ют приветствие или какой-либо другой пакет опроса по тому же каналу, через который они подключены, и по тому же каналу, по которому они пересылают трафик. Ёто внутриполосный опрос, который имеет преимущество отслеживани€ состо€ни€ канала, по которому пересылаетс€ трафик, передаетс€ информаци€ о доступности и т. д. — другой стороны, D запрашивает у A и B некоторую информацию о состо€нии канала [A, B] из другого места в сети. Ќапример, D может периодически провер€ть состо€ние двух интерфейсов на канале [A, B] или, возможно, периодически отправл€ть пакет по пути [C, A, B, C] и т. д. ѕреимущество заключаетс€ в том, что информаци€ о состо€нии большого количества каналов может быть централизована, что упрощает управление сетью и устранение неполадок. ќба типа опроса часто используютс€ в реальных сетевых развертывани€х.

ƒл€ работы механизмов опроса часто используютс€ два отдельных таймера:

  • “аймер дл€ определени€ частоты передачи опроса. ќн часто называетс€ интервалом опроса в случае внеполосного опроса и часто называетс€ таймером приветстви€ в случае внутриполосного опроса.
  • “аймер, чтобы определить, как долго ждать, прежде чем объ€вить св€зь или устройство отключенным, или включить сигнал тревоги. Ёто часто называют мертвым интервалом или мертвым таймером в случае внутриполосного опроса.
–ис. 2 ¬нутриполосный и внеполосный опрос

÷ели внутриполосного и внеполосного опроса часто различаютс€. ¬неполосный опрос дл€ обнаружени€ изменений в состо€нии сети часто (но не всегда - особенно в случае централизованной плоскости управлени€) используетс€ дл€ мониторинга состо€ни€ сети и позвол€ет централизованно реагировать на изменени€ в состо€нии. ¬нутриполосный опрос наиболее часто используетс€ (как и следовало ожидать) дл€ локального обнаружени€ изменений состо€ни€, чтобы управл€ть реакцией распределенных плоскостей управлени€.


ќбнаружение сбоев на основе событий

ќбнаружение сбоев на основе событий основываетс€ на некотором локальном, измеримом событии дл€ определени€ состо€ни€ конкретного канала или устройства. –исунок 3 демонстрирует это.

Ќа рисунке 3, который показывает одну из возможных реализаций элементов архитектуры между физическим интерфейсом и протоколом маршрутизации, есть четыре шага:

  1. —в€зь между двум€ микросхемами физического интерфейса (phy), расположенными на обоих концах св€зи, не работает. ћикросхемы физического интерфейса обычно €вл€ютс€ оптическими дл€ электрических передач обслуживани€. Ѕольшинство микросхем физического интерфейса также выполн€ют некоторый уровень декодировани€ вход€щей информации, преобразу€ отдельные биты в сети в пакеты (десериализаци€) и пакеты в биты (сериализаци€). »нформаци€ кодируетс€ физическим интерфейсом на носителе, который предоставл€етс€ двум€ физическими микросхемами, подключенными к физическому носителю. ≈сли канал не работает или один из двух интерфейсов отключен по какой-либо причине, микросхема физического интерфейса на другом конце канала увидит падение несущей почти в реальном времени - обычно в зависимости от скорости света и длины физического носител€. Ёто состо€ние называетс€ потерей носител€.
  2. ћикросхема физического интерфейса при обнаружении потери несущей отправл€ет уведомление в таблицу маршрутизации (RIB) на локальном устройстве. Ёто уведомление обычно запускаетс€ как прерывание, которое затем транслируетс€ в некоторую форму вызова интерфейса прикладного программировани€ (API) в код RIB, что приводит к тому, что маршруты, доступные через интерфейс, и люба€ информаци€ о следующем переходе через интерфейс помечаютс€ как устаревшие или удал€ютс€ из таблицы маршрутизации. Ётот сигнал может или не может проходить через базу пересылаемой информации (FIB) по пути, в зависимости от реализации.
  3. RIB будет уведомл€ть протокол маршрутизации о маршрутах, которые он только что удалил из локальной таблицы, на основе событи€ отключени€ интерфейса.
  4. ѕротокол маршрутизации затем может удалить любых соседей, доступных через указанные интерфейсы (или, скорее, через подключенные маршруты).
–ис. 3  ѕример обнаружени€ событий

Ќа рисунке 3 нет места, в котором бы присутствовал периодический процесс, провер€ющий состо€ние чего-либо, а также не было бы пакетов, перемещающихс€ по сети. ¬есь процесс основан на том, что микросхема физического интерфейса тер€ет носитель на подключенной среде, следовательно, этот процесс управл€етс€ событи€ми.

„асто бывает, что состо€ние, управл€емое событи€ми, и статус опроса совмещаютс€. Ќапример, на рисунке 3, если бы станци€ управлени€ периодически опрашивала статус интерфейса в локальном RIB, процесс от набора микросхем физического интерфейса к RIB был бы управл€емым событием, а процесс от RIB на станцию управлени€ будет направлен опросом.


—равнение обнаружени€ на основе событий и на основе опроса

“аблица 1 отображает преимущества и недостатки каждого механизма обнаружени€ событий.

¬неполосный опрос

¬нутриполосный опрос

”правл€емый событи€ми

–аспределение статусов

—татус управл€етс€ централизованной системой; централизованна€ система имеет более полное представление об общем состо€нии сети

—татус определ€етс€ локальными устройствами; дл€ получени€ более широкой картины состо€ни€ всей сети требуетс€ сбор информации с каждого отдельного сетевого устройства

—татус определ€етс€ локальными устройствами; дл€ получени€ более широкой картины состо€ни€ всей сети требуетс€ сбор информации с каждого отдельного сетевого устройства

—в€зь состо€ни€ пересылки со св€зью или состо€нием устройства

—ообщение о состо€нии св€зи и / или устройства может быть ложным; не провер€ет возможность пересылки напр€мую

—осто€ние канала и/или устройства может быть напр€мую св€зано с возможностью пересылки (исключение сбоев в механизме проверки состо€ни€)

—осто€ние канала и/или устройства может быть напр€мую св€зано с возможностью пересылки (исключение сбоев в механизме проверки состо€ни€)

—корость обнаружени€

ѕеред объ€влением канала или устройства должен пройти некоторый интервал ожидани€

не удалось предотвратить ложные срабатывани€; замедл€ет сообщение об изменени€х в сети

ѕеред объ€влением канала или устройства должен пройти некоторый интервал ожидани€

не удалось предотвратить ложные срабатывани€; замедл€ет сообщение об изменени€х в сети

Ќекоторый таймер перед сообщением о сбо€х может быть желательным, чтобы уменьшить сообщение о ложных срабатывани€х, но этот таймер может быть очень коротким и подкрепл€тьс€ двойной проверкой состо€ни€ самой системы; как правило, гораздо быстрее при сообщении об изменени€х сети

ћасштабирование

ƒолжен передавать периодические опросы, потребл€€ пропускную способность, пам€ть и циклы обработки; масштабируетс€ в этих пределах

ƒолжен передавать периодические опросы, потребл€€ пропускную способность, пам€ть и циклы обработки; масштабируетс€ в этих пределах

Ќебольшие объемы текущего локального состо€ни€; имеет тенденцию масштабироватьс€ лучше, чем механизмы опроса

’от€ может показатьс€, что обнаружение, управл€емое событи€ми, всегда должно быть предпочтительным, есть некоторые конкретные ситуации, когда опрос может решить проблемы, которые не могут быть решены механизмами, управл€емыми событи€ми. Ќапример, одно из главных преимуществ систем, основанных на опросе, особенно при внутриполосном развертывании, заключаетс€ в том, чтобы Ђвидетьї состо€ние невидимых блоков. Ќапример, на рисунке 4 два маршрутизатора соединены через третье устройство, обозначенное на рисунке как ретрансл€тор.

Ќа рисунке 4 устройство B представл€ет собой простой физический повторитель. ¬се, что он получает по каналу [A, B], он повторно передает, как и получил, по каналу [B, C]. Ќа этом устройстве нет какой-либо плоскости управлени€ (по крайней мере, о том, что известно A и C). Ќи A, ни C не могут обнаружить это устройство, поскольку оно не измен€ет сигнал каким-либо образом, который мог бы измерить A или C.

–ис. 4 –етрансл€торы сигналов и потер€ несущей

„то произойдет, если канал [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, которое можно рассматривать как своего рода Ђвиртуальный каналї, проход€щий через физический канал.

–ис. 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.


>