1 AS и 2 бордера

[spd2]

Привет уважаемым гуру маршрутизации! С прошедшими и наступающими праздниками!
Возникла у нас необходимость сделать второй бордер в нашей AS (в целях резервирования, снижения нагрузки и т.д.). Планируем сделать на freebsd + quagga. Существующий бордер держит 2 full-view от двух аплинков. Хотим оставить 1 аплинк на нем, а второй перенести на новый бордер. Вопрос вот в чем... вроде как при такой схеме нет особого смысла вязать бордеры с помощью IBGP? достаточно прописать дефолты друг на друга? Исходящий-то всё равно пойдет сразу через EBGP-соединение... Или тут есть подводные камни? Хотелось бы добиться полной взаимозаменяемости бордеров, падает один (тьфу-тьфу...)- работает другой

[root]

привет, тя так же с прошедшими

хм.. ты пишешь о двух разных подходах:
1.

Хотим оставить 1 аплинк на нем, а второй перенести на новый бордер.

2.

Хотелось бы добиться полной взаимозаменяемости бордеров, падает один (тьфу-тьфу...)- работает другой

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

достаточно прописать дефолты друг на друга?

ну и не будет трафика, т.к.:

2 full-view от двух аплинков

получится что у каждого сервера будет своя табла роутинга от каждого из апстримов, а соответвенно будут маршруты с более точным совпадением нежеле чем дефолт (0.0.0.0/0)

если мы идем по варианту №1 и хотим все же, что бы наш трафик ходил по лучшему маршруту, а не так что на какой бордер попал с того и ушел в одного из апстримов, то iBGP сессия между ними нужна.
если тебе пофиг как уйдет пакет, т.е. в какого из апстримов и оптимальный ли маршрут до получателя через апстрима на этом бордере - то iBGP можно и не поднимать и в этом случае можно и full-view не принимать. а тупо принимать default и все

по варианту #2 можно попробовать поднять CARP

З.Ы.

гуру маршрутизации!

ну до гуру нам далеко наверно, так знаем немного

[spd2]

Вариант естественно первый - работают два бордера одновременно (просто в голове вертелась мысль про вторую функцию серваков - NAS, и машинально написал про взаимозаменяемость).
Про дефолт идея была такая (без IBGP) - если бордер теряет канал со своим внешним пиром, то исходящий валится по дефолту на соседа, а тот уже отправляет во внешний мир. А почему хотел сделать без IBGP - че-то попутал критерии принятия решения в BGP, думал что критерий "EBGP лучше IBGP" идет раньше, чем AS_PATH и исходящий практически всегда будет уходить с "родного" бордера. Попутал короче.
Нада делать IBGP - самый лучший вариант.

[root]

думал что критерий "EBGP лучше IBGP" идет раньше

это так и есть, смотри:Административная дистанция

External Border Gateway Protocol (BGP) 20
Internal BGP 200

критерии выбора:
How the Best Path Algorithm Works

вот ещё:

How BGP Selects Paths

A router running Cisco IOS Release 12.0 or later does not select or use an IBGP route unless both of the following are true:

the router has a route available to the next-hop router

the router has received synchronization via an IGP (unless IGP synchronization has been disabled)

BGP bases its decision process on the attribute values. When faced with multiple routes to the same destination, BGP chooses the best route for routing traffic
toward the destination. The following process summarizes how BGP chooses the best route.

1. If the next hop is inaccessible, do not consider it.
This is why it is important to have an IGP route to the next hop.
2. If the path is internal, synchronization is enabled, and the route is not in the IGP, do not consider the route.
3. Prefer the path with the largest weight (weight is a Cisco proprietary parameter).
4. If the routes have the same weight, prefer the route with the largest local preference.
5. If the routes have the same local preference, prefer the route that was originated by the local router.
For example, a route might be originated by the local router using the network bgp command, or through redistribution from an IGP.
6. If the local preference is the same, or if no route was originated by the local router, prefer the route with the shortest autonomous system path.
7. If the autonomous system path length is the same, prefer the route with the lowest origin code (IGP < EGP < INCOMPLETE).
8. If the origin codes are the same, prefer the route with the lowest Multi Exit Discriminator (MED) metric attribute.
This comparison is only done if the neighboring autonomous system is the same for all routes considered, unless bgp always-compare-med is enabled.
9. If the routes have the same MED, prefer the external (EBGP) path over the internal (IBGP) path.
All confederation paths are considered internal paths, but Confederation EBGP is preferred over Confederation IBGP.
10. Prefer the route that can be reached through the closest IGP neighbor (the lowest IGP metric).
This means the router will prefer the shortest internal path within the autonomous system to reach the destination (the shortest path to the BGP next-hop).
11. If the following conditions are all true, insert the route for this path into the IP routing table:
Both the best route and this route are external.
Both the best route and this route are from the same neighboring autonomous system.
maximum-paths is enabled.

Нада делать IBGP - самый лучший вариант.

ну так они хотя бы маршрутами будут обмениваться, мне кажется это правильный вариант, т.к. все же это единая ASка

[spd2]

Судя по докам, сначала принимается решение о лучшем пути внутри маршрутных протоколов. Затем роутер выбирает лучший путь при помощи AD. Верно? Тогда исходящий практически всегда таки будет уходить с "родного" бордера, а не с соседа по AS. А вот входящий будет приходить и с соседа. С учетом того, что бордеры будут смотреть в разные AS, несимметрия получается...

[root]

сначала принимается решение о лучшем пути внутри маршрутных протоколов

это ты про пункт 2 ?
обычно все дают команду:

Код: Выделить всё

no synchronization

тут речь о синхронизации, т.е. если маршрут пришел через EGP, но нет "подверждения" (такого же маршрута) через IGP, то такой маршрут идет нафиг

протоколы смотрят в п.7:

7. If the autonomous system path length is the same, prefer the route with the lowest origin code (IGP < EGP < INCOMPLETE).

т.е. если маршруты равнозначные, то выбирается тот у которого наименьшеая административная дистанция

Тогда исходящий практически всегда таки будет уходить с "родного" бордера

скорее всего

несимметрия получается...

смотри:

3. Prefer the path with the largest weight (weight is a Cisco proprietary parameter).
4. If the routes have the same weight, prefer the route with the largest local preference.

кто тебе мешает повлиять на процесс ?
Юзай метрики (weight или local preference, или и то и то для верности ), с их помощью ты можешь заставить исходящий трафик из твоей AS ходить как тебе надо между твоими бордюрами

С учетом того, что бордеры будут смотреть в разные AS

поговори со своими апстримами, поддерживают ли они MED атрибут, с его помощью ты сможешь разрулить и входящий трафик к себе
+ можно балансировать траф с помощью из communities (если таковые есть) у твоих апстримов, т.е. по некоторым направлениям будешь препендить через одного из апстримов, что повлияет на вход. трафик к тебе
в любом случае сбалансировать входящий трафик гораздо сложнее чем исходящий, т.к. тут уже требуется поддержка "фич" твоими апстримами

[spd2]

Отпишусь по практическим результатам обсужденной схемы. Выбран, естественно, вариант с iBGP, как наиболее правильный.
Схема с 2 бордерами реализована и работает около месяца. Каждый бордер держит по 1 аплинку и iBGP сессию между собой. Балансировка трафика работает без проблем. Исходящий балансируется с помощью weight и local-pref, входящий - через community апстримов.

[Keeper-it]

Отпишусь по практическим результатам обсужденной схемы. Выбран, естественно, вариант с iBGP, как наиболее правильный.
Схема с 2 бордерами реализована и работает около месяца. Каждый бордер держит по 1 аплинку и iBGP сессию между собой. Балансировка трафика работает без проблем. Исходящий балансируется с помощью weight и local-pref, входящий - через community апстримов.

У вас задача очень похожа на мою, хотел спросить:

1. Ваши 2 бордера включены между собой в один коммутатор или любым другим надёжным способом?
2. Как отработает такая схема, если iBGP сессия между бордерами будет разорвана, без падения любых других линков?

В моём случаи имею вот такую схему

И очень охота сделать Сегменты максимально независимыми друг от друга, то есть
1. При отказе любого одного из Link 1,2,3, система продолжает работать и балансировать нагрузку между аплинками (пока внутренние 1Gb линки далеки от перегрузки).
2. При отказе любых двух из Link 1,2,3 одновременно, любые не изолированные сегменты продолжают работать через доступный аплинк.
3. При отказе любого одного из аплинков или одного из бордеров. весь траффик идёт через другой аплинк.
4. Когда всё работает, балансировать нагрузку на аплинки.
Бордовым выделено то, что есть, но близко к перегрузке
Оранжевым выделено то, чего нет, и надо сделать срочно
Синим выделено то, что планируется, но не горит
Сегментов в действительности 4, ещё 1 строится и 1 планируется. Разнесено всё на расстояния от 2 до дестяков км. Железо при этом - древний б/у хлам (надеюся что временно, кхе кхе), потому без резервирования никак не обойтись.
INET 2 готовы подать. как только мы будем готовы со своей стороны.

Главный вопрос
3. Возможно реализовать такое с 1й ASкой и несколькими PI?
4. Если да, то с чем прийдётся столкнуться, какие подводные камни?

[spd2]

У вас задача очень похожа на мою, хотел спросить:

1. Ваши 2 бордера включены между собой в один коммутатор или любым другим надёжным способом?
2. Как отработает такая схема, если iBGP сессия между бордерами будет разорвана, без падения любых других линков?

Главный вопрос
3. Возможно реализовать такое с 1й ASкой и несколькими PI?
4. Если да, то с чем прийдётся столкнуться, какие подводные камни?

Скажу кратенько по пунктам:

1. Да, включены в один коммутатор, т.к. находятся на одной площадке. Но не будет ничего сильно страшного, если они будут разнесены территориально.
2. Если разорвется iBGP сессия, то часть таблицы маршрутов на каждом бордере станет неоптимальной. Для исходящего трафика это приведет к неоптимальному выходу его из AS (удлинение пути и т.д.). Для входящего - если остались доступными маршруты к вашим сетям внутри AS, то BGP продолжит анонсировать сети во внешний мир, т.е. ничего не изменится.
3. Судя по схеме, вполне возможно. 1 AS достаточно, а сколько блоков PI - неважно, будете все нужные блоки анонсировать с обоих бордеров.
4. Подводных камней особо нет, не забудьте для iBGP сессии указать hext-hop-self.

[r0lsen]

доброго вечера коллеги.
Ситуация у меня весьма похожа, отличие идет только в том, что оба аплинка приходят на разные BR и необходимо как-то объединить их чтобы трафик шел по обоим аплинкам( каналы несимметричные обычным разбиение на анонсируемые подсети не получится нормально сделать). Из информации ; с 1 аплинка приходит фулл-вью таблица, со второго дефолт между BR поднята iBGP сессия , связь с вышестоящим провайдером через bgp.
Может кто-то сталкивался с подобной задачкой)