Network: SDN (Cisco ACI, Cisco DNA, VXLAN)

SDN – Software Defined Networking

  • На 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 во многом является ответом на следующие вопросы:

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

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

Концепция sdn очень широка и разные решения зачастую нацелены на разные вещи. Примеры 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.

Контроллеры имеют обычно два 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
Cisco aci
CISCO Aci leaf/spine topology

overlay network – подразумевает туннелирование  пакетов поверх underlay network. Туннелирование может быть как l2 (чаще), так и l3.

В качестве туннелирующего протокола overlay сети может использоваться:

    • Vxlan – virtual extensible lan
    • NVGRE – network virtualization using generic routing encapsulation
    • STT – stateless transport tunneling
    • GENEVE – generic network virtualization encapsulation

underlay network – l3 сеть/фабрика:

    • разделяет (vrf/vxlan) l3 сети или маршрутизирует трафик между ними в разных broadcast domain
    • коммутирует пакеты внутри одного broadcast domain

Все leaf коммутаторы в топологии vxlan связаны со всеми spine коммутаторами. При этом одноранговые соединения leaf-leaf и spine-spine не делаются.

No direct connectivity is allowed between spine nodes or between leaf nodes.
    • Leaf (по сути это Top of the rack, ToR свичи) свичи отвечают за маршрутизацию и коммутацию tenant packets в vxlan VNID, применение сетевых политик к трафику. На leaf свичах поднимается vxlan в виде VTEP. Ip адрес, который представляет VTEP на leaf называется PTEP (physical tunnel endpoint).
Leaf switches are responsible for routing or bridging tenant packets and for applying network policies. The ip address that represents the leaf VTEP is called the physical tunnel enpdoint (PTEP).
    • Spine свичи связывают всю топологию – spine и leaf устройства, внешние сети или несколько aci инсталляций. Spine свичи сохраняют mapping endpoint (как понимаю связь MAC+VNI) – PTEP.
Spine nodes interconnect leaf devices, and they can also be used to establish connections from a cisco ACI pod to an ip network or to interconnect miltiple ACI pods.

 

OpenStack Neutron
Neutron от openstack – открытое решение, которое реализует SDN с микросегментацией. Neutron построен по принципу предоставлению сетевых ресурсов как сервиса в облачных структурах (частные, гибридные, открытые облака). Другие компоненты openstack, типо horizon (web ui), nova (compute service) взаимодействуют с neutron через api.
cisco 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
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 трафика между двумя хостами до заданного назначения для задач мониторинга/траблшутинга/безопасности.
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 проблематика
Большая часть трафика в существующих ДЦ – это east-west, а не north-south. Он не выходит за периметр сети и файрвол на периметре, а зачастую даже и физический сервер (трафик между VM или даже контейнерами на одном гипервизоре или виртуальной машине).
Многие вендоры создали файрволы, в которых политики применяются на приложения, а сами файрволы независимы от топологии сети, направления сетевого трафика (north-south, east-west).
К примеру, может быть потребность во взаимодействии между приложением в vm1 и vm3, между vm2 и vm3.
При этом взаимодействие между приложением vm2 и vm3 должно быть запрещено.

Запрещение же это должно быть реализовано масштабируемо – не в виде router on a stick к какому то центральному firewall. Нельзя так же использовать vlan, subnet т.к. по факту это ненадежные идентификаторы в масштабируемых топологиях с динамическим назначением vlan/subnet.
Сильным усложнением являются контейнеры, которые нуждаются в аналогичных сервисах микросегментации в рамках одной хостовой машины.
microsegmentation
Традиционная сегментация с 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