Cloud Interconnect должен провести трафик из корпоративной сети или другого облака в MWS по выделенному пути, не используя публичный интернет. За внешне простой услугой скрывается переход между несколькими сетевыми технологиями: LAG и QinQ на сетевом уровне, BGP на границе, VRF и VPP в data plane, IPv6/SRv6 внутри облака.
В докладе разберём этот путь c точки зрения пограничного устройства. На нём будут терминироваться bgp-сессии от клиентов, а обмен трафиком осуществляться через набор QinQ-интерфейсов. QinQ здесь позволяет разделить магистраль и клиентские подключения. В качестве bgp спикера используется кастомный сервис на базе gobgp, обеспечивающий bgp c внешними клиентами и с underlay маршрутизаторами, обращаясь к ним через множество VRF.
Отдельно покажем путь управления маршрутом: GoBGP best path, поток событий, локальный multipath RIB и отдельный BGP source в VPP FIB, чтобы не смешивать разные по природе маршруты.
И всё это должно динамически конфигурироваться, согласно спецификации, зафиксированной в control plane: QinQ\VRF — создаваться и удаляться, bgp-сессии — строиться с правильными пирами, анонсы — отправляться, обогащаться и удаляться, а маршруты — добавляться в правильные VRF.
На тестах схема показала около 119 Гбит/с RX, 115 Гбит/с TX и 10,2 Mpps при построении Interconnect между MWS-VMWARE и MWS-P.
Backend-разработчик
Средний
Ведущий разработчик в MWS Сеть и сетевые сервисы.
Строит вирутальную сеть облака, в частности сетевые шлюзы: NAT, доступ в интернет и on-prem. Раньше работал в TradingView, занимался автоматизацией сбора и агрегации финансовых отчётов публичных компаний.