Сразу скажу — в заголовке статьи речь идет именно о маршрутизаторе, физическом устройстве, а не протоколе BGP. И нет, без протокола BGP жить не получится, по крайней мере пока, — но это вы и сами знаете. Зачем нужен протокол, чем он хорош, что позволяет сделать и как его настраивать — об этом написаны массы книг и статей как на Хабре, так и на сторонних ресурсах, посему данную тему опущу. Если вам хватает статики или в соседней автономной системе работает тварищ, которого можно просить изменять политики анонсов, можно смело закрывать пост — вам эта информация не нужна.
Если вы все еще читаете, позволю себе начать с дизайна, так как статья больше о проектировании решения, нежели о самом решении. Итак, мы — сервис-провайдер ISP A, имеющий одноименный пул адресов и необходимость анонса этих адресов в Сеть. Общая схема логических связей приведена на рисунке.
На границе нашей сети стоит маршрутизатор 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 сессию (или несколько) с соседом и форвардит трафик в Сеть. Можно ли обойтись без него? Для ответа проанализируем следующую топологию.
Мы убрали физический маршрутизатор и запустили пиринг BGP на устройстве ядра. Можно ли так? Да, благо сорвеменные L3 коммутаторы поддерживают запуск BGP. Однако в этом решении есть как минимум два слабых места. Первое — большинство коммутаторов не были созданы для полноценной маршрутизации, и поэтому имеют ограниченый размер таблицы маршрутизации. Например, Juniper EX4550 имеет ограничение в 14000 IPv4 юникаст-маршрутов, а Cisco Nexus3k — 16000. Второе — чтобы запустить BGP понадобится докупить лицензию, а это стоит 8 (Cisco Nexus3k) или 10 (Juniper EX4550) тыс.долл. Если нам понадобится резервирование коммутаторов, это удвоит приведенные цифры. Кроме этого, понадобится договариваться с вышестоящим провайдером для суммирования сетей, ну или получать маршрут по-умолчанию. Тем не менее, такой дизайн все-же позволятет отказаться от покупки выделенного маршрутизатора и в то же время пользоваться полезными плюшками BGP. Еще одна возможная вариация на эту тему приведена ниже.
Мы запускаем 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. Есть ли еще варианты? Можно ли обойтись без лицензионного сбора? И тут мы подходим к главной соли данного поста. Взглянем на топологию.
Основная идея та же — запустить 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 и задач попроще решение вполне подойдет.
Вот такие идеи. Надеюсь кому-нибудь они покажутся интересными и найдут свое применение.
Комментарии (24)
ibKpoxa
18.05.2017 19:16+1Если аплинк один, то зачем вообще Fullview?
Получайте просто default на кору и всё.
yand_ua
18.05.2017 22:46Я писал, что это только один из вариантов. Если вам интересно как может решение масштабироваться, что и зачем нужно, и как изменится, можем подумать вместе.
Получать на кору через BGP? Такой вариант приведен на втором рисунке. Признаю, там он называется PartView, он же PartialView. Однако в вырожденом варианте PartialView=0/0.
«Получать» статикой? Тогда я действительно некстати, но я об этом писал вначале статьи.
amarao
18.05.2017 21:44apt-get install exabgp
Цена? Ну, давайте считать. Если использовать raspberry pi — то баксов 30. Если нормальный сервер — тыщи три.yand_ua
18.05.2017 22:47Вы определенно к чему-то ведете, но пока не могу понять к чему.
alex_www
18.05.2017 23:09Ведет он к тому что exabgp можеть менять любые bgp атрибуты что in что out
Производительность правда у exabgp так себе если сравнить с очень быстрым birdyand_ua
19.05.2017 09:31Признаю, не слышал про exabgp, как и о многих других вещах — глупо это пытаться скрыть. Однако если я правильно толкую «exabgp можеть менять любые bgp атрибуты что in что out» нам нужен BGP между устройствами. Соответственно в моей статье это будет пункт 2 или 3. Для пункта 2 это избыточно — просто менять атрибуты я могу и на ядре. Для пункта 3 слишком мало — там идея в организации машины, которая будет иметь FullView или несколько для возможности локалькой сумаризации/приоритезации. К тому же целью моих изысканий являлся полный уход от BGP из-за лицензионной стоимости. И таки да, raspberry pi — сомнительно, что он вместит таблицу и будет обрабатывать достаточно быстро.
Pave1
19.05.2017 11:06Вот когда мы экономим на дорогущем хардварном роутере, который будет испольщовать функционал на 7% — это как бы понятно.
Но вот когда экономим на лицензии в угоду адово костыльного решения — это уже ИМХО бред.
Вы что, из своего кармана эту лицензию покупаете?
alk0v
19.05.2017 11:34Когда цена лицензии сопоставима с дорогущим хардварным роутером, тут тоже есть над чем задуматься. В целом вынести весь control plane с BGP на отдельную виртуалку — идея очень интересная и я бы не сказал, что это костыль.
Pave1
19.05.2017 12:28Так я под костылем подразумевал не вынос control plane на виртуалку. А доставку результатов работы этого самого control plane на свич костыльными методами. Ну и не стоит лицензия на BGP для коммутатора как новый ASR,
yand_ua
19.05.2017 15:07Я конечно может неправильно сделал, что опустил этот момент — думал это маловажная информация, так как я сосредотачивался больше на границе и взаимодействию устройств. Но давайте я исправлюсь.
Ядро у меня будет состоять из двух EX4550, соответственно 10Гб/с интерфейсы у меня уже в наличии. К ядру будут подключаться сервера с VMWare — виртуалки у меня тоже есть.
Ядро объединено в виртуальное шасси, соответственно стоимость лицензии возрастает в два раза — ее нужно покупать для каждого routing-engine в шасси. Итого 20 тыс.долл. Вот вам и стоимость ASR. У циски думаю ситуация не будет отличаться — если объединять нексусы в VSS или подобное решение, feature set должен совпадать, итого 18тыс.долл. согласно GPL.
По поводу костыля с доставкой не соглашусь — так любую манипуляцию можно назвать: препенд, приоритет, изменение административного расстояния. А мои идеи особо не отличаются от скажем препенда, разве что не реализованы нативно на оборудовании. К тому же я не заставляю поступать именно так — вариант крутить iBGP между виртуалкой и ядром в описании присутствует.
alecx
22.05.2017 11:42А смотрели в сторону Mikrotik CHR в качестве eBGP RR с суммаризацией, фильтрами и nexhop propagation? Цена одной 10Gbit лицензии 10к.руб.
yand_ua
22.05.2017 11:45Дело не в eBGP, его можно крутить и на Квагге и на Mikrotik CHR. Вариантов масса и все они упираются в одну стену — необходимость докупать BGP лицензию для ядра или ограничения IGP о которых я упомянул в посте. К тому же Mikrotik CHR сам по себе стоит денег — зачем, если есть Квагга/БИРД?
vp7
21.05.2017 00:39-1Не очень понял вашей проблемы.
Quagga не поняла вашу попытку анонсировать third-party nexthop (судя по тому, что удалось найти — в OSPF такой режим поддерживается)?
Варианта два:
1. Она это умеет, но вы не поняли как. Читать документацию, искать в интернете.
2. Она этого не умеет. Просить разработчиков реализовать новую функцию, либо самостоятельно пропатчить.
p.s. Покопался в документации, ответа на ваш вопрос не нашел. Тогда можно сразу пойти по п. 2 — сделать грязный хак, проверить корректную работу с вашим маршрутизатором и если проблем не будет, то делать уже правильно.
p.p.s. А ваш маршрутизатор сможет держать все записи BGP Full View, но полученные через OSPF (да ещё и с двух разных аплинков)?yand_ua
22.05.2017 12:54Чтобы не было двусмыслености под «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 тыс маршрутов, поддерживаемых устройствами ядра.
Serb514
22.05.2017 12:57То есть вы готовы платить за два 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) и забыть про квагиyand_ua
22.05.2017 13:25Одобрение коммента немного растянулось во времени, поэтому на часть вопросов уже ответил…
Если под «То есть вы готовы платить за два 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?
hexman
23.05.2017 13:42Дожились, уже BGP на raspberry pi тулим или это raspberry pi разжилось… В любом случае прикольно )
Что касается идеи, лично мне понравилась. Решение не универсальное, и будет иметь часть ограничений, но всё же не стандартный подход — отлично.
Что касается лицензирования. Как я понял в этом варианте можно получить FW, и отдать на forwarding-plane уже агрегированные маршруты. Быть может есть какие то L3 в forwarding-plane, кто позволит за не дорого иметь несколько тыс. маршрутов полученных по bgp. Вот в это и упираться, а с балансировкой нескольких каналов, можно решить меньшей/большей маской отправляемой на forwarding-plane.yand_ua
23.05.2017 13:55Raspberry вообще штука интересная. К тому же для него стандартен Raspbian, то есть урезаный Debian. Не удивлюсь, если Quagga или BIRD уже портированы для него плюс идея с exabgp из комментария. Ограничение даного варианта я уже описал.
Ваше понимание верно — получая FW на виртуалку (raspberry?) мы получаем возможность самостоятельно фильтровать и приоритезировать маршруты. И таки да, большинство L3 свичей без проблем держат 10+ тысяч маршрутов. Агрегируя FW к примеру в 4 маршрута по /2 можно объединить таблицу и уже оперировать этими маршрутами. Я кстати думал так сделать в начале своей работы на текущем мпесте, но потом оказалось, что основной провайдер + резервный — это максимум, что необходимо для наших потребностей.
Докупать ли лицензию и получить нативную возможность манипуляции next-hop или использовать мой «костыль» это уже дело личных преференций. А wire-speed маршрутизация при отсутствии потребности в продвинутых фичах довольно весомый агрумент «за».
Skyroger2
1. Двух интерфейсов 10GE вам не хватит — чтобы RIPE выдал вам BGP AS, у вас должно быть как минимум два апстрима. Так что 10GE надо минимум три — два к апстримам и один в вашу сеть.
2. Нужен ли вам FullView? Договоритесь с апстримами, пусть отдадут вам, например, префиксы /16 и меньше. Роутинг будет не совсем оптимальный, но это будет не самой большой вашей проблемой.
3. Маршрутизировать 10Gbps виртуальной машине будет тяжко. А если ещё какую-нибудь фильтрацию пакетов добавить… Что Cisco что Juniper тут совершенно не напрасно используют TCAM, QFP и прочее.
ibKpoxa
Двух интерфейсов хватит, достаточно чтобы 2 провайдера подтвердили что готовы работать, что будут линки никто проверять не будет, да один из линков может быть хоть на 10мбит
для одного аплинка анализ маршрутов вообще непонятно зачем нужен.
в данном случае виртуалка не будет ничего маршрутизировать, это будет делоать кора, виртуалка будет только анонсировать префикс.
yand_ua
1. Да, пира должно быть два, чтобы выдали АС, но она у меня есть. Вы упустили из вида, что два интерфейса «на борту» и кроме них есть еще интерфейсный концентратор как у Juniper, так и у Cisco. У MX80 вообще 4 интерфейса и два слота под концентраторы. Как вариант я могу пирится с двумя провайдерами в точке обмена и одного интерфейса хватит. Но я писал не совсем о выборе подходящей платформы для задачи Х.
2. Фуллвью наверное не нужен, тем более поначалу. Тем не менее уже при двух соседях поднимется вопрос приоритезации. Уж не знаю как ваши провайдеры, а мне с трудом верится, что каждый из моих будет фильтровать как мне хочется — таких клиентов как я у них десятки и под каждого не нафильтруешься. И я не утверждал, что FullView жизненно необходим.
3. Ответили ниже )
Skyroger2
Понятно. У вас всё-таки есть минимум два аплинка, AS и сети для неё, и вы хотите их использовать надеясь в будущем купить маршрутизатор и/или сохранить некоторую независимость от аплинков. Ок, свою AS вы проаннонсируете со всеми community и prepend-ами, а что будете делать с исходящим трафиком? Если один аплинк, то ладно, вариантов всё равно нет. А если несколько и один из них упал внезапно?
Насчёт фильтрации префиксов на аплинках — для них это проза жизни. Посмотрите например что отдаёт Голден Телеком aka Sovam:
http://www.ripe.net/whois?AS3216
Кому full-view, кому default, а там несколько сотен клиентов. Часть таблицы признаю не встречал, но там дел то ровно на две строчки в конфигурации. Можете и на своей стороне фильтровать.
alex_www
RIPE «выдаст» ASN любому физ или юр лицу вовремя платящаму RIPE взносы, не более.
yand_ua
Формально Skyroger2 прав, в правилах получения АС указано, что должны быть договоренности с минимум двумя пирами для получения AS. Что это за договоры, будут ли они выполнятся и можно ли по-другому вопрос другой, но положение такое есть.
По комменту: что я собираюсь делать я писал — на даный момент обойдусь статикой на ядре. Если аплинков несколько можно сделать floating static, если линки идут к разным пирам. Для моей стаб-АС этого достаточно, по крайней мере пока.
Я посмотрел на AS3216 и они отдают или 0/0 или FullView. Ничего по поводу фильтрации по /16 (как в изначальном комменте) не увидел. И я очень сильно сомневаюсь, что они такое предложат каждому клиенту. «две строчки в конфигурации» помноженное на количество пиров превратятся в неподъемную работу. А если «мне» потом понадобится что-то поменять? В любом случае, мой пир такого делать не будет да и не об этом был пост.