Facebook открыл (https://code.facebook.com/posts/291641674683314/open-r-open-... наработки, связанные с платформой маршрутизации Open/R, которая изначально развивалась как распределённая система маршрутизации для динамически меняющихся беспроводных mesh-сетей, но затем была перенесена для других сетевых применений, включая опорную сеть Facebook Express Backbone. Код эталонной реализации Open/R написан на языке C++ и распространяется (https://github.com/facebook/openr/) под лицензией MIT. Для определения RPC-вызовов используется язык описания интерфейсов Apache Thrift (http://thrift.apache.org/), а для обмена сообщениями между узлами - шина ZeroMQ (http://zeromq.org/).
Для управления доступен расширяемый CLI-интерфейс Breeze (https://github.com/facebook/openr/blob/master/openr/docs/Bre... написанный на языке Python. Для интеграции с централизованными системами управления трафиком предоставляется API, позволяющих внешним обработчикам получать сведения о состоянии линков или отслеживать обновления БД, например, получать информацию об изменении пропускной способности. Также доступен (https://github.com/facebook/openr/blob/master/openr/docs/Emu... эмулятор для тестирования при помощи виртуальных сетей на базе Open/R, поддерживающий симуляцию различных видов сбоев, трафика и характеристик работы участков сети (возникновения потери пакетов, перегрузки, задержек, jitter и т.п.).
Протокол Open/R подходит для создания автономных сетевых решений с построением оптимальных маршрутов на основе построения реплицируемой базы данных о состоянии каналов. Open/R может применяться как альтернатива OSPF и IS-IS, легко адаптируемая для различных применений. Распределённая система маршрутизации является одним из таких применений. Вместо реализации собственных механизмов согласования соединений, оформления кадров и других низкоуровневых элементов протокола, в Open/R применяется идея задействования языка Thrift для кодирования всех связанных с Open/R сообщений и применения для их передачи уже проверенной временем библиотеки ZeroMQ, позволяющей использовать такие расширенные схемы, как издатель-подписчик (https://ru.wikipedia.org/wiki/%D0%98%D0%....Open/R также изначально спроектирован как универсальная платформа, не привязанная к конкретным аппаратным системам и маршрутизаторам. Логика построения маршрутов и обмена информацией с другими узлами полностью отделена от средств установки маршрутов через специальную прослойку (модуль Platform). В качестве основной платформы для Open/R применяется сетевое оборудование на базе открытой платформы FBOSS (https://www.opennet.ru/opennews/art.shtml?num=40038), такое как коммутаторы Wedge 100 (https://code.facebook.com/posts/145488969140934/open-network.... При этом Open/R не зависит от ASIC и также может работать как поверх обычного сетевого стека Linux, так и с операционными системами Arista EOS и Juniper JunOS (QFX и PTX) через предоставляемый ими API на базе gRPC.
Элементы архитектуры Open/R:
- KV-STORE (https://github.com/facebook/openr/blob/master/openr/docs/KvS... - отвечает за ведение распределённого хранилища в формате ключ/значение (in-memory DB на базе CRDT (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_... синхронизацию данных и репликацию состояния между узлами;
- Spark (https://github.com/facebook/openr/blob/master/openr/docs/Spa... - выполняет задачи обнаружение соседних узлов при помощи протокола Link-Local Multicast и обрабатывает сведения об активности соседей. Каждый Hello-пакет передаётся с указанием цифровой подписи узла, что позволяет проверить его достоверность;- LinkMonitor (https://github.com/facebook/openr/blob/master/openr/docs/Lin... - выполняет мониторинг сетевых интерфейсов, обращаясь через прослойку Platform, а также управляет сеансами модуля Spark и транслирует выявленные соседние узлы в модуль
KV-STORE (поддерживает локальную базу соседних линков и управляет сеансами с соседними узлами);- PrefixManager (https://github.com/facebook/openr/blob/master/openr/docs/Pre... - решает задачи автоматического распределения сетевых префиксов;
- Decision (https://github.com/facebook/openr/blob/master/openr/docs/Dec... - вычисляет оптимальные маршруты и строит локальную таблицу маршрутизации на основе информации о топологии сети и базы префиксов, полученных из хранилища KV-STORE;
- FIB (https://github.com/facebook/openr/blob/master/openr/docs/Fib... - работает как прокси для программирования вычисленных маршрутов в фактическом системном окружении, обращаясь к нему через модуль Platform. Также занимается поддержанием базы состояний вычисленных маршрутов (forwarding state);
- Platform (https://github.com/facebook/openr/blob/master/openr/docs/Pla... - прослойка для низкоуровневого программирования маршрутизации и взаимодействия с сетевыми интерфейсами. Создаётся для каждой целевой аппаратной платформы и абстрагирует доступ к ней.
Основные возможности:
- Первоочередная поддержка IPv6 и задействование возможностей IPv6 по привязке локальных адресов для автоматической настройки без необходимости явного задания сетевой конфигурации;
- Полноценная поддержка маршрутизации IPv4 при необходимости;
- Распределение сетевых префиксов и настройка IP-адресов для узлов самоорганизующихся динамических сетей (Ad hoc (https://ru.wikipedia.org/wiki/%D0%91%D0%...- Возможность перезапуска без остановки работы и без нарушения процессов перенаправления трафика, что позволяет организовать применение обновлений на лету;
- Поддержка подсоединения и вывода из сети узлов и линков;
- Динамическое вычисление метрик RTT (время приема-передачи) и их уточнение через активные проверки;- Возможность установки собственных значений метрик, их статическая привязка или динамическое вычисление;
- Быстрая конвергенция (https://en.wikipedia.org/wiki/Network_convergence) сети с применением счётчиков отсрочки (backoff) для сбойных линков или узлов;
- Python-библиотека для взаимодействия со всеми основными процессами Open/R;
- Возможность расширения платформы путём распространения любых видов дополнительной информации и изменения логики вычисления маршрута;- Непрерывный контроль работоспособности сети через отправку проверочных запросов;
- Наличие API для интеграции с централизованными системами управления.
URL: https://code.facebook.com/posts/291641674683314/open-r-open-.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=47577
Выдайте приз господам в номинации "Самый монструозный продукт года".
так и не понял за всей этой мишурой маркетингового булщита, чем оно лучше ospf и isis
По описанию EIGISISDN
Не очень понятно, как именно позиционируется данный новый протокол?! Придумать более расширяемого протокола динамической маршрутизации чем ISO IS-IS сложно, да и не ясно зачем? К тому же для тех, кому не нравится IS-IS с его OSI специфичными частями, есть не менее прекрасный IETF OSPFv2/OSPFv3.
1)написано что оно умеет еще и пропускную способность как то мониторить.
2)имхо удобно для бэкенда что бы не только сеть, но и аппликейшн/дб связки контролировать
Так это давно уже все придумано, как бы трафик инжениринг бы работал. OSPF lsa type 10. Для ISIS тоже есть LSP.
Немного поправлю вас коллега, в IS-IS есть ряд TLV, не одно, их много, поэтому нет смысла писать их все номера, а вот LSP, - link state packet, аналог LSU, - link state update в терминологии OSPF. Но в общем, вы совершенно правы, а это так, уже детали, которые не меняют сути.Для тех, кто не знаком с IS-IS, у него нет понятия LSA, - link-state advertisement, в том смысле, в каком оно существует в OSPF, у первого всё кодируется в TLV, - type, length, value, это своего рода контейнер, содержащий совершенно любые данные. Сам IS-IS само-собой налагает определённые требования к реализации и определяет ряд обязательных TLV, но не запрещает, а даже поощряет внедрение функционально специфичных для реализации TLV.
Так в нём сначала появилась поддержка IPv4, затем IPv6, поскольку изначально он выполнял маршрутизацию для CSNP, - connection less network protocol. Поэтому в качестве router-id, опять же это понятие из мира OSPF/BGP/EIGRP/RIP, одним словом мира TCP/IP, используется NET, - network entity title, это особый тип NSAP, - network system access point, аналог IP адреса в мире TCP/IP, который так же описывает весь маршрутизатор, как и router-id, а не его конкретные интерфейсы. При этом NET содержит и адрес области, в терминологии IS-IS это Level 1, по своему смыслу область в обоих протоколах имеет одинаковое значение. Кроме магистральной области, в OSPF она имеет конкретный адрес 0.0.0.0 и налагает строгие требования на то, как она формируется. В IS-IS магистральная область, не имеет адреса и сформирована из Level 2 и Level 1/2 IS, - intermediate system, маршрутизатор в терминологии OSPF, и единственное требование Level 2 области, это её непрерывность.
Но оба протокола и IS-IS, и OSPFv2/v3, являются наиболее функциональными и наиболее масштабируемыми в рамках Interior Gateway Protocol. И хотя Cisco часто говорит о том, что Enhanced Interior Gateway Routing Protocol не уступает им, по многим параметрам, а по ряду параметров, в базовой конфигурации, так и превосходит их, например время сходимости у EIGRP в базовой конфигурации ниже, чем у OSPF, из-за того факта, что EIGRP заранее рассчитывает запасной маршрут FS, - Feasible Successors. Тем не менее, даже Cisco, рекомендует IS-IS в качестве IGP для своего SD-Access, - software-defined access, даже в корпоративной среде.
Хотя многие источники ставят знак равенства между 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 в зависимости от точки обзора.
Так это давно уже все придумано, как бы трафик инжениринг бы работал. OSPF lsa type 10. Для ISIS тоже есть LSP.
забавно что чувак, гордо пихающий в юзернейм свой "ccna", не понимает совершеннейшей омерзительности что мертворожденного osi-проекта и его единственного искусственно-оживленного выкидыша isis, что, тем более, ospf, придуманного ради копеечной экономии, когда лишние 64k памяти в роутер было очень-очень дорого.
Нет, я понимаю, до книжек где рассказывают, зачем (и как) в _локальных_ сетях используют bgp с кучей костыликов и подпорочек (ибо совершенно он не задумывался для них) ты еще не дорос, это и ccnp затрагивают-то только по верхам, но про eigrp-то тебя должны были заставить прочитать, или как ты умудрился свой RS сдать (S понятно, авторы asa его ниасилили, впрочем, они и ospf-то ниочень)?
В этих агитках, конечно, правды только половина, но все, что написано про недостатки альтернативных решений - правда.
У ISIS есть свои плюсы, ознакомьтесь с предметом. Если циска его не освещала раньше это означает только о заблуждениях циски. Сейчас в треке RS он есть
Cisco является одним из контрибютеров в IS-IS и одной из первых кто реализовал его в своих маршрутизаторах, к тому же IS-IS, всегда был в SP треке, да и в RS треке тоже, кроме CCNA RS.Да и вообще Cisco например рекомендует использовать именно IS-IS в рамках SD-Access к примеру, ага прямо в корпоративном секторе, и прямо вместе с SDN.
Поэтому Cisco прекрасно осведомлена о преимуществах IS-IS и всячески его рекомендует, просто в корпоративном секторе он не особо популярен по объективным причинам.
> ospf, придуманного ради копеечной экономиилол-кек-чебурек: ospf держит в памяти всю зону (а то и несколько зон), какой большой она не будь, и жрёт гораздо больше главного конкурента eigrp, который держит только соседей (вот он экономит память, да)
ps: is-is няшка
>> 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.
> и жрёт гораздо больше главного конкурента eigrpну так нашел с чем сравнивать. "у протокола ipx только один недостаток - он принадлежит фирме novell" (c)ранний MS.
igrp (из которого потом вышел eigrp) писали тоже во времена острой нужды в байтиках (а вот процессоры у циски уже были получше). Но он не только память экономит, он еще много чего хорошего делает, что и сегодня актуально. Если не лезть в mpls, конечно, для которого по тем самым причинам и непригоден.Недостаток один, но совершенно фатальный - принадлежит не той фирме. Поэтому умирает, и скоро умрет совсем. Товарищу, любителю заковыристых аббревиатур, предлагалось не про сам eigrp почитать, а про то, чего ради его пришлось изобретать при уже поддерживаемом всеми распрекрасном isis - оно там в учебниках для юных падаванов вполне понятными буквами разжевывается.
Любитель заковыристых аббревиатур, должен сказать, что 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 года, вообще.
Даже не знаю, что и сказать, 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 минут. Про ваши достижения не спрашиваю, мне не интересно это в контексте обсуждения протоколов динамической маршрутизации.
> никто iBGP не используетвы у себя в дефолт ситях не видели, что местечковые russia-телекомы творят: мне как-то от них досталось ~100 SRXов и на каждом был ibgp с редистрибуцией в ospf (сетка простая, одного ospf хватило за глаза, зачем ребята вообще тащили bgp в простенький VPN так и осталось загадкой). разбираться со всем этим делом я не стал и просто сменил работу.
Я живу в маленьком Сибирском городке, какие там дефолт сити. :)Что касается наличия iBGP с перераспределением маршрутов в OSPF, на каждом маршрутизаторе, это и правда выглядит странно. Интересно было бы узнать, какие цели преследовали авторы, данного решения, но похоже увы.
> Что касается наличия iBGP с перераспределением маршрутов в OSPF, на каждом маршрутизаторе,
> это и правда выглядит странно. Интересно было бы узнать, какие цели
> преследовали авторы, данного решения, но похоже увы.я тебе неглядя расскажу, какие - bgp для фильтрации, ospf - для сходимости (bfd у них либо не поддерживается, либо не работает, либо они до этой страницы еще не дочитали)
это совершенно типичное решение для ситуации, когда уперлись в родовые травмы ospf, а eigrp как раз ниасилен, потому что не циска или учились не по той книжке и начитались вредных агиток.
i - потому что bgp где-то еще и внешний тоже есть, mpls опять же ниасилен, не поддерживается или не работает, как и vrf-lite, чаще всего еще и использует белую райповсккую AS, одну на всех.
фильтрация, ну конечно же, будет сделана аксесс-листами, в лучшем случае - префиксами.
Если тебе в такой сети дан карт-бланш на изменения - привести в порядок можно за пару дней. Если ты младший падаван, то да, только валить нахрен оттуда. Потому что ты и будешь тем неудачником, который полезет по _всем_ железкам добавлять новую строчку в эти acl, смотри ничего не пропусти и не опечатайся.
Как у вас получилось сравнить BFD и OSPF в рамках механизма обеспечивающего быструю сходимость всей сети?Bidirectional Forwarding Detection протокол не может заменить IGP, поскольку кроме факта sub-second обнаружения сбоя соседа, он нечего больше предложить не может.
BGP протокол от этого не станет сходиться быстрее, хоть с BFD, хоть без него, по отношению к любому IGP, кроме RIP конечно.
P/S/ Единственное, что мне не нравится в беседах с вами, ваша мания величия. Вы так пренебрежительно говорите о других, будто вы по меньшей мере автор десятка RFC или CCAr, а вокруг одни неучи. Это вас совершенно не красит.
> привести в порядок можно за пару днейНапоминает влажные мячты нашего руководства.
Обычно после заявлений вроде: "Это можно сделать за 15 минут" сервисы подымать приходится минимум месяц, а из клиентов делать дураков. Особенно тяжко приходится в такие периоды support'у…
> вы у себя в дефолт ситях не видели, что местечковые 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(это не дефолт-сити, ма-а-а-ахонькая сеточка)
>[оверквотинг удален]
> выкидыша isis, что, тем более, ospf, придуманного ради копеечной экономии, когда
> лишние 64k памяти в роутер было очень-очень дорого.
> Нет, я понимаю, до книжек где рассказывают, зачем (и как) в _локальных_
> сетях используют bgp с кучей костыликов и подпорочек (ибо совершенно он
> не задумывался для них) ты еще не дорос, это и ccnp
> затрагивают-то только по верхам, но про eigrp-то тебя должны были заставить
> прочитать, или как ты умудрился свой RS сдать (S понятно, авторы
> asa его ниасилили, впрочем, они и ospf-то ниочень)?
> В этих агитках, конечно, правды только половина, но все, что написано про
> недостатки альтернативных решений - правда.И ещё забыл добавить, конечно же ASA поддерживает EIGRP и OSPF, в полном объёме, как и BGP.
> И ещё забыл добавить, конечно же ASA поддерживает EIGRP и OSPF, в
> полном объёме, как и BGP.в полном объеме - три хаха. Попробуй его совместить с асиным vpn (в обоих вариантах, там один смешнее другого) и удивись результату. Потом не будешь удивляться, когда увидишь асу, используемую только для шифрования туннелей, проброшенных сквозь нее с более вменяемых коробок.
а eigrp там добавили, помнится, в аж девятой, что-ли, версии, и такой, что пользоваться им вообще невозможно.
EIGRP появился в ASA 7, относительно маршрутизации через VPN, то если подробнее напишите, что через что сделать, то попробую, почему бы и нет.
две совершенно типичнейшие (в жизни, а не в учебниках ccna) задачи (обычно нерешаемые в рамках одной асы в принципе ;)- site2site ipsec. оба сайта неплоские, или просто большие, статика не катит
в случае единственного пира ты решишь эту проблему за счет ручного указания его адреса. Если их два через один интерфейс- опа, приехали, эти настройки у нас на интерфейсах.- dynamic ipsec (та гадина за натом и статический туннель строить вообще не на чем)
во что оно превращается, если еще и пытаться использовать асу как файрвол (вдруг кто-то с дуба рухнул ;) - отдельная история.
И так, site-to-site VPN, с несколькими пирами, через один физический интерфейс, так?При этом в туннеле должен быть EIGRP?
С пиром за NAT, очевидно, что инициировать туннель прийдётся второй стороне.
> При этом в туннеле должен быть EIGRP?при этом должна быть хоть какая-то работающая маршрутизация.
Полагаю, в реальном случае, пособирав уже все собранные до вас давно грабли, вы придете к тому же, к чему и все - gre тунелю с поддерживающих gre устройств и bgp в туннеле, а в сторону асы - только статики для тунельных эндпоинтов.
Но это работает только в простых случаях, где без асы в общем-то обошлись бы вовсе.
Относительно 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 раздельно в рамках одного устройства.
> Про случай с NAT, можно сделать стенд, поскольку такая конфигурация в принципе
> для site-to-site не нормальна, для Remote Access вполне нормальна, да.она не то что "нормальна", она скоро станет единственно-возможной. Потому что адреса денех стоют, и чем дальше, тем дороже. А v6 все никак "не готов для десктопа" ;-)
То есть можете его считать "remote access", только на практике за тем remote - офис окажется, человек на 200, и сетка у него тоже будет с фокусами.Вы еще и обратно в асу же (в другие интерфейсы, другой контекст или в другую асу) будете этот траффик заворачивать из-за необходимости натить еще и внутреннюю адресацию по обоим сторонам.
Потому что каждый второй дятел думает что выбрав 172.20.0.0 вместо привычного 16 он всех перехитрил. (а остальные просто делают плоскую 10)
> А вообще ASA заменяется сейчас активно на Firepower Threat Defense, который в
мечтать не вредно.
На деле с рынка именно файрволов циска уже безвозвратно вылетела, проспав модные тренды, да еще и пытаясь разводить кроликов на per-user оплату vpn.хотя именно в нашей стране, возможно, останется навечно, потому что с умением заносить и откатывать у них в свое время сложилось.
А в Netsukuku были фрактальные алгоритмы.
А в cjbdns - dht+свич. Не такое уж плохое комбо, хотя свич переусложненный и билдсистема странная.
> ... для обмена сообщениями между узлами - шина ZeroMQ.вот балбесы.
>> ... для обмена сообщениями между узлами - шина ZeroMQ.
> вот балбесы.у пехепешников так принято. Я его слепила из тех модулей что было.
На самом деле - для _этой_ задачи - почему бы и нет. Главное, не оказаться тем неудачником, который будет там искать проблемы.
Я так и не понял на каком оборудовании все это работает. Помоему протоколов для Mesh уже написано уйма, а вот оборудования так и нет.
Судя по новости на Wedge 100, который является Top Of Rack коммутатором, что при этом у них применяется на Spine/Core, вообще не ясно. Сказано, что ещё Arista EOS и Juniper JunOS может использоваться, но, что имеется ввиду, сложно понять из текста новости.И вообще похоже, что речь идёт о Data Center специфичном протоколе, там где живут TRILL, SPB и прочие, в которых IS-IS основа Control Plane.
Вот это применяется на spine/super-spine: https://code.facebook.com/posts/864213503715814/introducing-.../Плюс какое-то количество вайтбоксов циски-джунипера-аристы-проч.
Никакого ядра нет: https://en.wikipedia.org/wiki/Clos_networkФБ, как и Гугл, использует SDN во внутренних сетях уже который год, так что традиционные протоколы маршрутизации для них — ненужное легаси, которое разработано не для того, что действительно нужно (минимальные и предсказуемые задержки на постоянно перестраивающейся сети).
Вот, например, как развивалась сеть Гугла: https://www.nextplatform.com/2015/06/19/inside-a-decade-of-g.../
Спасибо, почитаю.
> Спасибо, почитаю.будешь читать - обрати внимание, что _внутри_ свитча у них - bgp. А не ospf, хотя, казалось бы, тут-то ему самое место ;-)
>> Спасибо, почитаю.
> будешь читать - обрати внимание, что _внутри_ свитча у них - bgp.
> А не ospf, хотя, казалось бы, тут-то ему самое место ;-)У Facebook кастомное решение, в котором по их мнению iBGP с route reflector это отличная идея.
Почему по-вашему там должен быть именно OSPF?
> Почему по-вашему там должен быть именно OSPF?правильный вопрос - где у нас вообще останется ospf, если даже внутрисвитчевая маршрутизация почему-то "отличная идея" не на нем.
А на протоколе, изначально вообще-то рассчитанном на медленные линки и "подумаешь, потеряем пару тыщ пакетиков, пока сойдется".
Останется, как IGP для MPLS или IGP для SDN, до момента когда контроллер возьмёт дело в свои руки. Я плохо знаком с архитектурой решений Facebook, поэтому мне вообще странно видеть внутри моста BGP, в качестве backplane, даже не знаю пока, как правильно называть то, что он заменяет в традиционных решениях.Расскажите лучше, почему вы не любите OSPF? Я имею технические детали ваших претензий к нему, может и я стану его не любить. :)
Про Google очень интересно было, хоть и мало пригодно для кого-то, кто не Google.SDN для DC имеют многие вендоры, но в масштабах Google и их специфике наверное никто бы не смог предложить им лучше решения, чем созданной ими самими.
> Я так и не понял на каком оборудовании все это работает.на своем, мордокнижном-наколеночном.
"зато дешевенькое".оборудования для sdn как раз полным-полно, но мордокнижка во-первых не хочет за это платить, ей дешевле даже заказное, но из дешевых деталей и без патентов циски/жунипера в комплекте, во-вторых, как раз под ее запросы оно не факт что хорошо подходит.
как кто-то удачно выразился в стертом тредике - это sdn, придуманная php'шниками. Для себя, любимых.