Пользователь
0,0
рейтинг
28 февраля 2011 в 03:29

Фулвью ор нот фулвью: о пользе и вреде полной 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 «куда посылать») и разные там другие параметры, определяющие ценность этого маршрута. Когда есть два (полученных от разных маршрутизаторов-соседей) маршрута для одного префикса, в ход идут как раз эти атрибуты. Они определяют, какой некстхоп будет использован для передачи.

Пример:
rviews@route-server.as8218.eu> show route 8.8.8.8    
inet.0: 343453 destinations, 1643368 routes (343453 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

/*  Активный (т. е. наилучший с точки зрения BGP) маршрут помечен звездочкой, 
    только он используется для передачи трафика */
>8.8.8.0/24         *[BGP/170] 6w2d 06:12:47, MED 200, localpref 3200, from 83.167.56.18
                      AS path: 15169 I
                    > to 83.167.56.240 via ge-0/0/0.0
                    [BGP/170] 4w1d 04:00:53, MED 200, localpref 3200, from 83.167.56.6
                      AS path: 15169 I
                    > to 83.167.56.240 via ge-0/0/0.0
                    [BGP/170] 4w2d 04:00:03, MED 200, localpref 3200, from 83.167.56.5
                      AS path: 15169 I
                    > to 83.167.56.240 via ge-0/0/0.0
[...]

Здесь показаны три маршрута к префиксу 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 тыс. активных маршрутов:

route-server>show ip bgp summary 
BGP router identifier 12.0.1.28, local AS number 65000
BGP table version is 22316128, main routing table version 22316128
339895 network entries using 41127295 bytes of memory   // Активные префиксы: 340 тыс.
6244036 path entries using 324689872 bytes of memory     // Всего префиксов: 6,2 млн.
420973/58130 BGP path/bestpath attribute entries using 58936220 bytes of memory
82551 BGP AS-PATH entries using 2164884 bytes of memory
150 BGP community entries using 3600 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 426921871 total bytes of memory
Dampening enabled. 1728 history paths, 1519 dampened paths
BGP activity 3285644/2945748 prefixes, 85118539/78874498 paths, scan interval 60 secs
[…]

Или то же самое плюс IPv6 на Juniper:
rviews@route-server.as8218.eu> show route summary    
Autonomous system number: 8218
Router ID: 83.167.63.120
inet.0: 343437 destinations, 1643129 routes (343437 active, 0 holddown, 0 hidden) 
              Direct:      3 routes,      3 active
               Local:      1 routes,      1 active
                 BGP: 1642930 routes, 343238 active
              Static:      2 routes,      2 active
               IS-IS:    193 routes,    193 active
[…]
inet6.0: 4796 destinations, 20733 routes (4796 active, 0 holddown, 0 hidden) 
              Direct:      4 routes,      4 active
               Local:      2 routes,      2 active
                 BGP:  20577 routes,   4640 active
              Static:      1 routes,      1 active
               IS-IS:    149 routes,    149 active

Конструкция из нескольких еще необсчитанных 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) — ну очевидно же, что тем медленнее, чем больше в массиве элементов, каким алгоритмом не ищи.

Вывод второй. Подбирая аппаратный маршрутизатор на BGP-пиринг с фулвью, испросите продавца насчет максимального размера FIB. Если продавец не знает — повод призадуматься о его компетентности. Возможные варианты:
  • < 500 тыс. для IPv4 — лучше не стоит такое сегодня брать. Совсем не за горами время, когда этого будет мало. А ведь есть еще и IPv6.
  • ~500 тыс. — эта цифра популярна для т. н. больших L3-коммутаторов, тех самых, у которых дури много, а набор коммутационных процедур довольно посредственный. Хотя бывают приятные исключения. «Большие» от «маленьких» коммутаторов здесь отличаются во-первых размером коробки и старшинством модели в линейке, во-вторых и в-главных — объемом коммутационной памяти: редко когда «маленький» 24-портовый коммутатор поддерживает полмиллиона записей в FIB. Так вот, хотя коммутационной памяти у «больших» L3-коммутаторов вроде бы достаточно для сегодняшней фулвью, проделывать с пакетом сложные штуки они почти никогда не умеют (собственно, в этом их главное отличие от маршрутизаторов). Их, с одной стороны, если очень хочется, вроде бы и можно использовать для этой задачи, с другой — лучше бы не надо. Очень уж там много всяких нюансов. Короче, подумайте и помучайте продавца хорошенько, прежде чем покупать L3-коммутатор на BGP-пиринг c фулвью.
  • миллион и больше — достойная цифра.
Если продавец сможет вас более-менее уверенно проконсультировать еще и про размер 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 тысяч. Какая корпоративная сеть не мечтает стать операторской?

Ответы тут такие (выбирайте, какой больше нравится):
  • И правильно, не отказывайте себе в удовольствии. Вендоры и продавцы маршрутизаторов будут очень рады этому вашему желанию. Надеюсь, работодатель вас в этом тоже поддержит (материально).
  • Внедряя и администрируя публичную АС и BGP-пиринг, вам придется решить более сложную и интересную задачу: балансировка входящего трафика и резервирование линков для него. Вид, в котором ваше адресное пространство видно в интернете (роутинг) и видно ли (ричабилити), как организовать резервирование, что будет при нарушении внутренней связности АС, и еще целая куча сложных вопросов ждет от вас решительных и верных действий. Это вам не фулвью принять.
  • Наконец, посмотреть, как выглядит полная таблица, можно и на любом публичном route-сервере (вам, кстати, придется это сделать, отлаживая свои анонсы).
@salium
карма
119,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (55)

  • +3
    Замечательная статья, но очень много терминов-кАлек (бизнес-критикал, ричабилити), не очень устоявшихся (хотя я не очень знаком с терминологией, но файрвол, роутер и пиринг вполне нормально воспринимаю). Было бы хорошо терминологию во введение вывести (например, в середине статьи внезапно есть ссылка на вики про АС, хотя если читатель понял всё предыдущее, то что такое АС он явно знал).
    • +4
      Ну, про бизнес-критикал (в отношении вконтакте и одноклассников) — это шутка была. Видимо неудачная :) В остальном — в общем, я с вами согласен. Просто тут сложно найти стилевой баланс между неформальностью и заумностью. Заменить везде ричабилити на доступность (а точнее даже на сигнализацию доступности), роутинг на маршрутизацию, фулвью на полную таблицу, некстхоп на следующий узел — выйдет введение к диссертации. Я изо всех старался этого избежать. В частности используюя такие вот псевдожаргонизмы, записывая их по-русски. Примерно та же история с балансом между статьей для детского сада и совсем уж заумью, которая будет понятна, лишь тем, кто и без меня все это знает. Дело в том, что я и так потратил на всякого рода правки этой статьи несколько больше времени, чем рассчитывал, поэтому в какой-то момент решил остановиться :)
      • 0
        а почему была выбранная именно эта тема?
        • 0
          потому что bgp-нубу выбирающие железо по размеру rib'а/fib'а видимо достали всех не только в чатиках. Ж)))
  • +8
    Статья на 5+. Зачитался. Особенно манерой изложения. Раскрыта разница L3-коммутаторов и маршрутизаторов на пальцах. Автору ОГРОМНОЕ спасибо.
  • 0
    Спасибо за статью, хотя и не для «уровня Хабра» она.

    > И крайне редко обсуждается вопрос о необходимости этого самого фулвью.

    Значит у сетевиков та же дурацкая практика «меряться письками», неважно зачем она предназначена. Напомнило как чайник выбирает себе ноутбук «для интернета и игр», хочет, конечно, «сааааамый мощный». Долго выедает всем мозг про i7, и как поставить на ноут 8 гиг памяти, а потом выясняется что интернет у него — аська и вконтактик, а игрушки — шарики и махджонг.
    Зато самый мощщщщный.
    Напоминает выбор автомобиля по крайнему числу на спидометре (больше — значит автомобиль лучше)
    • +1
      А какой у Хабра уровень?
    • 0
      А чем сетевеки отличаются от всех других? :)
  • +20
    Я тупой :’(
    • +1
      C прошедшим!
  • 0
    Спасибо большое, интересно. На тему BGP- пиринг vs Default Gateway.

    А для каких случаев может пригодится полный пиринг, если следующий хоп один? Мне в голову приходят только специфические возможности BPG типа Blackhole, но ведь оно сработает даже если на PE отфильтровывать маршруты.
    • +1
      Не BGP-пиринг vs дефолт, а фулвью vs. дефолт. Все описанное не отменяет того, что у вас есть а) своя АС, б) свой блок адресов, в) вы BGP-пиритесь с другими автономными системами, в) вы анонсируете свои префиксы в мир. Вообще пункты (б) и (в) — это то, ради чего непровайдерам нужен BGP-пиринг. И умение правильно влиять на свои анонсы в мир (на основе которых мир посылает вам трафик) — гораздо более тонкая задача.
    • +1
      Фулвью с одиим линкам может быть нужна, если она вам зачем-то нужна, но форвадить на ее базе трафик вы не собираетесь. Например на нее можно просто сидеть и втыкать :) Проводить какие-нибудь исследования, рисовать графики и т. п. Затем ее можно дальше куда-нибудь передать, где она дейтвительно нужна. Например внутри корпоративной сети (которой самой по себе не нужна никакая фулвью) есть сетевая лаборатория, где фулвью может пригодиться для тестов.
  • +2
    ~500 тыс. — эта цифра популярна для т. н. больших L3-коммутаторов, тех самых, у которых дури много, а набор коммутационных процедур довольно посредственный.
    Шикарно излагается. Прочитал с большим интересом.
  • +1
    На самом деле у фулвью есть один важный и часто решающий плюс, о котором я до сих пор стыдливо умалчивал. Многим кажется, что это круто. Одно дело, когда show route summary показывает 7 маршрутов, и совсем другое — когда 700 тысяч. Какая корпоративная сеть не мечтает стать операторской?
    это быстро проходит, да как-то и вообще не сильно тянет на аргумент инженера ;) К тому же никто и никогда не пропустит full-view внутрь сети, тем более корпоративной.
  • +4
    статья просто бомба, и хрен с ним, что опоздал из-за чтения на работу :)
  • 0
    Статья безусловно полезная, особенно для тех кто не в теме, но желает разобраться.

    Но один пропущенный важный момент делает вредным конечный вывод.

    Дело в том что интернет и протокол BGP подразумевает равноправное взаимодействие сторон.
    Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность. Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.

    Вместо того чтобы отдать решение о выборе исходящего трафика протоколу BGP, в котором динамически балансируются миллионы частных интересов, ты подкидываешь монетку и тыкаешь наугад. Фул вью это не 350 тысяч ненужных записей, а 350 тысяч заявлений разных участников о своей политике маршрутизации. Отказываясь от этой информации ты отказываешься от возможности самостоятельно принимать решение в выборе пути.

    Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно.

    Если возникнут вопросы как именно схема основной резервный снижает надежность BGP, могу привести примеры, но из прочтения статьи должно быть понятно.
    • +1
      Вы меня извините, но ваш коммент — это как раз и есть те самые классические заблуждения.

      «Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность.»

      Ну… спорю, что в 90% случаев от того, какой из своих аплинков предпочтет корпоративный ЦОД для потребилтеля его сервиса ничего не изменится. А вот влиять на свои анонсы (что гораздо важнее) парню на том конце вообще никто запретить не может.

      «Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.»

      Все наоборот. Не используя фулвью, легко добиться, например, схемы полного active/passive, когда в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны. С фулвью — ну тоже можно, например, префиксам от бекапного линка LP выставить ниже, но это будет та самая история про «Адам, выбирай себе жену», равносильная двум дефолтам с разными метриками (то есть полный бред). Опираясь же на фулвью при форвадинге по-настоящему (сравнивая AS-PATH'ы) — вы вообще никак не можете предсказать, куда пойдет трафик. Ассиметрия на пиринге — вещь неизбежная, т. к. решения о форвадинге туда и обратно принимаются независимо. Можно лишь стараться нагружать линки в нужной пропорции. Так, как я и написал, без фулвью это как раз проще.

      «Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно»

      Это утверждение просто неверно для большинства нетранзитных аэсок.

      • 0
        А когда вы говорите о балансировке трафика между двумя дефолтами, какую технологию вы имеете в виду? Equal cost multi path? Т.е. разные пакеты из одного потока (tcp сессии) могут уйти через разные аплинки?
        Такая ассиметрия гораздо коварнее (при диагностике проблем) чем свойственная для bgp ассиметрия входящего относительно исходящего трафика.
        • +3
          Во, интересная тема, тоже полная мифов.

          На самом деле сегодня ECMP в большинстве реализаций работает иначе, чем вы описали. Балансировка происходит не для каждого пакета, а per-flow. Причем маршрутизатор не хранит состояния сессий: у пакета берутся некоторые параметры (включая src/dst IP и src/dst-порты транспортного протокола), с них вычисляется ключ (хэш), и этот ключ определяет некстхоп. В устройствах попроще типа помянутых l3-свичей делается примерно так next_hop_idx = hash_key mod number_of_next_hops. В устройствах посерьезнее используются функции посложнее, позволяющие, например, достичь балансировки в заданной пропорции. Кое-где также можно влиять на поля пакета, из которых считается хэш.

          Соответственно пакеты в рамках одной сессии будут иметь одинаковый хэш, и уйдут одним маршрутом.
          • 0
            Тогда это меняет дело :)
      • 0
        Хорошо, элементарный вопрос на засыпку.

        У меня 1 аплинку к оператору A, второй аплинк к Оператору B. Имеем далее сайт находящийся в автономной системе C который доступен как через А, так и через B.

        Причем как это обычно бывает A и B находятся в одном городе, но имеют связь между собой через франкфурт.

        Нарисуйте конфигурацию БЕЗ full-view которая защитит передачу трафика при любом из двух возможных обрывов ликов у C.

        «Ассимитрия на пиринге» это зло которое создают вот именно такие «оптимизаторы» которые никогда не слышали слова comunity. Кстати, в вашей статье это слово упоминается всего один раз в неизвестном мне сочетании «BGP bandwidth community».

        Так же вы утверждаете что L3 свичи и Роутеры отличаются поддержкой комьюнити. Это не правда, совсем не другим они отличаются :)

        «в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны» Хочется спросить, вы за свою жизнь хоть раз бгб-мултихоминг настраивали?
        Это утверждение полная чушь! 10 лет занимаюсь работой с BGP и могу совершнно уверено сказать что:

        Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает. А потому что на другом конце всгда есть такой же упертый, который упорно пытается свой исходняк влить вам совсем не в ту дырку в которую хочется принять вам. Об чем я пытаюсь сигнализировать.

        • +1
          1. Понимаете, вы смотрите на все это как бы глазами провайдера и исходите из предположения, что ситуация, когда неполная связность с интернетом у проавайдера при отсутствии знания об этом у клиента (за счет использования дефолта) — это случай, о котором клиенту стоит печься.

          ОК, может быть и стоит, я же написал, что мы теряем информацию о ричабилити конкретных префиксов. И да, это в определенной степени компроммис, имеющий оборотную сторону. Но только важно отдавать себе отчет, с чем, собственно мы собираемся бороться при помощи фулвью, если уж мы так ее хотим. Большинство не отдает.

          Кроме того, все это все равно полная ерунда. Потому что если предполагаеть, что провайдер дурак, то никакя фулвью вас не спасет. Потому что потеря связности с миром у провайдера — это ситуация в миллион раз менее вероятная, чем какая-нибудь другая жопа, от котороый вы не защититесь. Нет никакой гарантии, что посылая трафик провайдеру, опираясь при этом на специфик-префиксы из фулвью, провайдер его не закольцеут или не заблекхолит. А еще в сто раз более вероятно, что у провайдера возникнет перегрузка какого-нибудь внешнего линка, и BGP об этом даже не узнает.

          Поэтому-то я и говорю. Если вы, будучи корпоративной сетью, хотите сами стать чуть-чуть провайдером, то никто не может вам этого запретить. Но только все же надо отдавать себе отчет, что одним только принятием фулвью вы практически ничего не выиграете. А проиграете — почти наверняка. А дальше принимайте решение сами. На мой взгляд правильный выбор провайдера тут в сто раз важнее всех фулвью.

          2. Про комьюнити и отличие роутеров от L3-сивичей — простите, вы мне приписываете слова, которых я не говорил. Я говорил, что возможность неравномерной балансировки посредством bandwindth community — это эдвансная фича, которую L3-свичи не умеют. Комьюнити и bandwidth-комьюнити — это не одно и то же. Наберите в гугле Bandwidth community.

          3. Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает.

          LOL. Простите. Автоциатата:

          Маршрутная информация всегда передается навстречу трафику, который коммутируется на ее основе. То есть на базе фулвью передается исходящий из вашей АС трафик. Не смотря на всю очевидность этого тезиса, далеко не всегда практическое его значение осознается в полной мере.

          Фулвью на нашей стороне не имеет НИКАКОГО отношения к входящему трафику. Вообще.

          Что до входящего трафика — вы не правы. Большинство нормальных провайдеров поддерживают комьюнити, позволяющие поставить низкий LP на наши анонсы, чтобы использовать линк как бекап. Плюс к этому есть еще длина префиксов. Но я не хочу об этом даже начинать разговор. Он принципиально про другое и не имеет никакого отношения к данной статье. Кроме того на эту тему полно литературы.
          • 0
            В вопросе наличия информации в полной таблице и ее потери при исключении фул-вью мы кажется сошлись.

            В вопросе того, что в 99% случаях фул вью рядовому пользователю ничего не дает я тоже соглашусь.

            А вот в вопросе нужно ли устранять оставшиеся 1% проблем у нас отношение разное.

            Я, с точки зрения провайдера считаю что нужно. Потратил время и деньги на AC-ку и свой блок адресов — используй. Если не хочешь, то должен осознавать то отказ от принятия решения на базу full-view ухудшит надежность в решении… тех самых 1% сбоев.
            • 0
              Ок, мир :)

              Только еще одно. Бросаясь в бой на 1% проблем надо а) сначала решить 99%, б) в серьез отдавать себе отчет, какой ценой будет это борьба.

              А так, я чо, я сам работаю маршрутизаторы продаю, так что я только за :)
              • 0
                Вот почему так издеваетесь в статье над тупыми продовцами )) коллег подтруниваете, да еще и со своей организации поди хехе… а они читают и косятся, сцука мол, шарит )
                Спасибо, за статью. Это на самом деле хорошо, когда человек шарит в том, чем занимается. А те пусть на стройку идут или в такси; )
          • 0
            > что мы теряем информацию о ричабилити конкретных префиксов

            вот вчера ломался ростелеком, гора из трех сотен с лишним тысяч префикс фулла была на месте, а трафик не ходил. вот вам и ричабилити конкретных префиксов. так что наличие конкретных префиксов еще не гарантия ричабилити.
      • 0
        За статью аплодирую стоя.
        Вот только есть вопрос — просветите чайника, чем плохи два дефолтных маршрута с разными метриками, ежели у меня допустим два алпинка, которыми командует программный роутер?
        • 0
          Два каких маршрута? Статических? — тем, что если один из провайдеров сломается, вы об этом даже не узнаете.

          Или два дефолта, полученных от провайдеров по BGP с разными, скажем, LP (это не совсем метрика, но почти как)? Да ничем они не плохи, всем хороши. Ну некоторым очень хочется балансировать исходящий трафик. Зачем-то. Ну, бывает, и правда надо. Тогда метрики (LP в данном случае) и все остальные параметры качества BGP-маршрутов должны быть одинаковые, плюс еще включено пара доп. опций, и тогда оба некстхопа для данного отправятся в FIB.
  • –1
    О… похоже на годную статью.:-)

    Куда катится хабр.…
    Забадай его бумбурум.

  • +1
    Ох я помню отговаривал один маленький корпоратив от идеи на Cisco 28xx принимать себе 2 FV, при том что основным аргументом у админа было а-ля «Ну это же круто! Нам нужны все префиксы!»… Эту бы статью да ему под нос.
    • +4
      А еще он на ней нат делал и нетфлоу снимал? :)
      • +4
        Вы не поверите…
  • +1
    Обязательно в избранное. Буду читать до просветления время от времени. Много еще мне непонятного, но крайне интересное чтиво.
  • –2
    Сначала я подумал, что статья будет интересной, но в итоге она могла бы уместиться в четырех выводах. Хотя, возможно, для человека со стороны такое изложение будет более приемлемым, чем для более квалифицированного.
  • –2
    Блин, пишите хотя бы на английском некоторые слова, а то от вашего «Фулвью ор нот фулвью» глаза сломаешь.
  • +2
    Отлично. Я обожаю такие статьи по одной причине: я их читаю. До какой-нибудь книжки или оф. документации у меня бы ещё очень не скоро дошло дело.
    Спасибо большое. Очень ценная информация, которая подана понятным и, надо признать, интересным языком.
    Хотелось бы ещё статью о балансировке входящего трафика (и т.д.)
  • –1
    Очень замечательная статья. Я абсолютный новичок в динамической маршрутизации, знаю лишь азы и понял 80% статьи(думаю со временем надо будет перечитать чтобы понять всю статью).

    PS: Аффтар жжошь, пеши исчо )
  • 0
    Спасибо за статью!
    А можно подробнее про
    > «Имея же два дефолта без фулвью и правильный маршрутизатор, можно и вовсе явно указать пропорцию: в канал поуже слать 30%, в канал пошире — 70»?
    Или ткните носом ссылкой где почитать? Спасибо!
    • +1
      Ой, случайно не там ответил.

      В общем случае вот:
      www.google.ru/search?hl=&q=bgp+bandwidth+community&sourceid=navclient-ff&rlz=1B5GGGL_enRU318RU318&ie=UTF-8

      А хорошо про внедрение этого написано в книжке «Junos Enterprise Routing» by Doug Marschke, Harry Reynolds
      Стр. 236 и ниже (подраздел «Use BGP for Assymetric Load Balancing») books.google.com/books?id=UI2ZwjIgBwwC&lpg=PP1&dq=JUNOS%20Enterprise%20Routing&hl=ru&pg=PA236#v=onepage&q&f=false
  • 0
    В общем случае вот:
    www.google.ru/search?hl=&q=bgp+bandwidth+community&sourceid=navclient-ff&rlz=1B5GGGL_enRU318RU318&ie=UTF-8

    А хорошо про внедрение этого написано в книжке «Junos Enterprise Routing» by Doug Marschke, Harry Reynolds
    Стр. 236 и ниже (подраздел «Use BGP for Assymetric Load Balancing») books.google.com/books?id=UI2ZwjIgBwwC&lpg=PP1&dq=JUNOS%20Enterprise%20Routing&hl=ru&pg=PA236#v=onepage&q&f=false
  • 0
    Большое спасибо за статью. Доходчиво, грамотно и без воды.
  • 0
    одного не могу понять
    зачем спецы potaroo.net рисуют такие графики (многолинейные, многоцветовые, с шумом и без легенды)
    когда в своих же документах используют вполне внятные картинки?

    • 0
      Я думаю, это традиция. Этот график уже стал эпосом. Его перепечатывают в книжках и т. д. Разные цвета тут — разные маршрутизаторы, что вполне логично показать.

      Кроме того, potaroo.net — это не «спецы», а совершенно конкретный Geoff Huston. Судя по общему всему (включая и приведенную вами картинку, тоже не белстящую), дизайн, представление данных, типографика — это все не его конек :)
  • +1
    > Дальше либо используем только один из маршрутов, а второй держим про запас (на случай, если первый отвалится) и пускаем весь исходящий трафик по одному линку, либо настраиваем балансировку нагрузки

    > Некоторый (в общем, единственный) минус такого подхода — это то, что вместе с «гранулярным» роутингом мы отказались

    возможно я что-то пропустил в статье, но ведь есть и «компромис» между крайностями «фуллвью» и «дефолт-оригинейт». можно ведь договориться с провайдером о передачи вам его «партиал-меш» + «дефолт». в первое войдут все префиксы от кастомеров провайдера, его собственные префиксы и префиксы с исков к которым он подключен. имея два, три, стодвацдатьтри линка с такими условиями мы вполне можем отправить исходящий трафик по «лучшему» маршруту, как и принять входящий трафик, даже скорее всего большая часть трафика будет ходить симметрично, что тоже весьма позитивная деталь. размер партиал-меша где-то до 20 тысяч префиксов => даже в древний каталист 3550 оно влезет :) другое дело что в rib наверно несколько линков не влезет, ну я думаю можно найти свич где риб жирненький. :) у фаундри/брокад вообще в л3 свищи несколько фв помещаются. :)

    ну а вообще да, крутая статья, столько откровений для забра еще ни в одной статье мне кажется не было. мне бы такую пару-тройку лет назад. хотя, статья, конечно, не избавляет от необходимости читать хелеби и иже с ним. :)
    • 0
      Про частичный меш и вообще более эдвансные компромиссы — согласен. Просто статья все-таки чуть другого уровня. Плюс с провайдерами договариваться — это целая наука :) Хотя кое у кого даже комьюнити стоят, так что можно и не договариваться, а матчить эти комьюнити плюс as-path. А те, которые готовы, в моих советах не нуждаются. Большинство же компаний со своими автономками — это upto десятки мегабит исходящего трафика. Ну пошлют они мегабит-другой в сторону клиент провайдера Б через провайдера А. На деле они либо пирятся на IX, либо один другому аплинк. Ужас-ужас-ужас :)

      На мой вкус, что действительно важно энтерпрайзу — это принять префиксы всяких своих удаленных IPSec-пиров и прочего такого добра. Но в реальности не многие готовы даже этим парится.

      У брокейда — вы про риб или про фиб? Про риб — это не большая редкость. У джунипера в EX3200/4200 можно пару ФВ впихнуть (наверняка и больше, но я не пробовал), просто слово заветное надо знать. А вот в фиб — это у брокейда только CER, который в общем-то роутер.
    • 0
      Кстати, тут еще вот какой момент такой, о котором я совершенно забыл сказать (хотя наверное и так многовато текста), что если энтерпрайзная АС физически мультихомная (то есть разные аплинки приходят в территориально разные офисы), то связность внутри АС скорее всего совершенно смехотворная: арендованый L2-канал без резервированя, без ничего. Хорошо еще если у приличного оператора. При этом нагруженый внутренним трафиком. В такой ситуации лучше бы бордер не валял дурака, а слал все в интернет, даже если если это трафик в АС аплинка другого офиса.
      • 0
        > У брокейда — вы про риб или про фиб? Про риб — это не большая редкость. У джунипера в EX3200/4200 можно пару ФВ впихнуть (наверняка и больше, но я не пробовал), просто слово заветное надо знать. А вот в фиб — это у брокейда только CER, который в общем-то роутер.

        про риб, ага, я и не говорил что редкость, ага, просто выбрать где пожирней :) я CER не щупал, но судя по презе он от CES отличается разжиревшим fib/rib'ом и вложеными в коробку лицухами про бгп, что превращает его в просто л3 свищ с жирным фибом и поддержкой бгп. хотя, может этого и достаточно чтобы называться маршрутизатором, смотря что хотеть от маршрутизатора. :)

        > Ну пошлют они мегабит-другой в сторону клиент провайдера Б через провайдера А. На деле они либо пирятся на IX, либо один другому аплинк. Ужас-ужас-ужас :)

        да, есть такое. /* bursts in tears */

        /* offtopic
        а подскажите какую дельную литературу по освоению netscreen'ов, те что на screenos, почитать, а то когда открываю дефолтовый конфиг и пытаюсь читать, начинает болеть голова…
        offtopic */
        • 0
          CER — хорошая штука. У нас есть в лабе/демо. Главное отличие от CES именно в раземере FIB и другими лицензиями (два уровня вместо трех). Еще кажется CES L3VPN (BGP MPLS) не поддерживает. Был бы он еще под JUNOS'ом, цены б ему не было :)

          По ScreenOS — ну вообще у них документация очень неплохая. Concepts & Examples которая: www.juniper.net/techpubs/en_US/screenos6.3.0/information-products/pathway-pages/screenos/index.html

          Есть еще две книжки:

          1. oreilly.com/catalog/9780596510039
          2. www.amazon.com/Configuring-Juniper-Networks-Netscreen-Firewalls/dp/1597491187/sr=11-1/qid=1164817844

          Первая поэдванснее и поконцептуальнее, хотя и написана как сборник рецептов. Вторая — больше про то, на какие кнопки жать. Вторая (первое издание по крайней мере) точно гуляет в пиратском виде, первую — не встречал, но и не искал, т. к. есть бумажная.

          Еще есть крутая дока sin.pvs.ro/NetscreenJNCIS-FWV-StudyGuide-v1.3-public.pdf, написанная энтузиастом-одиночкой. Она старовата и кишит опечатками, но все равно довольно крута.
        • 0
          P. S. То, что в моем понимании дает CER право называться маршрутизатором — это таки да FIB 512k IPV4, но в совокупности с MPLS более-менее похожим на MPLS.
          • 0
            спасибо за ссылки на доки, особенно на доку энтузиаста, похоже «то что нужно». :) думаю вряд ли сильно релизы скриноса между собой отличаются, во всяком случае не принципиально как минимум.
  • 0
    При наличии нескольких ISP и при использовании только Default Route, в случае, если произойдёт отказ одного из ISP и при этом пириниг между вашим роутером и провайдером сохраняется, то Вы получите блэкхоул, Т.е. ISP не функционирует, а вы на него продолжаете слать трафик через default route. Тут придётся тогда либо IP SLa задействовать, либо просить провайдеров, чтобы они кроме default route передавали какие-нибудь внешние сети, по исчезновению которых запускать скрипты и прочее. Тогда зачем вообще BGP нужен, не понятно, можно вполне обойтись чем-то вроде Dynamic DNS и при падении ISP менять IP-адреса внешних ресурсов. На практике вполне легко добиться 5-минутного переключения, что сопоставимо с временем конвергенции BGP.
    • 0
      Если вспомнить, что роутинг и ричабилти — не одно и тоже, то будет чуть понятнее. Да, отказ от кастом-префиксов — это определенная плата. И вся речь лишь о том, в чем эта плата состоит и за что она.

      Если вы не держите полной таблицы — вы не знаете, ходит ли префикс от назначения A к вашему провайдеру по BGP. Это не то же самое, что уверенность в том, что если вы (при наличии префикса)

      Если префикса нет, значит связности (ричабилити) нету. Но. Если префикс есть — это вообще ни о чем не говорит. В боевых ситуациях бывает сколько угодно примеров, когда префикс есть, а трафик не ходит. Потому где-то у ISP линк перегружен например, или потому что у него в сети флэппинг или какая-нибудь еще нестабильность, от которой наличие FullView на вашей стороне никак не страхует.

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

      Теперь про то, за что это (отказ от FV) плата. Ну, собственно, вся статья про это. Вы существенно экономите (деньги) на оборудовании.

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

      Примерно в 90% случаях, когда я работаю таким консультантом для случая корпоративной сети, моя рекомендация — потратить эти деньги на что-нибудь более полезное.

      Мы в каментах тут про все это много раз поговорили со всех сторон. Вот например дельная веточка:
      habrahabr.ru/post/113906/?reply_to=7045634#comment_3703216

      >чем-то вроде Dynamic DNS и при падении ISP менять IP-адреса внешних ресурсов.

      Для интерактивных приложений типа web — нет. А для неинтерактивных (типа SMTP) реализация как правило поддерживает возможность резервирования средствами протокола (если недоступен один MX, идем на другой). В сущности, да, корпоративной сети AS и PI-блок нужна в первую очередь для обеспечения отказоустойчивости web-сервисов. Все остальное по большому счету сегодня можно сделать не парясь этим.

      Для связности интернета, транзитных AS и т. д. — там да, там полные таблицы во все стороны нужны.
    • 0
      Упс. Сорвалось.

      > Это не то же самое, что уверенность в том, что если вы (при наличии префикса)

      Это не то же самое, что уверенность в том, что если вы (при наличии префикса A) пошлете трафик назначению A, то он до него дойдет.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.