d-e-n-i-s Опубликовано 10 ноября, 2011 · Жалоба Такая проблема, от основного аплинка получаю full view, решили сделать резерв, договорились с местным оператором что даст резерв, но он может отдать только default и le 19. 1. подскажите вариант резервирования, в случае падения основного аплинка. 2. вариант балансировки. Используем quagga. P.S. Сильно не пинайте, настройке BGP только учусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 10 ноября, 2011 · Жалоба Такая проблема, от основного аплинка получаю full view, решили сделать резерв, договорились с местным оператором что даст резерв, но он может отдать только default и le 19. 1. подскажите вариант резервирования, в случае падения основного аплинка. 2. вариант балансировки. Используем quagga. P.S. Сильно не пинайте, настройке BGP только учусь. По резервированию - ставьте разный localpref на маршруты от основного и резервного аплинков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 10 ноября, 2011 · Жалоба на одну железку приходит два аплинка ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d-e-n-i-s Опубликовано 10 ноября, 2011 · Жалоба По резервированию - ставьте разный localpref на маршруты от основного и резервного аплинков. Дык, полной карты то нету ! ?! на одну железку приходит два аплинка ? Да, сервер на базе linux Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 10 ноября, 2011 · Жалоба По резервированию - ставьте разный localpref на маршруты от основного и резервного аплинков. Дык, полной карты то нету ! ?! на одну железку приходит два аплинка ? Да, сервер на базе linux А какая разница, есть полная карта или нет? Если вам резервирование, то принимаете от основного FV и от резервного /19 и default, но ставите разный localpref на маршруты от основного и резервного. При падении канала основного, в RIB попадут маршруты от резервного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 10 ноября, 2011 · Жалоба если у вас одна железка то вам в помощь атрибут weight + route-map для балансировки исходящего от вас трафика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 10 ноября, 2011 · Жалоба Согласен с двумя предыдущими ораторами. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 10 ноября, 2011 · Жалоба Для входящего к вам трафика используйте препенды, либо договоритесь, чтобы резервный оператор ставил их на вас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 10 ноября, 2011 · Жалоба Для входящего к вам трафика используйте препенды, либо договоритесь, чтобы резервный оператор ставил их на вас. лучше делайте MED или те же AS-PATH prepend, чем каждый раз договариваться с провайдером когда вам что то надо будет изменить, просто скажите что будете использовать MED что бы он не ставил вам weigth и local-pref. или Делайте AS-PATH-Prepend. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d-e-n-i-s Опубликовано 10 ноября, 2011 · Жалоба Для входящего к вам трафика используйте препенды, либо договоритесь, чтобы резервный оператор ставил их на вас. лучше делайте MED или те же AS-PATH prepend, чем каждый раз договариваться с провайдером когда вам что то надо будет изменить, просто скажите что будете использовать MED что бы он не ставил вам weigth и local-pref. или Делайте AS-PATH-Prepend. А будет работать local-pref и prepend на default ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 10 ноября, 2011 · Жалоба Для входящего к вам трафика используйте препенды, либо договоритесь, чтобы резервный оператор ставил их на вас. лучше делайте 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" Сэм Халаби. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 10 ноября, 2011 (изменено) · Жалоба На сколько я вас понял у вас еще будут префиксы /19 и их будет много , тем более у вас одна железка вам не нужен local pref. Делайте weight . Если же у вас только default будет то смысла нет никакого вообще замарачиваться балансировкой исходящего трафика. Хотя можно сделать балансировку и на default. А что касается as prepend то коллега прав это для inbound traffic. Weight и local pref = outbound traffic Med и prepend = inbound traffic Изменено 10 ноября, 2011 пользователем config Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 10 ноября, 2011 · Жалоба Да возможно там и разные ас я почемуто посчитал что одна и тазе. Ну раз разные тогда конечно только as path prepend. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 10 ноября, 2011 · Жалоба Окажу платные услуги по балансировке трафика как на вход, так и на исход :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 10 ноября, 2011 · Жалоба Окажу платные услуги по балансировке трафика как на вход, так и на исход :) Буду твоим консультантом за отдельную плату :-)))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 10 ноября, 2011 · Жалоба Окажу платные услуги по балансировке трафика как на вход, так и на исход :) Буду твоим консультантом за отдельную плату :-)))) Договорились. Если что-то не осилю, переброшу тебе :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d-e-n-i-s Опубликовано 13 ноября, 2011 · Жалоба Знатоки ошибаются... И так: Апстрим 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 не помогают) Заранее спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 13 ноября, 2011 (изменено) · Жалоба Знатоки ошибаются... И так: Апстрим 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. Зафильтруйте их приём на А. Изменено 13 ноября, 2011 пользователем vurd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d-e-n-i-s Опубликовано 13 ноября, 2011 · Жалоба Падает ровно на 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 отвалится, резерв будет не полноценный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 13 ноября, 2011 (изменено) · Жалоба Тогда придется в А добавлять default route, иначе если B отвалится, резерв будет не полноценный. обязательно, только loc-pref пониже поставьте для этого дефолта. Изменено 13 ноября, 2011 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 14 ноября, 2011 · Жалоба А зачем Вам В наливает /19, а А фулвью? В данном случае абсолютно достаточно получить от обоих аплинков дефолт и разрулить их weight-ами, а для разруливания даунлоада выставить препенды. На счет задержки при обрыве сессии - есть команда сброса всех префиксов при срыве сессии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d-e-n-i-s Опубликовано 14 ноября, 2011 · Жалоба А зачем Вам В наливает /19, а А фулвью? В данном случае абсолютно достаточно получить от обоих аплинков дефолт и разрулить их weight-ами, а для разруливания даунлоада выставить препенды. На счет задержки при обрыве сессии - есть команда сброса всех префиксов при срыве сессии. Есть в это правда, но если захочется чуток раскидать трафик по аплинкам, тогда с default проблем больше. А если сессия не порвется, т.е. последняя миля до аплинка жива, и сам аплинк жив, но у него проблемы на канале ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 15 ноября, 2011 · Жалоба Есть в это правда, но если захочется чуток раскидать трафик по аплинкам, тогда с default проблем больше. Неа. Проблемно будет только раскидывать свой аплоад - придется творить PBR. А балансировка даунлоада не составит проблем, если оба аплинка Вам дадут коммунити. А если сессия не порвется, т.е. последняя миля до аплинка жива, и сам аплинк жив, но у него проблемы на канале ? В этом случае Вам фиолетово - дает аплинк дефолт онлы или наливает фул-вью. Западло случится в обоих случаях. Этим, кстати, славится РЕТН - ну и что, что трафик от Москвы до Воронежа поехал через Стокгольм и Франкфурт с пингами по 600мс, резервирование ведь сработало ;) ? Такие вещи придется отслеживать ручками/скриптами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
joesm Опубликовано 15 ноября, 2011 · Жалоба Для балансировки исходящего трафика PBR не нужен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...