Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 119
Тэг «магия вуду» очень хорошо описывает тему. Нужно добавить ещё «танец с бубном».
Более подробно вместе с конфигами схема работы приведена здесь.
Cкачать их можно из данного репозитория.
Ссылки потерялись.
Открывающая кавычка Alt+0171 -> «
Закрывающая кавычка Alt+0187 -> »
Закрывающая кавычка Alt+0187 -> »
> В час пик это чудо инженерной мысли «прожевало" входящий поток 1.4Гбит/c,
> при суммарном kpps на всех интерфейсах порядка 400.
Коллега, у вас что-то не то с цифрами. При нагрузке в 1.5-2 гигабита генерируемых пользовательским трафиком pps как правило куда больше.
Тазики в ключевых точках сети — это как по мне вообще стремное решение. что мешало поставить туда внятные L3-коммутаторы?
> при суммарном kpps на всех интерфейсах порядка 400.
Коллега, у вас что-то не то с цифрами. При нагрузке в 1.5-2 гигабита генерируемых пользовательским трафиком pps как правило куда больше.
Тазики в ключевых точках сети — это как по мне вообще стремное решение. что мешало поставить туда внятные L3-коммутаторы?
Выдавали пользователям /30 сетки, причем с самом начале еще и отдельный VLAN на пользователя.
Недостатки такого подхода всплыли очень быстро :)
Недостатки такого подхода всплыли очень быстро :)
Подход на самом деле не так уж и плох, но для этого нужно строить нормальный aggregation level, а там уже линуксам делать, боюсь, нечего, увы.
мы как-то тоже выдавали… а потом при ребуте такого сервака 1200 вланов подымались минут 40 на коре2дуо под гентой. Потом купили элайттелесин свитч за 120 тыс(против 10 тыщ за писюк) и на нем подняли вланы. Но дело не только в том, что они долго подымаются при ребуте, но и в том, что линукс очень плохо себя при этом чувствовал, куда лучше использовать л3 коммутатор, что в конечном счете очень хорошо отразилось на задержках. Кстати от 1200 вланов и 200мб\с суммарно через писюк — коре2дуо сдувался быстро. Но так мы больше не подключаем, теперь ip адрес привязывается к порту абонента на свитче, к которому он подключен
аналогично, вполне нормальные цифры у автора
вот на одном из аплинков
5 minute input rate 201770000 bits/sec, 39021 packets/sec
5 minute output rate 411565000 bits/sec, 59521 packets/sec
вот на одном из аплинков
5 minute input rate 201770000 bits/sec, 39021 packets/sec
5 minute output rate 411565000 bits/sec, 59521 packets/sec
Да, тут я пожалуй погорячился. Нормальный pps.
Сейчас на входе ~600М и под 70кппс
Видать, думалось о другом когда коммент писал =)
Сейчас на входе ~600М и под 70кппс
Видать, думалось о другом когда коммент писал =)
Познавательно, занимательно. Молодцы!
В данный момент тоже используете Linux в каких-либо решениях?
В данный момент тоже используете Linux в каких-либо решениях?
Расскажите, пожалуйста, как «повышалась… комфортность работы наших пользователей» при выданных серых адресах?
Вполне очевидно, что когда пользователь работает из-за NAT, то его компьютер не виден напрямую, т. е. косвенно повышается безопасность клиента, от некоторых видов сетевых атак, например у атакующего нет возможности прямо просканировать открытые порты на компьютере клиента.
Если бы мы выдавали «живые» ip то любой флуд на ip клиента занимал бы его полосу, т. к. полосы в те далекие времена были «узкими» а анлим дорогим, то мы приняли решение помочь клиентам. Для тех из клиентов кому был необходим «белый» ip такая услуга безусловна предоставлялась.
Если бы мы выдавали «живые» ip то любой флуд на ip клиента занимал бы его полосу, т. к. полосы в те далекие времена были «узкими» а анлим дорогим, то мы приняли решение помочь клиентам. Для тех из клиентов кому был необходим «белый» ip такая услуга безусловна предоставлялась.
молодцы, что еще можно сказать. но я лучше буду это все делать цисками и иметь здоровый сон и хороший аппетит.
Да как бы и мы «выросли» и теперь используем оборудование от самых извесных вендоров, просто в определенные моменты роста «домового» провайдера есть смысл применить более дешевые решения а на съэкономленные деньги развивать инфраструктуру и быстрее захватить часть рынка, чем вложиться в более дорогое железо и «сосать лапу».
Данная статья как Вы могли заметить подводит некоторую черту, так сказать «подитоживает» наш опыт использования программных решений.
Спасибо за комментарий, спите спокойно :)
Данная статья как Вы могли заметить подводит некоторую черту, так сказать «подитоживает» наш опыт использования программных решений.
Спасибо за комментарий, спите спокойно :)
Если вы расскажете чем дешево шейпить и натить из цисковского оборудования, то я желаю про это знать.
> проходило 1800 мбит/с (да, да это не описка, трафик почти 2 гигабита/с)
у нас в настоящий момент одна Linux коробка «нарезает» (в смысле шейпит согласно тарифам) в ЧНН 9.6Гбит/с при 1.8 мегапакетах. Самописный модуль для шейпинга+упрощённая маршрутизация.
у нас в настоящий момент одна Linux коробка «нарезает» (в смысле шейпит согласно тарифам) в ЧНН 9.6Гбит/с при 1.8 мегапакетах. Самописный модуль для шейпинга+упрощённая маршрутизация.
это просто АД. как-то я был худшего мнения о линухе. шейперы на фре максимум могут гиг вытянуть, нагрузка идет в основном от интераптов на сетевухах.
на сток фре с тюнингом в sysctl net.* можно и 5-6Гбит\с, и то не предел.
ну, в линуксце есть NAPI. Насколько мне известно, на фре нет ничего подобного, там либо поллинг либо прерывания. Хотя интеловкие карты генерируют прерывания по похожему алгоритму и, возможно, тюнингом параметров генерации прерываний можно добиться существенного уменьшения количества прерываний. Но на фре мы особо не тестировались. Да, и 9.6гбит это на 10ге интеловкой карточке, на гигабитных результаты поскромнее. Хотя, там проблемы были, скорее, в эзерченеле, на 1 сетевухе прокачивается ~990мбит.
На фре тоже можно, только это уже танцы с бубном гораздо более глубокие, чем в линуксе (специальные драйвера от того же тындекса, куча sysctl-ей, etc.).
Какое ядро?
Linux всем хорош и замечателен, но есть одно НО, если я уйду из конторы, то пришедший человек будет очень долго и нудно вникать в суть конфигов и всего прочего, т.к. универсального стандарта нет. И в большинстве случаев если сервера не критичные, то пришедший линуксоид не будет разбирать конфиги предыдущего, а просто поставит все заново и под себя. В этом плане циско, да и любое хардварное решение, гораздо интереснее, у него есть стандартный интерфейс с которым разберется любой.
Ну так документировать надо. Зная основные идеи, изложенные в локальной вики, например, знакомый с линуксцами человек разберётся достаточно быстро, имхо. На хардварных маршрутизаторах будь то циско или что угодно ещё, иногда тоже весьма навороченные конфиги в которых не так просто разобраться.
у нас в Одессе, во многих ISP имеется один ключевой админ и часто отсутствует внятная документация.
так что хозяевам очень не выгоден уход админа
так что хозяевам очень не выгоден уход админа
Просто согласитесь, в железке есть только один конфиг и из него все можно прочитать, а вот в линухе в какие дебри я запихну конфиг это уже никому неизвестно =)
Ну лично для меня этот аспект не сильно важен, а руководству цена линуксовых решений нравится.
Что особенно нравится, это автор уже описал, при поломке циски, хоть 4 раза она будет на гарантии, но если нет скалада запчастей, то у вас будет простой, а с писюками перекинуть харды 3 минуты делов.
Ну лично для меня этот аспект не сильно важен, а руководству цена линуксовых решений нравится.
Что особенно нравится, это автор уже описал, при поломке циски, хоть 4 раза она будет на гарантии, но если нет скалада запчастей, то у вас будет простой, а с писюками перекинуть харды 3 минуты делов.
Я честно говоря долго мучался с Linux в качестве роутера, потому на все роутеры рано или поздно поселилась FreeBSD.
ipfw, netgraph, mpd и ещё много плюшек пришлось съесть.
ipfw, netgraph, mpd и ещё много плюшек пришлось съесть.
мы как-то тоже пользовались линуксами в качестве л3 коммутаторов, но производительность у них все равно слабая при большом кол-ве вланов, маршрутов, интерфейсов,etc… голый iptables вообще не годится, приходиться прибегать к хакам вроде ipset, но вот если взглянуть на фрибзд, там уже в стоке ipfw все это умеет и на практике она оказалась куда производительнее линукса, причем в линуксе использовался очень глубокий тюнинг.
В Москве в ряде домовых сетей в качестве L3 коммутаторов без проблем используют ДЛинки…
Не только в Москве. Сам когда-то работал у прова, отвечал за участок где было примерно 250 длинков, горел в среднем один свитч в неделю. И то обычно там, где скачки напряжения либо повышенная температура.
Я говорю не про те ДЛинки, которые «на домах»(там L2… и знаменитая серия 3526 или аналоги). Речь идёт об L3 коммутаторах — это уровень агрегации. Очень надёжные машинки…
а уж цена — позволяет при желании делать тройное резервирование…
а уж цена — позволяет при желании делать тройное резервирование…
Особливо 3610. Мммм! Мне Длинк в свое время дал один из первых сэмплов на тест — там еще даже логотипы Ruiji были. :-) Сказка, а не коммутатор. Длинк умеет иногда выбирать OEM-поставщиков. Больше всего мне понравилось, когда я в целях эксперимента отправил на него full-view по bgp. Исчерпалась память, после чего он тихонько сообщил в лог, что процесс bgp ведет себя плохо, убил его и спокойно продолжил работать дальше. Раз в несколько минут он пробовал снова запускать bgp, снова кончалась память и он снова его без лишних истерик убивал. :-) После Цисковских багов — это просто праздник какой-то. :-)
Был бы это боевой маршрутизатор — он бы тоже тихо, без истерик убивал вам интернет вместе с BGP? :)
Во-первых, он не предназначен для того, чтобы роутить интернет — у него для этого силенок не хватит. Это нормальный l3-свич на агрегацию или, скажем, в сторону пиринговых площадок смотреть (чем он у нас и занимался). Был бы он для интернета — держал бы full view. :-) Но не надо требовать он железа того, для чего оно не предназначено…
Во-вторых, если уж BGP умер — статика никуда не делась. И даже если бы этот свич стоял «на интернете», то просто трафик бы полился в сторону одного из аплинков… Ну да, пришлось бы потом расплачиваться в буквальном смысле, да и предварительно нужно бы было с этим аплинком договориться, чтобы в таких случаях он продолжал нашу AS'ку анонсить, но в любом случае это все решаемо и после решения даже в такой экстремальной ситуации свич вполне мог бы выполнять свои функции. :-)
В-третьих, тот факт, что свич не умер, позволяет в любом случае зайти на него удаленно и все поправить. Что не просто важно, а мега-важно. :-)
В-четвертых, независимо ни от чего истерику должен поднимать не свич, а специально предназначенные для этого средства, которые завоют сиреной, пошлют админу SMS и так далее. :-)
Во-вторых, если уж BGP умер — статика никуда не делась. И даже если бы этот свич стоял «на интернете», то просто трафик бы полился в сторону одного из аплинков… Ну да, пришлось бы потом расплачиваться в буквальном смысле, да и предварительно нужно бы было с этим аплинком договориться, чтобы в таких случаях он продолжал нашу AS'ку анонсить, но в любом случае это все решаемо и после решения даже в такой экстремальной ситуации свич вполне мог бы выполнять свои функции. :-)
В-третьих, тот факт, что свич не умер, позволяет в любом случае зайти на него удаленно и все поправить. Что не просто важно, а мега-важно. :-)
В-четвертых, независимо ни от чего истерику должен поднимать не свич, а специально предназначенные для этого средства, которые завоют сиреной, пошлют админу SMS и так далее. :-)
«горел в среднем один свитч в неделю. И то обычно там, где скачки напряжения либо повышенная температура»
Вы считаете это хорошим показателем? Один свитч в неделю? За полгода у нас в конторе не сгорел ни один свитч (не DLink'и), причём стоят они в весьма разнообразных местах. Хотя нет, на одном сгорел порт, на DLink'е, кстати)
Вы считаете это хорошим показателем? Один свитч в неделю? За полгода у нас в конторе не сгорел ни один свитч (не DLink'и), причём стоят они в весьма разнообразных местах. Хотя нет, на одном сгорел порт, на DLink'е, кстати)
К чему ваш комментарий? Ну да, используют, та же корбина использует 3526 и 3627, мы тоже их используем.
А при каком количестве вланов начинались проблемы? И как они выглядели. У меня вся сейчас в среднем по 50-60 вланов на узле. Роутеры на базе Интел Атома с двумя риалтековскими сетевушками. Работает без нареканий, но у меня и трафик до 50 мбит не везде дотягивает
КЭП разлогиньтесь!
>… и советуют купить Cisco или уж на совсем крайний случай Juniper.
хуясебе крайний случай — juniper. вы ценники на juniper-то хоть видели?
хуясебе крайний случай — juniper. вы ценники на juniper-то хоть видели?
Цены на одиникового класса Juniper и Cisco тоже примерно одинаковы, допустим шасси Cisco 7600 и шасси Juniper MX960 примерно в диапазоне 50k$+
Просто некоторые люди — анабиозники и все еще думают, что кроме циски никто не делает телекомное железо :)
тоже хотел в таком роде коммент сделать…
добавлю, не только ценики, но и производительность на разном уровне. так что такое построение предложения тоже не приветсвую.
у провов, не домушников, в ядре маршрутизации стоит джунипер мощненкий, а не циска серии аля 12000 >.
да и посмотрите на BRAS, погуглите, на чем строят…
добавлю, не только ценики, но и производительность на разном уровне. так что такое построение предложения тоже не приветсвую.
у провов, не домушников, в ядре маршрутизации стоит джунипер мощненкий, а не циска серии аля 12000 >.
да и посмотрите на BRAS, погуглите, на чем строят…
Эм… У меня вопрос — назовёте хоть одну провайдерскую компанию, не использующую *nix системы?
Раскажите пожалуйста как реализовывалось дублирование оборудовани (если оно было), в частности интересно дублирование NAT коробок, что бы было что-то подобное HSRP и желательно с копированием state таблиц.
Вы лучше скажите непросвещенным людям, сколько такое решение от вендора стоит денег. Линукс роутеры занимают свою нишу — это оборудование провайдера-дискаунтера, который подкупает пользователей прежде всего ценой на услуги
Вы не умеете их готовить. На nag.ru в свое время был клевый тред, где сидели товарищи выбирали BRAS рассуждали что вот это за 10k$ тянет тыщу абонентов умеет то это клево это все такое, а потом туда ВНЕЗАПНО врывается человек с linux роутером и терминации 3 тысяч сессий на одном сервере за 2 тыщи баксов :)
Я не об этом, просто в OpenBSD есть CARP, аналог HSRP и копирование nat таблиц через pfsync, но pps производительность у OpenBSD просто печальна, пришлось ставить под ту задачу linux. Но вот ни ядерного CARP ни pfsync я не нашел, пришлось засетапить cold spare, а хочется hot spare.
Кстати, а как на Линуксе не знаю, а вот на *BSD — без проблем. Например, для pf есть pfsync. Но обычно копированием state-таблиц никто не заморачивается — просто ставят рядом несколько серверов и роутят на них трафик (либо на конкретные, а остальные — бэкап, либо на все сразу по round-robin'у). Если кто-то отвалился — трафик сам на другой сервер перетекает… А что у кого-то tcp-сессия отвалилась — се ля ви. Это же даже простоем не назовешь. :-) Особенно учитывая, что нормальный сервер умрет максимум раз в полгода (хотя с чего бы ему?) — не чаще… Но обычно реже, конечно. У меня сервера под роутинг/шейпинг/NAT, которые были на удаленных объектах (соответственно, которые не надо было трогать и апгрейдить — обслуживают своих пользователей и ладно) по нескольку лет работали — заморачиваться из-за этого бэкапом с копированием состояний файрволла/НАТа как-то не было смысла…
pfsync и CARP сильные аргуменнты, но не устроил pps — на OpenBSD он печален совсем, на FreeBSD получше в разы но все равно не то.
Ну, я OpenBSD и не предлагаю — там далеко не только с pps печально… :-) pfsync, конечно, можно и на Фре запустить, но с точки зрения производительности это все равно будет фигня — сам pf спроектирован по-дурацки и больше подходит чтобы по-быстрому в две строчки настроить инет в офисе, а не для провайдинга… Я его через pmc профилировал — это ужас какой-то. Весь проц тратился только на то, чтобы pf в себя в таблице как раз свои состояния искал (при том, что трафика было кот наплакал)… Опять же — у вас какая задача? Шейпинг провайдерский на pf все равно не сделать.
А нативный ipfw по производительности никаких проблем не имеет — все начинает упираться уже в сетевушки, прерывания и т.п., что тюнится в других местах… Ядерный dummynet и nat решают.
В общем, там на самом деле по производительности разницы особой нет, так что кому что привычнее… Not spare на NAT — оно вообще у кого есть? Думается, если сессия и оборвется — ничего особо страшного не произойдет. :-)
А нативный ipfw по производительности никаких проблем не имеет — все начинает упираться уже в сетевушки, прерывания и т.п., что тюнится в других местах… Ядерный dummynet и nat решают.
В общем, там на самом деле по производительности разницы особой нет, так что кому что привычнее… Not spare на NAT — оно вообще у кого есть? Думается, если сессия и оборвется — ничего особо страшного не произойдет. :-)
Ядерный dummynet и nat решают.
Вот как бы не так… представьте что вы неможете по какой то причине делать распределенный NAT и надо обжимать 800MB/500kpps на одной фряхе.
Незнаю как в восьмерке, а в семерке dummynet однопоточный, он выедает полностью один проц (т.е. на 100%) и дальше все его ждут… и все — остальные 7 ксеонов скучают рядом и немогут ничем помочь шейпингу.
Да, dummynet к сожалению как был однопоточным, так, насколько я помню, и остался… :-( Хотя там и так есть что потюнить. Вы через pmc не пробовали профилировать, чтобы посмотреть, что именно выжирает? Опять же, в 8 процах смысла, может, и нет, но 2 загрузить, ИМХО, можно вполне — кроме dummynet'а есть еще чем заниматься. :-) И вообще надо в корень смотреть и тюнить netisr (иногда достаточно просто значение net.isr.direct сменить). У меня тоже на 200Мбитах все, типа, затыкалось под завязку, а стоило одну переменную поменять — как сразу прокачалось 300 и проц стал загружен только на 40%… К тому же в семерке еще — не помню в какой именно — net.inet.ip.dummynet.io_fast добавили, что тоже освобождению проца способствует.
Короче, не все так однозначно, ИМХО. dummynet хоть и однопоточный, но быстрый, а тормозят чаще другие вещи…
Короче, не все так однозначно, ИМХО. dummynet хоть и однопоточный, но быстрый, а тормозят чаще другие вещи…
io_fast это конечно — это обязательно.
net_isr трогать при двух сетевушках и 8 ядрах вообще противопоказанно, но можно потрогать драйвера сетевух (разумеется яндексовые) и cpuset. А еще если у вас нет больного на голову руководства то запретить двойное проходждение через пайпы.
В общем для шейпинга сама архитектура x86 неочень хорошо подходит для таких задач.
net_isr трогать при двух сетевушках и 8 ядрах вообще противопоказанно, но можно потрогать драйвера сетевух (разумеется яндексовые) и cpuset. А еще если у вас нет больного на голову руководства то запретить двойное проходждение через пайпы.
В общем для шейпинга сама архитектура x86 неочень хорошо подходит для таких задач.
Гм. Я трогал и нормально было… Но у меня ядер было только четыре. ;-)))
Насчет архитектуры — а чем шейпить-то тогда?
Насчет архитектуры — а чем шейпить-то тогда?
Вот например обзор.
А в целом все сводиться к аппаратным железкам которых на рынке немного.
Если же по какой то причине надо использовать х86 то лучше заранее думать о кластеризации.
А в целом все сводиться к аппаратным железкам которых на рынке немного.
Если же по какой то причине надо использовать х86 то лучше заранее думать о кластеризации.
stateful nat можно реализовать с помощью vrrp и синхронизации ipconntrack
Ну здрасте. Вас в гугле забанили? Есть вот такая цацка conntrack-tools.netfilter.org/ внутре ее есть conntrackd который позволяет синхронизировать сервисы. Вместо HSRP лучше использовать www.ucarp.org/project/ucarp
Это в юзерспейсе, совсем не то.
В смысле в userspace?! За каким чертом это тащить на уровень kernel?!
когда сетевые драйверы и стек реализует ядро, зачем тащить это в юзерспейс вообще непонятно.
не проверял разные режимы в линуксе, но во freebsd ядерный carp работает куда быстрее чем ucarp.
также как и ядерный carp во freebsd работает быстрее чем vrrpd в линуксе.
не проверял разные режимы в линуксе, но во freebsd ядерный carp работает куда быстрее чем ucarp.
также как и ядерный carp во freebsd работает быстрее чем vrrpd в линуксе.
зачем тащить это в юзерспейс вообще непонятно.
Не зачем тащить в ядро те части которые работают по верх стандартного стека tcp/ip. Они как раз должны быть на уровне userspace.
не проверял разные режимы в линуксе, но во freebsd ядерный carp работает куда быстрее чем ucarp.
Куда быстрее это на сколько? На 2 милисекунды?
Юзал, работает?
Гм. Странный топик. :-) Как было сказано — все и так используют *nix — что тут обсуждать? Разве что конкретные технические реализации… Но в них на самом деле особых вариантов-то и нет и все всё и так знают (это к вопросу о том, что работать и обучать людей сложнее — ни фига).
Единственная эмоция, которую вызвала статья и с которой хотелось бы поделиться: PC-серверам не место на уровнях доступа, распределения/агрегации! Все вещи, которые легко реализуются в железе (типа коммутации разных уровней) — должны реализовываться в железе. А вот тот же шейпинг и NAT — это все чисто софтовые вещи, которые нереально с достаточным уровнем качества и гибкости реализовать в железе. Та же Циска это все делает программными средствами на CPU, а не специализированных микроконтроллерах. Ну так зачем городить огород, если можно самому это же сделать софтово? :-)
Вот, собственно, и все, что, ИМХО, нужно знать по этой тематике. :-)
ps: У серверов есть минус — их тяжелее в Роскомнадзор сдавать. Если самосбор, то вообще слабореально, а если покупные — то это сразу дороже и у них обычно сертификация только для телематики (т.е. хостинг и т.п.), а не для передачи данных. Возможно, сейчас что-то изменилось, но раньше эти вопросы приходилось решать в индивидуальном порядке со своим инспектором. В итоге все обычно сводилось к фейковым проектам, когда указывается, что либо все делается одной левой железкой (мы как-то сеть на полторы тысячи человек сдавали, которую по документам роутил D-Link DI-604. ;-) Особенно смешно было, что его реально пришлось поставить на узел связи, куда-то подключить, чтобы лампочки моргали, и предъявить потом формальной комиссии. ;-) ), либо одним покупным сервером со всеми документами, а на самом деле — пятью дополнительными серверами под этим «официальным». В этом плане мне особенно хорошо подходили сервера от 3logic, потому что стоили минимально, имели все необходимые сертификаты и собирались в корпусах от GenesysRack (!!!), так что можно было самим собрать несколько идентично выглядящих и «распространить» на них документы первого и единственного. :-)
И так далее, и тому подобное. :-) На практике оказывается на самом деле, что технические вопросы использоваться *nix по сути отсутствуют — берешь и используешь (железа — полно, документации — полно). А вот сопутствующие задачи зачастую даже больше геморроя приносят… Это, кстати, еще одна причина, по которой «большие» провайдеры предпочитают по максимум использовать брендованное специализированное оборудование — вопросов от контролирующих органов сильно меньше, чем к «кулибиным». :-)
Единственная эмоция, которую вызвала статья и с которой хотелось бы поделиться: PC-серверам не место на уровнях доступа, распределения/агрегации! Все вещи, которые легко реализуются в железе (типа коммутации разных уровней) — должны реализовываться в железе. А вот тот же шейпинг и NAT — это все чисто софтовые вещи, которые нереально с достаточным уровнем качества и гибкости реализовать в железе. Та же Циска это все делает программными средствами на CPU, а не специализированных микроконтроллерах. Ну так зачем городить огород, если можно самому это же сделать софтово? :-)
Вот, собственно, и все, что, ИМХО, нужно знать по этой тематике. :-)
ps: У серверов есть минус — их тяжелее в Роскомнадзор сдавать. Если самосбор, то вообще слабореально, а если покупные — то это сразу дороже и у них обычно сертификация только для телематики (т.е. хостинг и т.п.), а не для передачи данных. Возможно, сейчас что-то изменилось, но раньше эти вопросы приходилось решать в индивидуальном порядке со своим инспектором. В итоге все обычно сводилось к фейковым проектам, когда указывается, что либо все делается одной левой железкой (мы как-то сеть на полторы тысячи человек сдавали, которую по документам роутил D-Link DI-604. ;-) Особенно смешно было, что его реально пришлось поставить на узел связи, куда-то подключить, чтобы лампочки моргали, и предъявить потом формальной комиссии. ;-) ), либо одним покупным сервером со всеми документами, а на самом деле — пятью дополнительными серверами под этим «официальным». В этом плане мне особенно хорошо подходили сервера от 3logic, потому что стоили минимально, имели все необходимые сертификаты и собирались в корпусах от GenesysRack (!!!), так что можно было самим собрать несколько идентично выглядящих и «распространить» на них документы первого и единственного. :-)
И так далее, и тому подобное. :-) На практике оказывается на самом деле, что технические вопросы использоваться *nix по сути отсутствуют — берешь и используешь (железа — полно, документации — полно). А вот сопутствующие задачи зачастую даже больше геморроя приносят… Это, кстати, еще одна причина, по которой «большие» провайдеры предпочитают по максимум использовать брендованное специализированное оборудование — вопросов от контролирующих органов сильно меньше, чем к «кулибиным». :-)
Ну так зачем городить огород, если можно самому это же сделать софтово? :-)
Ну огород там не в софте (хотя и в нем тоже — заточенность под задачу), а в железе — срок службы, надежность, снижение цены и повышение надежности путем отказа от лишних функций\компонентов (зачем вам там SATA или USB, например?) и т.д.
Железка, делающая одно дело и строго на него ориентированная почти всегда будет проще и надежнее, чем «комбайн».
Если у кого-то сервера не могут работать по нескольку лет — этот человек просто не умеет их готовить. :-) Таким — что сервера, что железячное решение — значения уже не имеет. Но мы ведь говорим о специалистах высокого класса, а не о самоделкиных? Кстати, с моей личной точки зрения, специалист высокого класса в частности и получает большие деньги за то, что он может позволить компании экономить на других вещах…
В «серьезном» оборудовании разнообразных функций/компонентов не меньше, чем в компе — всякие слоты для расширения функциональности и добавления интерфейсов, модули для флеш-памяти и так далее… В общем, все вполне сравнимо, если не наоборот: что такое материнская плата — 2-3 чипа и обвязка. А в «железном железе» частенько элементов-то как раз побольше будет — достаточно фотки внутренностей посмотреть. Это только копеечные wifi-роутеры из одного чипа и памяти состоят. :-)
Опять же, никто не заставляет собирать сервер самому. А промышленные решения как раз пятиканального звука и оптического SPDIF'а обычно лишены. :-) Правда, мой опыт показывает, что уровень качества массовых продуктов дошел до того, что самосбор из бытовых комплектующих работает не хуже и в надежности не уступает профессиональным решениям…
«Комбайн» применительно к серверам — это когда один несчастный комп и натит, и шейпит, и роутит, держит локальный сайт, файлопомойку, а админ еще думает, как бы туда CS-сервер прикрутить… :-) Такого, конечно же, допускать нельзя — тут я с вами совершенно согласен.
И в любом случае нельзя забывать о такой вещи как доступность. В комментах на это уже обратили внимание, к слову говоря: если железка от крупного вендора сдохнет (а такое тоже бывает, ага), то единственный вариант — ждать такую же. А дорогих железок (а все «софтовые» Циски/Жуниперы как ни крути — дорогие) на складах обычно россыпи не валяются… А заранее вторую покупать — это разориться в конец можно… С серверами такого нет никогда.
Очень показательны в этой связи рассказы одного человечка на nag.ru, который работал в телекоме в Ливане (если память не изменяет) во время войны. Они смогли сохранить бизнес только за счет того, что использовали широкодоступные комплектующие (компы то есть): граница почти закрыта, импорта нет, ждать замены железок — нереально. А менять надо часто, т.к. вообще-то бомбы падают. :-) Обычного компьютерного железа, купленного до войны на складах в магазинах было достаточно, чтобы позволить без проблем поддерживать инфраструктуру провайдера.
В «серьезном» оборудовании разнообразных функций/компонентов не меньше, чем в компе — всякие слоты для расширения функциональности и добавления интерфейсов, модули для флеш-памяти и так далее… В общем, все вполне сравнимо, если не наоборот: что такое материнская плата — 2-3 чипа и обвязка. А в «железном железе» частенько элементов-то как раз побольше будет — достаточно фотки внутренностей посмотреть. Это только копеечные wifi-роутеры из одного чипа и памяти состоят. :-)
Опять же, никто не заставляет собирать сервер самому. А промышленные решения как раз пятиканального звука и оптического SPDIF'а обычно лишены. :-) Правда, мой опыт показывает, что уровень качества массовых продуктов дошел до того, что самосбор из бытовых комплектующих работает не хуже и в надежности не уступает профессиональным решениям…
«Комбайн» применительно к серверам — это когда один несчастный комп и натит, и шейпит, и роутит, держит локальный сайт, файлопомойку, а админ еще думает, как бы туда CS-сервер прикрутить… :-) Такого, конечно же, допускать нельзя — тут я с вами совершенно согласен.
И в любом случае нельзя забывать о такой вещи как доступность. В комментах на это уже обратили внимание, к слову говоря: если железка от крупного вендора сдохнет (а такое тоже бывает, ага), то единственный вариант — ждать такую же. А дорогих железок (а все «софтовые» Циски/Жуниперы как ни крути — дорогие) на складах обычно россыпи не валяются… А заранее вторую покупать — это разориться в конец можно… С серверами такого нет никогда.
Очень показательны в этой связи рассказы одного человечка на nag.ru, который работал в телекоме в Ливане (если память не изменяет) во время войны. Они смогли сохранить бизнес только за счет того, что использовали широкодоступные комплектующие (компы то есть): граница почти закрыта, импорта нет, ждать замены железок — нереально. А менять надо часто, т.к. вообще-то бомбы падают. :-) Обычного компьютерного железа, купленного до войны на складах в магазинах было достаточно, чтобы позволить без проблем поддерживать инфраструктуру провайдера.
по выше сказанному можно лишь сделать только один вывод: к телекомам вы имеете отношение ровно такое же, как картошка к тропическим фруктам.
Вы не могли бы пояснить подробнее, что именно вас натолкнуло на такой вывод? :-) Или вы относитесь к хардкорным православным тру-связистам, для которых, скажем, Ethernet и SIP — ересь, а рулят только ATM и ОКС-7? ;-) Я не с точки зрения наехать, просто я действительно удивлен вашим сообщением: это всегда странно, когда в треде резко появляется человек и сходу заявляет, что кто-то в треде — дурак. :-) Т.е., это весело, конечно, но как-то неконструктивно. Опять же — следует ожидать, что вы позицию автора топика тоже не разделяете? Однако, этого в ваших комментах к топику не видно…
Одним словом, хотелось бы, чтобы вы более подробно выразили свою позицию и мнение по обсуждаемому вопросу. :-)
Одним словом, хотелось бы, чтобы вы более подробно выразили свою позицию и мнение по обсуждаемому вопросу. :-)
не надо выдавать желаемое за действительное. дураком я никого не обзывал. я лишь заметил что всё это имеет мало общего с телекомом. я не спорю что домушние сети собранные любителями линукса ради проведения домой себе интернета вряд ли могут позволить купить себе какую вундервафлю (однако есть примеры как такие сети покупали себе б/у фаундри/циско/жунипер и в ус не дули довольные покупкой :)), но и вобщем-то со всеми вытекающими. :)
да, с позицией автора топика и многих в откомментировавших я не согласен. тут считают что «Не Linux в провайдинге используют разве что самые неадекватные». со сторонниками этой идеи я не имею большого желания вести долгую и нудную палемику об очевидных вещах. я хочу лишь чтобы сторонники этой идеи пошли к ростелекому, ретн.нету, транстелекому, телии и многим другим операторам связи и рассказали о том как они ошибаются, ведь можно сэкономить и использовать линукс, мужики-то ведь не знают, ога. кстати, их всех только что назвали неадекватными. мне на такие заявления нечего сказать, я просто не найду подходящих слов чтобы быть понятым сообществом.
кстати, не смотря на все заявления про линукс, автор топика таке купил для ната cisco asa, а для погранца cisco asr. не кажется что одно протеворечит другому? да, не озаботились резервом, но это проблемы кастомера, чо уж. быть годным оператором связи нынче накладно, суетно и вовсе не сулит золотые горы. :)
автор топика, кстати, рассказывает про сооружения аварийных костылей о которых не было подумано вначале и риски не были правильно оценены. это уже тут общество провозгласило культ линукса на не совсем понятной почве.
да, с позицией автора топика и многих в откомментировавших я не согласен. тут считают что «Не Linux в провайдинге используют разве что самые неадекватные». со сторонниками этой идеи я не имею большого желания вести долгую и нудную палемику об очевидных вещах. я хочу лишь чтобы сторонники этой идеи пошли к ростелекому, ретн.нету, транстелекому, телии и многим другим операторам связи и рассказали о том как они ошибаются, ведь можно сэкономить и использовать линукс, мужики-то ведь не знают, ога. кстати, их всех только что назвали неадекватными. мне на такие заявления нечего сказать, я просто не найду подходящих слов чтобы быть понятым сообществом.
кстати, не смотря на все заявления про линукс, автор топика таке купил для ната cisco asa, а для погранца cisco asr. не кажется что одно протеворечит другому? да, не озаботились резервом, но это проблемы кастомера, чо уж. быть годным оператором связи нынче накладно, суетно и вовсе не сулит золотые горы. :)
автор топика, кстати, рассказывает про сооружения аварийных костылей о которых не было подумано вначале и риски не были правильно оценены. это уже тут общество провозгласило культ линукса на не совсем понятной почве.
Ну вот так бы сразу! А то картошка, фрукты тропические… Как раз разве что дураком не назвали. :-)
А по теме — не нужно, ИМХО, все валить в одну кучу. Магистральный провайдинг, работа с юриками и работа с физиками — это все совершенно разные вещи. Как раз ошибаются те, кто пытается навязать одни и те же стандарты для совершенно разных сфер телекома. Много ли надо ТТК или Ретну шейпить (не тупо скорость резать на порту, а нарезать каждому индивидуальному IP отдельную полосу) или NAT'ить? Думается, не особо. А pc-сервера именно для этих задач большей частью и используются (на уровне доступа/агрегации делать это как раз зло, о чем я в первую очередь и сказал автору).
Опять же, если вы посмотрите на городские сети для обслуживания физ.лиц, то они будут выглядеть примерно одинаково, что у провайдера на 5 тыс. человек, что на 10 тыс., что на 50 тыс… Достаточно тот же форум Нага почитать, чтобы в этом убедиться. Печально все только у совсем мелких, но они на то и совсем мелкие. :-)
А что касается автора, то надо его спросить еще, насколько все у них потом шоколадно с ASA сложилось.
Если резюмировать: мухи должны быть отдельно, а котлеты — отдельно. Если меня позовут работать в ТТК (хотя зачем я им нужен?), то я не буду там роутить многогигабитные потоки на Линуксе — это, разумеется, бессмысленно. Но если меня позовут техническим директором в какой-нибудь небольшой телеком на несколько тысяч абонентов (или, тем более, в новый проект, который с нуля делать начинают, а значит по возможности и деньги лишние тратить не надо, и губы сразу раскатывать тоже — неизвестно, как вообще бизнес пойдет), то я не вижу причин, почему не надо шейпить, NAT'ить и, допустим, терминировать PPPoE/PPTP на компе. :-)
А по теме — не нужно, ИМХО, все валить в одну кучу. Магистральный провайдинг, работа с юриками и работа с физиками — это все совершенно разные вещи. Как раз ошибаются те, кто пытается навязать одни и те же стандарты для совершенно разных сфер телекома. Много ли надо ТТК или Ретну шейпить (не тупо скорость резать на порту, а нарезать каждому индивидуальному IP отдельную полосу) или NAT'ить? Думается, не особо. А pc-сервера именно для этих задач большей частью и используются (на уровне доступа/агрегации делать это как раз зло, о чем я в первую очередь и сказал автору).
Опять же, если вы посмотрите на городские сети для обслуживания физ.лиц, то они будут выглядеть примерно одинаково, что у провайдера на 5 тыс. человек, что на 10 тыс., что на 50 тыс… Достаточно тот же форум Нага почитать, чтобы в этом убедиться. Печально все только у совсем мелких, но они на то и совсем мелкие. :-)
А что касается автора, то надо его спросить еще, насколько все у них потом шоколадно с ASA сложилось.
Если резюмировать: мухи должны быть отдельно, а котлеты — отдельно. Если меня позовут работать в ТТК (хотя зачем я им нужен?), то я не буду там роутить многогигабитные потоки на Линуксе — это, разумеется, бессмысленно. Но если меня позовут техническим директором в какой-нибудь небольшой телеком на несколько тысяч абонентов (или, тем более, в новый проект, который с нуля делать начинают, а значит по возможности и деньги лишние тратить не надо, и губы сразу раскатывать тоже — неизвестно, как вообще бизнес пойдет), то я не вижу причин, почему не надо шейпить, NAT'ить и, допустим, терминировать PPPoE/PPTP на компе. :-)
> Как раз ошибаются те, кто пытается навязать одни и те же стандарты для совершенно разных сфер телекома.
расскажите это местному на моей деревне хоменету с 20 или сколько там тысячами абонентов, отчаяно пытавшемуся жить на телесинах и линуксах/бсдях, но таке сдавшемуся и купившему гору «котов» за гору денег. представте себе, они довольны.
> Много ли надо ТТК или Ретну шейпить (не тупо скорость резать на порту, а нарезать каждому индивидуальному IP отдельную полосу) или NAT'ить?
а что, хомяку надо больше что-то? хомяку как раз таке можно и вообще меньше :) не надо озадачиваться годными свищами на доступ способными нарезать скорость в обоих направлениях. ему как раз можно бриджующий полисер сунуть между ядром и погранцом и быть счастливым. вопрос с nat'ом решается так же. чего здесь сложного и страшного не очень понятно. цена решения от вендора первого эшелона? если уж вдаваться в детали, ну для nat'а у juniper'а есть на 500 мегабит железка где-то за 100 тыщ рублей. пролиант для этих затей не намного дешевле будет, если вообще будет.
> Опять же, если вы посмотрите на городские сети для обслуживания физ.лиц, то они будут выглядеть примерно одинаково, что у провайдера на 5 тыс. человек, что на 10 тыс., что на 50 тыс…
нет, не одинакого. у кого-то pppoe, у кого-то pptp, у кого-то «умный доступ» c vlan per user и на котах, у кого-то такой же доступ и на писючках с санным линуксом и лютыми лагами и печалью в фейловере. из «бесплатных» альтернатив меня только фряха с мпд и каром радует как впн-концентратор. всё остальное уныло чуть более чем полностью. ну да, думминетик во фряхе тоже удобен по тейбларгу в таблице гору динамических пайпов рожать. :))
> А что касается автора, то надо его спросить еще, насколько все у них потом шоколадно с ASA сложилось.
опять же если вдаваться в детали, то по моему скромному мнению — аса говно. но это уж наверно удел всего совка дрочить, плакать, колоться на циско, но всего равно её жрать. но это их выбор, возможно чем-то обусловлен даже.
> Но если меня позовут техническим директором в какой-нибудь небольшой телеком на несколько тысяч абонентов…
ппц, несколько тысяч абонентов и продолжать абать вола на линуксах. простите, конечно, но таких директоров надо гнать ссанными тряпками с такими их политиками.
расскажите это местному на моей деревне хоменету с 20 или сколько там тысячами абонентов, отчаяно пытавшемуся жить на телесинах и линуксах/бсдях, но таке сдавшемуся и купившему гору «котов» за гору денег. представте себе, они довольны.
> Много ли надо ТТК или Ретну шейпить (не тупо скорость резать на порту, а нарезать каждому индивидуальному IP отдельную полосу) или NAT'ить?
а что, хомяку надо больше что-то? хомяку как раз таке можно и вообще меньше :) не надо озадачиваться годными свищами на доступ способными нарезать скорость в обоих направлениях. ему как раз можно бриджующий полисер сунуть между ядром и погранцом и быть счастливым. вопрос с nat'ом решается так же. чего здесь сложного и страшного не очень понятно. цена решения от вендора первого эшелона? если уж вдаваться в детали, ну для nat'а у juniper'а есть на 500 мегабит железка где-то за 100 тыщ рублей. пролиант для этих затей не намного дешевле будет, если вообще будет.
> Опять же, если вы посмотрите на городские сети для обслуживания физ.лиц, то они будут выглядеть примерно одинаково, что у провайдера на 5 тыс. человек, что на 10 тыс., что на 50 тыс…
нет, не одинакого. у кого-то pppoe, у кого-то pptp, у кого-то «умный доступ» c vlan per user и на котах, у кого-то такой же доступ и на писючках с санным линуксом и лютыми лагами и печалью в фейловере. из «бесплатных» альтернатив меня только фряха с мпд и каром радует как впн-концентратор. всё остальное уныло чуть более чем полностью. ну да, думминетик во фряхе тоже удобен по тейбларгу в таблице гору динамических пайпов рожать. :))
> А что касается автора, то надо его спросить еще, насколько все у них потом шоколадно с ASA сложилось.
опять же если вдаваться в детали, то по моему скромному мнению — аса говно. но это уж наверно удел всего совка дрочить, плакать, колоться на циско, но всего равно её жрать. но это их выбор, возможно чем-то обусловлен даже.
> Но если меня позовут техническим директором в какой-нибудь небольшой телеком на несколько тысяч абонентов…
ппц, несколько тысяч абонентов и продолжать абать вола на линуксах. простите, конечно, но таких директоров надо гнать ссанными тряпками с такими их политиками.
1) Честно говоря не особенно понял, к чему вы это. Вы хотите сказать, что этот «хоменет» купил то же оборудование, которое использует ТТК/Ретн?
2) Ну вот как раз полисер и нарезка «динамических пайпов по тейбларгу» — это вообще-то две большие разницы. :-) Вопрос с НАТом я и не говорил, что сложно решается. Я лишь поинтересовался, где такие задачи есть у магистралов.
3) Вы видите принципиальную разницу между pppoe и pptp? :-) По мне — так один фиг. Немного конфиг того же mpd будет отличаться и все. :-) VLAN per user — все-таки для физиков не так часто встречается, ИМХО. Это же с Q-in-Q морочиться надо, да и вообще я лично против того, чтобы весь районный трафик в центр собирать — его там ворочать тяжело. Сейчас железки уровня доступа позволяют его адекватно фильтровать прямо на этом самом уровне доступа. Вот и пусть фильтруют, а межабонентский трафик пусть там и ходит…
Так или иначе, но сколько я городских ethernet-сетей по стране видел — все примерно одного плана. У кого-то больше компов и «рассыпуха» на доступе, а у кого-то — нормальные L2+ на доступе и L3 на агрегации. Но суть та же…
4) О том и речь. :-)
5) Конечно. Намного лучше, чтобы пришел такой директор, который сразу скажет, что нужно сразу дцать мильонов инвестиций в оборудование, иначе ничего не заработает. :-) Многие именно таких директоров очень любят как раз — с ними намного приятнее денежки инвесторов пилить. :-) И главное ведь не поспоришь! ;-)
2) Ну вот как раз полисер и нарезка «динамических пайпов по тейбларгу» — это вообще-то две большие разницы. :-) Вопрос с НАТом я и не говорил, что сложно решается. Я лишь поинтересовался, где такие задачи есть у магистралов.
3) Вы видите принципиальную разницу между pppoe и pptp? :-) По мне — так один фиг. Немного конфиг того же mpd будет отличаться и все. :-) VLAN per user — все-таки для физиков не так часто встречается, ИМХО. Это же с Q-in-Q морочиться надо, да и вообще я лично против того, чтобы весь районный трафик в центр собирать — его там ворочать тяжело. Сейчас железки уровня доступа позволяют его адекватно фильтровать прямо на этом самом уровне доступа. Вот и пусть фильтруют, а межабонентский трафик пусть там и ходит…
Так или иначе, но сколько я городских ethernet-сетей по стране видел — все примерно одного плана. У кого-то больше компов и «рассыпуха» на доступе, а у кого-то — нормальные L2+ на доступе и L3 на агрегации. Но суть та же…
4) О том и речь. :-)
5) Конечно. Намного лучше, чтобы пришел такой директор, который сразу скажет, что нужно сразу дцать мильонов инвестиций в оборудование, иначе ничего не заработает. :-) Многие именно таких директоров очень любят как раз — с ними намного приятнее денежки инвесторов пилить. :-) И главное ведь не поспоришь! ;-)
1. я хочу сказать что как магистрала никто не обременяет натами, так и хомяка никто не обременяет мплсом на полмира. ценовой перевес явно не в сторону хомяка. у хомяка задачи гораздо скромнее и соответственно цена на инфраструктуру тоже. «купить кота» для хомяка и тоже самое для магистрала — две большие разницы как по цене, так и по фичам. да и обслуживать спд на полмира явно накладнее чем например горсть раенов в городе.
2. а в чем разница, тем более «БОЛЬШАЯ»? :D
3. да, вижу. зачем q-in-q? зачем тащить трафик в ядро? ну и кто сказал что этого трафика будет много? в звезде у вас и так трафик между свичами ходит как минимум через агрегацию, ну добавится к нему трафик между портами на свичах, чо такого-то. или у вас порта доступа по полосе такие же как «магистральные» линки между свищами? вобщем я не хочу вдаваться в детали и полемику по ним, хотя уже вдался. :D если кратко, то нет, суть не та же.
4. нет, у вас речь о том что вместо асы надо поставить линукс, а у меня речь о том что при желании можно жить на вендорах первого эшелона, тем более уж в таком простом месте как хоменетик :) надо просто адекватно составлять себе список задач для железа.
5. хоменет из нескольких тысяч абонентов, а тем более нескольких десятков тысяч, без особых сложностей может позволить купить себе даже новых котов. ну да ладно, в разных местах наверняка разная планка «самоокупаемости» хоменета и его «прибыльности». не буду спорить о количестве абонентов. переформулирую: техдир игнорирующий возможность преобретать «нормальные» решения от вендоров и «экономящий» линуксом должен быть распят на кресте и выпорот ссаными тряпками. :)
ps: на вопросы из пункта 3 отвечать не надо. а то всё превратится в обмусоливание деталей. :)
2. а в чем разница, тем более «БОЛЬШАЯ»? :D
3. да, вижу. зачем q-in-q? зачем тащить трафик в ядро? ну и кто сказал что этого трафика будет много? в звезде у вас и так трафик между свичами ходит как минимум через агрегацию, ну добавится к нему трафик между портами на свичах, чо такого-то. или у вас порта доступа по полосе такие же как «магистральные» линки между свищами? вобщем я не хочу вдаваться в детали и полемику по ним, хотя уже вдался. :D если кратко, то нет, суть не та же.
4. нет, у вас речь о том что вместо асы надо поставить линукс, а у меня речь о том что при желании можно жить на вендорах первого эшелона, тем более уж в таком простом месте как хоменетик :) надо просто адекватно составлять себе список задач для железа.
5. хоменет из нескольких тысяч абонентов, а тем более нескольких десятков тысяч, без особых сложностей может позволить купить себе даже новых котов. ну да ладно, в разных местах наверняка разная планка «самоокупаемости» хоменета и его «прибыльности». не буду спорить о количестве абонентов. переформулирую: техдир игнорирующий возможность преобретать «нормальные» решения от вендоров и «экономящий» линуксом должен быть распят на кресте и выпорот ссаными тряпками. :)
ps: на вопросы из пункта 3 отвечать не надо. а то всё превратится в обмусоливание деталей. :)
Ох, мы с вами действительно все глубже и глубже зарываемся в мелочи. :-) Поэтому, если вы не против, я резюмирую свою позицию. Она состоит в том, что средства для выполнения цели надо выбирать исключительно исходя из своих потребностей, их возможностей по выполнению этой цели, удобству/простоте и соотношению цена/качество. Молиться не надо ни на вендоров первого эшелона, ни на *nix'овые сервера: и то и другое — религиозный фанатизм. Если задачу без ущерба для качества и т.п. можно решить на PC-сервере — надо это делать. Если задача решается на PC-сервере плохо/некачественно/неудобно_в_обслуживании/менее_надежно и т.п. — надо от этого уходить и искать другое решение удовлетворяющее необходимым критериям. Ряд задач лучше подходят для реализации на серверах, чем другие. Ряд задач не подходят вообще и решаются только на «железе». Если одну и ту же задачу с одними и теми же качественными результатами один человек решает на Циске, другой на Жунипере, третий на каком-нибудь китайском Ruijie, а четвертый — на *nix-сервере, то выбирать надо уже не исходя из религиозных соображений, а как раз исходя из цены, доступности соответствующим железок/комплектующих и так далее.
Делать икону что из серверов, что из Цисок/Жуниперов — неправильно. Это фанатизм головного мозга и именно того тех.директора, который не может мыслить гибко и креативно и искать наилучшее решение для конкретной задачи, а как стойкий оловянный солдатик держится всегда одного и того же способа, «который ему привычнее и роднее», — вот именно такого директора и надо гнать теми самыми тряпками. Dixi.
Делать икону что из серверов, что из Цисок/Жуниперов — неправильно. Это фанатизм головного мозга и именно того тех.директора, который не может мыслить гибко и креативно и искать наилучшее решение для конкретной задачи, а как стойкий оловянный солдатик держится всегда одного и того же способа, «который ему привычнее и роднее», — вот именно такого директора и надо гнать теми самыми тряпками. Dixi.
Ну если вам интересно ASA мы рассматривали для замены linux NAT. В результате не поставили потому что получалось дороже и хуже. Управлять да становилось проще, но сама железяка стоила много денег и не позволяла маленькими ступеньками наращивать необходимую мощность, так еще эта железяка не умеет столько всего трекить сколько умеет сейчас ядро linux.
В случае стоящего железа всегда надо загадывать, что оно сломается. Как результат если вам хватает PC роутера лучше купить их два и один держать в резерве чес купить на те же деньги один cisco роутер.
теперь буду смотреть на наши DI-604 с уважением… :)
вот-вот. звиздеть про опен соурс по телеку — все горазды. а как дело доходит — пожалуйста откатик за цисочки дайте или на лапу чтобы мы «закрыли глаза» на «эти ваши линуксы». :(
VLAN на пользователя? Суровые сибирские…
Что тут сурового? Суровое тут только то, что влан пер юзер ещё не дошёл до мухосрансков и многие товарищи воспринимают это как «ололо НЕХ». Не хочу шокировать, но почитайте ещё про технологии PON. Судя по всему, вообще глаза на стол выпадут с удивления от таких неведомых технологий :\
Ну вообще типичный MetroEthernet. Только в нем еще MPLS цепляют после точки агрегации :)
советуют купить Cisco или уж на совсем крайний случай Juniper
не соглашусь: на самый крайний случай советую купить Routerboard/Mikrotik
Как добрые люди делают NAT на Linux на пару тысяч абонентов?
Вопрос в алгоритме использования диапазона белых IP. Если делать NAT одним правилом iptables большую серую сеть на небольшую белую, то Linux будет случайном образом выделять белый IP для каждого потока от абонентов. В этом случае некоторые сайтики (vkontakte, например) перестают нормально работать.
Можно ли поменять алгоритм использования диапазона белых IP?
Workaround известен. Нужно делать NAT маленькой серой сетки на один белый адрес. Но не удобно как-то…
Вопрос в алгоритме использования диапазона белых IP. Если делать NAT одним правилом iptables большую серую сеть на небольшую белую, то Linux будет случайном образом выделять белый IP для каждого потока от абонентов. В этом случае некоторые сайтики (vkontakte, например) перестают нормально работать.
Можно ли поменять алгоритм использования диапазона белых IP?
Workaround известен. Нужно делать NAT маленькой серой сетки на один белый адрес. Но не удобно как-то…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Linux на службе у провайдера