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

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

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

Ётот раздел лекций начнетс€ с обсуждени€ того, почему создаютс€ и используютс€ виртуальные топологии, проиллюстрированные двум€ примерами использовани€. ¬о втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. ƒалее будут рассмотрены два примера технологий виртуализации: сегментна€ маршрутизаци€ (segment routing-SR) и программно - определ€емые глобальные сети (Software-Defined Wide Area Networks- SD-WAN).


ѕонимание виртуальных сетей

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

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

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

Ќа рисунке 1 показана сеть с виртуальной топологией, расположенной поверх физической топологии.

Ќа рисунке 1 виртуальна€ топологи€ была создана поверх физической сети, с виртуальным каналом [C,H], созданным дл€ передачи трафика по сети. „тобы создать виртуальную топологию, C и H должны иметь некоторую локальную информацию пересылки, отдел€ющую физическую топологию от виртуальной топологии, котора€ обычно проходит либо через E, либо через D. Ёто обычно принимает форму либо специального набора записей виртуального интерфейса в локальной таблице маршрутизации, либо таблицы виртуальной маршрутизации и пересылки (VRF), содержащей только информацию о виртуальной топологии.

‘изическа€ и виртуальна€ топологии

–ассмотрение потока пакетов через виртуальную топологию может быть полезно дл€ понимани€ этих концепций.  ак бы выгл€дел поток пакетов, если бы C и H имели виртуальные интерфейсы? –исунок 2 демонстрирует это.

Ќа рисунке 2 процесс пересылки выполн€етс€ следующим образом:

  1. A передает пакет к M.
  2. C получает этот пакет и, исследу€ свою локальную таблицу маршрутизации, находит, что кратчайший путь к месту назначени€ лежит через виртуальный интерфейс к H. Ётот виртуальный интерфейс обычно называетс€ туннельным интерфейсом; он выгл€дит с точки зрени€ таблицы маршрутизации, как и любой другой интерфейс маршрутизатора.
  3. ¬иртуальный интерфейс, через который необходимо передать пакет, имеет инструкции перезаписи, которые включают добавление нового заголовка, заголовка туннел€ или внешнего заголовка в пакет и пересылку полученного пакета. »сходный заголовок пакета теперь называетс€ внутренним заголовком. C добавл€ет внешний заголовок и обрабатывает новый пакет дл€ пересылки.
  4. “еперь C исследует новый пункт назначени€, которым €вл€етс€ H (помните, что исходным пунктом назначени€ был M). H не подключен напр€мую, поэтому C необходимо вы€снить, как достичь H. Ёто называетс€ рекурсивным поиском, поскольку C ищет путь к промежуточному месту назначени€, чтобы доставить пакет к конечному месту назначени€, но не к нему.
  5. “еперь C поместит правильную информацию в пакет в заголовок link local, чтобы перенаправить трафик на E.
  6.  огда E получает этот пакет, он удал€ет внешнюю информацию о переадресации, «аголовок link local и пересылает трафик на основе первого заголовка C, помещенного в пакет, во врем€ первоначального поиска. Ётот внешний заголовок говорит E переслать пакет в H; E не видит и не включает исходный внутренний заголовок, помещенный на пакет A.
  7. E добавит новый «аголовок link local, чтобы пакет был правильно переадресован в H, и передаст пакет по правильному интерфейсу.
  8.  огда H получает пакет, он удал€ет «аголовок link local и обнаруживает внешний заголовок. ¬нешний заголовок говорит, что пакет предназначен дл€ самого H, поэтому он очистит этот заголовок и обнаружит исходный заголовок пакета или внутренний заголовок.
  9. “еперь H посмотрит в своей локальной таблице маршрутизации и обнаружит, что M локально подключен. H поместит правильный «аголовок link local в пакет и передаст его через правильный интерфейс, чтобы пакет достиг M.
ѕересылка пакета по виртуальному каналу

≈сли C и H используют VRF, а не туннельные интерфейсы, процесс в предыдущем списке измен€етс€ на шагах 2 и 8. Ќа шаге 2 C будет искать M как пункт назначени€ в VRF, св€занном каналом [A, C].  огда C обнаруживает, что трафик к M должен пересылатьс€ через виртуальную топологию через H, он помещает внешний заголовок в пакет и снова обрабатывает пакет на основе этого внешнего заголовка через базовый VRF или, скорее, таблицу маршрутизации, представл€ющую физическую топологию.  огда H получает пакет, он удал€ет внешний заголовок и снова обрабатывает пакет, использу€ VRF, к которому подключен M, дл€ поиска информации, необходимой дл€ пересылки трафика в его конечный пункт назначени€. ¬ этом случае интерфейс туннел€ замен€етс€ отдельной таблицей пересылки; вместо того, чтобы обрабатывать пакет через одну и ту же таблицу дважды с использованием двух разных адресатов, пакет обрабатываетс€ через две разные таблицы пересылки.

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

  • ¬нутренний заголовок находитс€ на том же уровне или более низком уровне, чем внешний заголовок (например, заголовок Ethernet, переносимый внутри заголовка IPv6; обычно IPv6 переноситс€ внутри Ethernet).
  • ѕо крайней мере, некоторые сетевые устройства на пути, будь то виртуальные или физические, пересылают пакет только на основе внешнего заголовка.

ѕереход от виртуальных интерфейсов к VRFs концептуально отличаетс€ достаточно, чтобы породить различные описательные термины. Underlay -это физическа€ (или потенциально логическа€!) топологи€, через которую туннелируетс€ трафик. Overlay - это набор туннелей, составл€ющих виртуальную топологию. ¬ большинстве случаев термины Underlay и Overlay не используютс€ с отдельными туннел€ми или в случае службы, работающей через общедоступный »нтернет. —ервис, который создает виртуальную топологию через общедоступный »нтернет, часто называют сервисом over-the-top.

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


ѕредоставление услуг Ethernet по IP-сети.

’от€ приложени€ не должны создаватьс€ с использованием подключени€ Ethernet в качестве базового, многие из них это делают. Ќапример:

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

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

”читыва€ сеть, основанную на IP, котора€ предполагает Ethernet как один из многих транспортных средств, поверх которых будет работать IP, как вы можете обеспечить подключение Ethernet к устройствам, св€занным по IP-сети? Ќа рисунке 3 показаны задачи, которые необходимо решить.

Ќа рисунке 3 процесс, работающий на A с IP-адресом 2001:db8:3e8:100::1, должен иметь возможность взаимодействовать со службой, работающей на B с IP-адресом 2001:db8:3e8:100::2, как если бы они находились в одном сегменте Ethernet (две службы должны видеть друг друга в обнаружении соседей и т. д.). „тобы сделать проблему более сложной, служба на A также должна иметь возможность перемещатьс€ в K без изменени€ своего локального кэша обнаружени€ соседей или маршрутизатора по умолчанию. —ама сеть, €вл€етс€ маршрутизируемой сетью, работающей под управлением IPv6.

ѕример проблемы с Ethernet посредством IP

„то необходимо дл€ выполнени€ требований?

ƒолжен быть способ передачи кадров Ethernet по IP-сети, раздел€ющей серверы. ќбычно это будет своего рода туннельна€ инкапсул€ци€, как описано в начале этого раздела. “уннелирование позволило бы принимать кадры Ethernet на C, например, инкапсулированные в какой-то внешний заголовок, чтобы их можно было транспортировать по маршрутизируемой сети.  огда пакет, содержащий кадр Ethernet, достигает D, этот внешний заголовок может быть удален, и кадр Ethernet пересылаетс€ локально. — точки зрени€ D, фрейм имеет локальное происхождение.

ƒолжен быть способ узнать о пунктах назначени€, доступных через туннель, и привлечь трафик в туннель. Ќа самом деле это две отдельные, но взаимосв€занные проблемы. ѕривлечение трафика в туннель может включать запуск второй плоскости управлени€ с ее собственными VRFs или добавление дополнительной информации в существующую плоскость управлени€ об адресах Ethernet Media Access Control (MAC), доступных на каждом пограничном маршрутизаторе.

ћожет потребоватьс€ перенести маркировку качества обслуживани€ (QoS) из внутреннего заголовка во внешний заголовок, чтобы трафик обрабатывалс€ правильно при его пересылке.

¬иртуальный частный доступ к корпоративной сети.

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

¬иртуальные частные сети в публичной сети

¬ этом варианте использовани€ есть две основные проблемы:

  •  ак можно защитить трафик между отдельным хостом - B - и трем€ хостами в небольшом офисе - C, D и E - от перехвата и чтени€ злоумышленником?  ак можно защитить сами адреса назначени€ от попадани€ в публичную сеть? Ёти проблемы св€заны с некоторой защитой, котора€, в свою очередь, подразумевает некоторую форму инкапсул€ции пакетов.
  •  ак можно управл€ть качеством работы пользователей в этих удаленных местах дл€ поддержки передачи голоса по IP и других приложений в реальном времени? ѕоскольку провайдеры в »нтернете не поддерживают QoS, необходимо обеспечить другие формы гарантии качества.

“аким образом, задача, которую необходимо решить, включает еще две общие проблемы.

  • ƒолжен быть способ инкапсулировать трафик, передаваемый по общедоступной сети, без раскрыти€ исходной информации заголовка и без подвергани€ информации, содержащейс€ в пакете, дл€ проверки. —амым простым решением этих проблем €вл€етс€ туннелирование (часто в зашифрованном туннеле) трафика от A и F к граничному маршрутизатору в сети организации G, где инкапсул€ци€ может быть удалена, а пакеты перенаправлены на A.
  • ƒолжен быть способ объ€вить достижимые пункты назначени€ от G к удаленным пользовател€м, а также существование (или достижимость) удаленных пользователей к G и сети позади G. Ёта информаци€ о достижимости должна использоватьс€ дл€ привлечени€ трафика в туннели. ¬ этом случае плоскости управлени€ может потребоватьс€ перенаправить трафик между различными точками входа и выхода в общедоступную сеть и попытатьс€ контролировать путь трафика через сеть, чтобы обеспечить удаленным пользовател€м хорошее качество работы.

ѕодведем итоги

ƒва варианта использовани€, показанные выше, актуализируют два вопроса, которые должно решить каждое решение сетевой виртуализации:

 ак трафик инкапсулируетс€ в туннель, чтобы можно было отделить пакеты и информацию плоскости управлени€ от базовой сети?

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


ѕримечание

Path MTU Detection (PMTUD) часто плохо определ€ет MTU инкапсулированных пакетов. »з-за этого часто требуетс€ ручна€ настройка MTU в точке наложени€ заголовка туннел€.

 ак пункты назначени€ достигаютс€ через туннель, объ€вленный через сеть?

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

¬ решени€х с overlay и over-the-top развертываетс€ отдельна€ плоскость управлени€ (или передаетс€ отдельна€ база данных с информацией о доступности дл€ адресатов, достижимых в underlay и overlay в единой плоскости управлени€). ѕункты назначени€, доступные через underlay и overlay, помещаютс€ в отдельные таблицы маршрутизации (VRF) на головной станции туннел€, а таблица, используема€ дл€ пересылки трафика, основана на некоторой форме системы классификации. Ќапример, все пакеты, полученные на конкретном интерфейсе, могут быть автоматически помещены в оверлейный туннель, или все пакеты с определенным классом обслуживани€, установленным в их заголовках пакетов, или весь трафик, предназначенный дл€ определенного набора пунктов назначени€. ћеханизмы полного наложени€ и верхней виртуализации обычно не полагаютс€ на метрики дл€ привлечени€ трафика в туннель на головной станции.

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