LINUX.ORG.RU

сравнительное тестирование linux/*bsd в качестве маршрутизатора


0

0

Mike Tancsa сравнил производительность linux/*bsd в качестве маршрутизатора и опубликовал результаты в рассылке freebsd-net.

http://article.gmane.org/gmane.os.fre...

PS: читать стоит всю дискуссию.
PPS: openbsd показала худшие результаты, что не является неожиданностью.

>>> Подробности

anonymous

Проверено: anonymous_incognito ()

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

> это СТАРАЯ проблема из-за криворукости интеловских программеров.

Угу. Причем программеры интел как-то странно криворуки. Для Linux у них идеальный драйвер, один из лучших. А вот когда они садятся писать драйвер под бздню, руки как-то сами искривляются?

dmesg
()
Ответ на: комментарий от anonymous

> ну так 4.11 уже не поддерживается, блин ей уже почти 2 года!

А что, бздуны не поддерживают системы после двух лет??? Фууу, что за дерьмо? Точно какая-то недосистема... Возьмите любой RedHat, там официальная поддержка 7 лет, и потом поддержка от community :)

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

> Ну написал же dmesg... Ты 400м как делаешь ? Пакетами по 1500B или по

> 30 ?

Вот именно. Очень хочется посмотреть, как себя поведет фря на этих 400 мегабитах, когда:

1. Там будет Nat 2. Там будут анлимные тарифные планы и пара-тройка тысяч человек запустит eMule в 200-300 потоков :)

dmesg
()
Ответ на: комментарий от anonymous

> Кривые поделия типа zebra/quagga не предлагать.

Zebra разруливает как внешний пул IP адресов (мы являемся LIR'ом и имеем свою AS), более того Zebra разруливает внутрисетевой локальный траффик, и 14 маршрутизаторов находятся в OSPF домене и обмениваются маршрутами внутрисетевых подсетей. В течении 4 лет сначала с Quagga а потом с Zebra проблем не было _никаких_ _никогда_. Вообще. Так что выпрямляйте руки :)

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

>> Ну написал же dmesg... Ты 400м как делаешь ? Пакетами по 1500B или по >> 30 ?

>Вот именно. Очень хочется посмотреть, как себя поведет фря на этих 400 мегабитах, когда:

>1. Там будет Nat 2. Там будут анлимные тарифные планы и пара-тройка тысяч человек запустит eMule в 200-300 потоков :)

очень спокойно. У меня емульщики и 5к соединений осиливают, в таблице НАТа до 7-8к сессий открытых. 95% idle, учитывая, что работает ipcad в юзерленде. Таких юзеров из 1к около 30. Всё в шоколаде. :) Но, конечно же, не 400мбит, но всё же :)

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

>Пример, как фанатик-линуксоид может нат криво настроить, покажите пожалуйста.

Вам виднее, ведь это ваши данные о 100% загруженности cisco.

>> Магистральные каналы от 2 до 100 мегабит - по десятку интерфейсов на каждом узле. >Ничего не дает. Важен трафик.

Внутрисетевой трафик никто не считает - приоритезация видео,телефония,корпоративный и инет. Загруженность каналов 60-90%.

>Может ли циска объединять разноскоростные разнотипные каналы с разными интерфейсам в один? Как?

Не знаю, не пробовал за ненадобностью. "разноскоростные разнотипные каналы", к примеру радиорелейка (поток е1) используется как основной и, к примеру спутник (256кбит) используется как резервный в случае падения основного, ибо гонять траф через спутник дороговато.

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

> Кстати, вопрос ради информации (раз уж о магистральных каналах заговорили):
> Может ли циска объединять разноскоростные разнотипные каналы
с разными интерфейсам в один? Как?

Между двумя маршрутизаторами ? Да, практически, кто хочешь может, не только Циска. Читать про ECMP.

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

> Как сосет сиска почитать можно здесь: http://www.linux.org.ru/view-message.jsp?msgid=1588771

Ага, да-да. Я верю. :-)

Сосать, кстати, может, и сосёт. Но всё зависит от того, какая она, в какой она конфигурации и с чем её сравнивают.


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

не _писти_ !
red hat 7.3 чуть больше 3 лет, а он уже не поддерживается, читать рассылки надо, красноглазый 8)

anonymous
()
Ответ на: комментарий от dmesg

Для NAT у Cisco есть PIX/ASA Firewall throughput up to 1200Mbps

Естественно модельку надо подбирать под нагрузку

Маршрутизаторы должны маршрутизировать, firewall -- фильтровать.

anonymous
()
Ответ на: комментарий от dmesg

> В течении 4 лет сначала с Quagga а потом с Zebra проблем не было _никаких_ _никогда_. Вообще.

Хм. А почему с Куаги на Зебру, а не наоборот ? И каков принцип борьбы с размером лога Зебры, кстати ?

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

> Внутрисетевой трафик никто не считает - приоритезация видео,телефония,корпоративный и инет. Загруженность каналов 60-90%.

НАТа нет - мимо.
А при такой инсталляции 30% - это очень много.

> используется как резервный в случае падения основного

Я спрашивал не про резервирование, а про объединентие.
Резервирование делается даже на оффтопике - ничего достойного.

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

Извините, но это вам про ECMP читать надо.
Он работает не на уровне пакетов, а на уровне соединений. И служит совсем другим целям. Не будем говорить уж об ограничениях.

Вопрос был про объединение нескольких разных каналов в один.
То есть задача состоит в получении одного "физического" канала из разнотипных.

anonymous
()
Ответ на: комментарий от dmesg

>> это СТАРАЯ проблема из-за криворукости интеловских программеров.

> Угу. Причем программеры интел как-то странно криворуки. Для Linux у > них идеальный драйвер, один из лучших. А вот когда они садятся писать > драйвер под бздню, руки как-то сами искривляются?

Обьясняю. Изначально драйвер написали и отладили для Линукс. Потом его минимально переписали, чтобы он завелся под FreeBSD. Теперь суть проблемы понятна?

puxpux
()
Ответ на: комментарий от Troop

>> У меня вот только 2.6, а у них уже 2.18...

> The LINUX kernel was 2.6.18.2 on FC5. Ну, опечатались люди ^_^

Так сильно спешили запостить свою провокацию?

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

> Извините, но это вам про ECMP читать надо.

Где ? :-)

> Он работает не на уровне пакетов, а на уровне соединений. И служит
> совсем другим целям. Не будем говорить уж об ограничениях.

Почитайте документацию, скажем, на BayRS... Можно на JunOS. В последней, кстати, от версии зависит. Раньше было попакетно, теперь на уровне потока, решили, что так лучше. Как у Cisco, честно говоря, не интересовался.

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

> Вопрос был про объединение нескольких разных каналов в один.

Для передачи трафика без, собственно, вникания как и с некоторой балансировкой нагрузки - ECMP

> То есть задача состоит в получении одного "физического" канала из разнотипных.

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

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

> SuSE рулит, ясно даже и без тестов.

А теперь, в дружбе с M$, ещё сильнее рулить станет.

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

> Можно на JunOS. В последней, кстати, от версии зависит. Раньше было попакетно, теперь на уровне потока, решили, что так лучше.

Точнее, это от версии процессора в FEB завит IP1, или IP2.

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

> RELENG_4 Polling FastWD победила! и ещё 4ку хотят прикрыть! 6ку не сделали нормально, до ума не довели, 4ка рвёт в клочья все остальные оси. кто из кодеров, объясните, что такого в 5ке и 6ке наломали, что понизили производительность системы так сильно, что выровнять до сих пор не могут?

Захотели SMP нормально сделать. Если в 4-ке используется один lock (в простонародье известный как Giant), то в 5-ке и далее имеем кучу маленьких lock-ов, каждый из которых блокирует только определённую подсистему. Поскольку такие крупные изменения вносились независимо большим количеством людей, то

1. Кое-где перестраховываются и лочат некоторые вещи по несколько раз.

2. Появились целые дополнительные уровни абстракции чтобы долго не думать как сделать правильно.

В 5-ке в основном распараллеливали сеть, а в 6-ке -- vfs.

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

> Для передачи трафика без, собственно, вникания как и с некоторой балансировкой нагрузки - ECMP

Не будет работать.
Пример: одно TCP соединение.

> 1. Зачем ?

Оператор не может предоставить один широкий канал,
например, 5M.
Но можно взять 3 по 2M.
Причем два - у одного оператора,
один - у другого.
Каналы разной конфигурации.

> 2. Ваши предложения ?

Вообще-то был вопрос: см. пост от 04.12.2006 10:31:25
Если нужно предложение, то надо использовать Linux.

> 3. А как этот канал виртуальный работать будет, если один из физических отвалится ?

В Linux'е - как угодно.

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

> AFAIK, ipfw и pf - просто конфигурялки к одному и тому же ядерному фильтру (ну юзерспейс NAT разный - это маловажно, если речь о чистом роутинге)... разницы по большому счету быть не должно.

В лужах и без вас метана хватает. Учите матчасть.

ЗЫЖ Userspace NAT в pf -- это пять.

anonymous
()

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

anonymous
()
Ответ на: комментарий от Stalwart

счетчик трафика это fprobe он сильно не тормозит, думаю это шейпер тормозит так dummynet

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

> А что он не софтом управляется? В нём наверное на микрухах фильтры для трафика построены?

Представьте себе. ACL в цисках именно такие.

anonymous
()
Ответ на: комментарий от dmesg

> P.S. Что только с бздней не делали, как только её не тюнили - 150 тысяч пакетов в секунду - это предел для неё (на em интерфейсах, на остальных - и того меньше), хоть тресни. Что ни говори - а бздня - это система даже не вчерашнего, а позавчерашнего дня.

Вы просто не умеете её готовить. 1mpps в секунду -- далеко не предел. Смотрите в сторону fast_fwd хотя бы

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

> Интересно а можно ли в линухе кластерный роутер-файрволл сделать чтобы нагрузку распределять?

Можно, но для крупных сетей неприменимо. Смотрите в сторону аппаратных решений или на худой конец -- *BSD

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

ACL у них просто не влезает ;)
Там пакетики только аппаратно переформируются,
а обработка acl все-равно в софте.
Остальное читайте в сископресс.

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

> Можно, но для крупных сетей неприменимо. Смотрите в сторону аппаратных решений или на худой конец -- *BSD

Кластер на BSD?! Не, этого анекдота я не переживу...

annoynimous ★★★★★
()

Собственно СвободнуюБСД убили в 5,6 ветках. Закрытие 4ой станет просто самоубийством(даже может быть оно и осознанное).

ОткрытаяБСД написанная параноиками естественно не могла победить, потому что авторы пишут её на постоянных "хакерских вечеринках"(проще говоря пьянках), причем сперто это опять-таки у Сетевиков(те кто пишут СетевуюБСД), как и сама ОС.

Одни линуксойды пишут ОС :-)

Metallic
()
Ответ на: комментарий от anonymous

> Смотрю сейчас на все свои core-маршрутизаторы (преимущественно 36хх) - загрузка 10-30%. Магистральные каналы от 2 до 100 мегабит - по десятку интерфейсов на каждом узле.

мда. core на 36xx это прошлый век. магистраль на 2 мбит - мне осталось только спрятаться.

36xx только и годны, чтобы 2-3мя двойками рулить, дашь им мегабит 10-15 мелкими пакетами (voip, tdmoip) - и пипец, 100% cpu load. и упаси боже нат включить, сдохнет ваще.

marten
()
Ответ на: комментарий от anonymous

>> Для передачи трафика без, собственно, вникания как и с некоторой балансировкой нагрузки - ECMP

> Не будет работать.
> Пример: одно TCP соединение.

Ой 8-(). (побежал выключать, а то лет пять не работает уже :-) ).

> Оператор не может предоставить один широкий канал, например, 5M.
> Но можно взять 3 по 2M. Причем два - у одного оператора, один - у
> другого. Каналы разной конфигурации.

Но, в конечном итоге, между двумя собственными роутерами имеется N прямых каналов ? Так ?

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

> > 2. Ваши предложения ?

> Если нужно предложение, то надо использовать Linux.

Про это, кстати, я догадался. ;-) А вот более конкретно ?

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

>В лужах и без вас метана хватает. Учите матчасть.

[quote Р. Смит, Полный справочник по FreeBSD] Фильтрацию пакетов выполняет ядро FreeBSD, поскольку обработка пакетов на таком низком уровне - прерогатива ядра. Таким образом, утилиты фильтрации пакетов являются всего лишь интерфейсами: они сообщают ядру о том, что следует делать с пакетами, которые удовлетворяют определенным критериям. Наиболее распространены 2 утилиты: - ipfw ...

- IP Filter ...

>ЗЫЖ Userspace NAT в pf -- это пять.

Программы ipfw и IP Filter содержат средства настройки NAT. В первом случае соответствующая утилита называется natd, во втором - ipnat. [/quote]

Наверное, я жестоко обманут камрадом Р. Смитом. Ну и пох, ибо аццки ненавижу и бздю и ярых бздунов, особенно тех, кто отправляет учить малознакомую им "матчасть".

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

>>
Программы ipfw и IP Filter содержат средства настройки NAT. В первом случае соответствующая утилита называется natd, во втором - ipnat.
<<

да, сынок, ты опять пролетел =))

IP Filter и pf - это разные вещи (как в анекдоте про чукчей и К.Маркса и Ф.Энгельса)

pf пришел с OpenBSD

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

>>при 400000 пакетов, ядро Linux + NAPI генерит всего 7 прерываний в секунду

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

Она не дергает прерывание, т.к. соответствующий бит в регистре карточки во время NAPI polling замаскирован, в это время dev->poll() читает дескрипторы и обрабатывает пакеты без прерываний.

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

Информация г-на Смита относится к 4-й ветке, а с тех пор очень много воды утекло. Сейчас в сетевом стеке существует ровно 3 хука, на которые файервол должен зацепить свои обработчики. Это к вашей реплике по поводу того, что ipfw и pf -- это разные интерфейсы к одним и тем же функциям ядра.

ipfw действительно использует natd для NAT-а, а в pf NAT зашит внутри файервола.

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

> red hat 7.3 чуть больше 3 лет, а он уже не поддерживается

Дятел, ты вкорне неправ :-)

Во-первых на, лови обновления для RH 7.3: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/

Из недавних - обновление php, sendmail, apache.

Во-вторых, в начале 2007 года релизу RedHat 7.3 будет 5 (пять) лет.

Так что перед тем, как пукнуть в лужу, для начала хотябы бегло изучи предмет спора :-)

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

> Хм. А почему с Куаги на Зебру, а не наоборот ?

Бррр, конечно же наоборот. Когда зебра изменила лицензию и её форкнули в кваггу, мы перешли на кваггу. Это я спросоня ошибся :) С размером логов проблем нет, logrotate ротейтит, а разве с этим когда-нибудь были трудности?

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

> Ой 8-(). (побежал выключать, а то лет пять не работает уже :-) ).

Одно TCP соединение занимает уже 5 лет один из каналов? ;)

> Но, в конечном итоге, между двумя собственными роутерами имеется N прямых каналов ? Так ?

Нет. Один.

anonymous
()
Ответ на: комментарий от puxpux

> Обьясняю. Изначально драйвер написали и отладили для Линукс. Потом его

> минимально переписали, чтобы он завелся под FreeBSD. Теперь суть

> проблемы понятна?

Мне это абсолютно неинтересно. Мне, как конечному пользователю (инженеру отдела IT провайдера) совершенно неинтересны половые трудности разработчиков BSD и их проблемы с драйверами. Мне чхать на то, кто там и подо что писал изначальнр и что потом подо что отлаживал. Мне нужно готовое проверенное решение. BSD на роль маршрутизатора не годится, если сравнивать с Linux. В офисе, где небольшие нагрузки - может быть. Мелкой домашней сетке на 100-1000 юзеров - может быть. Но на этом юрисдикция этой прогнившей и полуразложившейся в недоразвитом состоянии системы заканчивается. Где мало-мальски серьезные нагрузки и где нужны enterprise класса решения, Linux (серверы и рабочие станции) и Windows (рабочие станции). Всё остальное - удел фанатиков одиночек. Мне надо работать, извините, а не читать девелоперские рассылки и постоянно что-то компилить. С этим к нуубам.

dmesg
()
Ответ на: комментарий от anonymous

> Интересно а можно ли в линухе кластерный роутер-файрволл сделать

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

Можно и НУЖНО. Читайте про Linux + ucarp. Мало того, что нагрузка делится между гейтами, так если ещё и один из гейтов падает (питание, проблема с железом или каналами), его работу на себя берут другие гейты.

dmesg
()
Ответ на: комментарий от anonymous

> google://HSRP
> google://VRRP

Уже почитал.
Мимо - нет нормальной (или вообще нет) балансировки нагрузок.

> google://CARP

Может быть - но изначально для failover.

> Ибо зело убога реализация в Линуксе.

Уже нашел описания - отзывы отличные.
google:// linux balance router firewall


anonymous
()
Ответ на: комментарий от dmesg

Расскажите, пожалуйста, каким образом нагрузка на роутинг и файрволл распределяется?
Мне показалось, что это HA решение больше.

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

> Смотрите в сторону fast_fwd хотя бы

Фаст форвардинг был включен в первую очередь. Без него совсем грустно. Даже по советам Глеба Смирнова в нужных местах задирали размер буфферов в драйвере em. Нет, не прет. Полтора года мудохались. Перепробовали _всё_. BSD уступает и уступает _значительно_ Linux'у в сетевых делах (о другом пока не сужу, т.к. последние 5 лет очень плотно работаю сетевым администратором. остальное - второстепенно).

dmesg
()
Ответ на: комментарий от anonymous

>> Можно

> Как?

linux + ucarp. Ни в коем случае не берите xBSD. Потратите кучу времени и нервов. Как тут уже выше писали: кластер из BSD - это анекдот. Шутка такая :)

dmesg
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.