Комментарии 55
Замечательная статья, но очень много терминов-кАлек (бизнес-критикал, ричабилити), не очень устоявшихся (хотя я не очень знаком с терминологией, но файрвол, роутер и пиринг вполне нормально воспринимаю). Было бы хорошо терминологию во введение вывести (например, в середине статьи внезапно есть ссылка на вики про АС, хотя если читатель понял всё предыдущее, то что такое АС он явно знал).
Ну, про бизнес-критикал (в отношении вконтакте и одноклассников) — это шутка была. Видимо неудачная :) В остальном — в общем, я с вами согласен. Просто тут сложно найти стилевой баланс между неформальностью и заумностью. Заменить везде ричабилити на доступность (а точнее даже на сигнализацию доступности), роутинг на маршрутизацию, фулвью на полную таблицу, некстхоп на следующий узел — выйдет введение к диссертации. Я изо всех старался этого избежать. В частности используюя такие вот псевдожаргонизмы, записывая их по-русски. Примерно та же история с балансом между статьей для детского сада и совсем уж заумью, которая будет понятна, лишь тем, кто и без меня все это знает. Дело в том, что я и так потратил на всякого рода правки этой статьи несколько больше времени, чем рассчитывал, поэтому в какой-то момент решил остановиться :)
Статья на 5+. Зачитался. Особенно манерой изложения. Раскрыта разница L3-коммутаторов и маршрутизаторов на пальцах. Автору ОГРОМНОЕ спасибо.
Спасибо за статью, хотя и не для «уровня Хабра» она.
> И крайне редко обсуждается вопрос о необходимости этого самого фулвью.
Значит у сетевиков та же дурацкая практика «меряться письками», неважно зачем она предназначена. Напомнило как чайник выбирает себе ноутбук «для интернета и игр», хочет, конечно, «сааааамый мощный». Долго выедает всем мозг про i7, и как поставить на ноут 8 гиг памяти, а потом выясняется что интернет у него — аська и вконтактик, а игрушки — шарики и махджонг.
Зато самый мощщщщный.
Напоминает выбор автомобиля по крайнему числу на спидометре (больше — значит автомобиль лучше)
> И крайне редко обсуждается вопрос о необходимости этого самого фулвью.
Значит у сетевиков та же дурацкая практика «меряться письками», неважно зачем она предназначена. Напомнило как чайник выбирает себе ноутбук «для интернета и игр», хочет, конечно, «сааааамый мощный». Долго выедает всем мозг про i7, и как поставить на ноут 8 гиг памяти, а потом выясняется что интернет у него — аська и вконтактик, а игрушки — шарики и махджонг.
Зато самый мощщщщный.
Напоминает выбор автомобиля по крайнему числу на спидометре (больше — значит автомобиль лучше)
НЛО прилетело и опубликовало эту надпись здесь
Спасибо большое, интересно. На тему BGP- пиринг vs Default Gateway.
А для каких случаев может пригодится полный пиринг, если следующий хоп один? Мне в голову приходят только специфические возможности BPG типа Blackhole, но ведь оно сработает даже если на PE отфильтровывать маршруты.
А для каких случаев может пригодится полный пиринг, если следующий хоп один? Мне в голову приходят только специфические возможности BPG типа Blackhole, но ведь оно сработает даже если на PE отфильтровывать маршруты.
Не BGP-пиринг vs дефолт, а фулвью vs. дефолт. Все описанное не отменяет того, что у вас есть а) своя АС, б) свой блок адресов, в) вы BGP-пиритесь с другими автономными системами, в) вы анонсируете свои префиксы в мир. Вообще пункты (б) и (в) — это то, ради чего непровайдерам нужен BGP-пиринг. И умение правильно влиять на свои анонсы в мир (на основе которых мир посылает вам трафик) — гораздо более тонкая задача.
Фулвью с одиим линкам может быть нужна, если она вам зачем-то нужна, но форвадить на ее базе трафик вы не собираетесь. Например на нее можно просто сидеть и втыкать :) Проводить какие-нибудь исследования, рисовать графики и т. п. Затем ее можно дальше куда-нибудь передать, где она дейтвительно нужна. Например внутри корпоративной сети (которой самой по себе не нужна никакая фулвью) есть сетевая лаборатория, где фулвью может пригодиться для тестов.
~500 тыс. — эта цифра популярна для т. н. больших L3-коммутаторов, тех самых, у которых дури много, а набор коммутационных процедур довольно посредственный.
Шикарно излагается. Прочитал с большим интересом.
Шикарно излагается. Прочитал с большим интересом.
На самом деле у фулвью есть один важный и часто решающий плюс, о котором я до сих пор стыдливо умалчивал. Многим кажется, что это круто. Одно дело, когда show route summary показывает 7 маршрутов, и совсем другое — когда 700 тысяч. Какая корпоративная сеть не мечтает стать операторской?
это быстро проходит, да как-то и вообще не сильно тянет на аргумент инженера ;) К тому же никто и никогда не пропустит full-view внутрь сети, тем более корпоративной.
это быстро проходит, да как-то и вообще не сильно тянет на аргумент инженера ;) К тому же никто и никогда не пропустит full-view внутрь сети, тем более корпоративной.
статья просто бомба, и хрен с ним, что опоздал из-за чтения на работу :)
Статья безусловно полезная, особенно для тех кто не в теме, но желает разобраться.
Но один пропущенный важный момент делает вредным конечный вывод.
Дело в том что интернет и протокол BGP подразумевает равноправное взаимодействие сторон.
Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность. Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.
Вместо того чтобы отдать решение о выборе исходящего трафика протоколу BGP, в котором динамически балансируются миллионы частных интересов, ты подкидываешь монетку и тыкаешь наугад. Фул вью это не 350 тысяч ненужных записей, а 350 тысяч заявлений разных участников о своей политике маршрутизации. Отказываясь от этой информации ты отказываешься от возможности самостоятельно принимать решение в выборе пути.
Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно.
Если возникнут вопросы как именно схема основной резервный снижает надежность BGP, могу привести примеры, но из прочтения статьи должно быть понятно.
Но один пропущенный важный момент делает вредным конечный вывод.
Дело в том что интернет и протокол BGP подразумевает равноправное взаимодействие сторон.
Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность. Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.
Вместо того чтобы отдать решение о выборе исходящего трафика протоколу BGP, в котором динамически балансируются миллионы частных интересов, ты подкидываешь монетку и тыкаешь наугад. Фул вью это не 350 тысяч ненужных записей, а 350 тысяч заявлений разных участников о своей политике маршрутизации. Отказываясь от этой информации ты отказываешься от возможности самостоятельно принимать решение в выборе пути.
Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно.
Если возникнут вопросы как именно схема основной резервный снижает надежность BGP, могу привести примеры, но из прочтения статьи должно быть понятно.
Вы меня извините, но ваш коммент — это как раз и есть те самые классические заблуждения.
«Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность.»
Ну… спорю, что в 90% случаев от того, какой из своих аплинков предпочтет корпоративный ЦОД для потребилтеля его сервиса ничего не изменится. А вот влиять на свои анонсы (что гораздо важнее) парню на том конце вообще никто запретить не может.
«Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.»
Все наоборот. Не используя фулвью, легко добиться, например, схемы полного active/passive, когда в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны. С фулвью — ну тоже можно, например, префиксам от бекапного линка LP выставить ниже, но это будет та самая история про «Адам, выбирай себе жену», равносильная двум дефолтам с разными метриками (то есть полный бред). Опираясь же на фулвью при форвадинге по-настоящему (сравнивая AS-PATH'ы) — вы вообще никак не можете предсказать, куда пойдет трафик. Ассиметрия на пиринге — вещь неизбежная, т. к. решения о форвадинге туда и обратно принимаются независимо. Можно лишь стараться нагружать линки в нужной пропорции. Так, как я и написал, без фулвью это как раз проще.
«Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно»
Это утверждение просто неверно для большинства нетранзитных аэсок.
«Отключая фул-вью на своем конце, ты лишаешь «парня на том конце» возможности выбора входящего трафика, понижает его надежность.»
Ну… спорю, что в 90% случаев от того, какой из своих аплинков предпочтет корпоративный ЦОД для потребилтеля его сервиса ничего не изменится. А вот влиять на свои анонсы (что гораздо важнее) парню на том конце вообще никто запретить не может.
«Создаешь «ассиметрию трафика» — очень сложную для диагностики проблему. Это некий эгоцентризм — пусть я экономлю, а другие напрягаются.»
Все наоборот. Не используя фулвью, легко добиться, например, схемы полного active/passive, когда в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны. С фулвью — ну тоже можно, например, префиксам от бекапного линка LP выставить ниже, но это будет та самая история про «Адам, выбирай себе жену», равносильная двум дефолтам с разными метриками (то есть полный бред). Опираясь же на фулвью при форвадинге по-настоящему (сравнивая AS-PATH'ы) — вы вообще никак не можете предсказать, куда пойдет трафик. Ассиметрия на пиринге — вещь неизбежная, т. к. решения о форвадинге туда и обратно принимаются независимо. Можно лишь стараться нагружать линки в нужной пропорции. Так, как я и написал, без фулвью это как раз проще.
«Если тебе не нужно фул-вью, то скорее всего два три аплинка тебе тоже не нужны. Без фул-вью эффективность их использования серьезно снижается именно в случае настоящих интернет-катастроф (типа известного блекаутаа на М9), когда резервирование более всего нужно»
Это утверждение просто неверно для большинства нетранзитных аэсок.
А когда вы говорите о балансировке трафика между двумя дефолтами, какую технологию вы имеете в виду? Equal cost multi path? Т.е. разные пакеты из одного потока (tcp сессии) могут уйти через разные аплинки?
Такая ассиметрия гораздо коварнее (при диагностике проблем) чем свойственная для bgp ассиметрия входящего относительно исходящего трафика.
Такая ассиметрия гораздо коварнее (при диагностике проблем) чем свойственная для bgp ассиметрия входящего относительно исходящего трафика.
Во, интересная тема, тоже полная мифов.
На самом деле сегодня ECMP в большинстве реализаций работает иначе, чем вы описали. Балансировка происходит не для каждого пакета, а per-flow. Причем маршрутизатор не хранит состояния сессий: у пакета берутся некоторые параметры (включая src/dst IP и src/dst-порты транспортного протокола), с них вычисляется ключ (хэш), и этот ключ определяет некстхоп. В устройствах попроще типа помянутых l3-свичей делается примерно так next_hop_idx = hash_key mod number_of_next_hops. В устройствах посерьезнее используются функции посложнее, позволяющие, например, достичь балансировки в заданной пропорции. Кое-где также можно влиять на поля пакета, из которых считается хэш.
Соответственно пакеты в рамках одной сессии будут иметь одинаковый хэш, и уйдут одним маршрутом.
На самом деле сегодня ECMP в большинстве реализаций работает иначе, чем вы описали. Балансировка происходит не для каждого пакета, а per-flow. Причем маршрутизатор не хранит состояния сессий: у пакета берутся некоторые параметры (включая src/dst IP и src/dst-порты транспортного протокола), с них вычисляется ключ (хэш), и этот ключ определяет некстхоп. В устройствах попроще типа помянутых l3-свичей делается примерно так next_hop_idx = hash_key mod number_of_next_hops. В устройствах посерьезнее используются функции посложнее, позволяющие, например, достичь балансировки в заданной пропорции. Кое-где также можно влиять на поля пакета, из которых считается хэш.
Соответственно пакеты в рамках одной сессии будут иметь одинаковый хэш, и уйдут одним маршрутом.
Хорошо, элементарный вопрос на засыпку.
У меня 1 аплинку к оператору A, второй аплинк к Оператору B. Имеем далее сайт находящийся в автономной системе C который доступен как через А, так и через B.
Причем как это обычно бывает A и B находятся в одном городе, но имеют связь между собой через франкфурт.
Нарисуйте конфигурацию БЕЗ full-view которая защитит передачу трафика при любом из двух возможных обрывов ликов у C.
«Ассимитрия на пиринге» это зло которое создают вот именно такие «оптимизаторы» которые никогда не слышали слова comunity. Кстати, в вашей статье это слово упоминается всего один раз в неизвестном мне сочетании «BGP bandwidth community».
Так же вы утверждаете что L3 свичи и Роутеры отличаются поддержкой комьюнити. Это не правда, совсем не другим они отличаются :)
«в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны» Хочется спросить, вы за свою жизнь хоть раз бгб-мултихоминг настраивали?
Это утверждение полная чушь! 10 лет занимаюсь работой с BGP и могу совершнно уверено сказать что:
Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает. А потому что на другом конце всгда есть такой же упертый, который упорно пытается свой исходняк влить вам совсем не в ту дырку в которую хочется принять вам. Об чем я пытаюсь сигнализировать.
У меня 1 аплинку к оператору A, второй аплинк к Оператору B. Имеем далее сайт находящийся в автономной системе C который доступен как через А, так и через B.
Причем как это обычно бывает A и B находятся в одном городе, но имеют связь между собой через франкфурт.
Нарисуйте конфигурацию БЕЗ full-view которая защитит передачу трафика при любом из двух возможных обрывов ликов у C.
«Ассимитрия на пиринге» это зло которое создают вот именно такие «оптимизаторы» которые никогда не слышали слова comunity. Кстати, в вашей статье это слово упоминается всего один раз в неизвестном мне сочетании «BGP bandwidth community».
Так же вы утверждаете что L3 свичи и Роутеры отличаются поддержкой комьюнити. Это не правда, совсем не другим они отличаются :)
«в нормальной ситуации только один линк будет использоваться для передачи трафика в обе стороны» Хочется спросить, вы за свою жизнь хоть раз бгб-мултихоминг настраивали?
Это утверждение полная чушь! 10 лет занимаюсь работой с BGP и могу совершнно уверено сказать что:
Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает. А потому что на другом конце всгда есть такой же упертый, который упорно пытается свой исходняк влить вам совсем не в ту дырку в которую хочется принять вам. Об чем я пытаюсь сигнализировать.
1. Понимаете, вы смотрите на все это как бы глазами провайдера и исходите из предположения, что ситуация, когда неполная связность с интернетом у проавайдера при отсутствии знания об этом у клиента (за счет использования дефолта) — это случай, о котором клиенту стоит печься.
ОК, может быть и стоит, я же написал, что мы теряем информацию о ричабилити конкретных префиксов. И да, это в определенной степени компроммис, имеющий оборотную сторону. Но только важно отдавать себе отчет, с чем, собственно мы собираемся бороться при помощи фулвью, если уж мы так ее хотим. Большинство не отдает.
Кроме того, все это все равно полная ерунда. Потому что если предполагаеть, что провайдер дурак, то никакя фулвью вас не спасет. Потому что потеря связности с миром у провайдера — это ситуация в миллион раз менее вероятная, чем какая-нибудь другая жопа, от котороый вы не защититесь. Нет никакой гарантии, что посылая трафик провайдеру, опираясь при этом на специфик-префиксы из фулвью, провайдер его не закольцеут или не заблекхолит. А еще в сто раз более вероятно, что у провайдера возникнет перегрузка какого-нибудь внешнего линка, и BGP об этом даже не узнает.
Поэтому-то я и говорю. Если вы, будучи корпоративной сетью, хотите сами стать чуть-чуть провайдером, то никто не может вам этого запретить. Но только все же надо отдавать себе отчет, что одним только принятием фулвью вы практически ничего не выиграете. А проиграете — почти наверняка. А дальше принимайте решение сами. На мой взгляд правильный выбор провайдера тут в сто раз важнее всех фулвью.
2. Про комьюнити и отличие роутеров от L3-сивичей — простите, вы мне приписываете слова, которых я не говорил. Я говорил, что возможность неравномерной балансировки посредством bandwindth community — это эдвансная фича, которую L3-свичи не умеют. Комьюнити и bandwidth-комьюнити — это не одно и то же. Наберите в гугле Bandwidth community.
3. Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает.
LOL. Простите. Автоциатата:
Маршрутная информация всегда передается навстречу трафику, который коммутируется на ее основе. То есть на базе фулвью передается исходящий из вашей АС трафик. Не смотря на всю очевидность этого тезиса, далеко не всегда практическое его значение осознается в полной мере.
Фулвью на нашей стороне не имеет НИКАКОГО отношения к входящему трафику. Вообще.
Что до входящего трафика — вы не правы. Большинство нормальных провайдеров поддерживают комьюнити, позволяющие поставить низкий LP на наши анонсы, чтобы использовать линк как бекап. Плюс к этому есть еще длина префиксов. Но я не хочу об этом даже начинать разговор. Он принципиально про другое и не имеет никакого отношения к данной статье. Кроме того на эту тему полно литературы.
ОК, может быть и стоит, я же написал, что мы теряем информацию о ричабилити конкретных префиксов. И да, это в определенной степени компроммис, имеющий оборотную сторону. Но только важно отдавать себе отчет, с чем, собственно мы собираемся бороться при помощи фулвью, если уж мы так ее хотим. Большинство не отдает.
Кроме того, все это все равно полная ерунда. Потому что если предполагаеть, что провайдер дурак, то никакя фулвью вас не спасет. Потому что потеря связности с миром у провайдера — это ситуация в миллион раз менее вероятная, чем какая-нибудь другая жопа, от котороый вы не защититесь. Нет никакой гарантии, что посылая трафик провайдеру, опираясь при этом на специфик-префиксы из фулвью, провайдер его не закольцеут или не заблекхолит. А еще в сто раз более вероятно, что у провайдера возникнет перегрузка какого-нибудь внешнего линка, и BGP об этом даже не узнает.
Поэтому-то я и говорю. Если вы, будучи корпоративной сетью, хотите сами стать чуть-чуть провайдером, то никто не может вам этого запретить. Но только все же надо отдавать себе отчет, что одним только принятием фулвью вы практически ничего не выиграете. А проиграете — почти наверняка. А дальше принимайте решение сами. На мой взгляд правильный выбор провайдера тут в сто раз важнее всех фулвью.
2. Про комьюнити и отличие роутеров от L3-сивичей — простите, вы мне приписываете слова, которых я не говорил. Я говорил, что возможность неравномерной балансировки посредством bandwindth community — это эдвансная фича, которую L3-свичи не умеют. Комьюнити и bandwidth-комьюнити — это не одно и то же. Наберите в гугле Bandwidth community.
3. Как только поднимаешь BGP, то трафик начинает литься с двух проводов. Даже если вы давите всеми способом входящий трафик он все равно прилезает.
LOL. Простите. Автоциатата:
Маршрутная информация всегда передается навстречу трафику, который коммутируется на ее основе. То есть на базе фулвью передается исходящий из вашей АС трафик. Не смотря на всю очевидность этого тезиса, далеко не всегда практическое его значение осознается в полной мере.
Фулвью на нашей стороне не имеет НИКАКОГО отношения к входящему трафику. Вообще.
Что до входящего трафика — вы не правы. Большинство нормальных провайдеров поддерживают комьюнити, позволяющие поставить низкий LP на наши анонсы, чтобы использовать линк как бекап. Плюс к этому есть еще длина префиксов. Но я не хочу об этом даже начинать разговор. Он принципиально про другое и не имеет никакого отношения к данной статье. Кроме того на эту тему полно литературы.
В вопросе наличия информации в полной таблице и ее потери при исключении фул-вью мы кажется сошлись.
В вопросе того, что в 99% случаях фул вью рядовому пользователю ничего не дает я тоже соглашусь.
А вот в вопросе нужно ли устранять оставшиеся 1% проблем у нас отношение разное.
Я, с точки зрения провайдера считаю что нужно. Потратил время и деньги на AC-ку и свой блок адресов — используй. Если не хочешь, то должен осознавать то отказ от принятия решения на базу full-view ухудшит надежность в решении… тех самых 1% сбоев.
В вопросе того, что в 99% случаях фул вью рядовому пользователю ничего не дает я тоже соглашусь.
А вот в вопросе нужно ли устранять оставшиеся 1% проблем у нас отношение разное.
Я, с точки зрения провайдера считаю что нужно. Потратил время и деньги на AC-ку и свой блок адресов — используй. Если не хочешь, то должен осознавать то отказ от принятия решения на базу full-view ухудшит надежность в решении… тех самых 1% сбоев.
> что мы теряем информацию о ричабилити конкретных префиксов
вот вчера ломался ростелеком, гора из трех сотен с лишним тысяч префикс фулла была на месте, а трафик не ходил. вот вам и ричабилити конкретных префиксов. так что наличие конкретных префиксов еще не гарантия ричабилити.
вот вчера ломался ростелеком, гора из трех сотен с лишним тысяч префикс фулла была на месте, а трафик не ходил. вот вам и ричабилити конкретных префиксов. так что наличие конкретных префиксов еще не гарантия ричабилити.
За статью аплодирую стоя.
Вот только есть вопрос — просветите чайника, чем плохи два дефолтных маршрута с разными метриками, ежели у меня допустим два алпинка, которыми командует программный роутер?
Вот только есть вопрос — просветите чайника, чем плохи два дефолтных маршрута с разными метриками, ежели у меня допустим два алпинка, которыми командует программный роутер?
Два каких маршрута? Статических? — тем, что если один из провайдеров сломается, вы об этом даже не узнаете.
Или два дефолта, полученных от провайдеров по BGP с разными, скажем, LP (это не совсем метрика, но почти как)? Да ничем они не плохи, всем хороши. Ну некоторым очень хочется балансировать исходящий трафик. Зачем-то. Ну, бывает, и правда надо. Тогда метрики (LP в данном случае) и все остальные параметры качества BGP-маршрутов должны быть одинаковые, плюс еще включено пара доп. опций, и тогда оба некстхопа для данного отправятся в FIB.
Или два дефолта, полученных от провайдеров по BGP с разными, скажем, LP (это не совсем метрика, но почти как)? Да ничем они не плохи, всем хороши. Ну некоторым очень хочется балансировать исходящий трафик. Зачем-то. Ну, бывает, и правда надо. Тогда метрики (LP в данном случае) и все остальные параметры качества BGP-маршрутов должны быть одинаковые, плюс еще включено пара доп. опций, и тогда оба некстхопа для данного отправятся в FIB.
О… похоже на годную статью.:-)
Куда катится хабр.…
Забадай его бумбурум.
Куда катится хабр.…
Забадай его бумбурум.
Ох я помню отговаривал один маленький корпоратив от идеи на Cisco 28xx принимать себе 2 FV, при том что основным аргументом у админа было а-ля «Ну это же круто! Нам нужны все префиксы!»… Эту бы статью да ему под нос.
Обязательно в избранное. Буду читать до просветления время от времени. Много еще мне непонятного, но крайне интересное чтиво.
Сначала я подумал, что статья будет интересной, но в итоге она могла бы уместиться в четырех выводах. Хотя, возможно, для человека со стороны такое изложение будет более приемлемым, чем для более квалифицированного.
НЛО прилетело и опубликовало эту надпись здесь
Отлично. Я обожаю такие статьи по одной причине: я их читаю. До какой-нибудь книжки или оф. документации у меня бы ещё очень не скоро дошло дело.
Спасибо большое. Очень ценная информация, которая подана понятным и, надо признать, интересным языком.
Хотелось бы ещё статью о балансировке входящего трафика (и т.д.)
Спасибо большое. Очень ценная информация, которая подана понятным и, надо признать, интересным языком.
Хотелось бы ещё статью о балансировке входящего трафика (и т.д.)
Очень замечательная статья. Я абсолютный новичок в динамической маршрутизации, знаю лишь азы и понял 80% статьи(думаю со временем надо будет перечитать чтобы понять всю статью).
PS: Аффтар жжошь, пеши исчо )
PS: Аффтар жжошь, пеши исчо )
Спасибо за статью!
А можно подробнее про
> «Имея же два дефолта без фулвью и правильный маршрутизатор, можно и вовсе явно указать пропорцию: в канал поуже слать 30%, в канал пошире — 70»?
Или ткнитеносом ссылкой где почитать? Спасибо!
А можно подробнее про
> «Имея же два дефолта без фулвью и правильный маршрутизатор, можно и вовсе явно указать пропорцию: в канал поуже слать 30%, в канал пошире — 70»?
Или ткните
Ой, случайно не там ответил.
В общем случае вот:
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
В общем случае вот:
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
В общем случае вот:
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
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
Большое спасибо за статью. Доходчиво, грамотно и без воды.
одного не могу понять
зачем спецы potaroo.net рисуют такие графики (многолинейные, многоцветовые, с шумом и без легенды)
когда в своих же документах используют вполне внятные картинки?
зачем спецы potaroo.net рисуют такие графики (многолинейные, многоцветовые, с шумом и без легенды)
когда в своих же документах используют вполне внятные картинки?
Я думаю, это традиция. Этот график уже стал эпосом. Его перепечатывают в книжках и т. д. Разные цвета тут — разные маршрутизаторы, что вполне логично показать.
Кроме того, potaroo.net — это не «спецы», а совершенно конкретный Geoff Huston. Судя по общему всему (включая и приведенную вами картинку, тоже не белстящую), дизайн, представление данных, типографика — это все не его конек :)
Кроме того, potaroo.net — это не «спецы», а совершенно конкретный Geoff Huston. Судя по общему всему (включая и приведенную вами картинку, тоже не белстящую), дизайн, представление данных, типографика — это все не его конек :)
Ну, можно пользоваться данными от Team Cymru: www.cymru.com/BGP/bgp_prefixes.html
> Дальше либо используем только один из маршрутов, а второй держим про запас (на случай, если первый отвалится) и пускаем весь исходящий трафик по одному линку, либо настраиваем балансировку нагрузки
> Некоторый (в общем, единственный) минус такого подхода — это то, что вместе с «гранулярным» роутингом мы отказались
возможно я что-то пропустил в статье, но ведь есть и «компромис» между крайностями «фуллвью» и «дефолт-оригинейт». можно ведь договориться с провайдером о передачи вам его «партиал-меш» + «дефолт». в первое войдут все префиксы от кастомеров провайдера, его собственные префиксы и префиксы с исков к которым он подключен. имея два, три, стодвацдатьтри линка с такими условиями мы вполне можем отправить исходящий трафик по «лучшему» маршруту, как и принять входящий трафик, даже скорее всего большая часть трафика будет ходить симметрично, что тоже весьма позитивная деталь. размер партиал-меша где-то до 20 тысяч префиксов => даже в древний каталист 3550 оно влезет :) другое дело что в rib наверно несколько линков не влезет, ну я думаю можно найти свич где риб жирненький. :) у фаундри/брокад вообще в л3 свищи несколько фв помещаются. :)
ну а вообще да, крутая статья, столько откровений для забра еще ни в одной статье мне кажется не было. мне бы такую пару-тройку лет назад. хотя, статья, конечно, не избавляет от необходимости читать хелеби и иже с ним. :)
> Некоторый (в общем, единственный) минус такого подхода — это то, что вместе с «гранулярным» роутингом мы отказались
возможно я что-то пропустил в статье, но ведь есть и «компромис» между крайностями «фуллвью» и «дефолт-оригинейт». можно ведь договориться с провайдером о передачи вам его «партиал-меш» + «дефолт». в первое войдут все префиксы от кастомеров провайдера, его собственные префиксы и префиксы с исков к которым он подключен. имея два, три, стодвацдатьтри линка с такими условиями мы вполне можем отправить исходящий трафик по «лучшему» маршруту, как и принять входящий трафик, даже скорее всего большая часть трафика будет ходить симметрично, что тоже весьма позитивная деталь. размер партиал-меша где-то до 20 тысяч префиксов => даже в древний каталист 3550 оно влезет :) другое дело что в rib наверно несколько линков не влезет, ну я думаю можно найти свич где риб жирненький. :) у фаундри/брокад вообще в л3 свищи несколько фв помещаются. :)
ну а вообще да, крутая статья, столько откровений для забра еще ни в одной статье мне кажется не было. мне бы такую пару-тройку лет назад. хотя, статья, конечно, не избавляет от необходимости читать хелеби и иже с ним. :)
Про частичный меш и вообще более эдвансные компромиссы — согласен. Просто статья все-таки чуть другого уровня. Плюс с провайдерами договариваться — это целая наука :) Хотя кое у кого даже комьюнити стоят, так что можно и не договариваться, а матчить эти комьюнити плюс as-path. А те, которые готовы, в моих советах не нуждаются. Большинство же компаний со своими автономками — это upto десятки мегабит исходящего трафика. Ну пошлют они мегабит-другой в сторону клиент провайдера Б через провайдера А. На деле они либо пирятся на IX, либо один другому аплинк. Ужас-ужас-ужас :)
На мой вкус, что действительно важно энтерпрайзу — это принять префиксы всяких своих удаленных IPSec-пиров и прочего такого добра. Но в реальности не многие готовы даже этим парится.
У брокейда — вы про риб или про фиб? Про риб — это не большая редкость. У джунипера в EX3200/4200 можно пару ФВ впихнуть (наверняка и больше, но я не пробовал), просто слово заветное надо знать. А вот в фиб — это у брокейда только CER, который в общем-то роутер.
На мой вкус, что действительно важно энтерпрайзу — это принять префиксы всяких своих удаленных IPSec-пиров и прочего такого добра. Но в реальности не многие готовы даже этим парится.
У брокейда — вы про риб или про фиб? Про риб — это не большая редкость. У джунипера в EX3200/4200 можно пару ФВ впихнуть (наверняка и больше, но я не пробовал), просто слово заветное надо знать. А вот в фиб — это у брокейда только CER, который в общем-то роутер.
Кстати, тут еще вот какой момент такой, о котором я совершенно забыл сказать (хотя наверное и так многовато текста), что если энтерпрайзная АС физически мультихомная (то есть разные аплинки приходят в территориально разные офисы), то связность внутри АС скорее всего совершенно смехотворная: арендованый L2-канал без резервированя, без ничего. Хорошо еще если у приличного оператора. При этом нагруженый внутренним трафиком. В такой ситуации лучше бы бордер не валял дурака, а слал все в интернет, даже если если это трафик в АС аплинка другого офиса.
> У брокейда — вы про риб или про фиб? Про риб — это не большая редкость. У джунипера в EX3200/4200 можно пару ФВ впихнуть (наверняка и больше, но я не пробовал), просто слово заветное надо знать. А вот в фиб — это у брокейда только CER, который в общем-то роутер.
про риб, ага, я и не говорил что редкость, ага, просто выбрать где пожирней :) я CER не щупал, но судя по презе он от CES отличается разжиревшим fib/rib'ом и вложеными в коробку лицухами про бгп, что превращает его в просто л3 свищ с жирным фибом и поддержкой бгп. хотя, может этого и достаточно чтобы называться маршрутизатором, смотря что хотеть от маршрутизатора. :)
> Ну пошлют они мегабит-другой в сторону клиент провайдера Б через провайдера А. На деле они либо пирятся на IX, либо один другому аплинк. Ужас-ужас-ужас :)
да, есть такое. /* bursts in tears */
/* offtopic
а подскажите какую дельную литературу по освоению netscreen'ов, те что на screenos, почитать, а то когда открываю дефолтовый конфиг и пытаюсь читать, начинает болеть голова…
offtopic */
про риб, ага, я и не говорил что редкость, ага, просто выбрать где пожирней :) я CER не щупал, но судя по презе он от CES отличается разжиревшим fib/rib'ом и вложеными в коробку лицухами про бгп, что превращает его в просто л3 свищ с жирным фибом и поддержкой бгп. хотя, может этого и достаточно чтобы называться маршрутизатором, смотря что хотеть от маршрутизатора. :)
> Ну пошлют они мегабит-другой в сторону клиент провайдера Б через провайдера А. На деле они либо пирятся на IX, либо один другому аплинк. Ужас-ужас-ужас :)
да, есть такое. /* bursts in tears */
/* offtopic
а подскажите какую дельную литературу по освоению netscreen'ов, те что на screenos, почитать, а то когда открываю дефолтовый конфиг и пытаюсь читать, начинает болеть голова…
offtopic */
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, написанная энтузиастом-одиночкой. Она старовата и кишит опечатками, но все равно довольно крута.
По 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, написанная энтузиастом-одиночкой. Она старовата и кишит опечатками, но все равно довольно крута.
P. S. То, что в моем понимании дает CER право называться маршрутизатором — это таки да FIB 512k IPV4, но в совокупности с MPLS более-менее похожим на MPLS.
При наличии нескольких ISP и при использовании только Default Route, в случае, если произойдёт отказ одного из ISP и при этом пириниг между вашим роутером и провайдером сохраняется, то Вы получите блэкхоул, Т.е. ISP не функционирует, а вы на него продолжаете слать трафик через default route. Тут придётся тогда либо IP SLa задействовать, либо просить провайдеров, чтобы они кроме default route передавали какие-нибудь внешние сети, по исчезновению которых запускать скрипты и прочее. Тогда зачем вообще BGP нужен, не понятно, можно вполне обойтись чем-то вроде Dynamic DNS и при падении ISP менять IP-адреса внешних ресурсов. На практике вполне легко добиться 5-минутного переключения, что сопоставимо с временем конвергенции BGP.
Если вспомнить, что роутинг и ричабилти — не одно и тоже, то будет чуть понятнее. Да, отказ от кастом-префиксов — это определенная плата. И вся речь лишь о том, в чем эта плата состоит и за что она.
Если вы не держите полной таблицы — вы не знаете, ходит ли префикс от назначения 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 и т. д. — там да, там полные таблицы во все стороны нужны.
Если вы не держите полной таблицы — вы не знаете, ходит ли префикс от назначения 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 и т. д. — там да, там полные таблицы во все стороны нужны.
Упс. Сорвалось.
> Это не то же самое, что уверенность в том, что если вы (при наличии префикса)
Это не то же самое, что уверенность в том, что если вы (при наличии префикса A) пошлете трафик назначению A, то он до него дойдет.
> Это не то же самое, что уверенность в том, что если вы (при наличии префикса)
Это не то же самое, что уверенность в том, что если вы (при наличии префикса A) пошлете трафик назначению A, то он до него дойдет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы