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

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

Линуксовый ядерный CAPR (ссылки выше) также как и ucarp получают информацию о загруженности, помехозащищенности и т.п. каналов, на основании чего изменяется параметры (advertisement skew and base), рассылаемые внутри кластера роутеров, на основании чего может быть выбран новый. Падение роутера это всего лишь частный случай изменения параметров.

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

>>
Полтора года мудохались
<<

вы полтора года мудохались, а мы третий год без проблем, с 1500 выделенками(ADSL) = 20.000 пак в сек - работает нормально

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

> вы полтора года мудохались, а мы третий год без проблем

К чему это заявление? Удачные примеры не интересуют совсем. В нашем конкретном случае с огромными нагрузками BSD не живет.

При чем тут "у меня работает"? Всегда умиляют заявления типа "у меня всё работает, что я делаю не так?"... Да мне в душЕ совершенно всё равно, что у Вас работает. У меня НЕ работает. У меня и 6 моих коллег, которые являются опытными администраторами и не первый год замужем.

У меня есть знакомый, который офис держит до сих пор на Windows98. И маршрутизатор у него WIndows NT4. Седьмой год без проблем. И? Какова ценность Вашей информации? Чего сказать-то хотели?

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

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

Прячься или протяни на >300км оптику в степи. Кроме релеек ОпСоСов ничего нет (2*Е1 обычно). Есть спутник, но это медленно и дорого и юзается как резерв.

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

10mbit - VPN ("мелкие пакетами voip" и видео + куча туннелей) 10mbit инета с , о, боже, NAT'ом! 50mbit оптики с другим ядром сети 100mbit локалки 6 потоков Е1 256+512kbit спутника Загруженность каналов 60-80% ------- CPU-usage ~20% Memory ~40Mb I/O memory ~8.5Mb

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

> Линуксовый ядерный CAPR (ссылки выше) также как и ucarp получают информацию о загруженности, помехозащищенности и т.п. каналов, на основании чего изменяется параметры (advertisement skew and base), рассылаемые внутри кластера роутеров, на основании чего может быть выбран новый. Падение роутера это всего лишь частный случай изменения параметров.

Ох уж это устное народное творчество...

Ядерный CARP является портом *BSD-шного который пока не научился лазить с тестером в сеть :)

ucarp -- userspace поделка, которая вообще недостойна упоминания.

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

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

> Бррр, конечно же наоборот.
<skip>
> logrotate ротейтит, а разве с этим когда-нибудь были трудности?

Зебра слишком много понимает под informational. Суточноый лог может быть в десятках и сотнях Mb. Куага в той же сети рожает где-то в десятках и сотнях Kb. А так да, logrotate ротейтит.

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

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

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

Ага, а второе - другой. :-) А всё остальное - не работает. :-)
И нагрузка вовсе не как запланировано... И не контролирует её никто. ;-)

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

> Нет. Один.

Я имел ввиду "в конечном итоге перед объединением". Думал, что понятно написал. Что совсем в конце один - это понятно.

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

>>> linux + ucarp

>> Вы сами пробовали то что советуете?

> Я с этим работаю ежедневно.

Не расскажете как аналог carp.preempt сделать? А не криво?

ЗЫЖ Проект по ходу вроде закрыт уже. Нет?

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

> В реальных условиях (засранные вирусами венды, торренты, порнуха) фря работает, а линух тихо умирает

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

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

>> Линуксовый ядерный CAPR (ссылки выше) также как и ucarp получают информацию о загруженности, помехозащищенности и т.п. каналов, на основании чего изменяется параметры (advertisement skew and base), рассылаемые внутри кластера роутеров, на основании чего может быть выбран новый. Падение роутера это всего лишь частный случай изменения параметров.

>Ох уж это устное народное творчество...

>Ядерный CARP является портом *BSD-шного который пока не научился лазить с тестером в сеть :)

В том-то и дело, что это только в BSD нужно лазить с тестеров в сеть, в Linux для этого драйверы соответствующих железок, привязанные к статистике tc/iptables/drivers/anything, на основании которой выбираются параметры того или иного master router. Кстати, хотя CARP для Linux _не_ яввляется портом *BSD CARP, хотя идея одна и та же, но протокол различный - в Linux CARP введена дополнительная защита.

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

>Не расскажете как аналог carp.preempt сделать? А не криво?

Есть демон, который мониторит master/backup события, и статистику для выбора adv skew/base, он же может (но не знаю, реализовано это или нет) при отключении интерфейса менять adv skew/base для всех остальных виртуальных устройств (aka vhid).

>ЗЫЖ Проект по ходу вроде закрыт уже. Нет?

ucarp? Сейчас сайт не открывается, может быть временные проблемы?

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

>> Ядерный CARP является портом *BSD-шного который пока не научился лазить с тестером в сеть :)

> В том-то и дело, что это только в BSD нужно лазить с тестеров в сеть, в Linux для этого драйверы соответствующих железок, привязанные к статистике tc/iptables/drivers/anything, на основании которой выбираются параметры того или иного master router. Кстати, хотя CARP для Linux _не_ яввляется портом *BSD CARP, хотя идея одна и та же, но протокол различный - в Linux CARP введена дополнительная защита.

Интересно, мы про один и тот же CARP говорим? http://tservice.net.ru/~s0mbre/old/?section=projects&item=carp

Каким это образом драйверы завязываются, скажем, с tc? А с anything? :)

Я согласен, что adv_base и adv_skew теоретически можно менять автоматом на лету. Правда, не совсем красиво получается: человек же наверное о чём-то думал когда именно с такими настройками поднимал. Но каким образом нагрузка на сеть в одном броадкасте с точки зрения разных хостов может быть разной до меня совсем никак не доходит...

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

>> Не расскажете как аналог carp.preempt сделать? А не криво?

> Есть демон, который мониторит master/backup события, и статистику для выбора adv skew/base, он же может (но не знаю, реализовано это или нет) при отключении интерфейса менять adv skew/base для всех остальных виртуальных устройств (aka vhid).

В том-то и дело, что этот демон надо писать самостоятельно :)

Насчёт статистики -- no comments

>> ЗЫЖ Проект по ходу вроде закрыт уже. Нет?

> ucarp? Сейчас сайт не открывается, может быть временные проблемы?

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

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

> Я имел ввиду "в конечном итоге перед объединением". Думал, что понятно написал. Что совсем в конце один - это понятно.

До объединения - несколько.
После объединения - один.
Так понятно? :)

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

>> В том-то и дело, что это только в BSD нужно лазить с тестеров в сеть, в Linux для этого драйверы соответствующих железок, привязанные к статистике tc/iptables/drivers/anything, на основании которой выбираются параметры того или иного master router. Кстати, хотя CARP для Linux _не_ яввляется портом *BSD CARP, хотя идея одна и та же, но протокол различный - в Linux CARP введена дополнительная защита.

>Интересно, мы про один и тот же CARP говорим? http://tservice.net.ru/~s0mbre/old/?section=projects&item=carp

>Каким это образом драйверы завязываются, скажем, с tc? А с anything? :)

carp всего лишь низкоуровневый протокл, который показывает общее состояние данного хоста через adv base/skew другим заинтересованным участникам. Например когда один из каналов отключается (провайдер отключил или аппаратные проблемы), соответствующая статистика (хоть из cron, хоть из демона, привязанного к драйверу оборудования, поддерживающего канал - ведь не только ethernet используется) принимается во внимание и используется для изменения параметров.

>Я согласен, что adv_base и adv_skew теоретически можно менять автоматом на лету. Правда, не совсем красиво получается: человек же наверное о чём-то думал когда именно с такими настройками поднимал. Но каким образом нагрузка на сеть в одном броадкасте с точки зрения разных хостов может быть разной до меня совсем никак не доходит...

Их и _нужно_ менять на лету - при старте администратор выставляет параметры, актуальные на _текущий_ момент. Позже они могут измениться, что отразится в изменении adv base/skew.

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

>> Есть демон, который мониторит master/backup события, и статистику для выбора adv skew/base, он же может (но не знаю, реализовано это или нет) при отключении интерфейса менять adv skew/base для всех остальных виртуальных устройств (aka vhid).

>В том-то и дело, что этот демон надо писать самостоятельно :)

Таков подход - carp становится лишь низкоуровневой средой передачи текущего статуса хоста, он не должен и ему не надо лезть в глубокие внутренности работы сетевого стека, чтобы получить текущую пропускную способность, особенно если в системе используются тяжелые traffic control/netfilter rules.

>Насчёт статистики -- no comments

>>> ЗЫЖ Проект по ходу вроде закрыт уже. Нет?

>> ucarp? Сейчас сайт не открывается, может быть временные проблемы?

>Я вроде слышал, что его забросили после того как ядерный стал более-менее сносно работать. Могу и ошибаться, конечно.

Ничего по этому поводу не могу сказать.

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

> До объединения - несколько.
> После объединения - один.
> Так понятно? :)

Вроде бы. :-)

Да вот, вопрос такой. Эти несколько до обединения между двумя своими роутерами ? А то смутило упоминание второго канального (?) провайдера.

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

Мы друг друга не поняли :)
Имелись в виду выделенные каналы точка-точка.
Поэтому я и сказал, что ECMP - не то.
Кстати, и через маршрутизируемые сети
можно сделать балансировку так,
что в итоге появится один канал.
Все для этого есть в ядре.

О, а ECMP можно использовать по назначению для подканалов - это я правда только что придумал, то есть не пробовал :)

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

> так вот иногда бывает проблематично объяснить клиенту что ему кто-то из инета влил трафик, когда у него был выключен компьютер

А кто мешает зарулить сетку в Null, и не учитывать в netflow записи с этим интерфейсом? Появится пользователь, будет и более специфичный маршрут -- посчитается трафик.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

И сколько должно быть маршрутов? Давным давно в одной домашей сетке было такое чудо - Rip+pptp - на каждый поднятый тунель - rip update c маршрутом... при 2000 клентах - все это пипец как работало - без слез не взглянешь...

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

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

Жаль только Rambler не об этом знает... И весь их поток прекрастно FreeBSD разруливают.. Может таки в консерватории что-то не так?

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

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

=== не 7, а 5. Врать то не надо. Кроме того - забыли ситуацию когда от поддержки RH 9 просто отказались, а поддержку RH 7/8 свернули до 1 года? У мисье что-то не так с памятью?

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

> === не 7, а 5. Врать то не надо.

Блин, народ, ещё раз повторюсь. Ну изучите же вы вопрос, по которому пытаетесь спорить. Ну ведь пердите же в лужу. Или пи*деть - не мешки ворочить?

http://www.redhat.com/rhel/migrate/whichlinux/

Update lifetime Seven years

> Кроме того - забыли ситуацию когда от поддержки RH 9 просто

> отказались, а поддержку RH 7/8 свернули до 1 года?

Ещё раз повторюсь. Ну изучите же вы вопрос, по которому пытаетесь спорить. Ну ведь пердите же в лужу.

http://fedoralegacy.org/

RedHat 7.3 до сих пор поддерживается и будет ещё и дальше поддерживаться. А этому дистрибутиву почти 5 лет.

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

> Жаль только Rambler не об этом знает... И весь их поток прекрастно

> FreeBSD разруливают..

Давно рамблер стал интернет-провайдером, который обслуживает десятки тысяч клиентов, предоставляя им интернет по гигабитным каналам? Бредятину-то не надо нести. А разлуливать миллион http запросов с полудохлых диалапщиков и быть посредственным хостером даже зенон с Windows2000 может не напрягаясь. Нашли чем удивить... http траффик они разруливают. Не позорились бы.

P.S. Рамблеру всю жизнь быть вторым, и смотреть в спину яндексу. Судьба у рамблера такая.

P.P.S. Догадываетесь какая ось юзается яндексом? Подсказать, или сами догадаетесь? :-)

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

> P.P.S. Догадываетесь какая ось юзается яндексом? Подсказать, или сами догадаетесь? :-)

FreeBSD, а что? Linux тоже есть; для Oracle вроде.

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

На киске запускаем ip accounting и при при кол-ве завирусованных машин большем чем 5 киска благополучно клинится да так что зайти на нее даже локально не очень то выходит а зайти надо чтобы посмотреть кто заражен. Сам проверял на catalyst 2821. на 26XX и двоих засранцев достаточно. Не годится киска в роли пограничного маршрутизатора если при этом надоть еще и траф считать. Софт рутер хоть и догружаетс проц до 80-90 % но тем не менее держит не один десяток завирусованных машин и зайти всегда можно. Да и научить его душить таких деятелей можно на автомате а киску никак тупа она и проц у нее хилый..

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

lol
парень, чето ты завелся с полоборота, как будто что-то кому то доказывать обязан

а твои оскорбления и визгливые выкрики - признаки неуверенности

ps юзают все то что работает без сбоев на месте, а то что у кого-то не работает меня вообще не трогает

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

:) рассмешил, Catalyst 2821 бу-га-га, QoS и netflow, в догонку control-plan ... да ... bsd все же удобнее и гимора с ней меньше

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

Мальчик не любит кошек? Да он просто не умеет их готовить!

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

Человек, сисководам никогда не докажешь, что сиски их сосут,
потому что они кучу денег потратили и остались в ж. У них даже ситуаций нормальных не бывает, потому что сиски свои берегут, дорогие они.
Когда же их просишь показать систему _полностью_, а не количество там подвисших сессий, то они хлюпать носом начинают.

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

> И сколько должно быть маршрутов?

Динамических? В идеале -- 0 (ноль, зеро).

> Давным давно в одной домашей сетке было такое чудо - Rip+pptp - на каждый поднятый тунель - rip update c маршрутом...

И вот нахера, спрашивается? Во-первых, снимай netflow с самого NAS; во-вторых, ip route <client-network> Null0 254 на нём; в-третьих, ppp тоннели он видит директом.

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

Timeline Full Support - 2.5 yrs Deployment - 3 yrs Maintenance - 7 yrs

Phase 1: Full Support Start Date: General Availability End Date: 2.5 Years from General Availability date Description: During the Full Support phase, new hardware support will be provided at the discretion of Red Hat via Updates, Additionally, all available and qualified errata will be applied to the Enterprise products via Updates (or as required for Security level errata.) And finally, updated ISO images will only be provided during Phase 1: Full Support. Phase 2: Deployment Start Date: 2.5 years from General Availability (end of Full Support) End Date: 3 Years from General Availability date Description: During the Deployment phase, all available and qualified security and bug fix errata will be applied to the Enterprise products via Updates. Security Errata will be released as necessary independent an Update. Phase 3: Maintenance Start Date: General Availability End Date: 4 Years from end of Deployment (7 years from General Availability) Description: During the Maintenance phase, only Security errata and select mission critical bug fixes will be released for the Enterprise products.

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

>Ещё раз повторюсь. Ну изучите же вы вопрос, по которому пытаетесь >спорить. Ну ведь пердите же в лужу. >http://fedoralegacy.org/ >RedHat 7.3 до сих пор поддерживается и будет ещё и дальше >поддерживаться. А этому дистрибутиву почти 5 лет.

Он поддерживается RedHat-ом? Если нет (а так оно и есть), то в жопу такую поддержку.

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

> Он поддерживается RedHat-ом?

Да. Он поддерживается ровно теми же людьми, которые разрабатывают Fedora Core!

> Если нет (а так оно и есть)

Ещё раз повторюсь. Ну изучите же вы вопрос, по которому пытаетесь cпорить. Ну ведь пердите же в лужу. :-)

> то в жопу такую поддержку

Ну нельзя же так неприкрыто завидовать :-)

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

>> Догадываетесь какая ось юзается яндексом? Подсказать, или сами

>> догадаетесь? :-)

> FreeBSD, а что? Linux тоже есть; для Oracle вроде.

Только Debian. yandex-mail, yandex-search - Linux only.

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

> а твои оскорбления и визгливые выкрики - признаки неуверенности

Когда мне понадобится консультация доморощеного недопсихоаналитика, я обязательно к тебе обращусь :-)

> ps юзают все то что работает без сбоев на месте, а то что у кого-то не > работает меня вообще не трогает

Ещё раз. То, что у какого-то пионера где-то что-то работает на пяти машинах (фря, венда95 и так далее) - это не интересует совсем. Повторюсь - венда 95 тоже прекрасно работает. Всё зависит от задач. Интересуют _реальные огромные нагрузки_ на которых *BSD как сливала, так и сливает.

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

а чего сырбор :) тестили не оси, а драва под них! + тесты обновили да и разница минимальна стала! причем и + и - так что войны систем да и только!

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

>>Он поддерживается RedHat-ом? >Да. Он поддерживается ровно теми же людьми, которые разрабатывают Fedora Core!

RedHat Inc НЕ ПОДДЕРЖИВАЕТ больше RedHat Linux в т.ч. и RH7.3! Его поддерживают энтузиасты из Fedora Legacy Project http://fedoralegacy.org/about/

The Fedora Legacy Project is a community-supported open source project. It is not a supported project of Red Hat, Inc. although Red Hat, Inc. does provide some support services for it. While Red Hat Enterprise Linux is still supported by Red Hat and has a long support lifetime for all release versions, the same is not true of Red Hat Linux and Fedora Core releases.

Или вы ставите знак равенства между "Fedora Legacy Project is a community-supported open source project" и RedHat Inc?

>Ещё раз повторюсь. Ну изучите же вы вопрос, по которому пытаетесь >cпорить.

Только после вас.

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

>а у нас что на пятерке что на шестерке ~5 мегабит трафика не держит, проц занят на 40-80% интераптами, пулинги включены, карточки dlink гигабитные (помоему 528* модель), не поделитесь секретом?

Насколько я знаю, 528-T сделан на realtek8169. А реалтек есть гуано. Подарите сетевушки конкурентам.

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