Настройка BGP

[d-e-n-i-s]

Такая проблема, от основного аплинка получаю full view, решили сделать резерв, договорились с местным оператором что даст резерв, но он может отдать только default и le 19.

1. подскажите вариант резервирования, в случае падения основного аплинка.

2. вариант балансировки.

 

Используем quagga.

 

P.S. Сильно не пинайте, настройке BGP только учусь.

[StSphinx]

Такая проблема, от основного аплинка получаю full view, решили сделать резерв, договорились с местным оператором что даст резерв, но он может отдать только default и le 19.

1. подскажите вариант резервирования, в случае падения основного аплинка.

2. вариант балансировки.

 

Используем quagga.

 

P.S. Сильно не пинайте, настройке BGP только учусь.

 

По резервированию - ставьте разный localpref на маршруты от основного и резервного аплинков.

[config]

на одну железку приходит два аплинка ?

[d-e-n-i-s]

По резервированию - ставьте разный localpref на маршруты от основного и резервного аплинков.

Дык, полной карты то нету !

?!

 

на одну железку приходит два аплинка ?

Да, сервер на базе linux

[StSphinx]

По резервированию - ставьте разный localpref на маршруты от основного и резервного аплинков.

Дык, полной карты то нету !

?!

 

на одну железку приходит два аплинка ?

Да, сервер на базе linux

 

 

А какая разница, есть полная карта или нет? Если вам резервирование, то принимаете от основного FV и от резервного /19 и default, но ставите разный localpref на маршруты от основного и резервного. При падении канала основного, в RIB попадут маршруты от резервного.

[config]

если у вас одна железка то вам в помощь атрибут weight + route-map для балансировки исходящего от вас трафика.

[vlad11]

Согласен с двумя предыдущими ораторами. :)

[John_obn]

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

[config]

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

лучше делайте MED или те же AS-PATH prepend, чем каждый раз договариваться с провайдером когда вам что то надо будет изменить, просто скажите что будете использовать MED что бы он не ставил вам weigth и local-pref. или Делайте AS-PATH-Prepend.

[d-e-n-i-s]

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

лучше делайте MED или те же AS-PATH prepend, чем каждый раз договариваться с провайдером когда вам что то надо будет изменить, просто скажите что будете использовать MED что бы он не ставил вам weigth и local-pref. или Делайте AS-PATH-Prepend.

 

А будет работать local-pref и prepend на default ?

[StSphinx]

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

лучше делайте MED или те же AS-PATH prepend, чем каждый раз договариваться с провайдером когда вам что то надо будет изменить, просто скажите что будете использовать MED что бы он не ставил вам weigth и local-pref. или Делайте AS-PATH-Prepend.

 

Насчет MED'a, коллега, Вы сдается ошибаетесь. Он используется только в случае , когда имеется несколько точек входа из локальной в соседнюю AS, в случае eBGP.

А в данном случае, как я понимаю, соседние AS разные.

 

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

лучше делайте MED или те же AS-PATH prepend, чем каждый раз договариваться с провайдером когда вам что то надо будет изменить, просто скажите что будете использовать MED что бы он не ставил вам weigth и local-pref. или Делайте AS-PATH-Prepend.

 

А будет работать local-pref и prepend на default ?

 

А при чем тут default? Препенды вы ставите на свои префиксы, анонсируемые в мир.

Вы бы все таки почитали про BGP. Есть замечательная книжка - "Internet routing architectures" Сэм Халаби.

[config]

На сколько я вас понял у вас еще будут префиксы /19 и их будет много , тем более у вас одна железка вам не нужен local pref. Делайте weight . Если же у вас только default будет то смысла нет никакого вообще замарачиваться балансировкой исходящего трафика. Хотя можно сделать балансировку и на default. А что касается as prepend то коллега прав это для inbound traffic.

Weight и local pref = outbound traffic

Med и prepend = inbound traffic

Edited November 10, 2011 by config

[config]

Да возможно там и разные ас я почемуто посчитал что одна и тазе. Ну раз разные тогда конечно только as path prepend.

[vlad11]

Окажу платные услуги по балансировке трафика как на вход, так и на исход :)

[config]

Окажу платные услуги по балансировке трафика как на вход, так и на исход :)

Буду твоим консультантом за отдельную плату :-))))

[vlad11]

Окажу платные услуги по балансировке трафика как на вход, так и на исход :)

Буду твоим консультантом за отдельную плату :-))))

Договорились. Если что-то не осилю, переброшу тебе :)

[d-e-n-i-s]

Знатоки ошибаются...

И так:

Апстрим A: получаем fullv view

Апстрим B: получаем le 19 + default

 

Пытаемся настроить резерв:

A основной, B резерв

на исход на A: local pref 200

на исход на B: local pref 100

на вход на B: prepend 1234 1234 1234 1234

 

Результат: все работает через A, когда A падает, переключение на только через 5 минут, т.е. пока не отвалится BGP сессия A.

Вопрос: если у апрстима А проблемы не с последней милей, а с его каналами, и сессия так и не отвалится, соответственно резерв так и не включится.

Как уменьшить время переключения на резерв.

 

 

Тест номер 2:

B основной, A резерв

на исход на A: local pref 100

на исход на B: local pref 200

на вход на A: prepend 1234 1234 1234 1234

 

С входящим все ОК

А вот с исходящим начинаются сюрпризы: (напоминаю что от B получаю le 19 и default

там где есть два маршрута выбирает с наибольшим local pref т.е. идет через B

а вот там где один маршрут (ну подсети больше 19), идет через A, хотя у B маршрут default 0.0.0.0 с префиксом 200.

т.е. default игнорируется в данном случае.

Соответственно тестирование на отказ апстрима В не проводилось.

 

Вопрос: как заставить идет через default а не через full view (local-pref и weight не помогают)

 

Заранее спасибо.

[vurd]

Знатоки ошибаются...

И так:

Апстрим A: получаем fullv view

Апстрим B: получаем le 19 + default

 

Пытаемся настроить резерв:

A основной, B резерв

на исход на A: local pref 200

на исход на B: local pref 100

на вход на B: prepend 1234 1234 1234 1234

 

Результат: все работает через A, когда A падает, переключение на только через 5 минут, т.е. пока не отвалится BGP сессия A.

Вопрос: если у апрстима А проблемы не с последней милей, а с его каналами, и сессия так и не отвалится, соответственно резерв так и не включится.

Как уменьшить время переключения на резерв.

 

Если совсем падает, сократить время поможет "timers bgp keepalive holdtime"

 

BGP uses certain timers to control periodic activities such as the sending of keepalive messages and the interval after not receiving a keepalive message after which the Cisco IOS software declares a peer dead. By default, the keepalive timer is 60 seconds, and the hold-time timer is 180 seconds.You can adjust these timers. When a connection is started, BGP will negotiate the hold time with the neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on the negotiated hold time and the configured keepalive time.

 

Если один из апстримов потеряет кого-то у себя, то у вас исчезнет этот маршрут и трафик пойдет через B.

 

 

Тест номер 2:

B основной, A резерв

на исход на A: local pref 100

на исход на B: local pref 200

на вход на A: prepend 1234 1234 1234 1234

 

С входящим все ОК

А вот с исходящим начинаются сюрпризы: (напоминаю что от B получаю le 19 и default

там где есть два маршрута выбирает с наибольшим local pref т.е. идет через B

а вот там где один маршрут (ну подсети больше 19), идет через A, хотя у B маршрут default 0.0.0.0 с префиксом 200.

т.е. default игнорируется в данном случае.

Соответственно тестирование на отказ апстрима В не проводилось.

 

Вопрос: как заставить идет через default а не через full view (local-pref и weight не помогают)

 

Заранее спасибо.

 

Конечно, потому как префиксы меньше /19 являются more specific и маршрутизация происходит по принципу CIDR.

Зафильтруйте их приём на А.

Edited November 13, 2011 by vurd

[d-e-n-i-s]

Падает ровно на 5 минут.

Если поставить holdtime равный 60 секундам, не каких проблем не будет ?

 

 

 

Тест номер 2:

B основной, A резерв

на исход на A: local pref 100

на исход на B: local pref 200

на вход на A: prepend 1234 1234 1234 1234

 

С входящим все ОК

А вот с исходящим начинаются сюрпризы: (напоминаю что от B получаю le 19 и default

там где есть два маршрута выбирает с наибольшим local pref т.е. идет через B

а вот там где один маршрут (ну подсети больше 19), идет через A, хотя у B маршрут default 0.0.0.0 с префиксом 200.

т.е. default игнорируется в данном случае.

Соответственно тестирование на отказ апстрима В не проводилось.

 

Вопрос: как заставить идет через default а не через full view (local-pref и weight не помогают)

 

Заранее спасибо.

 

Конечно, потому как префиксы меньше /19 являются more specific и маршрутизация происходит по принципу CIDR.

Зафильтруйте их приём на А.

Тогда придется в А добавлять default route, иначе если B отвалится, резерв будет не полноценный.

[vlad11]

 

Тогда придется в А добавлять default route, иначе если B отвалится, резерв будет не полноценный.

 

обязательно, только loc-pref пониже поставьте для этого дефолта.

Edited November 13, 2011 by vlad11

[Alexandr Ovcharenko]

А зачем Вам В наливает /19, а А фулвью? В данном случае абсолютно достаточно получить от обоих аплинков дефолт и разрулить их weight-ами, а для разруливания даунлоада выставить препенды. На счет задержки при обрыве сессии - есть команда сброса всех префиксов при срыве сессии.

[d-e-n-i-s]

А зачем Вам В наливает /19, а А фулвью? В данном случае абсолютно достаточно получить от обоих аплинков дефолт и разрулить их weight-ами, а для разруливания даунлоада выставить препенды. На счет задержки при обрыве сессии - есть команда сброса всех префиксов при срыве сессии.

Есть в это правда, но если захочется чуток раскидать трафик по аплинкам, тогда с default проблем больше.

А если сессия не порвется, т.е. последняя миля до аплинка жива, и сам аплинк жив, но у него проблемы на канале ?

[Alexandr Ovcharenko]

Есть в это правда, но если захочется чуток раскидать трафик по аплинкам, тогда с default проблем больше.

Неа. Проблемно будет только раскидывать свой аплоад - придется творить PBR. А балансировка даунлоада не составит проблем, если оба аплинка Вам дадут коммунити.

 

А если сессия не порвется, т.е. последняя миля до аплинка жива, и сам аплинк жив, но у него проблемы на канале ?

В этом случае Вам фиолетово - дает аплинк дефолт онлы или наливает фул-вью. Западло случится в обоих случаях. Этим, кстати, славится РЕТН - ну и что, что трафик от Москвы до Воронежа поехал через Стокгольм и Франкфурт с пингами по 600мс, резервирование ведь сработало ;) ? Такие вещи придется отслеживать ручками/скриптами.

[joesm]

Для балансировки исходящего трафика PBR не нужен.