FAQ

Зачем ты всё время делаешь ремарку GRE/UDP?

Ну, вообще, это, можно сказать, специфично для Tungsten Fabric - можно вообще не брать во-внимание.

Но если брать, то сам TF, ещё будучи OpenContrail’ом поддерживал обе инкапсуляции: MPLS in GRE и MPLS in UDP.

UDP хорош тем, что в Source Port в его заголовке очень легко закодировать хэш-функцию от изначальных IP+Proto+Port, что позволит делать балансировку.

В случае GRE, увы, есть только внешние заголовки IP и GRE, которые одинаковы для всего инкапсулированного трафика и речь о балансировке не идёт - мало кто может заглянуть так глубоко внутрь пакета.

До некоторого времени маршрутизаторы, если и умели в динамические туннели, то только в MPLSoGRE, и только совсем недавно, научились в MPLSoUDP. Поэтому приходится делать всегда ремарку о возможности двух разных инкапсуляций.

Справедливости ради, стоит отметить, что TF вполне поддерживает и L2-связность с помощью VXLAN.

Ты обещал провести параллели с OpenFlow.

Они и правда напрашиваются. vSwitch в том же OpenStack’е делает весьма похожие вещи, используя VXLAN, у которого, кстати, тоже UDP-заголовок.

В Data Plane они работают примерно одинаково, существенно различается Control Plane. Tungsten Fabric использует XMPP для доставки информации о маршрутах на vRouter, в то время, как в OpenStack’е работает Openflow.

А можно чуть больше про vRouter?

Он делится на две части: vRouter Agent и vRouter Forwarder.

Первый запускается в User Space хостовой ОС и общается с SDN-контроллером, обмениваясь информацией о маршрутах, VRF и ACL.

Второй реализует Data Plane - обычно в Kernel Space, но может запускаться и на SmartNIC’ах - сетевых картах с CPU и отдельным программируемым чипом коммутации, что позволяет снять нагрузку с CPU хостовой машины, а сеть сделать быстрее и более предсказуемой.

Ещё возможен сценарий, когда vRouter - это DPDK-приложение в User Space.

vRouter Agent спускает настройки на vRouter Forwarder.

Что за Virtual Network?

Я обмолвился в начале статьи о VRF, что мол каждый тенант привязывается к своему VRF. И если для поверхностного понимания работы оверлейной сети этого было достаточно, то уже на следующей итерации надо делать уточнения.

Обычно в механизмах виртуализации сущность Virtual Network (можно считать это именем собственным) вводится отдельно от клиентов/тенантов/виртуальных машин - вполне себе самостоятельная вещь. А этот Virtual Network через интерфейсы уже можно подключить в один тенант, в другой, в два, да хоть куда. Так, например, реализуется Service Chaining, когда трафик нужно пропустить через определённые ноды в нужной последовательности, просто в правильной последовательности создавая и привзявая Virtual Network’и.

Поэтому как такового прямого соответствия между Virtual Network и тенантом нет.