The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Facebook открыл реализацию платформы и протокола маршрутизации Open/R

16.11.2017 10:51

Facebook открыл наработки, связанные с платформой маршрутизации Open/R, которая изначально развивалась как распределённая система маршрутизации для динамически меняющихся беспроводных mesh-сетей, но затем была перенесена для других сетевых применений, включая опорную сеть Facebook Express Backbone. Код эталонной реализации Open/R написан на языке C++ и распространяется под лицензией MIT. Для определения RPC-вызовов используется язык описания интерфейсов Apache Thrift, а для обмена сообщениями между узлами - шина ZeroMQ.

Для управления доступен расширяемый CLI-интерфейс Breeze, написанный на языке Python. Для интеграции с централизованными системами управления трафиком предоставляется API, позволяющих внешним обработчикам получать сведения о состоянии линков или отслеживать обновления БД, например, получать информацию об изменении пропускной способности. Также доступен эмулятор для тестирования при помощи виртуальных сетей на базе Open/R, поддерживающий симуляцию различных видов сбоев, трафика и характеристик работы участков сети (возникновения потери пакетов, перегрузки, задержек, jitter и т.п.).

Протокол Open/R подходит для создания автономных сетевых решений с построением оптимальных маршрутов на основе построения реплицируемой базы данных о состоянии каналов. Open/R может применяться как альтернатива OSPF и IS-IS, легко адаптируемая для различных применений. Распределённая система маршрутизации является одним из таких применений. Вместо реализации собственных механизмов согласования соединений, оформления кадров и других низкоуровневых элементов протокола, в Open/R применяется идея задействования языка Thrift для кодирования всех связанных с Open/R сообщений и применения для их передачи уже проверенной временем библиотеки ZeroMQ, позволяющей использовать такие расширенные схемы, как издатель-подписчик.

Open/R также изначально спроектирован как универсальная платформа, не привязанная к конкретным аппаратным системам и маршрутизаторам. Логика построения маршрутов и обмена информацией с другими узлами полностью отделена от средств установки маршрутов через специальную прослойку (модуль Platform). В качестве основной платформы для Open/R применяется сетевое оборудование на базе открытой платформы FBOSS, такое как коммутаторы Wedge 100. При этом Open/R не зависит от ASIC и также может работать как поверх обычного сетевого стека Linux, так и с операционными системами Arista EOS и Juniper JunOS (QFX и PTX) через предоставляемый ими API на базе gRPC.

Элементы архитектуры Open/R:

  • KV-STORE - отвечает за ведение распределённого хранилища в формате ключ/значение (in-memory DB на базе CRDT), синхронизацию данных и репликацию состояния между узлами;
  • Spark - выполняет задачи обнаружения соседних узлов при помощи протокола Link-Local Multicast и обрабатывает сведения об активности соседей. Каждый Hello-пакет передаётся с указанием цифровой подписи узла, что позволяет проверить его достоверность;
  • LinkMonitor - выполняет мониторинг сетевых интерфейсов, обращаясь через прослойку Platform, а также управляет сеансами модуля Spark и транслирует выявленные соседние узлы в модуль KV-STORE (поддерживает локальную базу соседних линков и управляет сеансами с соседними узлами);
  • PrefixManager - решает задачи автоматического распределения сетевых префиксов;
  • Decision - вычисляет оптимальные маршруты и строит локальную таблицу маршрутизации на основе информации о топологии сети и базы префиксов, полученных из хранилища KV-STORE;
  • FIB - работает как прокси для программирования вычисленных маршрутов в фактическом системном окружении, обращаясь к нему через модуль Platform. Также занимается поддержанием базы состояний вычисленных маршрутов (forwarding state);
  • Platform - прослойка для низкоуровневого программирования маршрутизации и взаимодействия с сетевыми интерфейсами. Создаётся для каждой целевой аппаратной платформы и абстрагирует доступ к ней.

Основные возможности:

  • Первоочередная поддержка IPv6 и задействование возможностей IPv6 по привязке локальных адресов для автоматической настройки без необходимости явного задания сетевой конфигурации;
  • Полноценная поддержка маршрутизации IPv4 при необходимости;
  • Распределение сетевых префиксов и настройка IP-адресов для узлов самоорганизующихся динамических сетей (Ad hoc);
  • Возможность перезапуска без остановки работы и без нарушения процессов перенаправления трафика, что позволяет организовать применение обновлений на лету;
  • Поддержка подсоединения и вывода из сети узлов и линков;
  • Динамическое вычисление метрик RTT (время приема-передачи) и их уточнение через активные проверки;
  • Возможность установки собственных значений метрик, их статическая привязка или динамическое вычисление;
  • Быстрая конвергенция сети с применением счётчиков отсрочки (backoff) для сбойных линков или узлов;
  • Python-библиотека для взаимодействия со всеми основными процессами Open/R;
  • Возможность расширения платформы путём распространения любых видов дополнительной информации и изменения логики вычисления маршрута;
  • Непрерывный контроль работоспособности сети через отправку проверочных запросов;
  • Наличие API для интеграции с централизованными системами управления.


  1. Главная ссылка к новости (https://code.facebook.com/post...)
  2. OpenNews: Facebook представил открытую платформу для создания сетевых коммутаторов
  3. OpenNews: Facebook открыл программные стеки для BMC-контроллеров и сетевых коммутаторов
  4. OpenNews: Компания Microsoft открыла код Linux-системы для сетевых коммутаторов
  5. OpenNews: Facebook запустил проект по созданию открытого оборудования для сотовых сетей
  6. OpenNews: Операционная система OpenSwitch перешла под крыло Linux Foundation
Лицензия: CC-BY
Тип: Интересно
Короткая ссылка: https://opennet.ru/47577-openr
Ключевые слова: openr, route, facebook, switch, ospf, isis
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, лютый жабист__ (?), 12:57, 16/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Выдайте приз господам в номинации "Самый монструозный продукт года".
     
  • 1.4, Leap42 (?), 13:14, 16/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так и не понял за всей этой мишурой маркетингового булщита, чем оно лучше ospf и isis
     
     
  • 2.5, Mikk (??), 13:29, 16/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По описанию EIGISISDN
     

  • 1.13, zanswer CCNA RS and S (?), 15:00, 16/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не очень понятно, как именно позиционируется данный новый протокол?! Придумать более расширяемого протокола динамической маршрутизации чем ISO IS-IS сложно, да и не ясно зачем? К тому же для тех, кому не нравится IS-IS с его OSI специфичными частями, есть не менее прекрасный IETF OSPFv2/OSPFv3.
     
     
  • 2.19, Аноним (19), 18:02, 16/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    1)написано что оно умеет еще и пропускную способность как то мониторить.
    2)имхо удобно для бэкенда что бы не только сеть, но и аппликейшн/дб связки контролировать
     
     
  • 3.21, McLoud (??), 20:39, 16/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Так это давно уже все придумано, как бы трафик инжениринг бы работал. OSPF lsa type 10. Для ISIS тоже есть LSP.
     
     
  • 4.38, zanswer CCNA RS and S (?), 10:17, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Немного поправлю вас коллега, в IS-IS есть ряд TLV, не одно, их много, поэтому н... большой текст свёрнут, показать
     
  • 4.39, zanswer CCNA RS and S (?), 11:22, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя многие источники ставят знак равенства между LSA=LSP, а ряд так же между LSU=LSP, ссылаясь на то, что хотя LSA используют собственные заголовки, а TLV один общий, тем не менее, они выполняют схожую операцию, объявление о топологии, префиксах, соседях и так далее.

    Но, тем не менее, ISO/IEC 10589-2002 даёт такое определение LSP:

    "LSP - Link State Protocol Data Unit"

    А RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments такое:

    "LSP - Link State Packet (a type of packet used by the IS-IS protocol)"

    И при этом RFC 2328: OSPF Version 2 такое:

    "A.3.5 The Link State Update packet

        Link State Update packets are OSPF packet type 4.  These packets
        implement the flooding of LSAs.  Each Link State Update packet
        carries a collection of LSAs one hop further from their origin.
        Several LSAs may be included in a single packet."

    Но, с другой стороны, соавтор ряда RFC по IS-IS Manav Bhatia, тоже сравнивает LSP с LSA, в контексте объявления состояния каналов, но при этом же указывает, что LSP сравним с LSU в контексте передачи самих пакетов через сеть.

    Поэтому я внесу коррективу в сказанное мною выше, что я не исправляю вас, а дополняю, поскольку в данном случае, LSP можно рассматривать и в рамках LSA, и в рамках LSU в зависимости от точки обзора.

     
  • 3.22, McLoud (??), 20:39, 16/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Так это давно уже все придумано, как бы трафик инжениринг бы работал. OSPF lsa type 10. Для ISIS тоже есть LSP.
     
  • 2.20, пох (?), 20:23, 16/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    забавно что чувак, гордо пихающий в юзернейм свой "ccna", не понимает совершеннейшей омерзительности что мертворожденного osi-проекта и его единственного искусственно-оживленного выкидыша isis, что, тем более, ospf, придуманного ради копеечной экономии, когда лишние 64k памяти в роутер было очень-очень дорого.
    Нет, я понимаю, до книжек где рассказывают, зачем (и как) в _локальных_ сетях используют bgp с кучей костыликов и подпорочек (ибо совершенно он не задумывался для них) ты еще не дорос, это и ccnp затрагивают-то только по верхам, но про eigrp-то тебя должны были заставить прочитать, или как ты умудрился свой RS сдать (S понятно, авторы asa его ниасилили, впрочем, они и ospf-то ниочень)?
    В этих агитках, конечно, правды только половина, но все, что написано про недостатки альтернативных решений - правда.

     
     
  • 3.23, McLoud (??), 20:43, 16/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У ISIS есть свои плюсы, ознакомьтесь с предметом. Если циска его не освещала раньше это означает только о заблуждениях циски. Сейчас в треке RS он есть
     
     
  • 4.34, zanswer CCNA RS and S (?), 08:23, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Cisco является одним из контрибютеров в IS-IS и одной из первых кто реализовал его в своих маршрутизаторах, к тому же IS-IS, всегда был в SP треке, да и в RS треке тоже, кроме CCNA RS.

    Да и вообще Cisco например рекомендует использовать именно IS-IS в рамках SD-Access к примеру, ага прямо в корпоративном секторе, и прямо вместе с SDN.

    Поэтому Cisco прекрасно осведомлена о преимуществах IS-IS и всячески его рекомендует, просто в корпоративном секторе он не особо популярен по объективным причинам.

     
  • 3.30, leap42 (ok), 03:12, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > ospf, придуманного ради копеечной экономии

    лол-кек-чебурек: ospf держит в памяти всю зону (а то и несколько зон), какой большой она не будь, и жрёт гораздо больше главного конкурента eigrp, который держит только соседей (вот он экономит память, да)

    ps: is-is няшка

     
     
  • 4.33, zanswer CCNA RS and S (?), 08:13, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> ospf, придуманного ради копеечной экономии
    > лол-кек-чебурек: ospf держит в памяти всю зону (а то и несколько зон),
    > какой большой она не будь, и жрёт гораздо больше главного конкурента
    > eigrp, который держит только соседей (вот он экономит память, да)
    > ps: is-is няшка

    Не согласен с вами, что главный конкурент OSPF это EIGRP, хотя смотря конечно в каком сегменте, если корпоративном сегменте, то согласен с вами, а если в ISP/TELCO, то там IS-IS, вечный, заклятый враг OSPF.

    И если скажем, OSPFv2 имел объективные недостатки, по отношению к IS-IS, например в виде LSA type 1/2 содержащих и информацию о топологии, и информацию о префиксах, что приводило к тому, что в SPF дереве префиксы были представлены узлами, а не листьями, как у IS-IS, что автоматически ставило крест на Incremental SPF в большинстве случаев, то в OSPFv3 IETF исправила эти недостатки.

    Правда и IS-IS не стоит на месте, у него тоже были проблемы в прошлом, к примеру с количество point-to-point интерфейсов, точнее с тем, сколько интерфейсов может быть описано в TLV и опять же благодаря усилиям IETF данную проблему исправили. Или например проблема с two-way handshake для point-to-point Hello, которую благодаря опять же IETF исправили, заменив на three-way handshake всё для того же P-t-P Hello, решив такую проблему, как не консистентное состояние LSDB при потери части LSP пакетов во время синхронизации. При этом полный reflooding мог произойти только через 18 часов, максимальное время жизни LSP. И IETF исправила данную проблему, вообще говоря оба протокола сейчас развиваются под крылом IETF, каждый в рамках своей WG.

     
  • 4.42, пох (?), 16:41, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > и жрёт гораздо больше главного конкурента eigrp

    ну так нашел с чем сравнивать. "у протокола ipx только один недостаток - он принадлежит фирме novell" (c)ранний MS.
    igrp (из которого потом вышел eigrp) писали тоже во времена острой нужды в байтиках (а вот процессоры у циски уже были получше). Но он не только память экономит, он еще много чего хорошего делает, что и сегодня актуально. Если не лезть в mpls, конечно, для которого по тем самым причинам и непригоден.

    Недостаток один, но совершенно фатальный - принадлежит не той фирме. Поэтому умирает, и скоро умрет совсем. Товарищу, любителю заковыристых аббревиатур, предлагалось не про сам eigrp почитать, а про то, чего ради его пришлось изобретать при уже поддерживаемом всеми распрекрасном isis - оно там в учебниках для юных падаванов вполне понятными буквами разжевывается.

     
     
  • 5.59, zanswer CCNA RS and S (?), 10:35, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Любитель заковыристых аббревиатур, должен сказать, что IS-IS впервые был представлен в IOS в 1993 году, тогда же, когда и EIGRP, то есть в один год. RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments, было представлено в 1990 году.

    Основная цель реализации EIGRP по отношению к IGRP был переход на без классовую маршрутизацию, CIDR, - classless interdomain routing, представленный всё в том же 1993 году. IGRP поддерживал только классовую маршрутизацию, как и RIPv1, что потребовало его переориентации, а после вышел ещё и EIGRP for IPv6. А всё потому, что в отличие от IS-IS, OSPF, RIP, EIGRP, требуют переориентации для каждого нового протокола, в той или иной степени, даже, если это просто новая версия IP протокол, а не скажем Shortest Path Bridging какой-нибудь.

    Я с радостью послушаю вашу точку зрения или ту, что изложена в тех книгах, что вы читали, по какой причине появился EIGRP, при имеющемся IGRP и отсутствующем у Cisco IS-IS до 1993 года, вообще.

     
  • 3.32, zanswer CCNA RS and S (?), 08:00, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Даже не знаю, что и сказать, EIGRP дистанционно-векторный протокол и памяти, как и ресурсов CPU он потребляет меньше, чем OSPF, который является протоколом с отслеживанием состояния-каналов, а значит должен хранить информацию о топологии всей сети, в отличие от EIGRP, который хранит информацию о топологии только смежных маршрутизаторов.

    IS-IS является наиболее широко используемым generic протоколом, кроме IGP в сетях провайдеров, как основа для MPLS, он ещё и используется в Control Plane таких протоколов, как TRILL, SPB, FSPF. Что не умоляет достоинств OSPF, который в ряде случаев может быть более предпочтительным, например ATM/FR, DMVPN, хотя в последнем EIGRP и лучше подходит.

    Что же касается BGP, то в качестве IGP протокола, никто iBGP не использует, по крайней мере я такого ещё не слышал. MPLS L3VPN, BGP TE, Multicast BGP, да, но, как замена IGP протоколам, таким, как OSPF/IS-IS это что-то новенькое. Или может быть вы из тех, кто используется eBGP с private AS внутри внутри одной AS, чтобы избавиться от требования наличия full-mesh для iBGP или использования route reflector/confederation?

    P/S/ Сдал оба экзамена на уровне ~930 баллов, менее чем за час из отведённых 90 минут. Про ваши достижения не спрашиваю, мне не интересно это в контексте обсуждения протоколов динамической маршрутизации.

     
     
  • 4.36, Leap42 (?), 09:24, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > никто iBGP не использует

    вы у себя в дефолт ситях не видели, что местечковые russia-телекомы творят: мне как-то от них досталось ~100 SRXов и на каждом был ibgp с редистрибуцией в ospf (сетка простая, одного ospf хватило за глаза, зачем ребята вообще тащили bgp в простенький VPN так и осталось загадкой). разбираться со всем этим делом я не стал и просто сменил работу.

     
     
  • 5.37, zanswer CCNA RS and S (?), 09:29, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я живу в маленьком Сибирском городке, какие там дефолт сити. :)

    Что касается наличия iBGP с перераспределением маршрутов в OSPF, на каждом маршрутизаторе, это и правда выглядит странно. Интересно было бы узнать, какие цели преследовали авторы, данного решения, но похоже увы.

     
     
  • 6.46, пох (?), 17:17, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Что касается наличия iBGP с перераспределением маршрутов в OSPF, на каждом маршрутизаторе,
    > это и правда выглядит странно. Интересно было бы узнать, какие цели
    > преследовали авторы, данного решения, но похоже увы.

    я тебе неглядя расскажу, какие - bgp для фильтрации, ospf - для сходимости (bfd у них либо не поддерживается, либо не работает, либо они до этой страницы еще не дочитали)

    это совершенно типичное решение для ситуации, когда уперлись в родовые травмы ospf, а eigrp как раз ниасилен, потому что не циска или учились не по той книжке и начитались вредных агиток.

    i - потому что bgp где-то еще и внешний тоже есть, mpls опять же ниасилен, не поддерживается или не работает, как и vrf-lite, чаще всего еще и использует белую райповсккую AS, одну на всех.

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

    Если тебе в такой сети дан карт-бланш на изменения - привести в порядок можно за пару дней. Если ты младший падаван, то да, только валить нахрен оттуда. Потому что ты и будешь тем неудачником, который полезет по _всем_ железкам добавлять новую строчку в эти acl, смотри ничего не пропусти и не опечатайся.

     
     
  • 7.57, zanswer CCNA RS and S (?), 08:25, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Как у вас получилось сравнить BFD и OSPF в рамках механизма обеспечивающего быструю сходимость всей сети?

    Bidirectional Forwarding Detection протокол не может заменить IGP, поскольку кроме факта sub-second обнаружения сбоя соседа, он нечего больше предложить не может.

    BGP протокол от этого не станет сходиться быстрее, хоть с BFD, хоть без него, по отношению к любому IGP, кроме RIP конечно.

    P/S/ Единственное, что мне не нравится в беседах с вами, ваша мания величия. Вы так пренебрежительно говорите о других, будто вы по меньшей мере автор десятка RFC или CCAr, а вокруг одни неучи. Это вас совершенно не красит.

     
  • 7.60, t28 (?), 14:19, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > привести в порядок можно за пару дней

    Напоминает влажные мячты нашего руководства.
    Обычно после заявлений вроде: "Это можно сделать за 15 минут" сервисы подымать приходится минимум месяц, а из клиентов делать дураков. Особенно тяжко приходится в такие периоды support'у…

     
  • 5.44, пох (?), 17:04, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > вы у себя в дефолт ситях не видели, что местечковые russia-телекомы творят:

    скорее всего - скопипастили с чьей-то mpls-сетки, не вникая в детали (иначе был бы eBGP).

    > ibgp с редистрибуцией в ospf (сетка простая, одного ospf хватило за
    > глаза, зачем ребята вообще тащили bgp в простенький VPN так и

    затем, что в нем есть фильтрация. И нет совершенно идиотской проблемы с multiarea, которая у циски решается избранными железками и тоже через задницу, нестандартным расширением, а все остальные городят паразитные петли. Или вовсе живут в одной area0 - ни фильтров, ни хотя бы агрегатов.
    Где-нибудь на другом конце города один унылый юзер к концентратору подключился - анонс его ценнейшей /32 побежал по тысчонке устройств. Ну или применительно к мордокниге - свитчнулась нагрузка на хост, анонсирующий свой сервис таким образом - с тем же результатом.

    Вот такое - действительно лечению не поддается. А банальная схема, позаимствованная у кого-то побольше, хоть и  без понимания, для чего придумана -  вполне.

    > осталось загадкой). разбираться со всем этим делом я не стал и

    пугливый какой. было б с чем разбираться-то...
    RP/0/RSP0/CPU0#sh run router ospf | utility wc -l
           72
    RP/0/RSP0/CPU0#sh run router isis | utility wc -l
          182

    (это не дефолт-сити, ма-а-а-ахонькая сеточка)

     
  • 3.35, zanswer CCNA RS and S (?), 08:26, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > выкидыша isis, что, тем более, ospf, придуманного ради копеечной экономии, когда
    > лишние 64k памяти в роутер было очень-очень дорого.
    > Нет, я понимаю, до книжек где рассказывают, зачем (и как) в _локальных_
    > сетях используют bgp с кучей костыликов и подпорочек (ибо совершенно он
    > не задумывался для них) ты еще не дорос, это и ccnp
    > затрагивают-то только по верхам, но про eigrp-то тебя должны были заставить
    > прочитать, или как ты умудрился свой RS сдать (S понятно, авторы
    > asa его ниасилили, впрочем, они и ospf-то ниочень)?
    > В этих агитках, конечно, правды только половина, но все, что написано про
    > недостатки альтернативных решений - правда.

    И ещё забыл добавить, конечно же ASA поддерживает EIGRP и OSPF, в полном объёме, как и BGP.

     
     
  • 4.49, пох (?), 17:39, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > И ещё забыл добавить, конечно же ASA поддерживает EIGRP и OSPF, в
    > полном объёме, как и BGP.

    в полном объеме - три хаха. Попробуй его совместить с асиным vpn (в обоих вариантах, там один смешнее другого) и удивись результату. Потом не будешь удивляться, когда увидишь асу, используемую только для шифрования туннелей, проброшенных сквозь нее с более вменяемых коробок.

    а eigrp там добавили, помнится, в аж девятой, что-ли, версии, и такой, что пользоваться им вообще невозможно.

     
     
  • 5.50, zanswer CCNA RS and S (?), 18:18, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    EIGRP появился в ASA 7, относительно маршрутизации через VPN, то если подробнее напишите, что через что сделать, то попробую, почему бы и нет.
     
     
  • 6.52, пох (?), 19:51, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    две совершенно типичнейшие (в жизни, а не в учебниках ccna) задачи (обычно нерешаемые в рамках одной асы в принципе ;)

    - site2site ipsec. оба сайта неплоские, или просто большие, статика не катит
    в случае единственного пира ты решишь эту проблему за счет ручного указания его адреса. Если их два через один интерфейс- опа, приехали, эти настройки у нас на интерфейсах.

    - dynamic ipsec (та гадина за натом и статический туннель строить вообще не на чем)

    во что оно превращается, если еще и пытаться использовать асу как файрвол (вдруг кто-то с дуба рухнул ;) - отдельная история.

     
     
  • 7.55, zanswer CCNA RS and S (?), 08:01, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    И так, site-to-site VPN, с несколькими пирами, через один физический интерфейс, так?

    При этом в туннеле должен быть EIGRP?

    С пиром за NAT, очевидно, что инициировать туннель прийдётся второй стороне.

     
     
  • 8.63, пох (?), 19:36, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    при этом должна быть хоть какая-то работающая маршрутизация Полагаю, в реальном... текст свёрнут, показать
     
  • 7.58, zanswer CCNA RS and S (?), 09:07, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Относительно site-to-site IPSec, не какой проблемы не обнаружил, IPSec VTI реализует поддержку передачи multicast трафика, в том числе и на ASA.

    Классический IPSec туннель негде не способен обеспечить передачу multicast пакетов, ввиду чего требуется Unicast neighbor в случае EIGRP и point-to-multipoint neighbor в случае OSPF.

    Про случай с NAT, можно сделать стенд, поскольку такая конфигурация в принципе для site-to-site не нормальна, для Remote Access вполне нормальна, да.

    А вообще ASA заменяется сейчас активно на Firepower Threat Defense, который в будущем полностью заменит ASA, избавив от необходимости держать ASA и Firepower services раздельно в рамках одного устройства.

     
     
  • 8.64, пох (?), 19:47, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    она не то что нормальна , она скоро станет единственно-возможной Потому что ад... текст свёрнут, показать
     

  • 1.15, Аноним (-), 15:28, 16/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в Netsukuku были фрактальные алгоритмы.
     
     
  • 2.54, Аноним (-), 21:40, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А в cjbdns - dht+свич. Не такое уж плохое комбо, хотя свич переусложненный и билдсистема странная.
     

  • 1.28, all_glory_to_the_hypnotoad (ok), 00:34, 17/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > ... для обмена сообщениями между узлами - шина ZeroMQ.

    вот балбесы.

     
     
  • 2.48, пох (?), 17:27, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> ... для обмена сообщениями между узлами - шина ZeroMQ.
    > вот балбесы.

    у пехепешников так принято. Я его слепила из тех модулей что было.
    На самом деле - для _этой_ задачи - почему бы и нет. Главное, не оказаться тем неудачником, который будет там искать проблемы.

     

  • 1.31, Аноним (-), 04:55, 17/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я так и не понял на каком оборудовании все это работает. Помоему протоколов для Mesh уже написано уйма, а вот оборудования так и нет.
     
     
  • 2.41, zanswer CCNA RS and S (?), 12:22, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по новости на Wedge 100, который является Top Of Rack коммутатором, что при этом у них применяется на Spine/Core, вообще не ясно. Сказано, что ещё Arista EOS и Juniper JunOS может использоваться, но, что имеется ввиду, сложно понять из текста новости.

    И вообще похоже, что речь идёт о Data Center специфичном протоколе, там где живут TRILL, SPB и прочие, в которых IS-IS основа Control Plane.

     
     
  • 3.43, xv (??), 16:49, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вот это применяется на spine/super-spine: https://code.facebook.com/posts/864213503715814/introducing-backpack-our-secon

    Плюс какое-то количество вайтбоксов циски-джунипера-аристы-проч.
    Никакого ядра нет: https://en.wikipedia.org/wiki/Clos_network

    ФБ, как и Гугл, использует SDN во внутренних сетях уже который год, так что традиционные протоколы маршрутизации для них — ненужное легаси, которое разработано не для того, что действительно нужно (минимальные и предсказуемые задержки на постоянно перестраивающейся сети).

    Вот, например, как развивалась сеть Гугла: https://www.nextplatform.com/2015/06/19/inside-a-decade-of-google-homegrown-da

     
     
  • 4.45, zanswer CCNA RS and S (?), 17:05, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, почитаю.
     
     
  • 5.53, пох (?), 19:53, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Спасибо, почитаю.

    будешь читать - обрати внимание, что _внутри_ свитча у них - bgp. А не ospf, хотя, казалось бы, тут-то ему самое место ;-)

     
     
  • 6.56, zanswer CCNA RS and S (?), 08:07, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Спасибо, почитаю.
    > будешь читать - обрати внимание, что _внутри_ свитча у них - bgp.
    > А не ospf, хотя, казалось бы, тут-то ему самое место ;-)

    У Facebook кастомное решение, в котором по их мнению iBGP с route reflector это отличная идея.

    Почему по-вашему там должен быть именно OSPF?

     
     
  • 7.65, пох (?), 19:51, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему по-вашему там должен быть именно OSPF?

    правильный вопрос - где у нас вообще останется ospf, если даже внутрисвитчевая маршрутизация почему-то "отличная идея" не на нем.
    А на протоколе, изначально вообще-то рассчитанном на медленные линки и "подумаешь, потеряем пару тыщ пакетиков, пока сойдется".

     
     
  • 8.66, zanswer CCNA RS and S (?), 20:06, 18/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Останется, как IGP для MPLS или IGP для SDN, до момента когда контроллер возьмёт... текст свёрнут, показать
     
  • 4.51, zanswer CCNA RS and S (?), 18:58, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Про Google очень интересно было, хоть и мало пригодно для кого-то, кто не Google.

    SDN для DC имеют многие вендоры, но в масштабах Google и их специфике наверное никто бы не смог предложить им лучше решения, чем созданной ими самими.

     
  • 2.47, пох (?), 17:26, 17/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так и не понял на каком оборудовании все это работает.

    на своем, мордокнижном-наколеночном.
    "зато дешевенькое".

    оборудования для sdn как раз полным-полно, но мордокнижка во-первых не хочет за это платить, ей дешевле даже заказное, но из дешевых деталей и без патентов циски/жунипера в комплекте, во-вторых, как раз под ее запросы оно не факт что хорошо подходит.

    как кто-то удачно выразился в стертом тредике - это sdn, придуманная php'шниками. Для себя, любимых.


     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру