Перейти к содержимому
Калькуляторы

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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, на нем и считаются таблицы для каждой железки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

 

Недостатки:

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

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

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

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

 

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

Изменено пользователем Ilya Evseev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Изменено пользователем dsk

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Очень странно. Выгрузил 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скорее всего кину между бордерами веревку отдельную,
достаточно влана.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.