Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы
На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.
И крайне редко обсуждается вопрос о необходимости этого самого фулвью.
Немножко «теории»
Не пугайтесь, я не стану рассказывать все с начала. Уверен, что большинству читателей хорошо известно содержимое моей теоретической вводной. Желающие могут смело ее пропустить. Однако же я регулярно сталкиваюсь с некоторой неуверенностью вполне компетентных в практических вопросах людей, когда речь заходит о нижеизлагаемом. Так что все-таки давайте немножко синхронизируем термины, прежде чем обсуждать матчасть.
Все, что впрямую не касается темы интернетной BGP-таблицы, в частности IGP, MPLS, VRF/VPN и т. п., оставим за скобками.
Роутинг и ричабилити
Фулвью — это практически справочник «Желтые страницы» для всего интернета. Только именно «Желтые страницы», а не ваша личная записная книжка. Принципиальная разница тут в том, что помимо разрешения букв в цифры — для чего в интернете служит не фулвью, а DNS — периодические справочники дают нам возможность знать о появлении и исчезновении объектов. Нужно же нам как-то узнавать, что тот или иной адрес вообще есть в интернете. Мало того, если вдруг он для нас доступен только через линк А, а через Б недоступен — мы ведь тоже хотим об этом знать. Это и есть сигнализация доступности (reachability). Не будем слишком глубоко в вдаваться в абстракции, отметим лишь важность осознавать, что ричабилити и роутинг суть разные вещи.
Роутинг (маршрутизация) — нахождение лучшего пути передачи трафика для заданного направления. Этот процесс мало похож на поиск в телефонном справочнике, а скорее имеет отношение к карте города: если один и тот же адрес x.x.x.x доступен нам и через линк А, и через линк Б, нужно принять решение, куда же посылать пакеты.
Предположим, что читатель знаком с протоколом IP и в курсе, что такое префикс, зачем ему длина, и с чем едят правило лонгест мач.
Итак, как видно из показанного выше знаменитого графика c bgp.potaroo.net , полная таблица интернет-маршрутизации (здесь и далее речь в основном об IPv4, хотя почти все кроме цифр справедливо также и для IPv6) нынче содержит почти 350 тысяч записей. Это число растет экспоненциально и довольно быстро. Каждая из записей представляет собой, собственно, маршрут: IP-префикс назначения (подсеть с маской), некстхоп (следующий узел aka «куда посылать») и разные там другие параметры, определяющие ценность этого маршрута. Когда есть два (полученных от разных маршрутизаторов-соседей) маршрута для одного префикса, в ход идут как раз эти атрибуты. Они определяют, какой некстхоп будет использован для передачи.
Здесь показаны три маршрута к префиксу 8.8.8.0/24, полученные от трех разных маршрутизаторов-соседей. По некоторой причине — кстати, в данном случае нетривиальной — первый из них был выбран наилучшим (в примере причина не показана). Пусть вас не смущает и то, что у всех трех маршрутов один и тот же некстхоп: данные сняты с весьма специфического маршрутизатора, не передающего транзитный трафик. И да, маршрутизатор-сосед и некстхоп — это не одно и то же.
Анонсируются маршруты между маршрутизаторами при помощи протокола BGP, который собой являет, ну, практически RSS-трансляцию (да простят меня теоретики за кощунственное сравнение). Собственно, термин Full View — популярен в основном у нас, иностранные коллеги чаще говорят Full BGP, Full Table или Full Feed.
То есть сам протокол ничего сложного из себя не представляет — просто способ автоматизированного обмена данными, обернутыми в лучших программистских традициях в нечто вроде контейнеров, которые стандарт протокола позволяет более-менее гибко расширять по мере необходимости. Механизмы поиска наилучшего пути (роутинга) и контроля связности (ричабилити) у него довольно просты, если не сказать примитивны. В частности BGP считает, что трафик передается не между маршрутизаторами, а между укрупненными сущностями: автономными системами (АС, произносится «а-эс») и почти ничего не знает об их внутренней структуре — путь через две транзитных АС, каждая из которых включает, скажем, десять внутренних хопов (маршрутизаторов), BGP сочтет более выгодным, чем путь через пять АС, каждая из которых внутри имеет два хопа. Кроме того, BGP практически ничего не знает о пропускной способности линков; в нашем приближении можно считать, что этот аспект вообще никак не учитывается при выборе маршрута.
По сравнению с другими протоколами он не слишком быстр в обнаружении изменений связности и, как мы только что убедились, далеко не всегда оптимально ищет лучшие пути. Однако это все — не только минус, но и плюс BGP, т. к. именно благодаря своей относительной прямолинейности и «укрупненности мазков» протокол хорошо приспособлен для передачи большого объема маршрутной информации.
Так вот таблица в 340 тысяч записей с кучей атрибутов — это довольно много. А таблиц таких нужно обычно не меньше двух («мэньше нэ былло смы-исла», но об этом потом). Одно лишь хранение всего этого добра требует многих сотен мегабайт памяти, а кроме передачи и держания в памяти, таблицы нужно «обсчитать», в результате чего получить набор наилучших (активных) маршрутов.
Например. Один маршрутизатор-сосед анонсировал нам, что он знает маршрут, скажем, к Гуглу, и другой сосед — тоже анонсировал. Теперь мы знаем, что Гугл доступен нам через каждого из соседей (ричабилити) и хотим принять решение, какой же из двух маршрутов использовать для передачи пакетов (роутинг). Для этого BGP сравнивает показания (разные атрибуты маршрутов: Local Preference, AS-PATH и другие) и принимает решение (по каким-то там, не имеющим сейчас значения критериям), что, допустим, через первого соседа лучше. И так для каждого префикса. Таким образом из нескольких таблиц (каждая из которых состоит из 340 тыс. записей), полученных от разных соседей, «компилируется» одна таблица на 340 тыс. активных маршрутов:
Конструкция из нескольких еще необсчитанных BGP-фидов (если быть точнее, то не только их, но и данных других протоколов), называется RIB (routing information base). Хранится она как правило в самой обычной оперативной памяти и обрабатывается самым обычным процессором. Соответственно именно к этим двум элементам и предъявляются требования, когда речь идет о количестве полных BGP-таблиц, которые можно впихнуть в RIB. Общее количество записей тут определяется как сумма всех полученных от соседей маршрутов: две фулвью — почти 700 тыс. префиксов, три — за миллион и т. д.
Вывод первый. Грузить фулвью, если у вас только одна сессия с внешним миром — бессмыслица. Обладание этим массивом информации не даст ничего, кроме нагрузки на оборудование, т. к. трафик можно передать только одним способом: «Адам, это Ева, выбирай себе жену». Представьте, что Адам решил бы прежде проанализировать 340 тысяч параметров Евы — где бы мы теперь были? Из данного правила есть редкие исключения, однако если вы не знаете, какие именно, то они — точно не ваш случай.
Памяти под RIB с несколькими фулвью нужно не то чтобы прям очень много, но сотни мегабайт — единицы гигабайт (в зависимости от количества фулвью, реализации и массы других аспектов). Процессору подчас тоже приходится не очень сладко, особенно в реализациях, имеющих BGP-сканер. Например апдаун сессии, через которую передается полная таблица, на иных платформах может приводить к стопроцентной загрузке процессора где-нибудь на полчасика.
Однако же понятно, что гигабайты памяти и гигагерцы процессорной частоты давно перестали быть чем-то особенным. И даже в контексте сетевого оборудования, производители которого славятся умением продавать обычную, как в компьютере, DRAM по цене космических летательных аппаратов, делая вид, что 2 ГБ — вершина прогресса, приведенные цифры не так уж страшно выглядят. Участники упомянутых в начале топика форумных дискуссий довольно часто приходят именно к такому выводу. Мол, главное памяти побольше. Это утверждение, в общем, верно, но к сожалению на нем дело отнюдь не заканчивается.
Давайте посмотрим, что происходит с фулвью дальше. Но прежде еще одно маленькое, но очень важное замечание.
Маршрутная информация всегда передается навстречу трафику, который коммутируется на ее основе. То есть на базе фулвью передается исходящий из вашей АС трафик. Не смотря на всю очевидность этого тезиса, далеко не всегда практическое его значение осознается в полной мере.
Форвадинг
Дальше эта «скомпилированная» таблица активных маршрутов используется для передачи трафика. Называется она FIB (forwarding information base), и количество записей в ней, грубо говоря, равно количеству записей в одной фулвью (340 тыс.). С ней все гораздо интереснее.
Лирическое отступление. Вообще говоря, Full View (в отличии от Full BGP Feed) — это как раз FIB. То есть в большинстве случаев правильнее было бы говорить не «мне нужен маршрутизатор, способный держать три фулвью», а «мне нужен маршрутизатор, способный держать три пира с фулвью».
И, кстати, подпись по оси ординат на великой и ужасной картинке, приведенной в начале поста, неправильная. Это не RIB, а FIB. Заголовок на внутренней странице об этом тоже какбе намекает.
Большинство современных маршрутизаторов, способных передавать трафик на скоростях от пары гигабит в секунду и выше, — «аппаратные». Аппаратность их в том, что FIB и ее атрибуты помещается не в обычную, а в специальную, грубо говоря, «быструю» коммутационную память (SRAM, TCAM, RLDRAM и пр.), к которой обращаются специальные же процессоры обработки пакетов. Эта память — едва ли не самый дорогой ресурс в маршрутизаторе. А возможная изощренность работы с ней — уж точно самый главный из факторов, влияющих на цену железа.
Скажем, коммутатор на 24 гигабитных порта, способный передавать трафик со страшной силой (одновременно на полной скорости всех интерфейсов), нынче стоит каких-нибудь пару тысяч долларов или даже еще дешевле. Он тоже вполне «аппаратный» и скорее всего мощности процессора и объема оперативки в нем достаточно, чтобы без проблем обмолотить штуки четыре фулвью в RIB. Мало того, часто софт в нем поддерживает много разных сложных фич. Однако «полноценный маршрутизатор», способный делать, казалось бы, то же самое, стоит раз в пятнадцать дороже. Все потому что помимо разного рода маркетологических тонкостей у коммутатора в таблицу коммутации можно поместить от силы 10–15 тыс. маршрутов, и набор доступных действий с этой таблицей у него значительно уже. Скажем, если для каждого пакета нужно искать запись в FIB не один раз, а два или три (это нужно чаще, чем вы думаете) — то коммутаторы за 2 тыс. $ такого не умеют.
Есть также программные коробки (производительностью, грубо говоря, до гигабита-двух), у которых, соответственно, FIB, как и RIB, хранится в обычной оперативке. У них, вообще, частенько слишком много всего в ней хранится, но об этом как-нибудь в другой раз — главное, что она (оперативка) не резиновая. Мало того, программный поиск по массиву с нахождением наилучшего соответствия (longest match) — ну очевидно же, что тем медленнее, чем больше в массиве элементов, каким алгоритмом н
Если продавец сможет вас более-менее уверенно проконсультировать еще и про размер RIB — сколько пиров с фулвью вы сможете держать на выбираемом аппарате — это верный признак продавца, который знает толк в том, чем торгует. Если же он еще и в состоянии поддержать беседу про отличие больших L3-коммутаторов от полноценных маршрутизаторов и готов вам рассказать о возможных последствиях использования больших коммутаторов для BGP-пиринга — вы на правильном пути, осталось договориться с ним о цене.
Практические рассуждения
Теперь нам предстоит ответить на обозначенный в заголовке вопрос о пользе и вреде фулвью. Для этого сначала еще чуточку пофилософствуем.
Агрегация vs. детализация
При динамической передаче маршрутов существует два противоположных принципа (слово «принцип» здесь означает не «убеждение» или «склонность», а скорее технический прием, используемый по назначению) работы с маршрутной информацией: детализация и агрегация. То есть либо подробность: много длинных префиксов, либо краткость: представление нескольких длинных префиксов в виде одного покороче.
Агрегация
Вообще говоря, уже ясно, что от детализации много вреда: каждый школьник знает, что чем больше информации, тем сложнее ее хранить и дороже ею оперировать. Во времена программных маршрутизаторов и юности IP тезис о необходимости минимизации количества маршрутов был аксиомой, не подлежащей обсуждению. Ради борьбы со снижением производительности от распухания RIB и FIB было придумано очень много всего интересного. К примеру, бесчисленные и беспощадные типы арий и LSA в OSPF или такая штука как MPLS (да-да, он вовсе не ради VPN или TE был изобретен), Cisco Express Forwarding и другие разной степени полезности вещи, включая, собственно, аппаратный форвадинг.
Агрегация (суммаризация) — целая маленькая наука, связанная с грамотным сегментированием, выбором адресного плана, умением управляться со всякими IGP-ариями, ловкостью рук при написании правил маршрутизации и т. п. Интересующихся отсылаю например к книге «Принципы проектирования корпоративных IP-сетей» А. Ретаны, Д. Слайса и Р. Уайта (Cisco Press).
Экстремальный случай агрегации — маршрут по умолчанию («дефолт»): 0.0.0.0/0, означающий «все, кроме того, к чему есть явные маршруты».
Детализация
К сожалению, интернет — такая штука, к которой слабо применимо все это блестящее искусство агрегации. Принципы независимости от географии, отсутствия централизованного управления, административной изолированности автономных систем, минимизации области повреждений при отказах и т. д. приводят к тому, что соседние префиксы, к примеру 212.90.0.0/19 и 212.90.32.0/19, если только они не принадлежат одной автономной системе (и здесь тоже далеко не всегда это возможно), никак нельзя представить в виде агрегированного префикса 212.90.0.0/18 с общими параметрами. В общем случае такая суммаризация может привести к возникновению закольцовок или «черных дыр».
Однако курсивное выделение «в общем случае» — неспроста. Очевидным исключением является вышеупомянутый маршрут по умолчанию. Собственно именно он используется как маршрут в интернет (и не только) в случаях, когда никакой фулвью у нас нету. То есть это практически единственно возможная альтернатива фулвью: наплевать вообще на всю внутреннюю структуру интернета. Давайте посмотрим, когда это возможно, и в чем разница форвадинга на базе дефолта и полной таблицы.
Кому и зачем же нужна фулвью?
С дефолтом все понятно: все, для чего нет специфических (своих) маршрутов, шлем провайдеру (аплинку) aka в интернет. А что, в сущности, дает нам тут фулвью? Она дает возможность принимать решения о выборе линка для послыки пакета, опираясь на знание не обо всем интернете в целом, а об отдельных его ресурсах. Во-первых пример: маршрут x.x.x.x/x доступен через линки A и Б, а маршрут y.y.y.y/y — только через линк Б. Раз так, то трафик к y.y.y.y/y можно посылать только через Б (ричабилити). Во-вторых — мы сможем оказывать влияние на соответствие между префиксами назначения и соседями, через которых мы будем слать трафик. Гуглу пошлем трафик через провайдера А, а Яндексу — через Б (роутинг).
Зачем это может быть нужно?
Первый, неоспоримый случай — наличие как выше- или равностоящих (uplink, IX), так и нижестоящих (клиенты) АС-соседей. То есть, когда наша автономная система транзитная, и к ней подключены клиенты, которые тоже что-то нам анонсируют. Использовать дефолт здесь нельзя по определению, т. к. мы в таком случае находимся не на окраине, а в «середине» интернета. Наличие агрегации маршрутов здесь может приводить к закольцовкам. Поэтому провайдерам приходится держать полную таблицу на всех маршрутизаторах, которые передают интернет-трафик на основе IP-заголовков. Оговоримся, что варианты «голь на выдумки хитра» тут тоже возможны, но во-первых их обсуждение выходят за рамки топика, во-вторых они довольно сложны в эксплуатации при промышленных мастабах сети. Поэтому, хотя вариации на эту тему не так уж и редко встречаются в жизни, очень часто их использование в провайдерских автономках привносит больше проблем, чем пользы.
Вывод третий. Если ваша АС транзитная, то без фулвью скорее всего не обойтись. Впрочем, вы наверное и сами все это знаете. Про MPLS и BGP-free core, я думаю, тоже что-нибудь да слышали. Если нет, то это вам ключевые слова для дальнейшего размышления.
Следующая, более интересная для нас задача — балансировака нагрузки таким образом, чтобы трафик через интернет шел либо оптимальными с точки зрения BGP (который, как мы выяснили, не всегда точен в выборе) путями, либо теми путями, какими мы хотим (и настроим). Оба желания могут быть вполне законны, если у вас действительно много исходящего (еще раз: исходящего!) из вашей АС трафика (гигабит-другой и больше), и в сложных манипуляциях есть экономическая целесообразность. Как правило такое бывает либо у провайдеров с транзитными автономками, которые все равно попадают под случай, описанный выше, либо у крупных ЦОДов, у которых, кстати, тоже скорее всего есть клиенты со своими АС. А даже если нет, то и тут индивидуальное знание о маршрутах для каждого префикса (которое дает фулвью) не помешает (см. например байку юзера shapa о его «войне» с Голденом).Если же ваша АС — не транзитная инфраструктура на продажу, а корпоративная сеть, пусть даже со своим небольшим (по мировым меркам) ЦОДом, исходящего трафика у вас скорее всего совсем мало (десятки—сотни мегабит), и задачи типа посылать трафик к Гуглу одним маршрутом, а к Яндексу другим — у вас почти наверняка нету (если только любопытства ради). Максимум что вам тут нужно для исходящего трафика — сбалансировать его либо равномерно, либо в какой-то нужной пропорции между несколькими интернет-линками. Вопреки бытующему мнению фулвью для этого не нужна и даже вредна — об этом ниже.
Третий — чуть более интересный и относительно неочевидный случай — фулвью, как информационное «подспорье». Часто хочется знать, с какими АС у вас идет наиболее интенсивный обмен трафиком. В ряде случаев, в том числе когда для передачи трафика фулвью не нужна, хочется снимать статистику для оценки разного рода тенденций трафика. В этих случаях фулвью используется механизмами типа NetFlow для получения дополнительной информации о трафике (исходящем и входящем). Но надо заметить, что реализация подобного мониторинга требует некоторого опыта и понимания, что должно уметь оборудование, где должна храниться та фулвью, чем это все чревато, и как правильно интерпретировать полученную статистику. Короче говоря, это эдвансная тема, выходящая за рамки топика. Кроме того, если трафика у вас не гигабиты, то скорее всего вам оно и не нужно. Другой вариант на эту тему — продемонстрированный выше консольный вывод, снятый со специальных маршрутизаторов, не передающих транзитный трафик. Они держат фулвью лишь для возможности ее анализа.
Когда можно обойтись без фулвью?
Крайне распространенным заблуждением является мнение, что, если у вас есть своя АС и блок адресов, то вы обязаны принимать полную таблицу. Это именно что заблуждение.
Как было сказано выше, самый сомнительный в отношении нужности фулвью случай (он же самый массовый и самый богатый неблестящими реализациями) — корпоративная сеть, которой АС нужна для обладания своим блоком адресов, чтоб, в свою очередь, не зависеть от провайдеров при резервировании интернет-ресурсов (публичных серверов, VPN-концентраторов и т. п.) Основная задача здесь — сделать возможным получение входящего из интернета трафика при потере одного из внешних подключений. Вспоминаем правило, гласящее, что трафик передается навстречу маршрутной информации. Вопрос: зачем нам нужна фулвью, если речь о входящем трафике? Ответ: да ни зачем не нужна.
Хорошо, но если мы отказываемся от фулвью, то как же мы будем передавать исходящий трафик? Да как обычно! Пишем правило маршрутизации, а еще лучше договариваемся с провайдером (обычно это не проблема), чтоб не насиловать оборудование по пустякам (а в идеальном случае для этого придуман механизм ORF), и принимаем от каждого провайдера только маршрут по умолчанию. Дальше либо используем только один из маршрутов, а второй держим про запас (на случай, если первый отвалится) и пускаем весь исходящий трафик по одному линку, либо настраиваем балансировку нагрузки: равномерную или даже в заданной пропорции при помощи BGP bandwidth community, если ваше оборудование такое умеет (вспоминаем разговор про отличие маршрутизаторов от L3-свичей). Все то же самое, если провайдеров не два, а три, пять, двадцать, сто двадцать.
Некоторый (в общем, единственный) минус такого подхода — это то, что вместе с «гранулярным» роутингом мы отказались и от контроля над ричабилити: у вас не будет сигнализации связности с конкретными ресурсами в интернете. Отдельные префиксы в фулвью — это информация непосредственно от ресурса, которому вам нужно послать трафик. А дефолт чаще всего сгенерирован вашим провайдером (ну, или провайдером вашего провайдера, что лучше), и может так случиться, что дефолт от провайдера вы получаете, а на самом деле никакого интернета у него (провайдера) нету. Вот вам и иллюстрация «черной дыры» как следствия агрегации маршрутов.
Во-первых это все-таки не очень большой риск: степень защищенности инфраструктуры ваших провайдеров в любом случае должна быть на порядок выше, чем у вас. Если же описанная ситуация происходит часто, то это повод задуматься о смене провайдера. Во-вторых, при двух интернет-линках и схеме «основной-резервыный» (напомню, речь только об исходящем трафике), можно дополнительно подстраховаться: ну, например, получите от основного провайдера пару префиксов типа Гугла и Яндекса и напишите правило, создающее агрегированный дефолт только в том случае, если заданные маршруты в норме.
Вы боитесь, что Вконтакте будет доступен только через одного провайдера, а Одноклассники только через другого? Такой челлендж для вас бизнес-критикал? Страшно, и желаете защититься? Хотите поговорить об этом с руководством? Оно тоже так думает и готово потратить деньги? — поздравляю (в первую очередь вашего поставщика оборудования). Нет? — что ж, для вас чуть ниже будет заключительный параграф.
В случаях же, когда вам нужна связность не с абстрактным интернетом, а с конкретными ресурсами, адреса которых (обычно в количестве десятков—сотен) известны, например, когда речь идет о терминировании статических туннелей для VPN с филиалами, можно (и даже нужно) кроме дефолта также принять от провайдеров маршруты к этим ресурсам (удаленным точкам). ORF здесь был бы особенно актуален, но как-то он не слишком в ходу.
Вред от фулвью
А почему, собственно и не фулвью? Чего париться-то всеми этими рассуждениями? Ну примем мы его себе, да и все дела?
Во-первых баласировать исходящий трафик в нужной пропорции, когда у вас на руках фулвью, в разы сложнее и муторнее (совершенно неинтересное занятие). По умолчанию балансировка работает по принципу «как карта ляжет». Допустим, вы арендуете широкий канал у провайдера попроще и подешевле и канал поуже у провайдера покруче и подороже. Так вот, если не принять специальных мер, бо́льшая часть исходящего трафика у вас попрет в узкий канал и (возможно) перегрузит его: связность у «крутого» провайдера лучше, и BGP, который ничегошеньки не знает о пропускной способности ваших линков, будет думать, что бо́льшая часть интернета к вам «ближе» через узкий канал. Хотя с точки зрения юзер-экспириенс скорее всего все равно, каким маршрутом слать трафик, главное, чтобы не было перегрузки. Имея же два дефолта без фулвью и правильный маршрутизатор, можно и вовсе явно указать пропорцию: в канал поуже слать 30%, в канал пошире — 70.
Во-вторых по экономическим причинам: корпоративной сети полноценный большой аппаратный маршрутизатор часто не по карману. Поэтому, если нужна высокая производительность (гигабиты), можно использовать те самые относительно дешевые свичи, способные держать в FIB лишь несколько тысяч префиксов.
Однако часто в корпоративных сетях для BGP-пиринга используется менее производительные, но значительно более многофункциональные программные коробки. И обычно та же коробка является одновременно бордер-маршрутизатором, пограничным стейтфул-файрволом, делает нат, всю внутреннюю маршрутизацию, а иной раз, прости господи, проверяет трафик на вирусы, фильтрует URL, моет посуду, варит кашу, стирает, гладит и нянчит детей. И все это добро хранится у нее в оперативной памяти, которая, как я уже отмечал, все-таки не резиновая, и обрабатывается общим процессором, который тоже не ломовая лошадь. Пихать в такую коробку еще и несколько фидов с фулвью — совсем как-то ни к чему. Да не нужно просто этого делать!
Вывод четвертый. Если автономная система у вас не транзитная (вы не провайдер и у вас нет клиентов со своими АС), и при этом вы сами для себя не можете четко сформулировать, зачем вам фулвью, — фулвью вам не нужна.
Что, если очень хочется?
На самом деле у фулвью есть один важный и часто решающий плюс, о котором я до сих пор стыдливо умалчивал. Многим кажется, что это круто. Одно дело, когда show route summary показывает 7 маршрутов, и совсем другое — когда 700 тысяч. Какая корпоративная сеть не мечтает стать операторской?