make.kernel Опубликовано 20 августа, 2009 · Жалоба Интересует сравнение с точки зрения потребления ресурсов (проц, память) и надежности. Сейчас стоит бордер на 3 аплинка - он-же раут-сервер и несколько серверов доступа. Задача стоит сделать 2 бордера и разнести аплинки, боюсь без фул-вью на доступе не получится чтобы оптимально трафик бегал. Попробовал на один из серверов доступа вылить фул-вью - процесс zebra сожрал одно ядро коре квада и просит еще. Может я копаю не туда? Джунипер и циски не предлагайте пжалста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dyer Опубликовано 21 августа, 2009 · Жалоба находил где-то сравнение: xorp > quagga > openbgpd, т.е. последний - наименее требовательный а не проще ли просто в один выделенный бордер аплинков завести. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 21 августа, 2009 · Жалоба что-то явно не так. quagga на pentium-D ( :) ) 2FV+IXы. load average: 0.12, 0.19, 0.10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 21 августа, 2009 · Жалоба а не проще ли просто в один выделенный бордер аплинков завести.Сейчас так и есть, пока можно на одном бордере и летим, однако пол-гигабита в пике перешагнули и растем, боюсь я за него. что-то явно не так.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, на нем и считаются таблицы для каждой железки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 21 августа, 2009 (изменено) · Жалоба У меня используются и Quagga и OpenBGPD, но без fullview. Преимущества OpenBGPD: - настройки гораздо короче и понятнее, потому что он не старается походить на Циску, - есть директива "fib-update no", позволяющая не вливать полученные маршруты в систему, - ресурсов требует очень немного, серьёзный подход к безопасности. Недостатки: - работает только под *BSD, для Линукса отсутствует, - не привязать к OSPF, т.к. OpenOSPFD глючит, а с Кваггой они на одной машине не уживаются, - версия в портах FreeBSD несвежая, - был серьёзный глюк, когда один из провайдеров стал по ошибке присылать нам fullview - сессия с ним сбрасывалась сразу же после установки. Поэтому, если нужен Linux, OSPF или fullview, IMHO надо использовать Quagga. Изменено 21 августа, 2009 пользователем Ilya Evseev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 21 августа, 2009 (изменено) · Жалоба У вас явно ненормальное поведение зебры. Посмотрите хотя бы ее логи, чем она там таким ресурсоемким занимается. 99.9% что проблемы не в зебре, а в консерватории ;) А вообще фуллвью на серверах доступа это явно лишнее, если уж на то пошло, то влепите второй бордер и заверните исходящий трафик с одного сервера доступа на первый бордер, а с другого на второй. Может получится немножко неоптимально с вашей точки зрения, но жить будет. Изменено 21 августа, 2009 пользователем dsk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 24 августа, 2009 · Жалоба А вообще фуллвью на серверах доступа это явно лишнее, если уж на то пошло, то влепите второй бордер и заверните исходящий трафик с одного сервера доступа на первый бордер, а с другого на второй. Может получится немножко неоптимально с вашей точки зрения, но жить будет.А тут совсем плохо - пинг до mail.ru через одного пира 60 мс а через другого 90 мс - покусают пользователи - попривыкали. Мне вот интересно, как решает большой провайдер вещи типа 2 аплинка, например первый - 800 мбит второй 600 мбит. Учитывая, что ВИП-тарифами продано 400 мбит а у остальных "скорость до" в случае аварии одного из аплинков. Нагрузка в пике скажем 1.2 гбит. Если хочется отправить трафик клиента по "правильному" маршруту нужно лепить в бордер и доступ карточки по 10 гбит? Хотя может большие не гоняют трафик через тазики с бсд, но мы пока до джунипера не доросли.У вас явно ненормальное поведение зебры. Посмотрите хотя бы ее логи, чем она там таким ресурсоемким занимается.ИНтерфейсы пересчитывает при подъеме опускании рррое, откровенного криминала не видно. Да и машина совсем стандартная 7.2-RELEASE, из ядра убраны лишние драйвера scsi и сетевушек и ipv6. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 24 августа, 2009 · Жалоба Очень странно. Выгрузил 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 Как и показывали ее логи - большая нагрузка при добавлении нового интерфейса. Идеи есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 24 августа, 2009 · Жалоба Фуллвью туда не засовывайте, не место ему на терминирующих туннели серверах, сами ж говорили что без него нормально. А тут совсем плохо - пинг до mail.ru через одного пира 60 мс а через другого 90 мс - покусают пользователиНу так это и разруливается на бордере, как раз исходняк можно покоцать как надо на основании фуллвью, со входняком сложнее, тут уже различные инструменты надо применять от коммунити аплинков до анонсирования спецификов.Вы сначала котлет от мух отделите, пусть бордер бордерит, а терминатор терминирует, и проблема сама умрет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 25 августа, 2009 (изменено) · Жалоба Вы сначала котлет от мух отделите, пусть бордер бордерит, а терминатор терминирует, и проблема сама умрет.Они отдельно. Котлеты в тарелке, мухи в компоте. Хочется мне 2 бордера, на несколько аплинков потому, что подошли к гигабиту суммарно - красиво ведь будет - пару аплинков в первый и пару во второй, и надежно и правильно. Как заставить терминаторов слать трафик по оптимальному пути, не вливая на них фулвью?Ну так это и разруливается на бордере, как раз исходняк можно покоцать как надо на основании фуллвью, со входняком сложнее, тут уже различные инструменты надо применять от коммунити аплинков до анонсирования спецификов.Класс, все идеально рулится. А если бордеров два поставить? Изменено 25 августа, 2009 пользователем make.kernel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 25 августа, 2009 · Жалоба Хочется мне 2 бордера, на несколько аплинков потому, что подошли к гигабиту суммарно - красиво ведь будет - пару аплинков в первый и пару во второй, и надежно и правильно. Как заставить терминаторов слать трафик по оптимальному пути, не вливая на них фулвью? http://forum.nag.ru/forum/index.php?showto...mp;#entry422782примерно то же обсуждалось, но красивого решения так и не видно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 25 августа, 2009 · Жалоба На одном терминаторе дефолт на один бордер, на другом на другой. Между всеми терминаторами и бордерами поднять сессии чтоб все это хозяйство резервировалось и т.п. Распедалится примерно поровну в вашем случае. Особо критичные префиксы, на которые жадуются юзеры, выпускайте в эту конструкцию в явном виде, фуллвью тут на терминаторах не нужен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 25 августа, 2009 · Жалоба Спасибо за наводку, но нет идеала в этом мире. Скорее всего кину между бордерами веревку отдельную, они друг другу трафик перельют через нее по best path, не так уж много его будет, который действительно ровнять нужно. Плохо конечно - есть возможность их географически по сети разнести поближе ко входам от аплинков, но при такой схеме смысла нету. И всетаки, как-то это большие провайдеры делают, а? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 25 августа, 2009 · Жалоба Скорее всего кину между бордерами веревку отдельную,достаточно влана. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 25 августа, 2009 · Жалоба У совсем больших или не очень, но богатых, на бордере стоит что-то тяжеловесное, да и не менее тяжеловесное ядро. Энономисты, рационализаторы и те кто поменьше рулят тазиками :) Вон Jab уже неоднократно описывал структуру своей сети, и в принципе там ничего нового нет. Просто судя по всему вы ходите чтоб все бегало ну прям совсем идеально, а так к сожалению не получается ни у кого, всегда будут перекосы, асимметрии и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 25 августа, 2009 · Жалоба Пойду у директора просить джуниперы :) Ага. И пару магистралей с гигабита на 10 перевести. Он пока будет в шоке согласится хоть аплинки к одинаковой скорости подтянуть, ато все хорошо, но 1 в два раза быстрее, фиг разложишь нормально. Вообщем ясно, перелив трафика между бордерами в best path наше все. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...