Inter-AS routing. Можно ли сэкономить на BGP маршрутизаторе?

    В качестве предисловия: вчера представил приведенные ниже идеи на локальной сходке администраторов. После презентации ко мне подошел представитель компании, занимающейся производством сетевого оборудования и спросил: «Ты публиковал это где-то? Поделись презентацией, я отправлю коллегам посмотреть.» Собственно, а почему бы и не опубликовать? Как говорят у нас в Украине «i ми, Химко, люди». Если уж кто-то из вендоров, хотя бы отдаленно, но заинтересовался, то и в коммьюнити найдется человек, которому идеи тоже покажутся интересными. Кроме этого, я и сам планирую использовать это решение. Сразу скажу, что 100% готового результата не будет, но будет некий промежуточный, которого достаточно для эрзац-роутинга и немного информации для продолжения работ в данном направлении. Поехали!

    Сразу скажу — в заголовке статьи речь идет именно о маршрутизаторе, физическом устройстве, а не протоколе BGP. И нет, без протокола BGP жить не получится, по крайней мере пока, — но это вы и сами знаете. Зачем нужен протокол, чем он хорош, что позволяет сделать и как его настраивать — об этом написаны массы книг и статей как на Хабре, так и на сторонних ресурсах, посему данную тему опущу. Если вам хватает статики или в соседней автономной системе работает тварищ, которого можно просить изменять политики анонсов, можно смело закрывать пост — вам эта информация не нужна.

    Если вы все еще читаете, позволю себе начать с дизайна, так как статья больше о проектировании решения, нежели о самом решении. Итак, мы — сервис-провайдер ISP A, имеющий одноименный пул адресов и необходимость анонса этих адресов в Сеть. Общая схема логических связей приведена на рисунке.

    image

    На границе нашей сети стоит маршрутизатор RTR A, который связан eBGP сессией с пиром-соседом. Через сессию протокола мы получаем FullView от соседа с указанием адреса следующейго перехода (next-hop) — IP адреса RTR B. В ответ — отдаем информацию о наших внутренних сетях с указанием next-hop RTR A. Сразу отмечу, что это лишь одна из множества возможных схем организации BGP соседства: маршрутизаторов на границе может быть несколько, равно как и соседей, сами соседи могут быть подключены не напрямую, мы можем получать больше одного FullView, резервировать каналы и прочее. Однако я позволю себе опустить анализ разнообразных схем организации пиринга и резервирования, и остановиться на простейшем случае — сути это не поменяет, а понимание упростит. Внутри нашей автономной системы работает IGP, посредством которого мы передаем достижимость сетей ISPA. Или не работает — это опять-таки лишь один из возможных вариантов.

    Пользовательский трафик проходит через ядро CoreA, маршрутизатор RTR A и уходит дальше в Сеть. В моем понимании это (со всеми возможными вариациями) классический метод организации периметра сети и соседства BGP. Теперь посмотрим сколько стоит данное аппаратное решение.

    Я буду отталкиваться от необходимой пропускной способности в 10Гб/с. Как минимум в решении должны присутствовать 10Гб/с интерфейсы с возможностью дальнейшего апгрейда. Juniper предлагает решение MX104-40G (или как вариант MX80) за 40 тыс.долл. с двумя (четырмя для MX80) 10Гб/с интерфейсами «на борту» и производительностью маршрутизации в 40Гб/с (80 — для MX80). Cisco отвечает устройством Cisco ASR 1001-X с базовой производительностью 2,5Гб/с и двумя 10Гб/с интерфейсами «на борту» за 17 тыс.долл + цена лицензии на улучшение производительности (до 20Гб/с) и активацию дополнительных интерфейсных слотов. Сразу скажу, что я не ставил перед собой задачу срогого сравнения устройств — в конце концов пост не об этом, но какие-то цифры нужны, так как наша основная задача снизить стоимость решения.

    Итак, минимум 17 тыс.долл. Что полезное делает наш маршрутизатор RTRA? Да в общем-то немного — крутит BGP сессию (или несколько) с соседом и форвардит трафик в Сеть. Можно ли обойтись без него? Для ответа проанализируем следующую топологию.

    image

    Мы убрали физический маршрутизатор и запустили пиринг BGP на устройстве ядра. Можно ли так? Да, благо сорвеменные L3 коммутаторы поддерживают запуск BGP. Однако в этом решении есть как минимум два слабых места. Первое — большинство коммутаторов не были созданы для полноценной маршрутизации, и поэтому имеют ограниченый размер таблицы маршрутизации. Например, Juniper EX4550 имеет ограничение в 14000 IPv4 юникаст-маршрутов, а Cisco Nexus3k — 16000. Второе — чтобы запустить BGP понадобится докупить лицензию, а это стоит 8 (Cisco Nexus3k) или 10 (Juniper EX4550) тыс.долл. Если нам понадобится резервирование коммутаторов, это удвоит приведенные цифры. Кроме этого, понадобится договариваться с вышестоящим провайдером для суммирования сетей, ну или получать маршрут по-умолчанию. Тем не менее, такой дизайн все-же позволятет отказаться от покупки выделенного маршрутизатора и в то же время пользоваться полезными плюшками BGP. Еще одна возможная вариация на эту тему приведена ниже.

    image

    Мы запускаем BGP процесс на физическом сервере или виртуальной машине, которая крутит eBGP сессию с RTRB и iBGP — с устройством ядра. На виртуалке устанавливаем один из доступных пакетов для запуска BGP, например Quagga, Vyatta или BIRD.

    Одной из прекрасных возможностей протокола BGP является возможность изменения next-hop при анонсе обновлений, ей мы и воспользуемся для того, чтобы избежать ситуации, когда пользовательский трафик необходимо форвардить через BGP спикера. То есть мы как-бы разделяем устройства, которые обладают маршрутной информацией (виртуалка) и устройства, которые занимаются пересылкой трафика (CoreA) внутри автономной системы. Соответственно, RTRB получает в качестве next-hop адрес CoreA и наоборот. Такой себе control-plane vs forwarding-plane. Сама идея не нова и активно используется при организации точек обмена, только посредством eBGP сессий.

    Это уже более интересный сценарий, так как теперь мы можем получать как FullView, так и несколько таковых, осуществлять фильтрацию и суммирование маршрутов локально, не прибегая к звонку провайдеру. Еще одной интересной особенностью решения является то, что нам не нужно даже наполнять таблицу ядра на виртуальной машине с BGP. Те, кто сталкивался с настройкой, например, Quagga знают, что нужно во-первых нужно включить опцию «ip forwarding» и затем передать маршруты, которые получил демон в ядро (ну или таблицу маршрутизации хоста) для корректного форвардинга трафика. Так вот, это все лишнее — виртуалка занимается только анонсом BGP информации и в продвижении трафика не участвует, а наполнение таблицы внутри Quagga занимает столько времени, сколько нужно для передачи непосредственно объема маршрутной таблицы — секунд 10.

    Это уже больше похоже на искомое решение, но вопрос с лицензией остается, ведь виртуалка и CoreA общаются посредством BGP. Есть ли еще варианты? Можно ли обойтись без лицензионного сбора? И тут мы подходим к главной соли данного поста. Взглянем на топологию.

    image

    Основная идея та же — запустить eBGP на виртуалке, но внутри автономной системы уже использовать какой-нибудь IGP протокол, к примеру как на рисунке, OSPF. Часть с eBGP сессией осталась неизменной и здесь все еще нет проблем. А вот с IGP они есть — ведь ни один из них не был предназначен для передачи non-directly connected next-hop, уж извините за обилие английских слов. Кроме прочего, Nexus3k требует лицензию и для OSPF, но это уже детали — у меня в сети Juniper, а для Нексуса можно использовать RIP :). Так или иначе, передать другой next-hop нужно, так как в противном случае пользовательский трафик пойдет через виртуалку, а такое решение не годится. Соответственно нам нужен некий костыль, который позволит «невозможное» — передать другой, не локальный, next-hop при анонсе маршрута. При обкатке идеи я пробовал следующие варианты:

    • Изменение next-hop при редистрибуции BGP->OSPF
    • Изменение next-hop в исходящей политике OSPF
    • Изменение next-hop во водящей политике OSPF
    • Изменение next-hop при экспорте в forwarding table на устройстве Juniper

    Кстати, о последнем пункте — экспорт в forwarding table — с его помощью можно осуществлять per-flow BGP ECMP, во всяком случае на Juniper. Если кому-то будет интересно, могу кинуть конфиг в благодарность за то, что вы уделили внимание посту.

    Так вот, к сожалению, все вышеперечисленное не работает. Qugga и Juniper тихо игнорировали мои ковыряния в политиках, а BIRD сразу ругался при попытке изменения параметра «next-hop» в анонсе. Вот так банально и обидно моя идея разбилась о скалы непонимания со стороны производителей. В процессе работы я даже загуглил проблему и оказалось не один я такая хитрая ж., но решения по факту не было, разве что указали на то, что у Cisco есть фича «forwarding address» (почитать можно здесь), но это не то.

    Уже почти отчаявшись, я обратился за помощью к коллегам. Андрушко Дмитрий, Коваленко Александр (@alk0v) и Симоненко Дмитрий, спасибо — страна должна знать своих героев! Итак, варианты есть.

    Первое — есть уже готовое решение для программно-определяемых сетей под названием проект Atruim (почитать). Кроме этого, если я правильно расслышал, Mellanox занимается производством устройств с Quagga/BIRD внутри. Собственно говоря, SDN клевая штука — делай что хочешь и как хочешь. Но это SDN и новое оборудование, а у меня задача решить все на существующем.

    Далее, если я правильно понял («если» — главное слово, так как я не силен в *NIXах), демоны в Quagga (например, ospfd) общаются с ядром через модуль iproute2 и чисто теоретически можно перехватить пакет на выходе из ospfd и модифицировать его. Уж не знаю правильно ли я думаю и возможно ли это, но как-то так.

    Ну и напоследок железный вариант — Scapy, который позволяет генерировать пакеты с заданым содержимым. И в самом деле — структура OSPF пакета нам известна, что и на какое значение менять тоже. Дело за малым — реализовать это. Вот здесь я и остановился на данный момент.

    То как я себе представляю решение — оно прежде всего должно быть динамическим. В противном случае зачем все эти танцы с протоколами? По поему мнению можно даже поднимать одну виртуалку для каждого eBGP пира — цена виртуальной машины ничтожна, а такое упрощение позволит просто модифицировать все исходящие OSPF пакеты, меняя один next-hop на другой.

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

    Я понимаю, что такое решение не подойдет для транзитных автономных систем и мест, где нужны дополнительные сервисы вроде MPLS. Возможны еще проблемы с геофильтрацией, или точнее приоритезацией конкретного пира с несмежными блоками адресов, где оптимальное сумирование затруднено. Нужно еще учитывать сравнительно медленную передачу маршрутной информации посредством IGP. Однако для тупиковых AS и задач попроще решение вполне подойдет.

    Вот такие идеи. Надеюсь кому-нибудь они покажутся интересными и найдут свое применение.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 36

      0
      1. Двух интерфейсов 10GE вам не хватит — чтобы RIPE выдал вам BGP AS, у вас должно быть как минимум два апстрима. Так что 10GE надо минимум три — два к апстримам и один в вашу сеть.
      2. Нужен ли вам FullView? Договоритесь с апстримами, пусть отдадут вам, например, префиксы /16 и меньше. Роутинг будет не совсем оптимальный, но это будет не самой большой вашей проблемой.
      3. Маршрутизировать 10Gbps виртуальной машине будет тяжко. А если ещё какую-нибудь фильтрацию пакетов добавить… Что Cisco что Juniper тут совершенно не напрасно используют TCAM, QFP и прочее.
        +2
        Двух интерфейсов хватит, достаточно чтобы 2 провайдера подтвердили что готовы работать, что будут линки никто проверять не будет, да один из линков может быть хоть на 10мбит

        для одного аплинка анализ маршрутов вообще непонятно зачем нужен.

        в данном случае виртуалка не будет ничего маршрутизировать, это будет делоать кора, виртуалка будет только анонсировать префикс.
          0
          1. Да, пира должно быть два, чтобы выдали АС, но она у меня есть. Вы упустили из вида, что два интерфейса «на борту» и кроме них есть еще интерфейсный концентратор как у Juniper, так и у Cisco. У MX80 вообще 4 интерфейса и два слота под концентраторы. Как вариант я могу пирится с двумя провайдерами в точке обмена и одного интерфейса хватит. Но я писал не совсем о выборе подходящей платформы для задачи Х.
          2. Фуллвью наверное не нужен, тем более поначалу. Тем не менее уже при двух соседях поднимется вопрос приоритезации. Уж не знаю как ваши провайдеры, а мне с трудом верится, что каждый из моих будет фильтровать как мне хочется — таких клиентов как я у них десятки и под каждого не нафильтруешься. И я не утверждал, что FullView жизненно необходим.
          3. Ответили ниже )
            0
            Понятно. У вас всё-таки есть минимум два аплинка, AS и сети для неё, и вы хотите их использовать надеясь в будущем купить маршрутизатор и/или сохранить некоторую независимость от аплинков. Ок, свою AS вы проаннонсируете со всеми community и prepend-ами, а что будете делать с исходящим трафиком? Если один аплинк, то ладно, вариантов всё равно нет. А если несколько и один из них упал внезапно?

            Насчёт фильтрации префиксов на аплинках — для них это проза жизни. Посмотрите например что отдаёт Голден Телеком aka Sovam:
            http://www.ripe.net/whois?AS3216
            Кому full-view, кому default, а там несколько сотен клиентов. Часть таблицы признаю не встречал, но там дел то ровно на две строчки в конфигурации. Можете и на своей стороне фильтровать.
            0
            RIPE «выдаст» ASN любому физ или юр лицу вовремя платящаму RIPE взносы, не более.
              0
              Формально Skyroger2 прав, в правилах получения АС указано, что должны быть договоренности с минимум двумя пирами для получения AS. Что это за договоры, будут ли они выполнятся и можно ли по-другому вопрос другой, но положение такое есть.
              По комменту: что я собираюсь делать я писал — на даный момент обойдусь статикой на ядре. Если аплинков несколько можно сделать floating static, если линки идут к разным пирам. Для моей стаб-АС этого достаточно, по крайней мере пока.
              Я посмотрел на AS3216 и они отдают или 0/0 или FullView. Ничего по поводу фильтрации по /16 (как в изначальном комменте) не увидел. И я очень сильно сомневаюсь, что они такое предложат каждому клиенту. «две строчки в конфигурации» помноженное на количество пиров превратятся в неподъемную работу. А если «мне» потом понадобится что-то поменять? В любом случае, мой пир такого делать не будет да и не об этом был пост.
            +1
            Если аплинк один, то зачем вообще Fullview?
            Получайте просто default на кору и всё.
              0
              Я писал, что это только один из вариантов. Если вам интересно как может решение масштабироваться, что и зачем нужно, и как изменится, можем подумать вместе.
              Получать на кору через BGP? Такой вариант приведен на втором рисунке. Признаю, там он называется PartView, он же PartialView. Однако в вырожденом варианте PartialView=0/0.
              «Получать» статикой? Тогда я действительно некстати, но я об этом писал вначале статьи.
              0
              apt-get install exabgp

              Цена? Ну, давайте считать. Если использовать raspberry pi — то баксов 30. Если нормальный сервер — тыщи три.
                0
                Вы определенно к чему-то ведете, но пока не могу понять к чему.
                  0
                  Ведет он к тому что exabgp можеть менять любые bgp атрибуты что in что out
                  Производительность правда у exabgp так себе если сравнить с очень быстрым bird
                    0
                    Признаю, не слышал про exabgp, как и о многих других вещах — глупо это пытаться скрыть. Однако если я правильно толкую «exabgp можеть менять любые bgp атрибуты что in что out» нам нужен BGP между устройствами. Соответственно в моей статье это будет пункт 2 или 3. Для пункта 2 это избыточно — просто менять атрибуты я могу и на ядре. Для пункта 3 слишком мало — там идея в организации машины, которая будет иметь FullView или несколько для возможности локалькой сумаризации/приоритезации. К тому же целью моих изысканий являлся полный уход от BGP из-за лицензионной стоимости. И таки да, raspberry pi — сомнительно, что он вместит таблицу и будет обрабатывать достаточно быстро.
                0
                Вот когда мы экономим на дорогущем хардварном роутере, который будет испольщовать функционал на 7% — это как бы понятно.
                Но вот когда экономим на лицензии в угоду адово костыльного решения — это уже ИМХО бред.
                Вы что, из своего кармана эту лицензию покупаете?
                  0
                  Когда цена лицензии сопоставима с дорогущим хардварным роутером, тут тоже есть над чем задуматься. В целом вынести весь control plane с BGP на отдельную виртуалку — идея очень интересная и я бы не сказал, что это костыль.
                    0
                    Так я под костылем подразумевал не вынос control plane на виртуалку. А доставку результатов работы этого самого control plane на свич костыльными методами. Ну и не стоит лицензия на BGP для коммутатора как новый ASR,
                      0
                      Я конечно может неправильно сделал, что опустил этот момент — думал это маловажная информация, так как я сосредотачивался больше на границе и взаимодействию устройств. Но давайте я исправлюсь.
                      Ядро у меня будет состоять из двух EX4550, соответственно 10Гб/с интерфейсы у меня уже в наличии. К ядру будут подключаться сервера с VMWare — виртуалки у меня тоже есть.
                      Ядро объединено в виртуальное шасси, соответственно стоимость лицензии возрастает в два раза — ее нужно покупать для каждого routing-engine в шасси. Итого 20 тыс.долл. Вот вам и стоимость ASR. У циски думаю ситуация не будет отличаться — если объединять нексусы в VSS или подобное решение, feature set должен совпадать, итого 18тыс.долл. согласно GPL.
                      По поводу костыля с доставкой не соглашусь — так любую манипуляцию можно назвать: препенд, приоритет, изменение административного расстояния. А мои идеи особо не отличаются от скажем препенда, разве что не реализованы нативно на оборудовании. К тому же я не заставляю поступать именно так — вариант крутить iBGP между виртуалкой и ядром в описании присутствует.
                        0
                        А смотрели в сторону Mikrotik CHR в качестве eBGP RR с суммаризацией, фильтрами и nexhop propagation? Цена одной 10Gbit лицензии 10к.руб.
                          0
                          Дело не в eBGP, его можно крутить и на Квагге и на Mikrotik CHR. Вариантов масса и все они упираются в одну стену — необходимость докупать BGP лицензию для ядра или ограничения IGP о которых я упомянул в посте. К тому же Mikrotik CHR сам по себе стоит денег — зачем, если есть Квагга/БИРД?
                  –1
                  Не очень понял вашей проблемы.
                  Quagga не поняла вашу попытку анонсировать third-party nexthop (судя по тому, что удалось найти — в OSPF такой режим поддерживается)?
                  Варианта два:
                  1. Она это умеет, но вы не поняли как. Читать документацию, искать в интернете.
                  2. Она этого не умеет. Просить разработчиков реализовать новую функцию, либо самостоятельно пропатчить.

                  p.s. Покопался в документации, ответа на ваш вопрос не нашел. Тогда можно сразу пойти по п. 2 — сделать грязный хак, проверить корректную работу с вашим маршрутизатором и если проблем не будет, то делать уже правильно.

                  p.p.s. А ваш маршрутизатор сможет держать все записи BGP Full View, но полученные через OSPF (да ещё и с двух разных аплинков)?
                    0
                    Чтобы не было двусмыслености под «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 тыс маршрутов, поддерживаемых устройствами ядра.
                      0
                      Ни Quagga ни BIRD не позволяют изменить next-hop в этом смысле.

                      Да, не умеют. Я имел в виду то, что сам протокол OSPF поддерживает такую возможность (т.е. IP адрес next-hop'а не обязан совпадать с IP адресом OSPF маршрутизатора), а значит можно просто пропатчить Quagga, проверить как к этому отнесутся ваши железки (вдруг они не поддерживают?) и если всё ok — сделать нормальный патч.
                        0
                        Можете привести пример возможности OSPF передавать кастомный next-hop? Потому как у меня это не получилось.
                          0
                          Покопался немного в спеках, получается вот что.
                          Спека по самому протоколу: 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.


                          Т.е. разработчики заложили данную фичу много-много лет назад.
                            0
                            Я не отрицаю, что возможность передавать другой 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 — в ближайшее время появится натурный стенд и чуть больше времени для обкатки, будем пробовать.
                            0
                            Покопался в возможностях микротиков, очень похоже, что именно они помогут решить вашу проблему.
                            В настройках OSPF можно повесить исходящие фильтры, среди прочего в фильтре можно выставить «set out nexthop».
                            https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters

                            OSPF у меня на микротиках используется скорее «чтобы было» и на point-to-point линке.
                            Проверил, на таком типе линка фокус не прошел (пытался выставить «левый» nexthop), но на обычном (не point-to-point) линке финт может и сработать. Можно попробовать воспроизвести вашу схему, но не знаю, когда до этого дойдут руки.

                            Попробуйте микротик.
                            ISO'шку для установки в виртуалку можно скачать с их сайта, если всё понравится и заработает как надо, то купите лицензию.
                              0
                              Благодарю, попробую.
                      0
                      То есть вы готовы платить за два 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) и забыть про кваги
                        0
                        Одобрение коммента немного растянулось во времени, поэтому на часть вопросов уже ответил…
                        Если под «То есть вы готовы платить за два 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?
                        0
                        Дожились, уже BGP на raspberry pi тулим или это raspberry pi разжилось… В любом случае прикольно )
                        Что касается идеи, лично мне понравилась. Решение не универсальное, и будет иметь часть ограничений, но всё же не стандартный подход — отлично.
                        Что касается лицензирования. Как я понял в этом варианте можно получить FW, и отдать на forwarding-plane уже агрегированные маршруты. Быть может есть какие то L3 в forwarding-plane, кто позволит за не дорого иметь несколько тыс. маршрутов полученных по bgp. Вот в это и упираться, а с балансировкой нескольких каналов, можно решить меньшей/большей маской отправляемой на forwarding-plane.
                          0
                          Raspberry вообще штука интересная. К тому же для него стандартен Raspbian, то есть урезаный Debian. Не удивлюсь, если Quagga или BIRD уже портированы для него плюс идея с exabgp из комментария. Ограничение даного варианта я уже описал.
                          Ваше понимание верно — получая FW на виртуалку (raspberry?) мы получаем возможность самостоятельно фильтровать и приоритезировать маршруты. И таки да, большинство L3 свичей без проблем держат 10+ тысяч маршрутов. Агрегируя FW к примеру в 4 маршрута по /2 можно объединить таблицу и уже оперировать этими маршрутами. Я кстати думал так сделать в начале своей работы на текущем мпесте, но потом оказалось, что основной провайдер + резервный — это максимум, что необходимо для наших потребностей.
                          Докупать ли лицензию и получить нативную возможность манипуляции next-hop или использовать мой «костыль» это уже дело личных преференций. А wire-speed маршрутизация при отсутствии потребности в продвинутых фичах довольно весомый агрумент «за».
                          0
                          Как вариант (на фоне других вполне даже рабочий и имеющий право на жизнь): у Микротика есть роутеры с 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, и закрыть вопрос.
                            0
                            Согласен, весьма интересные железки. Вариантов производителей и моделей на самом деле масса, но все-таки моя идея была не об этом, а о том что этот маршрутизаторный хоп на самом деле не выполняет в некоторых случаях никакой полезной работы за исключением собственно BGP сессии и в этих случаях можно от него отказаться.
                            0
                            интересно, жаль что в своё время пропустил эту статью. Интересная дискусия могла тогда получиться. Я что-то подобное делал для EIGRP и CGMP. habr.com/ru/post/262047
                            Подозреваю, что если б вы тогда её нашли тоже было бы намного проще всё)
                              0
                              Снимаю шляпу перед полётом мысли вашей статьи. Собственно самое обидное это то, что в спецификации OSPF искомая фича есть, но по загадочной причине отказывается работать. Правда с учётом нынешней стоимости железа на вторичном рынке и цены ошибки/бага подобные инженерные выкрутасы становятся менее актуальными.
                              0
                              Вопрос немного в воздух: а никто на практике не использовал топовые микротики (например CCR1072-1G-8S+) для подобных задач? BGP Full view с нагрузками билизкими к 10Gb/s?
                              Ценник там получается, скажем там, несколько отличный от -тцати тысяч долларов.
                                0
                                Так вы посмотрите на сайт микротика, там всё есть. «CCR1072 is capable of over 120 million packets per second throughput». Там же есть и результаты нагрузочных тестов mikrotik.com/product/CCR1072-1G-8Splus#fndtn-testresults

                              Only users with full accounts can post comments. Log in, please.