Comments 36
1. Двух интерфейсов 10GE вам не хватит — чтобы RIPE выдал вам BGP AS, у вас должно быть как минимум два апстрима. Так что 10GE надо минимум три — два к апстримам и один в вашу сеть.
2. Нужен ли вам FullView? Договоритесь с апстримами, пусть отдадут вам, например, префиксы /16 и меньше. Роутинг будет не совсем оптимальный, но это будет не самой большой вашей проблемой.
3. Маршрутизировать 10Gbps виртуальной машине будет тяжко. А если ещё какую-нибудь фильтрацию пакетов добавить… Что Cisco что Juniper тут совершенно не напрасно используют TCAM, QFP и прочее.
2. Нужен ли вам FullView? Договоритесь с апстримами, пусть отдадут вам, например, префиксы /16 и меньше. Роутинг будет не совсем оптимальный, но это будет не самой большой вашей проблемой.
3. Маршрутизировать 10Gbps виртуальной машине будет тяжко. А если ещё какую-нибудь фильтрацию пакетов добавить… Что Cisco что Juniper тут совершенно не напрасно используют TCAM, QFP и прочее.
UFO just landed and posted this here
1. Да, пира должно быть два, чтобы выдали АС, но она у меня есть. Вы упустили из вида, что два интерфейса «на борту» и кроме них есть еще интерфейсный концентратор как у Juniper, так и у Cisco. У MX80 вообще 4 интерфейса и два слота под концентраторы. Как вариант я могу пирится с двумя провайдерами в точке обмена и одного интерфейса хватит. Но я писал не совсем о выборе подходящей платформы для задачи Х.
2. Фуллвью наверное не нужен, тем более поначалу. Тем не менее уже при двух соседях поднимется вопрос приоритезации. Уж не знаю как ваши провайдеры, а мне с трудом верится, что каждый из моих будет фильтровать как мне хочется — таких клиентов как я у них десятки и под каждого не нафильтруешься. И я не утверждал, что FullView жизненно необходим.
3. Ответили ниже )
2. Фуллвью наверное не нужен, тем более поначалу. Тем не менее уже при двух соседях поднимется вопрос приоритезации. Уж не знаю как ваши провайдеры, а мне с трудом верится, что каждый из моих будет фильтровать как мне хочется — таких клиентов как я у них десятки и под каждого не нафильтруешься. И я не утверждал, что FullView жизненно необходим.
3. Ответили ниже )
Понятно. У вас всё-таки есть минимум два аплинка, AS и сети для неё, и вы хотите их использовать надеясь в будущем купить маршрутизатор и/или сохранить некоторую независимость от аплинков. Ок, свою AS вы проаннонсируете со всеми community и prepend-ами, а что будете делать с исходящим трафиком? Если один аплинк, то ладно, вариантов всё равно нет. А если несколько и один из них упал внезапно?
Насчёт фильтрации префиксов на аплинках — для них это проза жизни. Посмотрите например что отдаёт Голден Телеком aka Sovam:
http://www.ripe.net/whois?AS3216
Кому full-view, кому default, а там несколько сотен клиентов. Часть таблицы признаю не встречал, но там дел то ровно на две строчки в конфигурации. Можете и на своей стороне фильтровать.
Насчёт фильтрации префиксов на аплинках — для них это проза жизни. Посмотрите например что отдаёт Голден Телеком aka Sovam:
http://www.ripe.net/whois?AS3216
Кому full-view, кому default, а там несколько сотен клиентов. Часть таблицы признаю не встречал, но там дел то ровно на две строчки в конфигурации. Можете и на своей стороне фильтровать.
RIPE «выдаст» ASN любому физ или юр лицу вовремя платящаму RIPE взносы, не более.
Формально Skyroger2 прав, в правилах получения АС указано, что должны быть договоренности с минимум двумя пирами для получения AS. Что это за договоры, будут ли они выполнятся и можно ли по-другому вопрос другой, но положение такое есть.
По комменту: что я собираюсь делать я писал — на даный момент обойдусь статикой на ядре. Если аплинков несколько можно сделать floating static, если линки идут к разным пирам. Для моей стаб-АС этого достаточно, по крайней мере пока.
Я посмотрел на AS3216 и они отдают или 0/0 или FullView. Ничего по поводу фильтрации по /16 (как в изначальном комменте) не увидел. И я очень сильно сомневаюсь, что они такое предложат каждому клиенту. «две строчки в конфигурации» помноженное на количество пиров превратятся в неподъемную работу. А если «мне» потом понадобится что-то поменять? В любом случае, мой пир такого делать не будет да и не об этом был пост.
По комменту: что я собираюсь делать я писал — на даный момент обойдусь статикой на ядре. Если аплинков несколько можно сделать floating static, если линки идут к разным пирам. Для моей стаб-АС этого достаточно, по крайней мере пока.
Я посмотрел на AS3216 и они отдают или 0/0 или FullView. Ничего по поводу фильтрации по /16 (как в изначальном комменте) не увидел. И я очень сильно сомневаюсь, что они такое предложат каждому клиенту. «две строчки в конфигурации» помноженное на количество пиров превратятся в неподъемную работу. А если «мне» потом понадобится что-то поменять? В любом случае, мой пир такого делать не будет да и не об этом был пост.
UFO just landed and posted this here
Я писал, что это только один из вариантов. Если вам интересно как может решение масштабироваться, что и зачем нужно, и как изменится, можем подумать вместе.
Получать на кору через BGP? Такой вариант приведен на втором рисунке. Признаю, там он называется PartView, он же PartialView. Однако в вырожденом варианте PartialView=0/0.
«Получать» статикой? Тогда я действительно некстати, но я об этом писал вначале статьи.
Получать на кору через BGP? Такой вариант приведен на втором рисунке. Признаю, там он называется PartView, он же PartialView. Однако в вырожденом варианте PartialView=0/0.
«Получать» статикой? Тогда я действительно некстати, но я об этом писал вначале статьи.
apt-get install exabgp
Цена? Ну, давайте считать. Если использовать raspberry pi — то баксов 30. Если нормальный сервер — тыщи три.
Цена? Ну, давайте считать. Если использовать raspberry pi — то баксов 30. Если нормальный сервер — тыщи три.
Вы определенно к чему-то ведете, но пока не могу понять к чему.
Ведет он к тому что exabgp можеть менять любые bgp атрибуты что in что out
Производительность правда у exabgp так себе если сравнить с очень быстрым bird
Производительность правда у exabgp так себе если сравнить с очень быстрым bird
Признаю, не слышал про exabgp, как и о многих других вещах — глупо это пытаться скрыть. Однако если я правильно толкую «exabgp можеть менять любые bgp атрибуты что in что out» нам нужен BGP между устройствами. Соответственно в моей статье это будет пункт 2 или 3. Для пункта 2 это избыточно — просто менять атрибуты я могу и на ядре. Для пункта 3 слишком мало — там идея в организации машины, которая будет иметь FullView или несколько для возможности локалькой сумаризации/приоритезации. К тому же целью моих изысканий являлся полный уход от BGP из-за лицензионной стоимости. И таки да, raspberry pi — сомнительно, что он вместит таблицу и будет обрабатывать достаточно быстро.
Вот когда мы экономим на дорогущем хардварном роутере, который будет испольщовать функционал на 7% — это как бы понятно.
Но вот когда экономим на лицензии в угоду адово костыльного решения — это уже ИМХО бред.
Вы что, из своего кармана эту лицензию покупаете?
Но вот когда экономим на лицензии в угоду адово костыльного решения — это уже ИМХО бред.
Вы что, из своего кармана эту лицензию покупаете?
Когда цена лицензии сопоставима с дорогущим хардварным роутером, тут тоже есть над чем задуматься. В целом вынести весь control plane с BGP на отдельную виртуалку — идея очень интересная и я бы не сказал, что это костыль.
Так я под костылем подразумевал не вынос control plane на виртуалку. А доставку результатов работы этого самого control plane на свич костыльными методами. Ну и не стоит лицензия на BGP для коммутатора как новый ASR,
Я конечно может неправильно сделал, что опустил этот момент — думал это маловажная информация, так как я сосредотачивался больше на границе и взаимодействию устройств. Но давайте я исправлюсь.
Ядро у меня будет состоять из двух EX4550, соответственно 10Гб/с интерфейсы у меня уже в наличии. К ядру будут подключаться сервера с VMWare — виртуалки у меня тоже есть.
Ядро объединено в виртуальное шасси, соответственно стоимость лицензии возрастает в два раза — ее нужно покупать для каждого routing-engine в шасси. Итого 20 тыс.долл. Вот вам и стоимость ASR. У циски думаю ситуация не будет отличаться — если объединять нексусы в VSS или подобное решение, feature set должен совпадать, итого 18тыс.долл. согласно GPL.
По поводу костыля с доставкой не соглашусь — так любую манипуляцию можно назвать: препенд, приоритет, изменение административного расстояния. А мои идеи особо не отличаются от скажем препенда, разве что не реализованы нативно на оборудовании. К тому же я не заставляю поступать именно так — вариант крутить iBGP между виртуалкой и ядром в описании присутствует.
Ядро у меня будет состоять из двух EX4550, соответственно 10Гб/с интерфейсы у меня уже в наличии. К ядру будут подключаться сервера с VMWare — виртуалки у меня тоже есть.
Ядро объединено в виртуальное шасси, соответственно стоимость лицензии возрастает в два раза — ее нужно покупать для каждого routing-engine в шасси. Итого 20 тыс.долл. Вот вам и стоимость ASR. У циски думаю ситуация не будет отличаться — если объединять нексусы в VSS или подобное решение, feature set должен совпадать, итого 18тыс.долл. согласно GPL.
По поводу костыля с доставкой не соглашусь — так любую манипуляцию можно назвать: препенд, приоритет, изменение административного расстояния. А мои идеи особо не отличаются от скажем препенда, разве что не реализованы нативно на оборудовании. К тому же я не заставляю поступать именно так — вариант крутить iBGP между виртуалкой и ядром в описании присутствует.
Не очень понял вашей проблемы.
Quagga не поняла вашу попытку анонсировать third-party nexthop (судя по тому, что удалось найти — в OSPF такой режим поддерживается)?
Варианта два:
1. Она это умеет, но вы не поняли как. Читать документацию, искать в интернете.
2. Она этого не умеет. Просить разработчиков реализовать новую функцию, либо самостоятельно пропатчить.
p.s. Покопался в документации, ответа на ваш вопрос не нашел. Тогда можно сразу пойти по п. 2 — сделать грязный хак, проверить корректную работу с вашим маршрутизатором и если проблем не будет, то делать уже правильно.
p.p.s. А ваш маршрутизатор сможет держать все записи BGP Full View, но полученные через OSPF (да ещё и с двух разных аплинков)?
Quagga не поняла вашу попытку анонсировать third-party nexthop (судя по тому, что удалось найти — в OSPF такой режим поддерживается)?
Варианта два:
1. Она это умеет, но вы не поняли как. Читать документацию, искать в интернете.
2. Она этого не умеет. Просить разработчиков реализовать новую функцию, либо самостоятельно пропатчить.
p.s. Покопался в документации, ответа на ваш вопрос не нашел. Тогда можно сразу пойти по п. 2 — сделать грязный хак, проверить корректную работу с вашим маршрутизатором и если проблем не будет, то делать уже правильно.
p.p.s. А ваш маршрутизатор сможет держать все записи BGP Full View, но полученные через OSPF (да ещё и с двух разных аплинков)?
Чтобы не было двусмыслености под «third-party nexthop». В моем случае это передача достижимости сети через next-hop, который не является адресом интерфейса, соединяющего маршрутизаторы. Ни Quagga ни BIRD не позволяют изменить next-hop в этом смысле. Испробованые варианты я описал, вроде других доступных мест для изменения нет.
1. Если вы имели ввиду приведенный мной линк о forwarding address (http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13682-10.html), тогда это не то. Во-первых топология отличается, а с ней и вся логика. Во-вторых его нельзя настроить вручную — он либо работает сам или нет — решает железка согластно своим «ощущениям».
2. К вопросу о «жутком костыле» из предыдущего коммента. Но на самом деле это именно то, куда я двигаюсь.
p.p.s. Если под маршрутизатором вы имеете ввиду устройство ядра (колторое на самом деле L3 свич), то нет FullView он держать не сможет и я упоминал об этом. Вопрос передачи FullView через IGP туда же — это может и реально, но слишком нереально.
Но давайте подучаем вот о чем — а зачем нам собственно FullView? И раз уж в комментариях появились недовольства моими упрощениями, проанализируем ситуацию с несколькими FullView от нескольких провайдеров. Тем не менее, тип моего ISP важен: это провайдер прежде всего для конечных пользователей, не агрегатор других ISP или транзит. Итак, FullView нам нужен для оптимального выбора маршрута из множества возможных, которые нам высылают провайдеры — где-то дешевле, где-то быстрее, где-то короче. В таком случае апстримов будет два-три — в основном для избыточности, но и для балансировки тоже. В случае моего ISP необходимо будет наделять приоритетом достаточно ограниченое количество сетей — к примеру принадлежащих стране или датацентру (Amazon во Франкфурте как один из вариантов). На самом деле это вполне себе экзотика — многие пользуются обычным 0/0 ко всем провайдерам, но все же. Я пока не имел опыта с приоритезацией выхода на страну/датацентр, но рискну предположить, что это вполне может уложиться в те 14-16 тыс маршрутов, поддерживаемых устройствами ядра.
1. Если вы имели ввиду приведенный мной линк о forwarding address (http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13682-10.html), тогда это не то. Во-первых топология отличается, а с ней и вся логика. Во-вторых его нельзя настроить вручную — он либо работает сам или нет — решает железка согластно своим «ощущениям».
2. К вопросу о «жутком костыле» из предыдущего коммента. Но на самом деле это именно то, куда я двигаюсь.
p.p.s. Если под маршрутизатором вы имеете ввиду устройство ядра (колторое на самом деле L3 свич), то нет FullView он держать не сможет и я упоминал об этом. Вопрос передачи FullView через IGP туда же — это может и реально, но слишком нереально.
Но давайте подучаем вот о чем — а зачем нам собственно FullView? И раз уж в комментариях появились недовольства моими упрощениями, проанализируем ситуацию с несколькими FullView от нескольких провайдеров. Тем не менее, тип моего ISP важен: это провайдер прежде всего для конечных пользователей, не агрегатор других ISP или транзит. Итак, FullView нам нужен для оптимального выбора маршрута из множества возможных, которые нам высылают провайдеры — где-то дешевле, где-то быстрее, где-то короче. В таком случае апстримов будет два-три — в основном для избыточности, но и для балансировки тоже. В случае моего ISP необходимо будет наделять приоритетом достаточно ограниченое количество сетей — к примеру принадлежащих стране или датацентру (Amazon во Франкфурте как один из вариантов). На самом деле это вполне себе экзотика — многие пользуются обычным 0/0 ко всем провайдерам, но все же. Я пока не имел опыта с приоритезацией выхода на страну/датацентр, но рискну предположить, что это вполне может уложиться в те 14-16 тыс маршрутов, поддерживаемых устройствами ядра.
Ни Quagga ни BIRD не позволяют изменить next-hop в этом смысле.
Да, не умеют. Я имел в виду то, что сам протокол OSPF поддерживает такую возможность (т.е. IP адрес next-hop'а не обязан совпадать с IP адресом OSPF маршрутизатора), а значит можно просто пропатчить Quagga, проверить как к этому отнесутся ваши железки (вдруг они не поддерживают?) и если всё ok — сделать нормальный патч.
Можете привести пример возможности OSPF передавать кастомный next-hop? Потому как у меня это не получилось.
Покопался немного в спеках, получается вот что.
Спека по самому протоколу: https://www.ietf.org/rfc/rfc2328.txt
Раздел
В структуре пакета есть поле:
Более того, есть даже прямое упоминание о необходимом вам функционале:
Т.е. разработчики заложили данную фичу много-много лет назад.
Спека по самому протоколу: https://www.ietf.org/rfc/rfc2328.txt
Раздел
A.4.5 AS-external-LSAs описывает Link State Advertisement от boundary router'ов, это наш случай.В структуре пакета есть поле:
Forwarding address
Data traffic for the advertised destination will be forwarded to
this address. If the Forwarding address is set to 0.0.0.0, data
traffic will be forwarded instead to the LSA's originator (i.e.,
the responsible AS boundary router).
Более того, есть даже прямое упоминание о необходимом вам функционале:
The "forwarding address" has one other application. It enables
routers in the Autonomous System's interior to function as
"route servers". For example, in Figure 2 the router RT6 could
become a route server, gaining external routing information
through a combination of static configuration and external
routing protocols. RT6 would then start advertising itself as
an AS boundary router, and would originate a collection of OSPF
AS-external-LSAs. In each AS-external-LSA, Router RT6 would
specify the correct Autonomous System exit point to use for the
destination through appropriate setting of the LSA's "forwarding
address" field.Т.е. разработчики заложили данную фичу много-много лет назад.
Я не отрицаю, что возможность передавать другой next-hop могла быть заложена разработчиками протокола. Здесь только одно «но» — спецификация и реализация иногда не совпадают. Кстати, о forwarding address и как его видит Cisco я упоминал в статье и вот еще раз ссылка http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13682-10.html. Почитайте — там от описанного выше изящества ровным счетом ничего плюс куча ограничений. Поймите меня правильно — я не пытаюсь защищаться отрицанием предложений, наоборот — мне нравится Ваши идеи, настрой и в общем наш спор.
Ну а если трактовать RFC как таковой, то да — это именно то, что нужно. Если удастся реализовать на практике — готовое решение для мелких стаб-СП. Я как уже упоминалось в посте смотрел на этот функционал, но только у Cisco он работает не совсем так, как мне нужно, а у Juniper примеров реализации не нашел. Тем не менее, благодарю за настойчивость и выдержку из RFC — в ближайшее время появится натурный стенд и чуть больше времени для обкатки, будем пробовать.
Ну а если трактовать RFC как таковой, то да — это именно то, что нужно. Если удастся реализовать на практике — готовое решение для мелких стаб-СП. Я как уже упоминалось в посте смотрел на этот функционал, но только у Cisco он работает не совсем так, как мне нужно, а у Juniper примеров реализации не нашел. Тем не менее, благодарю за настойчивость и выдержку из RFC — в ближайшее время появится натурный стенд и чуть больше времени для обкатки, будем пробовать.
Покопался в возможностях микротиков, очень похоже, что именно они помогут решить вашу проблему.
В настройках OSPF можно повесить исходящие фильтры, среди прочего в фильтре можно выставить «set out nexthop».
https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters
OSPF у меня на микротиках используется скорее «чтобы было» и на point-to-point линке.
Проверил, на таком типе линка фокус не прошел (пытался выставить «левый» nexthop), но на обычном (не point-to-point) линке финт может и сработать. Можно попробовать воспроизвести вашу схему, но не знаю, когда до этого дойдут руки.
Попробуйте микротик.
ISO'шку для установки в виртуалку можно скачать с их сайта, если всё понравится и заработает как надо, то купите лицензию.
В настройках OSPF можно повесить исходящие фильтры, среди прочего в фильтре можно выставить «set out nexthop».
https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters
OSPF у меня на микротиках используется скорее «чтобы было» и на point-to-point линке.
Проверил, на таком типе линка фокус не прошел (пытался выставить «левый» nexthop), но на обычном (не point-to-point) линке финт может и сработать. Можно попробовать воспроизвести вашу схему, но не знаю, когда до этого дойдут руки.
Попробуйте микротик.
ISO'шку для установки в виртуалку можно скачать с их сайта, если всё понравится и заработает как надо, то купите лицензию.
То есть вы готовы платить за два 10г Линка, но приобрести маршрутизатор который способен с ними работать не готовы? Странный подход немного, можно рассмотреть решение с двумя 5г линками но без описываемых костылей. Или это не вариант?
Вы говорите что цена виртуалки ничтожна, это не совсем так, цена есть и она не такая маленькая как вам кажется, если на запускать это на обычных ПС с какой то дешёвой 10г картой.
Проблема third party next hop свойственна всем link-state протоколам by-design, и попытки изменить это поведения являются костылем
Вы можете использовать любой distance vector protocol:rip, eigrp, bgp который позволяют манипулировать next-hop нативно
FA filtering должен работать для OSPF, но я б в продакшн это не рекомендовал
Рекомендую посмотреть на проект FRR ( Free Range Routing) и забыть про кваги
Вы говорите что цена виртуалки ничтожна, это не совсем так, цена есть и она не такая маленькая как вам кажется, если на запускать это на обычных ПС с какой то дешёвой 10г картой.
Проблема third party next hop свойственна всем link-state протоколам by-design, и попытки изменить это поведения являются костылем
Вы можете использовать любой distance vector protocol:rip, eigrp, bgp который позволяют манипулировать next-hop нативно
FA filtering должен работать для OSPF, но я б в продакшн это не рекомендовал
Рекомендую посмотреть на проект FRR ( Free Range Routing) и забыть про кваги
Одобрение коммента немного растянулось во времени, поэтому на часть вопросов уже ответил…
Если под «То есть вы готовы платить за два 10г Линка...» вы имели ввиду оплату линка к провайдеру, то они на самом деле не очень дорогие, во всяком случае не 20тыс.долл. со старта. Если имелось ввиду оборудование, которое в принципе может терминировать 10Гб/с, то частично ответ выплывает из предыдущих комментариев — ядро агрегирует сервера с виртуалками и там необходимо иметь порты 10Гб/с. Позаимствовать пару портов под задачу подключения к провайдеру не проблема и виртуальная машина соответвенно тоже есть. Кроме этого, если 10Гб/с устройства нет, всегда есть модули аплинков на младших моделях свичей, например EX4200, на котором тоже можно запустить BGP. Можно еще посмотреть в сторону exabgp из комментариев, если цена виртуальной машины смущает.
По поводу distance-vector протоколов проверю и отпишусь, но уточню, что моей задачей было избежать использования BGP, так как с ним все и так работает, однако стоит дополнительных денег на лицензию.
FRR ( Free Range Routing) если я правильно прочитал это еще одна «вариация на тему». До тех пор пока они не будут поддерживать изменения всего-и-везде, это просто еще один из вариантов, не более. Итак, если с помошью FRR нельзя поменять forwarding address в OSPF или подобное, эта технология не для данной задачи. Поймите меня правильно — я не обсираю проект как таковой, но у меня четко определенная задача с которой на текущий момент не справились Quagga и BIRD.
Позволю себе повториться еще раз — ЕСТЬ решения данной проблемы, однако они требуют поддержки со стороны сети, что выливается или в стоимость лицензии или в закупку нового оборудования. Моя идея — отказ от необходимости покупки оборудования или модулей, которые не будут использоваться остальной сетью: у меня есть 10Гб/с свич, который мне нужен by-design и мне хочется, чтобы покупка этого свича была единственными расходами на инфраструктуру. Не потому, что денег нет, а потому что зачем платить 17к долларов за устройство, которое будет принимать несколько фулл-вью и отдавать ядру 0/0 или PatrialView?
Если под «То есть вы готовы платить за два 10г Линка...» вы имели ввиду оплату линка к провайдеру, то они на самом деле не очень дорогие, во всяком случае не 20тыс.долл. со старта. Если имелось ввиду оборудование, которое в принципе может терминировать 10Гб/с, то частично ответ выплывает из предыдущих комментариев — ядро агрегирует сервера с виртуалками и там необходимо иметь порты 10Гб/с. Позаимствовать пару портов под задачу подключения к провайдеру не проблема и виртуальная машина соответвенно тоже есть. Кроме этого, если 10Гб/с устройства нет, всегда есть модули аплинков на младших моделях свичей, например EX4200, на котором тоже можно запустить BGP. Можно еще посмотреть в сторону exabgp из комментариев, если цена виртуальной машины смущает.
По поводу distance-vector протоколов проверю и отпишусь, но уточню, что моей задачей было избежать использования BGP, так как с ним все и так работает, однако стоит дополнительных денег на лицензию.
FRR ( Free Range Routing) если я правильно прочитал это еще одна «вариация на тему». До тех пор пока они не будут поддерживать изменения всего-и-везде, это просто еще один из вариантов, не более. Итак, если с помошью FRR нельзя поменять forwarding address в OSPF или подобное, эта технология не для данной задачи. Поймите меня правильно — я не обсираю проект как таковой, но у меня четко определенная задача с которой на текущий момент не справились Quagga и BIRD.
Позволю себе повториться еще раз — ЕСТЬ решения данной проблемы, однако они требуют поддержки со стороны сети, что выливается или в стоимость лицензии или в закупку нового оборудования. Моя идея — отказ от необходимости покупки оборудования или модулей, которые не будут использоваться остальной сетью: у меня есть 10Гб/с свич, который мне нужен by-design и мне хочется, чтобы покупка этого свича была единственными расходами на инфраструктуру. Не потому, что денег нет, а потому что зачем платить 17к долларов за устройство, которое будет принимать несколько фулл-вью и отдавать ядру 0/0 или PatrialView?
Дожились, уже BGP на raspberry pi тулим или это raspberry pi разжилось… В любом случае прикольно )
Что касается идеи, лично мне понравилась. Решение не универсальное, и будет иметь часть ограничений, но всё же не стандартный подход — отлично.
Что касается лицензирования. Как я понял в этом варианте можно получить FW, и отдать на forwarding-plane уже агрегированные маршруты. Быть может есть какие то L3 в forwarding-plane, кто позволит за не дорого иметь несколько тыс. маршрутов полученных по bgp. Вот в это и упираться, а с балансировкой нескольких каналов, можно решить меньшей/большей маской отправляемой на forwarding-plane.
Что касается идеи, лично мне понравилась. Решение не универсальное, и будет иметь часть ограничений, но всё же не стандартный подход — отлично.
Что касается лицензирования. Как я понял в этом варианте можно получить FW, и отдать на forwarding-plane уже агрегированные маршруты. Быть может есть какие то L3 в forwarding-plane, кто позволит за не дорого иметь несколько тыс. маршрутов полученных по bgp. Вот в это и упираться, а с балансировкой нескольких каналов, можно решить меньшей/большей маской отправляемой на forwarding-plane.
Raspberry вообще штука интересная. К тому же для него стандартен Raspbian, то есть урезаный Debian. Не удивлюсь, если Quagga или BIRD уже портированы для него плюс идея с exabgp из комментария. Ограничение даного варианта я уже описал.
Ваше понимание верно — получая FW на виртуалку (raspberry?) мы получаем возможность самостоятельно фильтровать и приоритезировать маршруты. И таки да, большинство L3 свичей без проблем держат 10+ тысяч маршрутов. Агрегируя FW к примеру в 4 маршрута по /2 можно объединить таблицу и уже оперировать этими маршрутами. Я кстати думал так сделать в начале своей работы на текущем мпесте, но потом оказалось, что основной провайдер + резервный — это максимум, что необходимо для наших потребностей.
Докупать ли лицензию и получить нативную возможность манипуляции next-hop или использовать мой «костыль» это уже дело личных преференций. А wire-speed маршрутизация при отсутствии потребности в продвинутых фичах довольно весомый агрумент «за».
Ваше понимание верно — получая FW на виртуалку (raspberry?) мы получаем возможность самостоятельно фильтровать и приоритезировать маршруты. И таки да, большинство L3 свичей без проблем держат 10+ тысяч маршрутов. Агрегируя FW к примеру в 4 маршрута по /2 можно объединить таблицу и уже оперировать этими маршрутами. Я кстати думал так сделать в начале своей работы на текущем мпесте, но потом оказалось, что основной провайдер + резервный — это максимум, что необходимо для наших потребностей.
Докупать ли лицензию и получить нативную возможность манипуляции next-hop или использовать мой «костыль» это уже дело личных преференций. А wire-speed маршрутизация при отсутствии потребности в продвинутых фичах довольно весомый агрумент «за».
Как вариант (на фоне других вполне даже рабочий и имеющий право на жизнь): у Микротика есть роутеры с 10Гб портами, а именно:
CCR1036-8G-2S+ (8x Gigabit Ethernet, 2xSFP+ cages, 36 cores x 1.2GHz CPU, 4GB RAM, Up to 28Gbit/s) за $1095
CCR1036-8G-2S+EM (8x Gigabit Ethernet, 2xSFP+ cages, 36 cores x 1.2GHz CPU, 16GB RAM, Up to 28Gbit/s) за $1295
и
CCR1072-1G-8S+ (1x Gigabit Ethernet, 8xSFP+ cages, 72 cores x 1GHz CPU, 16GB RAM, 80Gbps) за $3050
BGP вполне держит, работает достаточно хорошо, и уж под вашу задачу, думаю, вполне подойдут. Причем, если пары SFP+ вам хватит (это если у вас только один 10Гб аплинк, а остальной(-ые) не более 1Гб, то даже первой из приведенных машинок хватит) — то взять пару штук за $2k, и закрыть вопрос.
CCR1036-8G-2S+ (8x Gigabit Ethernet, 2xSFP+ cages, 36 cores x 1.2GHz CPU, 4GB RAM, Up to 28Gbit/s) за $1095
CCR1036-8G-2S+EM (8x Gigabit Ethernet, 2xSFP+ cages, 36 cores x 1.2GHz CPU, 16GB RAM, Up to 28Gbit/s) за $1295
и
CCR1072-1G-8S+ (1x Gigabit Ethernet, 8xSFP+ cages, 72 cores x 1GHz CPU, 16GB RAM, 80Gbps) за $3050
BGP вполне держит, работает достаточно хорошо, и уж под вашу задачу, думаю, вполне подойдут. Причем, если пары SFP+ вам хватит (это если у вас только один 10Гб аплинк, а остальной(-ые) не более 1Гб, то даже первой из приведенных машинок хватит) — то взять пару штук за $2k, и закрыть вопрос.
Согласен, весьма интересные железки. Вариантов производителей и моделей на самом деле масса, но все-таки моя идея была не об этом, а о том что этот маршрутизаторный хоп на самом деле не выполняет в некоторых случаях никакой полезной работы за исключением собственно BGP сессии и в этих случаях можно от него отказаться.
интересно, жаль что в своё время пропустил эту статью. Интересная дискусия могла тогда получиться. Я что-то подобное делал для EIGRP и CGMP. habr.com/ru/post/262047
Подозреваю, что если б вы тогда её нашли тоже было бы намного проще всё)
Подозреваю, что если б вы тогда её нашли тоже было бы намного проще всё)
Снимаю шляпу перед полётом мысли вашей статьи. Собственно самое обидное это то, что в спецификации OSPF искомая фича есть, но по загадочной причине отказывается работать. Правда с учётом нынешней стоимости железа на вторичном рынке и цены ошибки/бага подобные инженерные выкрутасы становятся менее актуальными.
Вопрос немного в воздух: а никто на практике не использовал топовые микротики (например CCR1072-1G-8S+) для подобных задач? BGP Full view с нагрузками билизкими к 10Gb/s?
Ценник там получается, скажем там, несколько отличный от -тцати тысяч долларов.
Ценник там получается, скажем там, несколько отличный от -тцати тысяч долларов.
Так вы посмотрите на сайт микротика, там всё есть. «CCR1072 is capable of over 120 million packets per second throughput». Там же есть и результаты нагрузочных тестов mikrotik.com/product/CCR1072-1G-8Splus#fndtn-testresults
Sign up to leave a comment.
Inter-AS routing. Можно ли сэкономить на BGP маршрутизаторе?