LINUX.ORG.RU
решено Форум — Admin  

BGP балансировка. set as-path prepend. Отваливаются сети


0

2

Доброго дня!
Столкнулся с одной траблой, весь день вожусь. Такое ощущение, что ответ где-то рядом, но уже наверное глаз замылился.
2 оператора, канала симметричные по 100 мегабит.
Канал TKS полностью забивается на примем ROSTELECOM на 1/3.
В route-map RKS-out permit 100 ставлю 4-5 prepend :

set as-path prepend 12345 12345 12345 12345

При этом нагрузка практически выравнивается. Но, все бы отлично! пропадает пинг до 193.8.0.18. А этот узел очень нужен. Есть мысли, как сделать, чтобы на него prepend не распространялись?
Потому как от ROSTELECOM узел 193.8.0.18 не отвечает.
Или наоборот, на некоторые их было больше.

Если кого смутит prepend в route-map TKS-in permit 200 и route-map ROSTELECOM-in permit 200
Меняю распределение исходящего. Иначе на ROSTELECOM нагрузка существенно больше чем на TKS. Но это действие видимых проблем не вызывает.

cat bgpd.conf
hostname AS12345
password bgpdpass
enable password bgpdpass
log file /usr/local/etc/quagga/bgpd.log
!
router bgp 12345
bgp router-id 188.230.0.1
bgp log-neighbor-changes
no synchronization
network 188.230.0.0/22

neighbor 91.24.22.129 remote-as 11111
neighbor 91.24.22.129 description ROSTELECOM
neighbor 91.24.22.129 next-hop-self
neighbor 91.24.22.129 route-map ROSTELECOM-in in
neighbor 91.24.22.129 route-map ROSTELECOM-out out

neighbor 77.225.64.65 remote-as 22222
neighbor 77.225.64.65 description TKS
neighbor 77.225.64.65 next-hop-self
neighbor 77.225.64.65 route-map TKS-in in
neighbor 77.225.64.65 route-map TKS-out out
!
ip prefix-list bogons description bogus nets
ip prefix-list bogons seq 15 permit 0.0.0.0/8 le 32
ip prefix-list bogons seq 20 permit 127.0.0.0/8 le 32
ip prefix-list bogons seq 30 permit 10.0.0.0/8 le 32
ip prefix-list bogons seq 35 permit 172.16.0.0/12 le 32
ip prefix-list bogons seq 40 permit 192.168.0.0/16 le 32
ip prefix-list bogons seq 45 permit 169.254.0.0/16 le 32
ip prefix-list bogons seq 50 permit 224.0.0.0/4 le 32
ip prefix-list bogons seq 55 permit 240.0.0.0/4 le 32
ip prefix-list default description default route
ip prefix-list default seq 10 permit 0.0.0.0/0
ip prefix-list our-CIDR-blocks seq 5 permit 188.230.0.0/22 le 32
ip prefix-list upstream-out seq 10 permit 188.230.0.0/22
!
ip as-path access-list 1 permit _6451[2-9]_
ip as-path access-list 1 permit _645[2-9][0-9]_
ip as-path access-list 1 permit _64[6-9][0-9][0-9]_
ip as-path access-list 1 permit _65[0-9][0-9][0-9]_
!
route-map ROSTELECOM-in deny 100
match as-path 1
!
route-map ROSTELECOM-in deny 110
match ip address prefix-list bogons
!
route-map ROSTELECOM-in deny 115
match ip address prefix-list default
!
route-map ROSTELECOM-in deny 120
match ip address prefix-list our-CIDR-blocks
!
route-map ROSTELECOM-in permit 200
set as-path prepend 12345 12345 12345 12345
set local-preference 100
!
route-map ROSTELECOM-out permit 100
match ip address prefix-list upstream-out
!
route-map ROSTELECOM-out deny 200
!
route-map TKS-in deny 100
match as-path 1
!
route-map TKS-in deny 110
match ip address prefix-list bogons
!
route-map TKS-in deny 115
match ip address prefix-list default
!
route-map TKS-in deny 120
match ip address prefix-list our-CIDR-blocks
!
route-map TKS-in permit 200
set as-path prepend 12345 12345 12345
set local-preference 100
!
route-map RKS-out permit 100
match ip address prefix-list upstream-out
set as-path prepend 12345 12345 12345 12345
!
route-map RKS-out deny 200


← Gentoo. Добавить модуль к ядру.
Проблемы с настройкой раздачи интернета →

Ответ на: комментарий от kompas

Потому что пришлось бы идти в другой форум

gich
() автор топика

«При этом нагрузка практически выравнивается. Но, все бы отлично! пропадает пинг до 193.8.0.18. А этот узел очень нужен. Есть мысли, как сделать, чтобы на него prepend не распространялись?»

а изза чего пропадает то выяснил ? из за канала туда или обратно ? если выход на этот ip на другого провайдера переставить - то связи все равно нет ?

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

ae1234 ★★
()

и если речь о одном ip - может просто решить вопрос snat/dnat-ом на адресс интерфейса что смотрит на работающего прова ?

ae1234 ★★
()
Ответ на: комментарий от ae1234

а изза чего пропадает то выяснил ? из за канала туда или обратно ?

Пропадает когда вот тут
route-map RKS-out permit 100
match ip address prefix-list upstream-out
set as-path prepend 12345 12345 12345 12345

более 1 prepend. ТЕ когда
set as-path prepend 12345
пингуется.
NAT не вариант. Это для прямого IP надо.

gich
() автор топика
Ответ на: комментарий от gich

то есть точно обратный канал ?
если при изменение препендов в выходящих упдейтах - меняет ситуацию - то да - обратный канал

тогда или пробовать крутить комьюнити или искать где теряеться и связываться с теми админами ?
есть какойто другой вариант ?

ae1234 ★★
()
Ответ на: комментарий от ae1234

Если
neighbor 91.24.22.129 shutdown
то связь сразу есть.
no neighbor 91.24.22.129 shutdown
Если только запред принимать/отправлять адейты для 193.8.0.0/24 черех этого пира.

gich
() автор топика
Ответ на: комментарий от gich

бррр

мне кажеться и ли нет
RKS-out у тебя хоть где то используется ?

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

ae1234 ★★
()
Ответ на: комментарий от gich

с админами эт долго :)
ты роутингами то проверил исходящий маршрут ?

попробовал бы через комьюнити избежать плохую as

ae1234 ★★
()

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

AS ★★★★★
()

там какая-то оппа - у ростела и ещё у кого из верхних провов война - та же фигня на предыдущей работе - поламерики периодически не видит их AS.:-(

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

Посде танцев с бубном получилось что-то вроде:
..............
route-map ROSTELECOM-out permit 100
match ip address prefix-list upstream-out
set as-path prepend 12345 12345
!
..............
!
route-map ТKS-out permit 100
match ip address prefix-list upstream-out
set as-path prepend 12345 12345 12345 12345

С такими раскладами вроде все что надо пингуется и траффик почти сбалансирован. На сколько я знаю BGP, если разница между каналами 10-15% можно сказать идеальный случай.

у кого из верхних провов война

Тоже про это слышал. Но не думал, что придется бодаться.
Наверное пока оставлю такую схему.
Логично предположить, что если нашелся один «не пингующийся» найдутся еще? Если вроде все работает, как мне кажется найти еще пару граблей вероятность меньше.

gich
() автор топика
Ответ на: комментарий от gich

на старой работе парни тоже мучатся с этими всеми prepend-ами

увы! такова жисть!

mumpster ★★★★★
()

попробуй фиктивную AS(не свою, а целевую) засунуть в prepend. Все стандарты конечно нарушишь, но зато данный маршрут не учтется на маршрутизаторах целевой AS. Осторожно: за такое админы в приличном обществе бьют в морду

Pinkbyte ★★★★★
()
Ответ на: комментарий от mumpster

там какая-то оппа - у ростела и ещё у кого из верхних провов война

Беда может быть в другом. 193.8.0.18 анонсируется в блоке /24, кто-то где-то мог, не особенно подумав, отфильтровать мелочь, не сверяясь с http://www.ripe.net/ripe/docs/ripe-504

AS ★★★★★
()
Ответ на: комментарий от AS

ты знал :)

но вообще у коллег более /24 и тоже проблемки :-)

mumpster ★★★★★
()
Ответ на: комментарий от AS

Еще вопрос по ходу.
У кого какой есть опыт отказаустойчивости такого сочетания, как приведено выше? Заметил, что при падении одного из аплинков почему-то на второй не переходила нагрузка. Падало минуты на 3. Вопрос простой. ПО опыту, сколько времени требовалось для перераспределения маршрутной информации

gich
() автор топика
Ответ на: комментарий от gich

на E1 занимало где-то минут 7-10 днём, ночью - быстрее. но некторые машруты появлвялись толкьо минут через 20 (обsчно какая-нибудь австралия) на 10-мбит - минуты 2-3 основные, потом остальные (минут за 15)

mumpster ★★★★★
()
Ответ на: комментарий от gich

Заметил, что при падении одного из аплинков почему-то на второй не переходила нагрузка. Падало минуты на 3.

Таймаут на bgp-сессию 2 минуты по-умолчанию. Как правило, никто его не меняет. Соответственно, при падении линка, анонс от апстрима висит ещё и трафик идёт к нему, а канал порван. Ну и плюс какие-то десятки секунд на распространение информации о пропаже анонса после окончания таймаута.

AS ★★★★★
()
Ответ на: комментарий от mumpster

на E1 занимало где-то минут 7-10 днём, ночью - быстрее.

Скорее всего, это было связано с пропускной способностью канала (в меньшей степени) и производительностью процессора маршрутизатора. Там же полученное ещё обсчитать надо.

AS ★★★★★
()
Ответ на: комментарий от mumpster

не поверишь - больше 0,5 никогда не бывало :-)

0.5 - загрузка ? Или что ? Фиг знает, у меня возможность сравнения на железке BayNetworks BCN была. Там процессорных модулей несколько. Если bgp запускать на FRE2-60, более получаса таблицы втягивались, если на FRE4-PPC - минуты три. Но это во времена 150K таблицы было.

AS ★★★★★
()
Ответ на: комментарий от AS

тащмета я про попугаи по w и uptime :-)

у нас же там линукс был и bird, потом зебру или кваггу мужики поставили. но на загрузку это не сильно повлияло.;)

mumpster ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Gentoo. Добавить модуль к ядру.
Admin
Проблемы с настройкой раздачи интернета →