[Alex/AT]

вы что в vrf налили full view?

Партиалы, но большие (~10K маршрутов было, если память не изменяет). FV в глобалке. По-хорошему, соотнося размер FIB, 76xx должна уметь и несколько FV в VRF. Но - в теории умеет, на практике - фигвам. У аппаратуры тоже бывают свои нюансы.

Изменено 19 марта, 2012 пользователем Alex/AT

[alks]

мда.... у меня нет rsp а стоит 3bxl - если влить vrf full view тазик сдохнет

mls cef maximum-routes не пробовали крутить?

[s.lobanov]

Никто же не спорит, что RAM, tcam и cpu ограничены на железных роутерах. Вопрос стоял о том, что умеет или не умеет и о fv речи не шло. Не все же задачи ограничиваются хранением отдельных fv в отдельных таблицах, vrf вообще не для этого задуман, если уж на то пошло.

[Alex/AT]

мда.... у меня нет rsp а стоит 3bxl - если влить vrf full view тазик сдохнет

mls cef maximum-routes не пробовали крутить?

Лимиты не превышаются и не превышались, сидим в пределах аппаратных возможностей :)

Подкрутить особо высоко не получится - только в 2 раза, и то если ipv6 порезать, у этой штуки всего 1M маршрутов ipv4 в потолке.

Изменено 19 марта, 2012 пользователем Alex/AT

[Alex/AT]

Никто же не спорит, что RAM, tcam и cpu ограничены на железных роутерах. Вопрос стоял о том, что умеет или не умеет и о fv речи не шло. Не все же задачи ограничиваются хранением отдельных fv в отдельных таблицах, vrf вообще не для этого задуман, если уж на то пошло.

Ну как "не для этого задуман"... Прямое назначение - хранение нескольких таблиц форвардинга. А уж FV там или нет - это десятое, пока за пределы аппаратных возможностей не вылезло. В нашем же случае было грабельнее - оно вроде бы и есть, и в пределах возможностей, но вызывает совершенно эпические глюки.

 

Общий смысл сказанного - гибкость софтовых решений всё-таки выше :) Производительность - ниже. О чем выше и писал, когда приводил набор характеристик.

Изменено 19 марта, 2012 пользователем Alex/AT

[pfexec]

Фичастость заключается в реализации любого функционала, который только пожелаете. Захотелось к примеру получать по бгп несколько вью, при этом анонсить первый вью только бгп-клиентам из влана 5, второй - только бгп-клиентам из влана 10, а третий вообще никуда не анонсить, а пользовать локально - на тазике это элементарно реализовать. На железке, если не заложено - никак.

Захотелось еще форвардить пакеты из влана 5 в один аплинк, а из влана 10 - в другой, которые равноценны, и при падении одного из аплинков пускать всех в другой - опять же элементарно на тазике, на железке - скорее всего никак.

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

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

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

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

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

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

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

А кто говорит только о квагге? Посмотрите на BIRD что ли, для общего развития. IOS что, умеет несколько таблиц маршрутизации различных анонсить, как BIRD?

JunOS умеет всё это делать легко и изящно. а в иосе много что через жопу делается или как-то странно, ну это нормально для вендора ориентированного на ентерпрайз.

Общий смысл сказанного - гибкость софтовых решений всё-таки выше :) Производительность - ниже. О чем выше и писал, когда приводил набор характеристик.

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

[alex_001]

Кстати по поводу того что >10G ниизяя... http://uadm.uu.se/digitalAssets/21/21239_opensourcerouting.pdf . 100G (HD правда) , но видимо могли бы и больше , просто у авторов PCIe x16 кончились раньше :)

Железо по нынешним временам даже не самое топовое.

[Alex/AT]

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

Есть простая истина: гибкость != "100500 задач на одной платформе", а возможность адаптации под конкретную ситуацию, не ломая системы, и не нарушая системности подхода.

На софтовых тазиках это достигается чуть более, чем полностью - можно строить любой сервис, было бы желание, время, силы и деньги. Проблема только одна - производительность, но и эта проблема решаема - просто берется софтовый тазик, дополняется аппаратным решением по форвардингу трафика под задачу, управляющая система чуть двигается в сторону эмбедеда - и - вуаля. Отличные примеры - Cisco ASA, Cisco ASR, да и тот же Juniper.

Изменено 19 марта, 2012 пользователем Alex/AT

[NiTr0]

вендоры занимающиеся оборудованием для пд лучше опенсорс задротов знают что нужно отрасли

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

 

У мсье раздвоение личности? Или реализация всего через жопу для бздоида суть единственно правильное решение? А может, мсье любит ставить везде железо вендоров, ориентированных на SOHO?

 

один из живых примеров - мплс, который чуть менее чем полностью отсутствует в этих ваших опенсурсах

Ибо и нафиг не нужен на скоростях порядка единиц гигабит, а на десятках гигабит - специализированная железка окажется дешевле, хоть и будет весьма ограничена в функционале.

 

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

Угу, думают-думают, думают-думают, а вот пропорциональное урезание скорости по классам на шейпере при оверкоммите так и не придумали, как и разграничение по скорости на исход/вход на различные интерфейсы (не по подсетям, коих может быть 100500 на направление и которые могут ежедневно меняться, а именно по интерфейсам). Ах да, "это никому не надо, а кто надумал раздельно шейпить мир и IX либо продавать мультиплексированный канал и при этом избегать затыка при полках - тот нищеброд".

 

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

Угу, и выпущенные несколько лет назад железки сами собой, по мановению волшебной палочки, мутируют, обрастая новым функционалом в ASIC? А может, при появлении новой потребности и новой фичи у вендора вы полностью меняете ядро, выбрасывая старое на помойку и покупая новое железо с нужной вам фичей?

[terrible]

ппц вы полемику развели!

вендор делает такое железо и таким образом, чтобы оно утратило свою актуальность лет через 5, затем вы покупаете новое железо, т.е. работаем на вендора

само понятие "нищеброд", которое не единожды употребляется в этой ветке, никакой актуальной информации, кроме откровенного хамства и презрения, в себе не несёт. Ну не стыдно так выражаться?

 

Угу, думают-думают, думают-думают, а вот пропорциональное урезание скорости по классам на шейпере при оверкоммите так и не придумали, как и разграничение по скорости на исход/вход на различные интерфейсы (не по подсетям, коих может быть 100500 на направление и которые могут ежедневно меняться, а именно по интерфейсам). Ах да, "это никому не надо, а кто надумал раздельно шейпить мир и IX либо продавать мультиплексированный канал и при этом избегать затыка при полках - тот нищеброд".

 

согласен полностью

[vlad11]

Кстати по поводу того что >10G ниизяя... http://uadm.uu.se/digitalAssets/21/21239_opensourcerouting.pdf . 100G (HD правда) , но видимо могли бы и больше , просто у авторов PCIe x16 кончились раньше :)

Железо по нынешним временам даже не самое топовое.

И они тоже жаловались на Интел за недостаток документации к чипсетам и кривые дрова.

[alks]

вот новость интересная (хотя может для кого-то и боян)

 

http://servernews.ru/tags/Intel

 

скажите специалисты по линуксу - если сервер используется по nat (iptables)

что я должен ощутить с этой фичей?

[Ilya Evseev]

скажите специалисты по линуксу - если сервер используется по nat (iptables)

что я должен ощутить с этой фичей?

Вероятно, загрузка процессора уменьшится.

[alks]

в где iptables хранит таблицы пулов?

[Ilya Evseev]

в где iptables хранит таблицы пулов?

в там.

[alks]

ээээ ... а там это где? в RAM или в разных кэшах проца

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

[pfexec]

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

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

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

У мсье раздвоение личности? Или реализация всего через жопу для бздоида суть единственно правильное решение? А может, мсье любит ставить везде железо вендоров, ориентированных на SOHO?

типа ентерпрайз железо надо использовать в сервис провайдинге и метро езернете ? ЛОООЛ.

Ибо и нафиг не нужен на скоростях порядка единиц гигабит, а на десятках гигабит - специализированная железка окажется дешевле, хоть и будет весьма ограничена в функционале.

как она может быть ограничена. ограничена по сравнению с чем ? писюки ж вообще его не умеют. в чем ограниченность то ?

Угу, думают-думают, думают-думают, а вот пропорциональное урезание скорости по классам на шейпере при оверкоммите так и не придумали, как и разграничение по скорости на исход/вход на различные интерфейсы (не по подсетям, коих может быть 100500 на направление и которые могут ежедневно меняться, а именно по интерфейсам). Ах да, "это никому не надо, а кто надумал раздельно шейпить мир и IX либо продавать мультиплексированный канал и при этом избегать затыка при полках - тот нищеброд".

ну может и нищеброд, кто знает. но у вас явно столман головного мозга. Ж)

Угу, и выпущенные несколько лет назад железки сами собой, по мановению волшебной палочки, мутируют, обрастая новым функционалом в ASIC? А может, при появлении новой потребности и новой фичи у вендора вы полностью меняете ядро, выбрасывая старое на помойку и покупая новое железо с нужной вам фичей?

несколько лет назад - это сколько ? 5 ? 10 ? 20 ? но вобщем-то на модульных решениях вендор всячески поддерживает, выпуская новые платы и софт. ну и как бы есть такая штука как "планирование". глупо брать хоть железо, хоть писюки без прицела на вырост. так что не понимаю в чем тут баттхёрт у вас. в том что вы на ебае купили 76ую в говнозабивке и внезапно обнаружили отсутствие возможности установить на неё линагз с утм ? бида, что сказать. :)

 

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

вендор делает такое железо и таким образом, чтобы оно утратило свою актуальность лет через 5, затем вы покупаете новое железо, т.е. работаем на вендора

спрос рождает предложение, а не наоборот. если вы купили десять лет назад какое то решение и оно вас и ваш бизнес устраивает, то в чём проблема ? где козни вашего ZOG ? старое железо и софт устаревает одинаково и у вендоров, и у ваших любимых писюков.

[NiTr0]

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

Покажите мне комплексное решение, способное реализовать иерархический шейпер, с глобальным ограничением скорости абону либо с ограничением скорости на какое-либо направление (по радиус-аттрибутам), и с возможностью опять же пропорционального ограничения скорости на направление для всех абонов при оверкоммите. Что, нет, ибо в ASIC такое не упихать? Пичалька... Что, есть, стоит несколько десятков килобаксов при производительности в 100 кппс ибо софтовое по сути? Еще большая пичалька, тазик обойдется на 2 порядка дешевле...

 

как она может быть ограничена. ограничена по сравнению с чем ? писюки ж вообще его не умеют.

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

А MPLS к слову тоже уже есть, и достаточно давно. То, что вы не знали этого - ваше личное горе.

 

ну может и нищеброд, кто знает. но у вас явно столман головного мозга. Ж)

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

 

несколько лет назад - это сколько ? 5 ? 10 ? 20 ?

Максимум лет через 5-7 обычно внезапно оказывается, что железка не умеет что-то весьма важное - и все, приплыли. Как, к примеру, с IPv6, который на части кисок реализован софтово... А потом еще оказывается, что мозг e мегапупержелезяки имеет свойство внезапно виснуть при определенных условиях (к прмиеру, флудом его ложит)...

 

но вобщем-то на модульных решениях вендор всячески поддерживает, выпуская новые платы и софт.

Угу. Не считая того, что софт волшебным образом не отрастит ASICу недостающие блоки, а замена всего железа кроме шасси по цене будет сопоставима с покупкой нового...

 

ну и как бы есть такая штука как "планирование". глупо брать хоть железо, хоть писюки без прицела на вырост.

Вы знаете, что вашей сети потребуется через 5-7 лет? В 2006 вы могли бы предвидеть, что кто-то будет продавать абону гигабит за $15-20 (как это сейчас у некоторых провов наблюдается, причем не первый год)? А 10 лет назад, когда магистрали даже массово на меди строились, предвидели, что к физикам в частном секторе вскоре окажется выгоднее тянуть оптику?

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

[alks]

ну вот что вы спорите то попусту? имеет место быть и вендорное и софтовое решение

у меня к примеру под брасы используется циска под бордер джун а NAT - однозначно рулят сервера

и меня все это вполне устраивает

хотя в идеале хочу 1u железку + несколько 1ge 10ge портов и с большой красной кнопкой "***то" ))

и чтобы там было bras-dpi-border-billing-web-etc

 

Покажите мне комплексное решение, способное реализовать иерархический шейпер, с глобальным ограничением скорости абону либо с ограничением скорости на какое-либо направление (по радиус-аттрибутам), и с возможностью опять же пропорционального ограничения скорости на направление для всех абонов при оверкоммите. Что, нет, ибо в ASIC такое не упихать? Пичалька... Что, есть, стоит несколько десятков килобаксов при производительности в 100 кппс ибо софтовое по сути? Еще большая пичалька, тазик обойдется на 2 порядка дешевле...

 

любой DPI или ASR c софтом nbar2+isg

 

и ксати смеха ради, к примеру sandvine это бздуны а cisco SCE это линузятники

Изменено 20 марта, 2012 пользователем alks

[pfexec]

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

про ваших коней в вакууме уже говорили в соседней ветке. продолжайте дальше лепить по стопицот вложеных очередей в шейпер и считать что это правильно.

А MPLS к слову тоже уже есть, и достаточно давно. То, что вы не знали этого - ваше личное горе.

http://sourceforge.net/projects/mpls-linux/files/mpls-linux/Patches/

последний патч от 2011-07-29 для 2.6.35 ведра.

лол, вы что, серъезно говорите об этом как о _рабочей_ реализации mpls в linux'е ?

в openbsd я щитаю единственный актуальный вариант реализации mpls'а в писюке, но далекий конеш от состояния "готово к использованию".

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

очень сильно зависит от контекста применения. если речь про шпд, то да, полисинга хватит за глаза я щитаю. не понимаю в чём такая ярая надобность в этих ваших шейперах, тем более с десятком вложеных очередей. ЧСВ форсить ?

Максимум лет через 5-7 обычно внезапно оказывается, что железка не умеет что-то весьма важное - и все, приплыли. Как, к примеру, с IPv6, который на части кисок реализован софтово... А потом еще оказывается, что мозг e мегапупержелезяки имеет свойство внезапно виснуть при определенных условиях (к прмиеру, флудом его ложит)...

вы покупайте адекватное оборудование на текущий момент и не будет проблем через пять лет. на какой части "кисок" реализован софтово ipv6 ? на свиче 3550 ? так это свич, причем ему гораздо больше чем пять лет.

The last day to order Cisco Catalyst 3550 Series switches is May 2, 2006.

они как 6 лет уже eos. только за это время сколько поколений процессоров сменилось стоит посчитать, а 3550 ничотак, бодряком, до сих пор молотит свои Гбпс и Мппс, до которых писюку по-прежнему как до луны. А всё что посвежее или классом выше спокойно умеет и IPv6, и от флуда не сказать чтобы сильно умерало (65+sup2, который, внезапно, cl на ingress'е отрабатывает в pfc и позволяет защитить msfc от флуда без особых бед. ну ида, sup2 тоже уже давно и eol, и eos. однако, cisco даже апгрейд ПО в прошлом году запилила для него.

вобщем то что сейчас лежит на рынке б/у оборудования уже прослужило добрый десяток лет если не больше, которое до сих пор востребовано в этих ваших хоминетах и провайдерах. а вы говорите про то что железка от вендора через 7 лет бесполезна. я думаю что и купленные Cisco/Juniper/Brocade/Force10 адекватно дизайну сети и потребностям прослужат не меньше, а может и больше, если сеть устроена правильно.

 

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

у меня к примеру под брасы используется циска под бордер джун а NAT - однозначно рулят сервера

приятно видеть, что хоть кто-то в "теме". кстати, для bras есть у juniper интересные erx и mx бандлы.

хотя в идеале хочу 1u железку + несколько 1ge 10ge портов и с большой красной кнопкой "***то" ))

есть жеж такая, правда не в 1U. эти, редбаки ж. но, имхо, не очень хорошо всё навешивать на одну коробку

[Alex/AT]

при смене одминчика сеть на однородном вендоре

Потребует второго такого же. А специалисты с сертификацией вендора стоят ой как дорого. Впрочем, как и грамотные Linux-сетевики. А уж совмещение того и другого в одном лице стоит вообще жуть, но и отдача соответствующая. Суть в том, что вменяемый специалист при любом раскладе будет стоить примерно одних и тех же денег в пересчете на отдачу.

 

Я бы тут правильнее заметил следующее: если есть _большие_ деньги, лучше забиваться на вендора. Если больших денег нет, а решение надо "уже сейчас" - лучше для начала строить на софтах.

 

Ах да, это же на ASICе реализовывать сильно дорого и гиморно

Кстати да, шейперы на ASIC'ах почему-то всегда негибкие и грабельные. Хотя реализовать допустим тот же алгоритм hfsc в ASIC - не так уж и сложно.

Изменено 20 марта, 2012 пользователем Alex/AT

[Alex/AT]

(65+sup2, который, внезапно, cl на ingress'е отрабатывает в pfc и позволяет защитить msfc от флуда без особых бед

Дайте ему пожевать хотя бы 100-200 kpps ARP'а (на практике достаточно 30-40k) или OSPF в сторону железки, и удивитесь, как RP/SUP сдохнет от прерываний до неуправляемого состояния. L3 forwarding, кстати, тоже будет affected, если у вас конечно не 7600 с DFC. С DFC форвардингу будет шелковисто, но лягут роутинговые протоколы, так что едино.

 

Причём, даже CoPP не спасает от арпа (и не только) на 65xx/76xx, там надо вкручивать более хитрое извращение под названием hardware protocol policing.

 

кстати, для bras есть у juniper интересные erx и mx бандлы.

Из всего, что есть у жуна, вменяемо только MX80+, за эти деньги проще под брас взять ASR.

 

ну вот что вы спорите то попусту? имеет место быть и вендорное и софтовое решение

Дык всё с того и начиналось, что у каждого решения - своя ниша :)

Изменено 20 марта, 2012 пользователем Alex/AT

[DVM-Avgoor]

Дайте ему пожевать хотя бы 100-200 kpps ARP'а (на практике достаточно 30-40k) или OSPF в сторону железки, и удивитесь, как RP/SUP сдохнет от прерываний до неуправляемого состояния. L3 forwarding, кстати, тоже будет affected, если у вас конечно не 7600 с DFC. С DFC форвардингу будет шелковисто, но лягут роутинговые протоколы, так что едино.

 

Дак и писироутер сдохнет, разве нет? :)

[Alex/AT]

PPPoE BRAS - в пределах общесистемного лимита по pps не сдохнет, ему нечем ARP обрабатывать там, где клиенты. Бордер - тоже в принципе при грамотной настройке никуда не денется в пределах лимита по pps. Софтроутер, он тем и хорош, что поведение достаточно предсказуемо с ростом pps, и мало зависит от типа трафика.

 

Хотя на мегамолотилку L3 софт ставить бессмысленно, тут есть недорогие аппаратные решения. Софтроутеры нужны для специфичных решений.

Изменено 20 марта, 2012 пользователем Alex/AT

[alks]

Из всего, что есть у жуна, вменяемо только MX80+, за эти деньги проще под брас взять ASR.

 

вообще-то цена на мх80 идентична asr-esp5, не залоченного, но без лицухи на l3