ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

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

ѕеред началом, советуем почитать материал про плоскость управлени€.

“опологи€ - это набор св€зей (или ребер) и узлов, которые описывают всю сеть. ќбычно топологи€ описываетс€ и рисуетс€ как граф, но она также может быть представлена в структуре данных, предназначенной дл€ использовани€ машинами, или в дереве, которое обычно предназначено дл€ использовани€ людьми.

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

ќбобщение информации о топологии в плоскости управлени€

»зучение топологии

 азалось бы, достаточно просто узнать о топологии сети: изучить подключенные каналы передачи данных. ќднако то, что кажетс€ простым в сет€х, часто оказываетс€ сложным. »зучение локального интерфейса может рассказать вам о канале, но не о других сетевых устройствах, подключенных к этому каналу.  роме того, даже если вы можете обнаружить другое сетевое устройство, работающее с той же плоскостью управлени€ по определенному каналу, это не означает, что другое устройство может вас обнаружить. “аким образом, необходимо изучить несколько вопросов.


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

≈сли маршрутизаторы A, B и C подключены к одному каналу, как показано на рисунке 5, какие механизмы они могут использовать дл€ обнаружени€ друг друга, а также дл€ обмена информацией о своих возможност€х?

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

ќбнаружение соседей сетевого устройства в плоскости управлени€

–учна€ настройка - одно из широко распространенных решений этой проблемы. ¬ частности, в плоскост€х управлени€, предназначенных дл€ перекрыти€ другой плоскости управлени€, или плоскост€х управлени€, предназначенных дл€ построени€ отношений соседства через несколько маршрутизируемых переходов по сети, ручна€ настройка часто €вл€етс€ самым простым доступным механизмом. — точки зрени€ сложности, ручна€ настройка очень мало добавл€ет к самому протоколу. Ќапример, нет необходимости в какой-либо форме многоадресного объ€влени€ соседей. — другой стороны, ручна€ настройка соседей требует настройки информации о сосед€х, что увеличивает сложность с точки зрени€ конфигурации. ¬ сети, показанной на рисунке 5, маршрутизатор A должен иметь отношени€ соседства, настроенные с помощью B и C, маршрутизатор B должен иметь отношени€ соседства, настроенные с помощью A и C, а маршрутизатор C должен иметь отношени€ соседства, настроенные с помощью A и B. ƒаже если настройка соседей автоматизирована, ручна€ настройка углубл€ет и расшир€ет поверхности взаимодействи€ между плоскост€ми управлени€ и контрол€.

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

ѕри выводе соседей из объ€влений о маршрутизации важно иметь возможность определить, когда сосед вышел из стро€ (чтобы информаци€ о достижимости и топологии, полученна€ от соседа, могла быть удалена из любых локальных таблиц). Ќаиболее распространенный способ решени€ этой проблемы - использование пары таймеров: таймера задержки или отключени€ и таймера обновлени€ или объ€влени€. ѕока сосед отправл€ет обновление или объ€вление в пределах таймера отключени€ или задержки, он считаетс€ включенным или активным. ≈сли весь "мертвый" период проходит без получени€ каких-либо обновлений, сосед считаетс€ "мертвым", и предпринимаютс€ некоторые действи€, чтобы либо проверить информацию о топологии и доступности, полученную от соседа, либо он просто удал€етс€ из таблицы.

Ќормальна€ взаимосв€зь между таймером отключени€ и таймером обновлени€ составл€ет 3× - таймер отключени€ установлен на трехкратное значение таймера обновлени€. —ледовательно, если сосед не отправл€ет три подр€д обновлени€ или объ€влени€, таймер бездействи€ активируетс€ и начинает обработку неработающего соседа.

явные приветстви€ €вл€ютс€ наиболее распространенным механизмом обнаружени€ соседей. ѕакеты приветстви€ передаютс€ на основе таймера приветстви€, и сосед считаетс€ "мертвым", если приветствие не получено в течение интервала таймера ожидани€ или объ€влени€. Ёто похоже на таймеры dead и update, используемые дл€ вывода соседей из объ€влений маршрутизации. ѕриветстви€ обычно содержат информацию о соседней системе, такую как поддерживаемые возможности, идентификаторы уровн€ устройства и т. д.

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


ќбнаружение двусторонней св€зи

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

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

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

Ќа рисунке 6 предположим, что маршрутизатор A включен раньше B. ¬ этом случае:

  • A отправит приветстви€ с пустым списком соседей, поскольку он не получил приветстви€ от любого другого сетевого устройства по каналу.
  •  огда B включен, он получит приветствие A и, следовательно, включит A в список соседей, которые он слышал в своих hello пакетах.
  •  огда A получает приветствие B, он, в свою очередь, включает B в свой список "услышанных" соседей в своих пакетах приветстви€.
  •  огда и A, и B сообщают друг о друге в своих списках соседей, которые "слышно от", оба маршрутизатора могут быть уверены, что двустороннее соединение установлено.

Ётот процесс часто называют трехсторонним рукопожатием, состо€щим из трех шагов:

  • A должен послать привет B, чтобы B мог включить A в свой список соседей.
  • B должен получить приветствие A и включить A в свой список соседей.
  • A должен получить приветствие B с самим собой (A) в списке соседей B.

ѕоложитесь на базовый транспортный протокол. Ќаконец, плоскости управлени€ могут полагатьс€ на базовый транспортный механизм дл€ обеспечени€ двусторонней св€зи. Ёто необычное решение, но есть некоторые широко распространенные решени€. Ќапример, протокол Border Gateway Protocol (BGP), опираетс€ на протокол управлени€ передачей (TCP), чтобы обеспечить двустороннюю св€зь между спикерами BGP.

ƒвустороннее рукопожатие дл€ проверки двусторонней св€зи плоскости управлени€

ќпределение максимального размера передаваемого блока (MTU)

ƒл€ плоскости управлени€ часто бывает полезно выйти за рамки простой проверки двусторонней св€зи. ћногие плоскости управлени€ также провер€ют, чтобы максимальный размер передаваемого блока (MTU) на обоих интерфейсах канала был настроен с одинаковым значением MTU. Ќа рисунке 7 показана проблема, решаема€ с помощью проверки MTU на уровне канала в плоскости управлени€.

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

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

¬ли€ние несоответстви€ MTU на плоскость управлени€

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

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

—ам размер MTU может оказать большое вли€ние на производительность плоскости управлени€ с точки зрени€ ее скорости сходимости. Ќапример, предположим, что протокол должен передавать информацию, описывающую 500 000 пунктов назначени€ по многопоточному каналу с задержкой 500 мс, и дл€ описани€ каждого пункта назначени€ требуетс€ 512 бит:

  • ≈сли MTU меньше 1000 бит, дл€ плоскости управлени€ потребуетс€ 500 000 циклов туда и обратно дл€ обмена всей базой данных доступных пунктов назначени€, или около 500 000 × 500 мс, что составл€ет 250 000 секунд или около 70 часов.
  • ≈сли MTU составл€ет 1500 октетов или 12000 битов, плоскости управлени€ потребуетс€ около 21000 циклов туда и обратно дл€ описани€ всей базы данных доступных пунктов назначени€, или около 21000 × 500 мс, что составл€ет около 175 минут.

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

ƒалее почитайте материал о том, как происходит обнаружение соседей в сет€х.