https://89.19.215.112/openforum/vsluhforumID3/112772.html Facebook открыл (https://code.facebook.com/posts/291641674683314/open-r-open-routing-for-modern-networks/) наработки, связанные с платформой маршрутизации 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/).<br><br><br> Для управления доступен расширяемый CLI-интерфейс Breeze (https://github.com/facebook/openr/blob/master/openr/docs/Breeze.md), написанный на языке Python. Для интеграции с централизованными системами управления трафиком предоставляется API, позволяющих внешним обработчикам получать сведения о состоянии линков или https://89.19.215.112/openforum/vsluhforumID3/112772.html#66 Sat, 18 Nov 2017 17:06:28 GMT Останется, как IGP для MPLS или IGP для SDN, до момента когда контроллер возьмёт дело в свои руки. Я плохо знаком с архитектурой решений Facebook, поэтому мне вообще странно видеть внутри моста BGP, в качестве backplane, даже не знаю пока, как правильно называть то, что он заменяет в традиционных решениях. <br><br>Расскажите лучше, почему вы не любите OSPF? Я имею технические детали ваших претензий к нему, может и я стану его не любить. :)<br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#65 Sat, 18 Nov 2017 16:51:35 GMT &gt; Почему по-вашему там должен быть именно OSPF?<br><br>правильный вопрос - где у нас вообще останется ospf, если даже внутрисвитчевая маршрутизация почему-то "отличная идея" не на нем.<br>А на протоколе, изначально вообще-то рассчитанном на медленные линки и "подумаешь, потеряем пару тыщ пакетиков, пока сойдется".<br><br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#64 Sat, 18 Nov 2017 16:47:40 GMT &gt; Про случай с NAT, можно сделать стенд, поскольку такая конфигурация в принципе <br>&gt; для site-to-site не нормальна, для Remote Access вполне нормальна, да.<br><br>она не то что "нормальна", она скоро станет единственно-возможной. Потому что адреса денех стоют, и чем дальше, тем дороже. А v6 все никак "не готов для десктопа" ;-)<br>То есть можете его считать "remote access", только на практике за тем remote - офис окажется, человек на 200, и сетка у него тоже будет с фокусами.<br><br>Вы еще и обратно в асу же (в другие интерфейсы, другой контекст или в другую асу) будете этот траффик заворачивать из-за необходимости натить еще и внутреннюю адресацию по обоим сторонам.<br><br>Потому что каждый второй дятел думает что выбрав 172.20.0.0 вместо привычного 16 он всех перехитрил. (а остальные просто делают плоскую 10)<br><br>&gt; А вообще ASA заменяется сейчас активно на Firepower Threat Defense, который в <br><br>мечтать не вредно.<br>На деле с рынка именно файрволов циска уже безвозвратно вылетела, проспав модные тренды, да еще и пытаясь разв https://89.19.215.112/openforum/vsluhforumID3/112772.html#63 Sat, 18 Nov 2017 16:36:42 GMT &gt; При этом в туннеле должен быть EIGRP?<br><br>при этом должна быть хоть какая-то работающая маршрутизация.<br>Полагаю, в реальном случае, пособирав уже все собранные до вас давно грабли, вы придете к тому же, к чему и все - gre тунелю с поддерживающих gre устройств и bgp в туннеле, а в сторону асы - только статики для тунельных эндпоинтов.<br>Но это работает только в простых случаях, где без асы в общем-то обошлись бы вовсе.<br><br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#60 Sat, 18 Nov 2017 11:19:02 GMT &gt; привести в порядок можно за пару дней<br><br>Напоминает влажные мячты нашего руководства.<br>Обычно после заявлений вроде: "Это можно сделать за 15 минут" сервисы подымать приходится минимум месяц, а из клиентов делать дураков. Особенно тяжко приходится в такие периоды support'у&#8230;<br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#59 Sat, 18 Nov 2017 07:35:41 GMT Любитель заковыристых аббревиатур, должен сказать, что IS-IS впервые был представлен в IOS в 1993 году, тогда же, когда и EIGRP, то есть в один год. RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments, было представлено в 1990 году.<br><br>Основная цель реализации EIGRP по отношению к IGRP был переход на без классовую маршрутизацию, CIDR, - classless interdomain routing, представленный всё в том же 1993 году. IGRP поддерживал только классовую маршрутизацию, как и RIPv1, что потребовало его переориентации, а после вышел ещё и EIGRP for IPv6. А всё потому, что в отличие от IS-IS, OSPF, RIP, EIGRP, требуют переориентации для каждого нового протокола, в той или иной степени, даже, если это просто новая версия IP протокол, а не скажем Shortest Path Bridging какой-нибудь.<br><br>Я с радостью послушаю вашу точку зрения или ту, что изложена в тех книгах, что вы читали, по какой причине появился EIGRP, при имеющемся IGRP и отсутствующем у Cisco IS-IS до 1993 года, вообще.<br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#58 Sat, 18 Nov 2017 06:07:58 GMT Относительно site-to-site IPSec, не какой проблемы не обнаружил, IPSec VTI реализует поддержку передачи multicast трафика, в том числе и на ASA. <br><br>Классический IPSec туннель негде не способен обеспечить передачу multicast пакетов, ввиду чего требуется Unicast neighbor в случае EIGRP и point-to-multipoint neighbor в случае OSPF. <br><br>Про случай с NAT, можно сделать стенд, поскольку такая конфигурация в принципе для site-to-site не нормальна, для Remote Access вполне нормальна, да. <br><br>А вообще ASA заменяется сейчас активно на Firepower Threat Defense, который в будущем полностью заменит ASA, избавив от необходимости держать ASA и Firepower services раздельно в рамках одного устройства. <br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#57 Sat, 18 Nov 2017 05:25:38 GMT Как у вас получилось сравнить BFD и OSPF в рамках механизма обеспечивающего быструю сходимость всей сети?<br><br>Bidirectional Forwarding Detection протокол не может заменить IGP, поскольку кроме факта sub-second обнаружения сбоя соседа, он нечего больше предложить не может. <br><br>BGP протокол от этого не станет сходиться быстрее, хоть с BFD, хоть без него, по отношению к любому IGP, кроме RIP конечно. <br><br>P/S/ Единственное, что мне не нравится в беседах с вами, ваша мания величия. Вы так пренебрежительно говорите о других, будто вы по меньшей мере автор десятка RFC или CCAr, а вокруг одни неучи. Это вас совершенно не красит.<br> https://89.19.215.112/openforum/vsluhforumID3/112772.html#56 Sat, 18 Nov 2017 05:07:05 GMT &gt;&gt; Спасибо, почитаю.<br>&gt; будешь читать - обрати внимание, что _внутри_ свитча у них - bgp. <br>&gt; А не ospf, хотя, казалось бы, тут-то ему самое место ;-) <br><br>У Facebook кастомное решение, в котором по их мнению iBGP с route reflector это отличная идея. <br><br>Почему по-вашему там должен быть именно OSPF?<br>