Программная маршрутизация: история переезда с hub-n-spoke (vyatta+openvpn) на fullmesh (mikrotik+tincvpn) — часть 1


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


    Предистория вопроса


    Несколько лет назад, когда трава была зеленее, а %company_name% только начинала свою делятельность и имела 2 филиала,
    было принято решение использовать изпользовать Vyatta Network OS в качестве единой платформы маршрутизации, а статические openvpn site-to-site тоннели — в качестве решения для VPN.

    Одной из причиной такого решения была богатая возможность кастомизации ISR.
    В качестве одной из мер по резервированию в каждый филал устанавливалось по 2 маршрутизатора.
    «звездатая» топология при таком количестве пиров считалась оправданной.

    В качестве hardware appliance предполагалось использовать
    — полноценные сервера с esxi — для крупных инсталляций
    — сервера с atom — для мелких.

    ВНЕЗАПНО, за год количество филиалов увеличилось до 10, а еще за полтора — до 28.
    Постоянный поток фирчеквестов от бизнеса провоцировал рост трафика и появление новых сетевых и application сервисов.
    Некоторые из них оседали на виртуалках linux-маршрутизаторов, вместо отдельных серверов.

    Функционала vyatta стало не хватать, большое количество пакетов сказывалось на общей стабильности и производительности сервисов.

    Также, был ряд проблем с VPN.
    1. На тот момент было около 100 статических тоннелей, терминировавихся в одну точку.
    2. В перспективе было еще открытие 10 филиалов.

    К тому же, openvpn в текущей реализации,
    1. не позволяет создавать динамически генерируемые site-to-site тоннели.
    2. не является многопоточным, что на процессорах маршрутизаторов с 1-2 аплинковыми тоннелями приводит к перегрузке 1-2 ядер (из 8-16 в нашем случае) шифрованием и приводит к веселым последствиям для трафика внутри тоннеля.
    3. П.2 особенно характерен для маршрутизаторов, в процессорах которых отсутствовала поддержка AES-NI.

    Можно было использовать gre+ipsec, что сняло бы проблемы с производительностью — но остались бы тоннели, сотни их.

    Было очень грустно, хотелось обложиться теплыми цисками с аппаратным шифрованием и употребить dmvpn.
    Или уже глобальный MPLS VPN.
    Чтобы не мелочиться.

    Надо было что-то делать (с)

    — в филиалы стали 1-2х процессорные сервера с вкусным количеством мозга и esxi на борту
    — маршрутизаторы были разуплотнены и все сторонние сервисы переехали на выделенные виртуальные машины с pure linux
    — после некоторых поисков в качестве платформы маршрутизации была выбрана виртулизированная x86 routeros.
    Опыт эксплуатации микротика к тому времени уже был, проблем с производительностью и стабильности на наших задачах под x86 не было.
    На железных решениях, особенно — на RB7** и RB2011**- было и есть веселее

    Потенциально, такое решение давало прирост функционала в области
    — route redistribution
    — pbr + vrf
    — mpls
    — pim
    — qos
    а также некорторых других.

    Проблема была в том, что routeros (как и vyatta) не поддерживает многоточечные vpn.
    Опять стало грустно, начали копать в сторону чисто линуксовых fullmesh-решений.

    Отдельное, кстати, спасибо хабраюзеру ValdikSS за его статью.

    Были рассмотрены: peervpn,tinc, campagnol, GVPE, Neorouter, OpenNHRP, Cloudvpn, N2N
    В итоге остановились на tincvpn, как на компромиссном решении.
    Еще очень понравился gvpe экзотическими методами инкапсуляции, но он не позволял указать несколько IP (от разных ISP) для remote peer.

    Что обидно, tinc был тоже однопоточным.
    В качестве решения был использован грязный хак:
    1. между каждыми двумя членами mesh поднимается не по 1, а по N тоннелей, объединяемых потом в bond-интерфейс с балансировкой исходящего трафика.

    2. в результате, получаем уже N процессов, которые уже можно распределить между разными ядрами.

    При использовании указанной схемы, в лабе с
    — 8 tinc-интерфейсами, агреггироваными в один bond по указанной схеме
    — принудительной привязкой процессов к разным ядрам
    — 1 x xeon 54**, 55** (процессоры старого поколения без поддержки aes-ni)
    — aes128/sha1,
    — udp в качестве транспортного протокола.
    — без использования qos как изнутри так и снаружи тоннеля.

    Производительность vpn составляла около 550-600 mbps на гигабитном канале.
    Мы были спасены.

    Что получилось:
    1. Итоговое решение получило рабочее название «vpn-пара».
    2. Состоит из двух виртуальных машин, расположенных на одном esxi-хосте и объединенных виртуальным интерфейсом.
    1 — routeros, который занимается исключительно вопросами маршрутизации
    2 — pure linux с вылизаным и слегка допилиенным tinc.
    Выполняет роль vpn-моста.
    Конфигурация tinc — аналогично лабораторной, при этом bond-интерфейс сбриджен с виртуальным линком на микротик.
    В результате, у всех маршрутизаторов общий L2, можно поднимать ospf и наслаждаться.
    3. В каждом филиале по 2 vpn-пары.

    ...to be continued...

    Примечания


    1. В принципе, интегрировать tinc можно и в vyatta, по этому поводу даже был написан патч (для варианта с 1 интерфейсом)
    Но прогнозировать поведение такой связки в аварийной ситуации (или после обновления платформы) с кастомным патчем до конца сложно и для большой сети такие эксперименты нежелательны.

    2. Рассматривался также вариант «матрешка».
    Он имел 2 направления:
    — покупка аппаратного x86 микротика и поддержка linux-vm с vpn-мостом средствами встроенной виртуализации (KVM).
    не взлетело из-за низкой производительности.

    — nested virtualization (esxi -> routeros -> kvm -> linux).
    не взлетело по тем же причинам, из за отсутствия поддержки эмуляции VT-X/EPT в esxi 5.1 (нужно для запуска kvm-машины).
    Поделиться публикацией

    Комментарии 14

      0
      О, хотеть, хотеть альтернативу DM-VPN. Почитаю с удовольствием продолжение.
        0
        продолжениие будет.

        что касается альтернатив — их есть практически на любой вкус, все упирается в необходимую пропускную способность, бюджет и специфику проекта.

        например, для soho, где не нужна конская производительность vpn и фичлист, я бы взял
        не эту схему и не dmvpn, а что-то типа meraki mx602.
          0
          gvpe
            0
            >Еще очень понравился gvpe экзотическими методами инкапсуляции, но он не позволял указать несколько IP (от разных ISP) для remote peer.
              0
              О, действительно. Не заметил.

              Вообще по моему мнению отказоустойчивость здесь должна обеспечиваться уже протоколом динамической маршрутизации поверх этой full-mesh сети. В случае gvpe это означает, что на каждый uplink заводим по «ноде» (т.е. multihome-точки будут видеться в сети как несколько «нод») и уж через какую из них пойдёт маршрутизация будет определено автоматически.
          0
          Если кто не в курсе, то в новой версии Vyatta уже есть DMVPN.
            0
            спасибо за информацию.
            заказал демку 6.6 SE, посмотрю.
            позже отпишусь по результатам.

            возможно, для некоторых проектов пригодиться.

            Предварительно, меня огорчают 2 момента:
            1. оно есть только в платной версии.
            цена VSE без учета стоимости железа сравнима с ценой циски.

            2. я сильно подозреваю, что туда впилили не полноценный dmvpn, а opennhrp.
            что тоже неплохо, но для продашна непригодно.

            0
            Оставлю тут.

            Может кому на микротиках пригодится habrahabr.ru/post/169103/
              0
              Ну если в вашей сети ESXi стандарт, то посмотрите на cisco csr1000v и DMVPN со всеми его плюшками у вас в кармане (точнее full cisco routing portfolio solutions). Единственный вопрос лицензирования этого счастья для меня остался не ясен окончательно.
                0
                вы сделали мой день в буквальном смысле этого слова, спасибо.
                ушел копать.
                  0
                  Посмотрел, спасибо.
                  Очень интересная разработка, количество головной боли при сборке лаб уменьшится.

                  К сожалению, сейчас это больше proof of concept, а не реальный cloud маршрутизатор.

                  >Единственный вопрос лицензирования этого счастья для меня остался не ясен окончательно.
                  К сожалению, там все очевидно.
                  Ниже — выдержки из официального QA.

                  Q. How can I purchase the CSR 1000V?
                  A. You can purchase the CSR 1000V directly from Cisco or from a partner. The CSR 1000V is licensed based on throughput and feature set, and you can purchase it for a term of 1, 3 or 5 years.
                  The IOS-XE® Software Release 3.9 of the CSR 1000V offers five throughput options — 10 Mbps, 25 Mbps, 50 Mbps, 100 Mbps and 250 Mbps. Upon activation of a particular option, the CSR 1000V limits its aggregate bi-directional throughput to that option.
                  For the 10 Mbps, 25 Mbps and 50 Mbps throughput options, you can select any of the feature sets — Standard, Advanced, and Premium — shown below. For the 100 Mbps and 250 Mbps throughput options, you can only select the Standard feature set. Future releases of the CSR 1000V will offer the Advanced and Premium feature sets for 100 Mbps and 250 Mbps and will offer higher throughput options.
                  • Standard: Includes routing (BGP, EIGRP, OSPF, IPv6, ..), addressing (DHCP, NAT, VLAN), basic security (ACL, AAA), high availability: (HSRP, ..), and management (SSH, SNMP, NetFlow, ..) features
                  • Advanced: Includes Standard and advanced security (Zone-based Firewall, IPSec, Route-based VPNs — DMVPN, FlexVPN, ..) features
                  • Premium: Includes Advanced, MPLS (MPLS VPN, VRF), Application Experience (AppNav, QoS, AVC, IP SLA, ..) and IP mobility (LISP) features
                  After you purchase a license, you will receive a Product Activation Key (PAK). You must provide the PAK to a Cisco License Server along with a unique device identifier (which is generated when the CSR 1000V VM boots up) in order for the server to generate a license file for the CSR 1000V. You then must install and activate the license file in the CSR 1000V.

                  Q. What is the performance of the CSR 1000V?
                  A. The CSR 1000V is intended for single-tenant (VPC) networking use in a multi-tenant cloud, where the bandwidth expectations range from 10 Mbps to 1 Gbps.
                  The IOS-XE® Release 3.9 of the CSR 1000V offers five throughput licenses — 10 Mbps, 25 Mbps, 50 Mbps, 100 Mbps, and 250 Mbps. Upon activation of a particular throughput license, the CSR 1000V limits its aggregate bi-directional throughput to the throughput specified by the license. Future releases of the CSR 1000V will offer higher throughput licenses.

                  Т.е. если хочется virtual appliance с поддержкой vpn, максимальная суммарная пропускная способность этого решения из-за ограничений лицензирования — 50 mbps.
                  Что для продакшна категорически недостаточно, а для лаб есть бесплатная триалка.
                0
                а где 2ая часть?
                  0
                  О, привет из прошлого %)
                  Вторая часть этой статьи так и не родилась, к сожалению.

                  От описанной выше схемы через несколько месяцев отказались ввиду недостаточной стабильности tinc (мультикаст-шторм, гуляющий поверх Fullmesh — это нечто).

                  Итоговое решение выглядело как hub'n'spoke с 4х равноценными хабами.
                    0
                    а жаль)
                    спасибо.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое