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

quagga (bgpd) vs openbgpd + - где-то так

Интересует сравнение с точки зрения потребления ресурсов (проц, память) и надежности. Сейчас стоит бордер на 3 аплинка - он-же раут-сервер и несколько серверов доступа. Задача стоит сделать 2 бордера и разнести аплинки, боюсь без фул-вью на доступе не получится чтобы оптимально трафик бегал. Попробовал на один из серверов доступа вылить фул-вью - процесс zebra сожрал одно ядро коре квада и просит еще. Может я копаю не туда? Джунипер и циски не предлагайте пжалста.

Share this post


Link to post
Share on other sites

находил где-то сравнение:

xorp > quagga > openbgpd, т.е. последний - наименее требовательный

а не проще ли просто в один выделенный бордер аплинков завести.

Share this post


Link to post
Share on other sites

что-то явно не так.

quagga на pentium-D ( :) ) 2FV+IXы. load average: 0.12, 0.19, 0.10

 

Share this post


Link to post
Share on other sites
а не проще ли просто в один выделенный бордер аплинков завести.
Сейчас так и есть, пока можно на одном бордере и летим, однако пол-гигабита в пике перешагнули и растем, боюсь я за него.

 

что-то явно не так.

quagga на pentium-D ( :) ) 2FV+IXы. load average: 0.12, 0.19, 0.10

Сервер доступа номер рас, тот, который с фулвью

 

last pid: 54855;  load averages:  1.04,  1.07,  1.08                                                                                                                                   up 1+23:51:21  16:07:07
258 processes: 7 running, 240 sleeping, 11 waiting
CPU 0:  1.5% user,  0.0% nice, 40.6% system,  1.5% interrupt, 56.4% idle
CPU 1: 14.3% user,  0.0% nice, 54.9% system,  0.0% interrupt, 30.8% idle
CPU 2:  3.0% user,  0.0% nice, 40.6% system,  0.0% interrupt, 56.4% idle
CPU 3: 15.0% user,  0.0% nice, 24.1% system,  1.5% interrupt, 59.4% idle
Mem: 1001M Active, 542M Inact, 396M Wired, 19M Cache, 199M Buf, 42M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root          1 171 ki31     0K     8K RUN    3  38.1H 71.58% idle: cpu3
   14 root          1 171 ki31     0K     8K CPU0   0  36.3H 67.19% idle: cpu0
   13 root          1 171 ki31     0K     8K RUN    1  37.4H 66.16% idle: cpu1
   12 root          1 171 ki31     0K     8K CPU2   2  35.8H 59.28% idle: cpu2
1876 root          1 108    0 80724K 80172K CPU1   2  36:51 57.47% zebra
   23 root          1 -68    -     0K     8K -      2 650:17 44.09% em0 taskq
   24 root          1 -68    -     0K     8K -      0 595:28 33.15% em1 taskq
   15 root          1 -44    -     0K     8K WAIT   3  34:46  1.37% swi1: net
....
$ netstat -nr | wc -l
  295683
$ ifconfig | grep -c POINTO
625

 

Сервер доступа номер два, тот, на который бордер анонсирует default

last pid: 69851;  load averages:  1.08,  0.83,  0.74                                                                                                                                  up 23+18:47:05  16:12:27
218 processes: 7 running, 200 sleeping, 11 waiting
CPU 0:  0.0% user,  0.0% nice, 37.5% system,  0.0% interrupt, 62.5% idle
CPU 1:  2.6% user,  0.0% nice,  1.5% system,  1.5% interrupt, 94.4% idle
CPU 2:  0.4% user,  0.0% nice, 35.3% system,  0.0% interrupt, 64.3% idle
CPU 3:  1.9% user,  0.0% nice,  0.8% system,  1.5% interrupt, 95.9% idle
Mem: 973M Active, 636M Inact, 309M Wired, 36M Cache, 199M Buf, 46M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root          1 171 ki31     0K     8K CPU3   3 552.0H 100.00% idle: cpu3
   13 root          1 171 ki31     0K     8K RUN    1 547.3H 100.00% idle: cpu1
   12 root          1 171 ki31     0K     8K RUN    2 450.9H 80.57% idle: cpu2
   14 root          1 171 ki31     0K     8K RUN    0 445.7H 68.55% idle: cpu0
   24 root          1 -68    -     0K     8K CPU0   0 119.2H 38.48% em1 taskq
   23 root          1 -68    -     0K     8K CPU2   2 115.8H 24.07% em0 taskq
   15 root          1 -44    -     0K     8K WAIT   3 414:54  0.39% swi1: net
   18 root          1  44    -     0K     8K -      1  64:35  0.00% yarrow
1670 bind          7   4    0   726M   611M kqread 3  35:51  0.00% named
   35 root          1  20    -     0K     8K syncer 0  34:09  0.00% syncer
   16 root          1 -32    -     0K     8K WAIT   1  18:55  0.00% swi4: clock
....
$ netstat -nr | wc -l
    2325
$ ifconfig | grep -c POINTO
724

 

В среднем за минуту ложится и поднимается десятка полтора тунелей. На доступе bgpd не грузит проц практически нисколько, бордер для них route server, на нем и считаются таблицы для каждой железки.

Share this post


Link to post
Share on other sites

У меня используются и Quagga и OpenBGPD, но без fullview.

 

Преимущества OpenBGPD:

- настройки гораздо короче и понятнее, потому что он не старается походить на Циску,

- есть директива "fib-update no", позволяющая не вливать полученные маршруты в систему,

- ресурсов требует очень немного, серьёзный подход к безопасности.

 

Недостатки:

- работает только под *BSD, для Линукса отсутствует,

- не привязать к OSPF, т.к. OpenOSPFD глючит, а с Кваггой они на одной машине не уживаются,

- версия в портах FreeBSD несвежая,

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

 

Поэтому, если нужен Linux, OSPF или fullview, IMHO надо использовать Quagga.

Edited by Ilya Evseev

Share this post


Link to post
Share on other sites

У вас явно ненормальное поведение зебры. Посмотрите хотя бы ее логи, чем она там таким ресурсоемким занимается.

99.9% что проблемы не в зебре, а в консерватории ;)

 

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

Edited by dsk

Share this post


Link to post
Share on other sites
А вообще фуллвью на серверах доступа это явно лишнее, если уж на то пошло, то влепите второй бордер и заверните исходящий трафик с одного сервера доступа на первый бордер, а с другого на второй. Может получится немножко неоптимально с вашей точки зрения, но жить будет.
А тут совсем плохо - пинг до mail.ru через одного пира 60 мс а через другого 90 мс - покусают пользователи - попривыкали. Мне вот интересно, как решает большой провайдер вещи типа 2 аплинка, например первый - 800 мбит второй 600 мбит. Учитывая, что ВИП-тарифами продано 400 мбит а у остальных "скорость до" в случае аварии одного из аплинков. Нагрузка в пике скажем 1.2 гбит. Если хочется отправить трафик клиента по "правильному" маршруту нужно лепить в бордер и доступ карточки по 10 гбит? Хотя может большие не гоняют трафик через тазики с бсд, но мы пока до джунипера не доросли.
У вас явно ненормальное поведение зебры. Посмотрите хотя бы ее логи, чем она там таким ресурсоемким занимается.
ИНтерфейсы пересчитывает при подъеме опускании рррое, откровенного криминала не видно. Да и машина совсем стандартная 7.2-RELEASE, из ядра убраны лишние драйвера scsi и сетевушек и ipv6.

Share this post


Link to post
Share on other sites

Очень странно. Выгрузил link template - mpd перестал принимать новые подключения, аппетит зебры упал до почти ноля

last pid: 44993;  load averages:  0.89,  1.05,  1.10                                                                                                                                   up 4+20:13:08  12:28:54
244 processes: 6 running, 227 sleeping, 11 waiting
CPU 0:  1.5% user,  0.0% nice, 31.3% system,  0.0% interrupt, 67.2% idle
CPU 1:  2.3% user,  0.0% nice,  4.5% system,  0.8% interrupt, 92.5% idle
CPU 2:  1.5% user,  0.0% nice, 26.9% system,  0.0% interrupt, 71.6% idle
CPU 3:  0.7% user,  0.0% nice,  2.2% system,  0.7% interrupt, 96.3% idle
Mem: 1086M Active, 469M Inact, 318M Wired, 56M Cache, 199M Buf, 70M Free
Swap: 8192M Total, 16K Used, 8192M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root          1 171 ki31     0K     8K CPU3   3  92.5H 100.00% idle: cpu3
   13 root          1 171 ki31     0K     8K RUN    1  91.3H 97.75% idle: cpu1
   14 root          1 171 ki31     0K     8K CPU0   0  84.8H 70.75% idle: cpu0
   12 root          1 171 ki31     0K     8K RUN    2  83.9H 68.16% idle: cpu2
   23 root          1 -68    -     0K     8K CPU2   2  29.7H 36.57% em0 taskq
   24 root          1 -68    -     0K     8K -      0  28.0H 30.76% em1 taskq
1906 root          1  45    0  5456K  4040K select 0 141:07  3.08% natd
   15 root          1 -44    -     0K     8K WAIT   3  86:09  1.86% swi1: net
1876 root          1  44    0 81004K 80452K select 2  88:32  0.00% zebra
1882 root          1  44    0   103M   103M select 0  22:44  0.00% bgpd
1771 bind          7   4    0   690M   570M kqread 3  15:51  0.00% named
   18 root          1  44    -     0K     8K -      1  13:16  0.00% yarrow
   16 root          1 -32    -     0K     8K WAIT   1   8:15  0.00% swi4: clock

Как и показывали ее логи - большая нагрузка при добавлении нового интерфейса. Идеи есть?

Share this post


Link to post
Share on other sites

Фуллвью туда не засовывайте, не место ему на терминирующих туннели серверах, сами ж говорили что без него нормально.

 

А тут совсем плохо - пинг до mail.ru через одного пира 60 мс а через другого 90 мс - покусают пользователи
Ну так это и разруливается на бордере, как раз исходняк можно покоцать как надо на основании фуллвью, со входняком сложнее, тут уже различные инструменты надо применять от коммунити аплинков до анонсирования спецификов.

Вы сначала котлет от мух отделите, пусть бордер бордерит, а терминатор терминирует, и проблема сама умрет.

 

 

 

 

Share this post


Link to post
Share on other sites
Вы сначала котлет от мух отделите, пусть бордер бордерит, а терминатор терминирует, и проблема сама умрет.
Они отдельно. Котлеты в тарелке, мухи в компоте. Хочется мне 2 бордера, на несколько аплинков потому, что подошли к гигабиту суммарно - красиво ведь будет - пару аплинков в первый и пару во второй, и надежно и правильно. Как заставить терминаторов слать трафик по оптимальному пути, не вливая на них фулвью?
Ну так это и разруливается на бордере, как раз исходняк можно покоцать как надо на основании фуллвью, со входняком сложнее, тут уже различные инструменты надо применять от коммунити аплинков до анонсирования спецификов.
Класс, все идеально рулится. А если бордеров два поставить?
Edited by make.kernel

Share this post


Link to post
Share on other sites
Хочется мне 2 бордера, на несколько аплинков потому, что подошли к гигабиту суммарно - красиво ведь будет - пару аплинков в первый и пару во второй, и надежно и правильно. Как заставить терминаторов слать трафик по оптимальному пути, не вливая на них фулвью?
http://forum.nag.ru/forum/index.php?showto...mp;#entry422782

примерно то же обсуждалось, но красивого решения так и не видно...

Share this post


Link to post
Share on other sites

На одном терминаторе дефолт на один бордер, на другом на другой. Между всеми терминаторами и бордерами поднять сессии чтоб все это хозяйство резервировалось и т.п. Распедалится примерно поровну в вашем случае. Особо критичные префиксы, на которые жадуются юзеры, выпускайте в эту конструкцию в явном виде, фуллвью тут на терминаторах не нужен.

Share this post


Link to post
Share on other sites

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

 

И всетаки, как-то это большие провайдеры делают, а?

Share this post


Link to post
Share on other sites
Скорее всего кину между бордерами веревку отдельную,
достаточно влана.

 

Share this post


Link to post
Share on other sites

У совсем больших или не очень, но богатых, на бордере стоит что-то тяжеловесное, да и не менее тяжеловесное ядро.

Энономисты, рационализаторы и те кто поменьше рулят тазиками :) Вон Jab уже неоднократно описывал структуру своей сети, и в принципе там ничего нового нет.

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

Share this post


Link to post
Share on other sites

Пойду у директора просить джуниперы :) Ага. И пару магистралей с гигабита на 10 перевести.

Он пока будет в шоке согласится хоть аплинки к одинаковой скорости подтянуть, ато все хорошо, но 1 в два раза быстрее, фиг разложишь нормально. Вообщем ясно, перелив трафика между бордерами в best path наше все.

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