Network: SDN (Cisco ACI, Cisco DNA, VXLAN, Open/Juniper Contrail)

SDN – Software Defined Networking

Ни для кого не секрет, что оверлейная сеть, обеспечивающая мультитенантностьYandex.Cloud, реализована на OpenContrail (ныне Tungsten Fabric). Он, в свою очередь, требует IPv4-связно

https://tungsten.io
Thank you for your interest in Tungsten Fabric. The community has decided to shut down the project and will sunset this website on August 1, 2024.
  • На 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 was originally created to decouple control from the forwarding functions in networking equipment.

SDN во многом является ответом на следующие вопросы:

  1. Все больше приложений/бизнес требуют все более быстрый (деплой и работу), качественный (ошибки конфигурации) и безопасный сетевой сервис (консистентность конфигурации)
  2. Сетевые сервисы меняются: добавляются новые протоколы и функции, сеть переносится из datacenters в облака и проч; все это нужно поддерживать с учетом первого пункта
Networking functions such as routing, optimization, and security have changed.

Примеры SDN контроллеров.

Концепция sdn очень широка и разные решения зачастую нацелены на разные вещи. Примеры SDN решений:

      • 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.
- 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).
Northbound APIs (SDN northbound APIs) are typically restful APIs that are used to communicate between the SDN controller and the services and applications running over the network. Applications can tell the network devices (physical or virtual) what type of resources they need and, in turn, the SDN solution can provide the necessary resources to the application. Intent based networking and intent-based API.

  • Southbound api (openflow, cisco opflex) – для управления устройствами, подключенными к контроллеру. Обычно этими устройствами являются устройства того же вендора, что и контроллер.
Southbound APIs are used to communicate between the SDN controller and the switches and routers within the infrastructure.
Southbound APIs enable SDN controllers to dynamically make changes based on real-time demands and scalability needs. OpenFlow and Cisco Opflex provide southbound API capabilities.
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
- Vxlan uses an identifier or a tag that represents a logical segment that is called the VXLAN Network Identifier (VNID).
- The logical segment identified with the VNID is a layer 2 broadcast domain that is tunneled over the VTEP tunnels.
- The use of UDP in VXLAN enables routers to apply hashing algorithms on the outer UDP header to load balance network traffic. Network traffic that is riding the overlay network tunnels is load balanced over multiple links using equal-cost multi-path routing (ECMP).
- In traditional network designs, access switches connect to distribution switches. This causes redundant links to block due to spanning tree.

 

OpenStack Neutron
Neutron от openstack – открытое решение, которое реализует SDN с микросегментацией. Neutron построен по принципу предоставлению сетевых ресурсов как сервиса в облачных структурах (частные, гибридные, открытые облака). Другие компоненты openstack, типо horizon (web ui), nova (compute service) взаимодействуют с neutron через api.
По сути в Neutron три основных комнонента:
  1. Neutron server
  2. Neutron database
  3. Neutron plugins – neutron использует плагины и драйверы для реализации сетевого функционала – напр. neutron team ML2 – OVS/LB, Broacade Vyatta, Cisco NXOS/APIC/N1Kv/CSR1kv.

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
APIC manages the distributed policy repository responsible for the definition and deployment of the policy-based configuration of the Cisco ACI infrastructure.
- APIC also manages the topology and inventory information of all devices within the ACI pod.
- Monitoring the subsytem of the APIC. The APIC “observer” function monitors the health, state and performance information of the Cisco ACI pod.
- The “boot director” function is in charge of the booting process and firmware updates of the spine switches, leaf switches and the APIC components.
- The “appliance director” APIC function manages the formation and control of the APIC appliance cluster.
- The “virtual machine manager (VMM)” is an agent between the policy repository and a hypervisor. The VMM interacts with hypervisor management systems (for example, VMware vCenter).
- The “appliance element” maintains the inventory and start of the local APIC appliance.
Cisco DNA
Cisco DNA – digital network architecture.  DNA рассматривается как intent-based networking. DNA предоставляет сервисы автоматизации политик, валидации, аналитики в кампусных/branch/wan сетях. Решение основано на открытой и масштабируемой платформе.
DNA Controller (DNAС) – является  ядром решения DNA, которое обеспечивает централизованное управление.
Политики 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 трафика между двумя хостами до заданного назначения для задач мониторинга/траблшутинга/безопасности.
When you configure group-based access control policies you need to integrate the Cisco ISE with Cisco DNA Center. In Cisco ISE you configure the work process setting as “Single Matrix” so that there is only one policy matrix for all devices in the TrustSec network.






Depending on your organization’s environment and access requirements, you can segregate your groups into different virtual networks to provide further segmentation.

After Cisco ISE is integrated in Cisco DNA Center, the scalable groups that exist in Cisco ISE are propagated to Cisco DNA Center. If a scalable group that you need does not exist, you can create it in Cisco ISE.

You can also use an Encapsulated Remote Switched Port Analyzer (ERSPAN) configuration in Cisco DNA Center so that the IP traffic flow between two entities is copied o a given destination for monitoring or troubleshooting.


  
 

Assurance/monitoring сервисы позволяют настраивать сенсоры для мониторинга здоровья компонентов, например, беспроводных сетей (конфигурация AP, WLAN).
Сенсоры WLAN бывают двух видов:
  • Выделенные – 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.
Northbound rest API в DNA очень прокаченный, называют его intent-based API. Называют его так потому, что за политиками скрываются (policy based abstraction of business intent) конкретные бизнес задачи. А централизованная настройка через api дает тебе консистентность, которая, в свою очередь, ведет к лучшей безопасности.
Безопасность SDN, SDN SECURITY
SDN Firewall MICROSEGMENTATION, MACHINE TO MACHINE

Большая часть трафика в существующих ДЦ – это east-west, а не north-south. Он не выходит за периметр сети и файрвол на периметре, а зачастую даже и физический сервер (трафик между VM или даже контейнерами на одном гипервизоре или виртуальной машине).
Многие вендоры создали файрволы, в которых политики применяются на приложения, а сами файрволы независимы от топологии сети, направления сетевого трафика (north-south, east-west).
К примеру, может быть потребность во взаимодействии между приложением в vm1 и vm3, между vm2 и vm3.
При этом взаимодействие между приложением vm2 и vm3 должно быть запрещено.
Запрещение же это должно быть реализовано масштабируемо – не в виде router on a stick к какому то центральному firewall. Решениями прошлого считаются выделенные файрволы между VM/контейнерами.
Нельзя так же использовать vlan, subnet т.к. по факту это ненадежные идентификаторы в масштабируемых топологиях с динамическим назначением vlan/subnet.
Сильным усложнением являются контейнеры, которые нуждаются в аналогичных сервисах микросегментации в рамках одной хостовой машины.

Традиционная сегментация с 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”).
В виртуальной среде проблема стала острой – сейчас приложения могут мигрировать между серверами в разных ДЦ.
Микросегментация может быть как на уровне vm, так и на уровне контейнеров. Микросегментация должен быть завязана (начинаться и заканчиваться приложением) на приложение, а не сетевые индикаторы (network, vlan id).
Micro-segmentation must be "application-aware".
Так же в контексте микросегментации часто применяется концепция zero trust – не доверяем ничему и не разрешаем ничего (доступ к ресурсам, работу юзера с приложением, работу приложения с приложением), пока
  • мы не поймем, с кем имеем дело
  • мы, пока нет явного правила, разрешающего взаимодействие

И даже после разрешения мы постоянно проверяем трафик/поведение/состояние объектов, чтобы определить, что “доверие не потеряно”.

Примеры атак на SDN и методы защиты от них
Примеры угроз SDN:
  1. установка «левого» контроллера (malicious controller) для управления sdn устройствами и сервисами
  2. Man in the middle атаки между SDN контроллером и SDN устройствами для снифинга/изменения/подмены инструкций, отправляемых контроллером
  3. Атаки на доступность SDN контроллера (DoS, DDoS)
Способы защиты от подобных атак (все реализовано в Cisco DNA):
  1. Контроллер должен находиться в безопасном месте с контролем доступа (СКУД)
  2. Путь данных и управления должен быть разнесен (out of band management)
  3. Безопасность при использовании API
  4. Безопасность взаимодействия контроллера и устройств, которыми он управляет (в том числе API security)
  5. Patch management
  6. Использование шифрования

Leave a Reply