Jump to content
Калькуляторы

Нужна помощь в настройке Quagga BGP

Люди помогите!!!!

Имеем 2 провайдера, свою AS и пул адресов.

Надо разделить пользователей по каналам.

 

Конфиг zebra.conf

!
! Zebra configuration saved from vty 
! 2010/08/19 21:29:23 
! 
hostname Какое-то имя
password password
enable password password
log file /var/log/quagga/zebra.log 
!
!debug zebra events
!debug zebra packet
!
interface eth8
ip address xxx.xxx.x40.110/30
ipv6 nd suppress-ra

!
interface eth6
ip address yyy.yyy.yy1.47/31
ipv6 nd suppress-ra
!
interface br0
ip address 192.168.1.201/24
ip address 172.16.0.3/16
ip address 172.24.0.3/16
ip address 172.25.0.3/24
ipv6 nd suppress-ra
!
interface lo
interface lo:1
ip address xxx.xxx.xxx.1/24
ipv6 nd suppress-ra
!
ip route 0.0.0.0/0 xxx.xxx.xxx.109 15
ip route 0.0.0.0/0 yyy.yyy.yyy.46 25
ip route 10.0.0.0/8 Null0 254
ip route 172.16.0.0/16 Null0 254
ip route 172.24.0.0/16 Null0 254
ip route 172.25.0.0/16 Null0 254
ip route 192.168.0.0/16 Null0 254
ip route xxx.xxx.xxx.0/24 Null0 254
ip route xxx.xxx.xxx.0/25 xxx.xxx.xxx.72
ip route xxx.xxx.xxx.128/25 yyy.yyy.yyy.46
!
ip forwarding
!
!
line vty
exec-timeout 0 0

 

конфиг bgpd.conf

hostname OURAS
password pass
enable password pass
!debug bgp events
!debug bgp filters
!debug bgp fsm
!debug bgp keepalives
!debug bgp updates
!
bgp multiple-instance
bgp config-type cisco
!
log file /var/log/quagga/bgpd.log
log stdout
!
router bgp OURAS
no synchronization
bgp router-id xxx.xxx.xxx.1
bgp log-neighbor-changes
network xxx.xxx.xxx.0/24
neighbor xxx.xxx.xxx.72 remote-as ASISP1
neighbor xxx.xxx.xxx.72 description ISP1
neighbor xxx.xxx.xxx.72 update-source xxx.xxx.xxx.110
neighbor xxx.xxx.xxx.72 ebgp-multihop 255
neighbor xxx.xxx.xxx.72 weight 4000
neighbor xxx.xxx.xxx.72 soft-reconfiguration inbound
neighbor xxx.xxx.xxx.72 route-map ISP1-in in
neighbor xxx.xxx.xxx.72 route-map ISP1-out out
!
neighbor yyy.yyy.yyy.46 remote-as ASISP2
neighbor yyy.yyy.yyy.46 description ISP2
neighbor yyy.yyy.yyy.46 update-source yyy.yyy.yyy.47
neighbor yyy.yyy.yyy.46 ebgp-multihop 255
neighbor yyy.yyy.yyy.46 weight 1000
neighbor yyy.yyy.yyy.46 soft-reconfiguration inbound
neighbor yyy.yyy.yyy.46 route-map ISP2-in in
neighbor yyy.yyy.yyy.46 route-map ISP2-out out
!
ip prefix-list bogons description bogus nets
ip prefix-list bogons description 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 xxx.xxx.xxx.0/24 le 32
ip prefix-list upstream-out seq 10 permit xxx.xxx.xxx.0/24
!
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 ISP1-in deny 100
match as-path 1
!
route-map ISP1-in deny 110
match ip address prefix-list bogons
!
route-map ISP1-in deny 120
match ip address prefix-list our-CIDR-blocks
!
route-map ISP1-in permit 200
set local-preference 200
!
route-map ISP1-out permit 100
match ip address prefix-list upstream-out
!
route-map ISP1-out deny 200

route-map ISP2-in deny 100
match as-path 1
!
route-map ISP2-in deny 110
match ip address prefix-list bogons
!
route-map ISP2-in deny 120
match ip address prefix-list our-CIDR-blocks
!
route-map ISP2-in permit 200
set local-preference 100
!
route-map ISP2-out permit 100
match ip address prefix-list upstream-out
set as-path prepend OURAS OURAS OURAS OURAS OURAS
!
!route-map ISP2-out deny 200
!
line vty

 

У меня получается вообще непонятно что, вобщем я совсем запутался, хотелось бы чтоб 80% узеров ходило через ISP1, а 20% - через ISP2.

Похоже что у меня трафик разделился на два интерфейса, входящий по одному каналу идёт, исходящий по другому.

Edited by llaann

Share this post


Link to post
Share on other sites

У каждого аплинка свои приколы с маршрутизацией.

Да и внутри сети иногда бывает ассиметрия исхода.

 

Обращайтесь в личку за помощью, небезкорыстно помогу настроить BGP и внешний роутинг.

Edited by vlad11

Share this post


Link to post
Share on other sites

что значит

Надо разделить пользователей по каналам.
?

у Вас блок всего /24, Вы его анонсите всем провам одинаково.префиксами Вы только маршруты выбираете и все .

Share this post


Link to post
Share on other sites

что значит

Надо разделить пользователей по каналам.
?

у Вас блок всего /24, Вы его анонсите всем провам одинаково.префиксами Вы только маршруты выбираете и все .

 

Деже если блок /24, всегда можно разделить равномерно исход на 2 и более аплинков.

Главное, чтоб аплинки отдавали FV.

Edited by vlad11

Share this post


Link to post
Share on other sites

Надо разделить пользователей по каналам.

Исходящий - без проблем. Статические маршруты + fallback-gw.

Дополнительный плюс - не надо возиться с fullview.

 

Чтобы балансировать входящий, надо иметь блок больше /24,

регистрировать в RIPE route object'ы для подсетей

и анонсировать их разным аплинкам с разными препендами.

Share this post


Link to post
Share on other sites
Деже если блок /24, всегда можно разделить равномерно исход на 2 и более аплинков.

Главное, чтоб аплинки отдавали FV.

зачем фуллвью ? это ж только исходячка. исходячка как правило в разы меньше => похрен куда она пойдет. чтобы ровно разделить, хватит и ecmp на дефолтах от каждого из аплинков.
Статические маршруты + fallback-gw.
надо тчобы маршруты создавались в зависимости от состояния бгп сессии, чтобы при ее падении они удалялись. на квагге такое реализуется лишь скриптами из палок и кабаньего говна. sad but true.
Чтобы балансировать входящий, надо иметь блок больше /24,

регистрировать в RIPE route object'ы для подсетей

и анонсировать их разным аплинкам с разными препендами.

все не совсем так. если у вас есть большой блок который можно порезать на специфики до /24, то можно балансить спецификами. например есть /23, то одну /24 анонсим в один апстрим, другую /24 в другой, а /23 в оба. бида в том что не всегда трафик раскладывается по ровну между блоками сетей и вообще трафик никак не связан с адресами. это скорее такой деревянный вариант от безисходности. препенды на анонсы тоже деревянный вариант, т.к. влияют глобально на всё и сразу и управлять тем как разложится трафик будет получаться очень грубо: то весь трафик едет в один аплинк, то в другой.

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

Share this post


Link to post
Share on other sites

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

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

и таким образом балансировать входящую нагрузку с большой точностью.

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

 

правильный путь - использовать апстримов с развитыми комунитями

Не везде есть даже возможность подключения второго аплинка, не говоря уже о том,

что сначала принято смотреть на цену, а в последнюю очередь на поддержку community.

(благо любой современый магисрал имеет какие-никакие комунити),

Любой????

Пока это скорее исключение, чем правило.

Share this post


Link to post
Share on other sites

Тогда подскажите как правильно выбирать маршрут, у меня все уходят в ISP2, нужно чтобы все ходили через ISP1.

Share this post


Link to post
Share on other sites

Тогда подскажите как правильно выбирать маршрут, у меня все уходят в ISP2, нужно чтобы все ходили через ISP1.

1) фильтруйте все префиксы, которые приходят от аплинков.

2) вся маршрутизация наружу - статическая.

3) переключение с упавшего аплинка - через fallback-gw.

4) при использовании bgp маршрут входящего трафика не зависит от маршрута исходящего.

Share this post


Link to post
Share on other sites
Если адреса используются для NAT, то можно назначать для разных приватных подсетей публичные адреса из разных блоков,

и таким образом балансировать входящую нагрузку с большой точностью.

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

натить просто в несколько адресов из разных блоков, это не проблема. а адреса выдавать клиентам из разных блоков может стать проблемой в последствии, потому что внезапно окажется что все сети /24 утилизированы на 89% и не откуда дать доброму клиенту /26 для счастья.
Не везде есть даже возможность подключения второго аплинка, не говоря уже о том,

что сначала принято смотреть на цену, а в последнюю очередь на поддержку community.

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

Пока это скорее исключение, чем правило.

эээ.. да магисралов то раз два и обчелся ж: ттк, рт, совинтел (белайн), синтерра (мегафон), - у всех есть комунити.
2) вся маршрутизация наружу - статическая.

3) переключение с упавшего аплинка - через fallback-gw.

никак не пойму что такое фолбак-гв ? и зачем статическая маршрутизация, если есть бгп.

Share this post


Link to post
Share on other sites

никак не пойму что такое фолбак-гв ?

use google, luke!

https://www.google.com/search?q=fallback-gw

 

и зачем статическая маршрутизация, если есть бгп.

1) через статические маршруты проще балансировать исходящую нагрузку,

2) если аплинки шлют fullview, можно фильтровать их и этим прилично снизить нагрузку на бордер.

Что лучше - пять маршрутов или 370k?

Share this post


Link to post
Share on other sites

1) через статические маршруты проще балансировать исходящую нагрузку,

 

Не факт. Вы придумываете свой демон маршрутизации.

 

2) если аплинки шлют fullview, можно фильтровать их и этим прилично снизить нагрузку на бордер.

Что лучше - пять маршрутов или 370k?

Если у вас бюджетный киско-роутер, то он от FV загнется.

А если РС-роутер, то лучше брать максимум, легче балансировать.

Share this post


Link to post
Share on other sites
A script to activate backup routing on gateway failure.

пинцет. это типа "true"-решение ? закопайте обратно.

1) через статические маршруты проще балансировать исходящую нагрузку,
и как вы будете удалять статические маршруты при падении одного из пиров ? говноскриптом вышеупомянутым ? а может еще свой демон маршрутизации напишем ? зачем это всё, когда можно принять два дефолта и сделать ecmp. ну или если fv то по as-path'у раскидать префиксы туда-сюда. количество трафика то не зависит от количества префиксов. у вас легко может быть на какой не большой блок адресов трафика быть в разы больше чем на все остальные адреса вместе взятые.
2) если аплинки шлют fullview, можно фильтровать их и этим прилично снизить нагрузку на бордер.

Что лучше - пять маршрутов или 370k?

зачем их фильтровать ? не проще аплинк попросить тогда уж слать дефолт ? а что лучше fv или дефолт решает не количество префиксов, а решаемые задачи. под которые вобщем-то и покупается оборудование.
Если у вас бюджетный киско-роутер, то он от FV загнется.
не, ну не включать soft-inbound configuration и будет ок. просто зачем использовать "бюджетный киско-роутер" там где нужен нормальный роутер. из-за нищеты ?

ну и я не знаю, есть далеко не бюджетные роутеры неумеющие fv в fib'е. 76+rsp720-c хороший пример - стоит гору денег, а ничо не может. такие дела.

 

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

Share this post


Link to post
Share on other sites

благо любой современый магисрал имеет какие-никакие комунити

вот тут чаще всего и проблема - что надо нормальные а не "какиеникакие".... а "какиеникакие" - тоже часто только очень грубо могут регулировать

Share this post


Link to post
Share on other sites

Тогда подскажите как правильно выбирать маршрут, у меня все уходят в ISP2, нужно чтобы все ходили через ISP1.

 

Похоже никто из ответивших даже не смотрел приложенный конфиг...

 

При ваших настройках трафик и так должен идти через ISP1. У вас сессии то поднялись на обоих ISP ? Проблема может быть в том, что ISP1 - это multihop. Т.е. для маршрутов от него будет приниматься атрибут "Next Hop", и для адресов в нем может не оказаться нужных маршрутов через нужный интерфейс. Попробуйте сделать так:

route-map ISP1-in permit 200
set local-preference 200
set ip next-hop xxx.xxx.xxx.109

еще я бы рекомендовал статический маршрут добавить

ip route xxx.xxx.xxx.72/32 xxx.xxx.xxx.109

 

 

Также непонятно зачем вот эти маршруты

ip route xxx.xxx.xxx.0/25 xxx.xxx.xxx.72
ip route xxx.xxx.xxx.128/25 yyy.yyy.yyy.46

 

ЗЫ: И еще уберите weight с обоих пиров и никогда не пользуйтесь этим атрибутом - его придумала cisco, в стандарте BGP про него ничего нет.

Share this post


Link to post
Share on other sites
вот тут чаще всего и проблема - что надо нормальные а не "какиеникакие".... а "какиеникакие" - тоже часто только очень грубо могут регулировать
бывает, да. ну лучше "какие-нибудь", чем никаких вообще.
При ваших настройках трафик и так должен идти через ISP1. У вас сессии то поднялись на обоих ISP ? Проблема может быть в том, что ISP1 - это multihop. Т.е. для маршрутов от него будет приниматься атрибут "Next Hop", и для адресов в нем может не оказаться нужных маршрутов через нужный интерфейс. Попробуйте сделать так:
чо к чему? в один аплинк входячка может литься банально потому что оба апстрима своим аплинком имеют одного магисрала. это ж легко выяснить в ripe.net/ris и пробежавшись по лукенг глассам.

про исходячку, зачем делать некстхоп ? что вообще тут имеется ввиду. пусть топикстартер прочитает книжку (вам тоже советую) и осознает что да как. это будет гораздо полезнее и ценнее чем тысячи недосоветов на форуме хоменетов.

ЗЫ: И еще уберите weight с обоих пиров и никогда не пользуйтесь этим атрибутом - его придумала cisco, в стандарте BGP про него ничего нет.
и что такого ? волков боятся - в лес не ходить. если знаешь как он работает, почему им не пользоваться ?
У меня получается вообще непонятно что, вобщем я совсем запутался, хотелось бы чтоб 80% узеров ходило через ISP1, а 20% - через ISP2.
ну значит позовите одмина, он вам настроит. ну а если вы и есть тот одмин, то надо открывать книжку. такие дела.
Похоже что у меня трафик разделился на два интерфейса, входящий по одному каналу идёт, исходящий по другому.
у вас вес 4000 на одном пире и 1000 на другом, соответственно активным маршрутами с одинаковыми префиксами с обоих апстримов назначены те что с 4000.

Share this post


Link to post
Share on other sites

Я ж говорю, что некоторые даже не читают перед тем как ответить.

 

Похоже что у меня трафик разделился на два интерфейса, входящий по одному каналу идёт, исходящий по другому.
у вас вес 4000 на одном пире и 1000 на другом, соответственно активным маршрутами с одинаковыми префиксами с обоих апстримов назначены те что с 4000.

Если бы прочитали конфиг, то увидели, что weight 4000 стоит на ISP1, а если бы прочитали вот это сообщение

Тогда подскажите как правильно выбирать маршрут, у меня все уходят в ISP2, нужно чтобы все ходили через ISP1.

то поняли, что вопреки weight трафик ходит через другого аплинка.

 

 

При ваших настройках трафик и так должен идти через ISP1. У вас сессии то поднялись на обоих ISP ? Проблема может быть в том, что ISP1 - это multihop. Т.е. для маршрутов от него будет приниматься атрибут "Next Hop", и для адресов в нем может не оказаться нужных маршрутов через нужный интерфейс. Попробуйте сделать так:
чо к чему? в один аплинк входячка может литься банально потому что оба апстрима своим аплинком имеют одного магисрала. это ж легко выяснить в ripe.net/ris и пробежавшись по лукенг глассам.

про исходячку, зачем делать некстхоп ? что вообще тут имеется ввиду. пусть топикстартер прочитает книжку (вам тоже советую) и осознает что да как. это будет гораздо полезнее и ценнее чем тысячи недосоветов на форуме хоменетов.

Если бы сами почитали книжку, то наверно знали бы чем отличается обработка анонсов от ebgp-multihop пиров. Например, что от multihop пира принимается "Next Hop", и если маршрут к этому некстхопу будет виден через другого аплинка, то и трафик пойдет через другого аплинка.

 

pfexec, я делаю вывод, что вы - обычный болтун, тролль и невежда.

Share this post


Link to post
Share on other sites
Я ж говорю, что некоторые даже не читают перед тем как ответить.
у топикстартера представлне недостаточно информации для того чтобы однозначно понять что у него происходит. разница между нами в том что я не пытаюсь пальцем в небо тыкать и играть в телепата. да, прочитал по диагонали.
Если бы сами почитали книжку, то наверно знали бы чем отличается обработка анонсов от ebgp-multihop пиров. Например, что от multihop пира принимается "Next Hop", и если маршрут к этому некстхопу будет виден через другого аплинка, то и трафик пойдет через другого аплинка.
тащем-то нет, не так. начнем с того что от безисходности кто-то налепил в конфиг ebgp-multihop с ттл аж 255. очевидно же что никто даже не поинтересовался зачем. во-вторых, опять же не представлено достаточно информации чтобы понять нужен там этот мультихоп или нет. ну и в-третьих, квагга не умеет работать мультихопом, если до мультихоп пира маршрут изучен через бгп. об этом даже есть PR столетеней давности: https://bugzilla.quagga.net/show_bug.cgi?id=377

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

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

Share this post


Link to post
Share on other sites

бывает, да. ну лучше "какие-нибудь", чем никаких вообще.

возможно немного офтоп, но продолжу мысль по коммюнити, может поможет ТС - хорошо когда провайдер-апстрим разрешает (пропускает, не фильтрует) коммюнити - которые работают у его апстримов - иногда оооочень помогает....

Share this post


Link to post
Share on other sites

возможно немного офтоп, но продолжу мысль по коммюнити, может поможет ТС - хорошо когда провайдер-апстрим разрешает (пропускает, не фильтрует) коммюнити - которые работают у его апстримов - иногда оооочень помогает....

 

Многие апстримы их режут, "якобы, они память отжирают у маршрутизаторов".

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Покажите пример мусора?

Лично я хочу видеть сети с комьюнити аплинков моего аплинка.

Share this post


Link to post
Share on other sites

а вы хотите видеть комьюнити аплинков аплинков аплинков... в общем можно долго продолжать

 

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

 

Лично я хочу видеть сети с комьюнити аплинков моего аплинка.

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

 

PS. спасибо за идею, у нас BPG policy полгода назад я только реализовал, посрезать лишние комьнити - хорошая идея для развития, займусь на недельке

Share this post


Link to post
Share on other sites

а вы хотите видеть комьюнити аплинков аплинков аплинков... в общем можно долго продолжать

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

Нет. Мне достаточно коммьюнити от аплинка 2-го уровня.

Остальное нужное я посмотрю на LG.

P.S. а почему нельзя продавать роутеры с парой гигов памяти? флеш дорогая? маркетинговая защита?

Share this post


Link to post
Share on other sites

Нет. Мне достаточно коммьюнити от аплинка 2-го уровня.

+1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this