Перейти к содержимому
Калькуляторы

Настройка BGP основной full view + резерв default

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

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

?!

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

?!

 

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

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

лучше делайте 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" Сэм Халаби.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Weight и local pref = outbound traffic

Med и prepend = inbound traffic

Изменено пользователем config

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

И так:

Апстрим 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 не помогают)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

И так:

Апстрим 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.

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

Изменено пользователем vurd

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Падает ровно на 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 отвалится, резерв будет не полноценный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

Изменено пользователем vlad11

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.