SDN – Software Defined Networking
Ни для кого не секрет, что оверлейная сеть, обеспечивающая мультитенантностьYandex.Cloud, реализована на OpenContrail (ныне Tungsten Fabric). Он, в свою очередь, требует IPv4-связно
- На Cisco devnet сайте можно поизучать устройство и примеры работы с API разных продуктов Cisco и даже поделать различные лабы (пример с Cisco DNA)!
- Хорошо скоординированный static = SDN
- Концепция SDN подразумевает:
-
- в первую очередь разделение control/management plane (vm/hardware controller/etc) и data plane (bare-metal/vm) на разные устройства
- отказ обработки трафика box-by-box в пользу создания SDN фабрики – каждая “коробка” теперь сама не решает, как обрабатывать трафик
- перенос control/management plane на централизованный контроллер управления сетью
- потенциально лучшая безопасность:
- микросегментация на уровне VM или даже контейнеров
- легче поддерживать консистентность политик
- проще организовать полную видимость сети
- управление решением через API
- легко – централизованно, удобно (без cli) и масштабируемо
-
SDN во многом является ответом на следующие вопросы:
- Все больше приложений/бизнес требуют все более быстрый (деплой и работу), качественный (ошибки конфигурации) и безопасный сетевой сервис (консистентность конфигурации)
- Сетевые сервисы меняются: добавляются новые протоколы и функции, сеть переносится из datacenters в облака и проч; все это нужно поддерживать с учетом первого пункта
Networking functions such as routing, optimization, and security have changed.
Примеры SDN контроллеров.
-
-
-
Cisco ACI – aci использует leaf/spine topology и протокол vxlan. Подробнее.
-
-
-
-
-
Cisco DNA (скрин DNA). Подробнее ниже.
-
-
Contiv is a powerful, 100% open source networking solution for modern compute workloads. Integration and support for VM’s and Bare Metal allow you to provide a single network fabric across your infrastructure.
-
-
- Open vSwitch (OvS) и Open Virtual Network (OVN)
-
OVS это open source реализация multilayer виртуального коммутатора внутри гипервизора. Можно скачать open vswitch оффициального сайта openvswitch.org и играться с ним на основе документации на этом же сайта
-
OVN был изначально создан людьми из OVS для решения задачи создания open source решения для виртуальных сетей и SDN.
-
- Open vSwitch (OvS) и Open Virtual Network (OVN)
-
- OVN was originally created by the folks behind OVS for the purpose of bringing an open source solution for virtual network environments and SDN. - Open vSwitch is an open source implementation of a multilayer virtual switch inside the hypervisor.

- Opendaylight (ODL) – популярный SDN проект, который фокусируется на улучшении SDN контроллеров для предоставления сетевых сервисов используя оборудование различных вендоров. Подробнее можно почитать как на сайте opendaylight.org, так и на Cisco devnet.
Контроллеры имеют обычно два api интерфейса:
- Northbound/intent based api – для интеграции с внешними системами и приложениями. Обычно это другой вендор, а не вендор, реализующий контроллер. Например – приложение запрашивает ресурсы у контроллера sdn через northbound api, а контроллер обеспечивает их. Это называется intent-based networking или intent-based api. Подробнее об этом ниже в Cisco DNA (business intent).
- Southbound api (openflow, cisco opflex) – для управления устройствами, подключенными к контроллеру. Обычно этими устройствами являются устройства того же вендора, что и контроллер.
vxlan
- Vxlan – virtual extensible lan
- Vxlan обычно (если не настроить другое) работает на udp порту 4789
- Vxlan использует идентификатор локального L2 сегмента в виде VXLAN network identifier (VNI/VNID)
- Логический сегмент, идентифицируемый с VNID является бродкаст доменом, который туннелируется поверх vxlan tunnel endpoint (VTEP) туннелей.
- Использование udp в vxlan позволяет роутерам применять операцию хеширования на внешний udp заголовок (т.е. на заголовок добавленный vxlan) для балансировки сетевого трафика по ECMP. В итоге:
-
- сетевой трафик, передаваемый по overlay network туннелям балансируется на множество линков с использованием ECMP
- есть возможность сделать балансировку (выше) и отказоустойчивость на l3 для l2 трафика, с явными преимуществами в сравнении с l2 решениями по типу stp и erps
-
OpenStack Neutron
cisco aci
Cisco ACI (Application Centric Infrastructure) – позволяет организациям автоматически назначить endpoints к логическим security zones которые называют endpoint groups (EPG). EPG используются для группировки VM внутри tenant и применения политик/фильтров передачи (forwarding policies) к ним. Эти EPG основаны на разных network based и vm based атрибутах.
Cisco ACI имеет одну из лучших реализацией microsegmentation. Microsegmentation в cisco ACI может быть реализована с помощью интеграции с vCenter, microsoft system center VMM (virtual machine manager).
Микросегментация в ACI так же зачастую называется uSeg EPG. Можно объдинить endpoints и существующие application EPG в новый microsegment uSeg EPG. Далее сконфигурировать network/VM based атрибуты для данного uSeg EPG. К данному uSeg EPG можно применить динамические политики. Так же можно применить политики к любому endpoint внутри tenant. Например, вам нужно назначить WEB сервер в EPG и затем применить похожие настройки. По умолчанию все endpoint внутри EPG могу взаимодействовать с друг другом, но если вам нужно – вы можете это ограничить (напр. EPG состоит из production & development серверов) . Для реализации этого ограничения нужно создать новый EPG и назначить к нему endpoints на основе атрибута имени VM (prod*, dev*).
Применение атрибутов к uSeg EPG позволяет вам применить forwarding/security политики с большей гранулярностью чем при использовании EPG без атрибутов. Атрибуты уникальны внутри tenant. Вы можете применить uSeg EPG используя два типа атрибутов
-
- сетевые атрибуты (IP, IP/MAC address filter). Одному uSeg EPG можно сопоставить один или несколько MAC/IP адресов.
- атрибуты VM. Одному uSeg EPG можно сопоставить несколько VM based атрибутов (тип ОС, VMM, domain, hypervisor ID, datacenter, VM ID, VM name, vnic domain name, custom attributes/TAGs).
aci APIC
APIC контроллер – мозги всей SDN фабрики ACI, отвечает за деплой политик/конфигурации фабрики Cisco ACI. APIC так же:
-
- управляет топологией ACI pod (ACI fabric nodes)
- владеет инвентарной информацией всех устройств ACI pod
- осуществляет мониторинг всего ACI pod
- осуществляет обновление ПО всех элементов ACI pod (leaf, spine, apic)
- управление кластером из нескольких APIC
- взаимодействует с hypervisor (напр. VMware vCenter), напр. для идентификации endpoint в виде VM
- управляет и сохраняет все события ACI pod
- сохраняет информацию о самом APIC – inventory, state
Cisco DNA
- Group base ACL (GBAC, group based access control) – для их работы требуется интеграция cisco DNA с cisco ISE с конфигурацией Single Matrix. Созданные группы на ISE в итоге передаются на DNA и могут использоваться им для конфигураций. Для большей сегментации в крупных инсталляциях при необходимости (access requirements) можно разделить группы на несколько виртуальных сетей.
- IP base ACL – политики для сетевого трафика на основе адресов IP и направления (bi/uni-direction)
-
Access Contract – политики для сетевого трафика на основе протокола/порта
-
Application ACL – глубокая инспекция DPI и реализация QoS. Приложения можно забиндить в группы и к группам можно принимать политики. Приложения и группы можно привязывать к QoS traffic classes (RFC 4594).
-
Traffic copy ACL – в DNA center можно создать политику, которая реализует копирование ERSPAN потока IP трафика между двумя хостами до заданного назначения для задач мониторинга/траблшутинга/безопасности.
-
Выделенные – AP работает только как сенсор и не используется клиентами.
-
Сенсоры по требованию – AP временно превращается в сенсор для проведения тестов, после тестов AP выводится из режима сенсора.
A dedicated sensor is when an AP is converted into a sensor, and it stays in sensor mode (is not used by wireless clients) unless it is manually converted back into AP mode. An on-demand sensor is when an AP is temporarily converted into a sensor to run tests. After the tests are complete, the sensor goes back to AP mode.
Безопасность SDN, SDN SECURITY
SDN Firewall MICROSEGMENTATION, MACHINE TO MACHINE
Традиционная сегментация с vlan ограничена границами vlan в пределах дата центра или даже кампуса ((спорное утверждение – eoip, l2vpn, xconnect, vpls, l2tp v3 и проч. помогают пробрасывать vlan’ы в том или ином виде уже десятки лет)).
Traditional segmentation using VLANs introduces a lot of complexities. Application segmentation and policies were physically restricted to the boundaries of the VLAN within the same data center (or even in “the campus”).
Micro-segmentation must be "application-aware".
- мы не поймем, с кем имеем дело
- мы, пока нет явного правила, разрешающего взаимодействие
И даже после разрешения мы постоянно проверяем трафик/поведение/состояние объектов, чтобы определить, что “доверие не потеряно”.
Примеры атак на SDN и методы защиты от них
-
установка «левого» контроллера (malicious controller) для управления sdn устройствами и сервисами
-
Man in the middle атаки между SDN контроллером и SDN устройствами для снифинга/изменения/подмены инструкций, отправляемых контроллером
-
Атаки на доступность SDN контроллера (DoS, DDoS)
-
Контроллер должен находиться в безопасном месте с контролем доступа (СКУД)
-
Путь данных и управления должен быть разнесен (out of band management)
-
Безопасность при использовании API
-
Безопасность взаимодействия контроллера и устройств, которыми он управляет (в том числе API security)
-
Patch management
-
Использование шифрования