1 AS и 2 бордера

Статическая и динамическая, протоколы

1 AS и 2 бордера

Сообщение spd2 » 11 янв 2010, 17:23

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

Re: 1 AS и 2 бордера

Сообщение root » 12 янв 2010, 11:54

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

хм.. ты пишешь о двух разных подходах:
1.
spd2 писал(а):Хотим оставить 1 аплинк на нем, а второй перенести на новый бордер.

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

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

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

ну и не будет трафика, т.к.:
spd2 писал(а):2 full-view от двух аплинков

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

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

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

З.Ы.
spd2 писал(а):гуру маршрутизации!

ну до гуру нам далеко наверно, так знаем немного :)
С уважением, root

Изображение
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
root
Site Admin
 
Сообщения: 1882
Зарегистрирован: 11 июн 2008, 13:05
Откуда: Moscow, Russia

Re: 1 AS и 2 бордера

Сообщение spd2 » 12 янв 2010, 13:06

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

Re: 1 AS и 2 бордера

Сообщение root » 12 янв 2010, 13:29

spd2 писал(а):думал что критерий "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.


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

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

Изображение
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
root
Site Admin
 
Сообщения: 1882
Зарегистрирован: 11 июн 2008, 13:05
Откуда: Moscow, Russia

Re: 1 AS и 2 бордера

Сообщение spd2 » 13 янв 2010, 10:11

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

Re: 1 AS и 2 бордера

Сообщение root » 13 янв 2010, 13:15

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

это ты про пункт 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).

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

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

скорее всего

spd2 писал(а):несимметрия получается...

смотри:
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 ходить как тебе надо между твоими бордюрами

spd2 писал(а):С учетом того, что бордеры будут смотреть в разные AS

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

Изображение
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
root
Site Admin
 
Сообщения: 1882
Зарегистрирован: 11 июн 2008, 13:05
Откуда: Moscow, Russia

Re: 1 AS и 2 бордера

Сообщение spd2 » 07 мар 2010, 15:34

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

Re: 1 AS и 2 бордера

Сообщение Keeper-it » 07 мар 2010, 18:21

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


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

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

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


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

Главный вопрос
3. Возможно реализовать такое с 1й ASкой и несколькими PI?
4. Если да, то с чем прийдётся столкнуться, какие подводные камни?
Я знаю BGP, кунг-фу и ещё много умных слов.
Keeper-it
новичок
 
Сообщения: 8
Зарегистрирован: 05 мар 2010, 18:29

Re: 1 AS и 2 бордера

Сообщение spd2 » 10 мар 2010, 20:43

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

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

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


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

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

Re: 1 AS и 2 бордера

Сообщение r0lsen » 30 мар 2010, 18:23

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

След.

Вернуться в Маршрутизация / Routing

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

cron