устаревшее хорошее железо и устаревшее железо какбэ разные вещи. я не против видеть в стойках sunfire v120 и иже с ними, если их хватает на жизнь. равно как и остальной брэнднейм. но я не совсем понимаю в чем должно хватать самосборного на коленке целерона на виа чипсете и марвелл сетевыми картами, — если то чем он занимается приносит хотя бы хоть какую-то прибыль в каком-то виде, то стыдно не привести его в порядок. я что-то в этом духе имел ввиду.
да, *amp нынче моден, беспощаден и бессмысленен. ну разве что на каких-то больших хостингпровайдеров где без htaccess'а ни туда, ни сюда. но вобщем выбор софта дело каждого, кому-то опач, кому-то nginx, кому-то лайтшттпд…
смотря какой и где десктоп :) на работе, да, freebsd раньше, нынче opensolaris из-за необходимости кукожить на рабочем месте контейнеры и зфс. дома — виндовс.
не подумайте плохого, я пробовал линагз держать на десктопе. ну да, можно жить, вполне. только он не может предложить ничего что требуется для работы или досуга, а значит лично для меня он бесполезен. кстате, самым отвратным линагзом об который я марался был как раз таке fedora (или тогда он еще fedore core назывался), а самыми приятными были gentoo и arch. правда когда надоедает вечная компиляция и пляска вокруг передовых технологий весьма симпатично смотрится debian. но в любом случае, какая бы симпатичная у него не была обертка линагз остается линагзом…
проще следить за тем что прикрутил на пустой хост, чем разбираться с тем что насовале туда пидоровцы и разбираться что нужно, а что нет. ну и к тому же у меня крайне печальный опыт со всеми этими пидорами и рхелами, и вообще с rpm-based дистрибутивами. «прекрасно» любые линагзы на любом железе так же не работает, как и всё остальное. разница лишь в том что (open)solaris побрезговали поддержкой гавна железа (хотя и работают в этом направлении с целью популизации), а линугсятники до фанатичности готовы выбрасывать проприеритарные драйверы заменяя своими опынсурсными заглушками (как это с nvidia вышло). впрочем ваше утверждение что гавно с линагзом становится конфеткой лишь свидетельстует о том что ничего более значительного домашнего порнофтпсервера вы не делали… :\
долбоебы-недолбоебы, но произнести эту мерзопакость в слух правильно у меня язык отвалится. да, я презираю линагз: Р
зачем использовать дистрибутив из которого надо что-то выпиливать? почему не взять арч и собрать то что нужно?
насчет «zfs очень грузит систему» — не согласен. да, на любимый линугсятниками морально устаревший металолом его ставить глупо, да. а на новеньких серверах очень задорно крутится и вобщем-то ставит под сомнение вообще существования аппаратных RAID-контроллеров.
«это попытки ухода от xorg.conf» — это желание не пидорестроителей, это xorg пошел по пути plug-n-play под ручку с hal, что впрочем-то уж точно не плохо.
«Да, linux правильно произносится как «линукс».» — типа откровение? вас цепляет за душу? тогда «линагз-линагз-линагз-линагз-линагз-линагз-линагз-линагз» :D
ну какбэ все грядущие нововведения для solaris 11 (xvm, crossbow, ips и что там еще по мелочи) сейчас доступны в опене. и доступны весьма давно как видимо с целью обкатывания широкими массами. для чего же еще нужны все эти опен дистрибутивы? это как минимум экономия на затратах тестирования и отлова косяков. так же как федоре линагз ниразу не пригоден к использования, так же и опенсалярис использовать только на свой страх и риск.
учим матчасть. opensolaris является своеобразным куррентом разработки для solaris, точнее не совсем opensolaris. opensolaris базируется на SXCE/SXDE сборках, что вобщем особо ничего не меняет.
syscons не умеет utf, в остальном нет никаких препядствий. честно сказать utf для syscons'а вобщем-то и не нужен особо… много ли вы сидите с консоли? если сервер, то обычно ssh, если десктоп, то окошечки там разные…
выбор что использовать и для чего должен решать специалист, а не маркетасты с их гавнотендерами. т.е. решено использовать M$, как в данном случае, пишется тендер на лучшего интегретора M$ решений. а раз уж открыто это нельзя написать по закону, то вот изгаляются. но что уж поделать, такие вот извращенные законы в роиссе. не для кого это не секрет.
и что такого? очевидно заказчик хочет получить именно Microsoft по каким-то причинам, например имеет специалистов работающих с ПО M$ в штате. что в этом плохого? это лучше чем разводить зоопарк выбирая от тендера к тендеру то windows, то какой-нибудь сусе линагз, то редхат линагз, то еще что. зачем?
вы вкурсе что в скором времени, например, для тендера для оборудования для СПД необходим будет (или уже необходим) пункт о том что оно произведено в роиссе? циско и жунипер носом поворотили строить заводы на территории роисси, т.е. альтернатив алкатель-люцент нет. и в этом контексте не вижу ничего плохого в тендере писать циско-специфичные штуки, например поддержку eigrp протокола, косвенно указывая на этого вендора.
и, да, лучше стабильно использовать что-то одно, пускай так всеми нелюбимое (необосновано?), чем прыгать от линагза к линагзу как всем хочется и иметь перманентно меняющуюся инфраструктуру…
ойли? прямо таке несколько туннелей с одним dstip? соль проблемы в том что pf nat во freebsd не умеет (не умел) разделять gre туннели по Key и ставить в оба конца не нулевые значения.
в openbsd, да, pf nat давно уже как gre passthrough. во freebsd до 7ой ветки включительно нет. в 8ке вроде проскакивал порт свежего pf. поэтому возможно оно уже.
насчет судьбы его мне мало известно, но судя по всему он до сих пор не принят как-то :( однако, использования сендвича фиреволов тоже не решение проблемы. в данном случае на мой взгляд самый лучший вариант использовать ng_nat вместо pf. а чтобы оно протекало, да, надо будет слегка потанцевать :)
да, вы правы Ж) я всегда много не договариваю, так, только по верхушкам скачу :) могу и договорить, но тогда это потянет на отдельную статью, а ее писать, проверять орфографию и прочей ерундой заниматься у меня особо желания нет :( извиняйте если я вот так коряво :)
если речь про гигОбайт или гигАбайт, то не придерайтесь. если речь о том что я путаю биты с байтами, то покажите где. вроде не путаю, может очепятался :(
насчет информации, ну блин, я же не статью пишу :) я так, в камментах ерундой страдаю :) вовсе не значит что то что я говорю это догматичная истина. :(
> Получается, что Джуниперы эти — совсем дохлые? Странно: НАТ не более нагруженная операция, чем маршрутизация. Во всяком случае у меня циски валились от НАТа только когда сеть цепляла червя.
ойли? а что тогда 7200 + npe-G2 при нате ласты заворачивает? да чо уж нат, она и при обычном форвардинге ласты завернет гораздо раньше чем до гигобита доживет.
странно вообще от тебя слышать про нат такое. Оо
вообще маршрутизация выполняется на cef, что есть на любом cisco router'е или почти на любом. netflow export выполняется почти там же, поэтому утилизация при netflow export'е почти не меняется. а вот операция nat'а выполняется софтварно, т.е. на процессоре. или просто так спицально для nat'ов продают ace модуль за кучу денег для 6500-7600 решений?
данные «жуниперы» относятся к линейке J-series, что есть вобщем-то офисные маршрутизаторы, точнее фиреволы. по-умолчанию с junos 9.Х они работают во flow-based режиме и превращаются в пакетный маршрутизатор путем добавления нескольких магических комманд и переводом в packet-based режим. они целиком софтовые, т.е. и менеджмент устройства и форвардинг выполняется на _одном_ процессоре. да и если посмотреть во внутирь будет виден обычный писюк с целероном 2.5ГГц на борту :) однако, если нет желание маршрутизировать более гигобита трафика, то J-series очень вкусное решение. но, конечно, семплить с него нетфлоу или резать полисерами трафик на несколько тысяч абонентов при этом странная затея, примерно такая же как и натить при помощи cisco 7200 + npe-G2 :)
ахахаха Ж)) на софтой J-series снимаете netflow sampling? :D они ведь по-другому не умеют. да и железку ушатываете не понять чем ) и да, как на это все смотрят метрологи, когда вы билленгуете по скажем каждому 100ому пакету? есть сертификат и бумажки? :)
потому что с одной стороны кто-то там плачется что с производительностью плохо, а с другой стороны никого не смущает гонять трафик через два фиревола и ожидать при этом чудес. :)
я понимаю что в pf altq'ой не порежешь как думминетом по маске пер ойпи таблицу из префиксов парой строчками в конфиге, но раз был сделан выбор на ipfw + dummynet, то почему нельзя было использовать тогда уж ng_nat, которые уже наверно как вечность стабилен и готов к использованию (да-да, иногда что-нибудь ломают в нем, но если не жить на блейд-эдж технологий, то все будет успешно работать). во freebsd кстате есть тьма ядерных натов, большая часть из которых умеет работать с ipfw :) помимо ng_nat сюда можно отнести и ipnat от анахронизма в виде ipfilter. к тому же, до недавненго времени во freebsd pf nat не умел gre через себя пускать, а с ftp он так и не дружит особо. держит ftp-proxy или как его на лупбаке?
кстате, сам по себе pf и его nat, и его шейпер весьма и весьма шустры. возможно шустрее и ipfw. тут какбэ я не очень хочу разжигать холивары между любителями ipfw и pf. но вот как-то так, да.
а главная унылость схемы заключается в концепции резервирования. например, почему на каждом 4350 именно по отдельному аплинку? что, при необходимости проапгрейдить на одном из них junos будете опускать целиком весь аплинк? чем это все аргументировано? отстутвием пары килобаксов на память для 4350 чтобы уместить пару таблиц full-view в него? т.е. какбэ получается при выходе из строя всего лишь одного из 4350 мы теряем и маршрутизатор и второй аплинк. :( имхо не очень хорошо.
далее, ваша схема и приведенные конфиги противоречат друг другу, что из них правильно? если схема, то получается совсем все печально. зачем вам фуллвью, если выбор маршрута все равно выбирается на основании наличия дефолтного префикса от писюковых натошейперов? т.е. фактически сравнения всей фуллвью по атрибутам бгп и выбора наилучших маршрутов между двумя таблица от двух провайдеров не происходит. зачем тогда это все нужно?
мне кажется надо чуть лучше все таки готовиться и писать такие статьи, ну или хотя бы понимать о чем идет речь.
пс: и да, поллинг не есть хорошо. на хорошие сетевые карты опять же не хватило денег или не хватило терпения докрутить гайки в sysctl?
ппс: все эти писироутиры — это все как-то не айс :) cisco isg — вот это айс :)
унылая статья, унылая концепция границы и ядра спд :( таких затейников-домушников полроисси. и да, два фиревола — это пять. вобщем дальше я не осилил прочитать. :(
впрочем ладно, кто во что горазд, тот так и строит. :(
бай зэ вей, мне вот очень интересно, в каком месте вы тут производите учет проданных абонентам услуг?
да, *amp нынче моден, беспощаден и бессмысленен. ну разве что на каких-то больших хостингпровайдеров где без htaccess'а ни туда, ни сюда. но вобщем выбор софта дело каждого, кому-то опач, кому-то nginx, кому-то лайтшттпд…
смотря какой и где десктоп :) на работе, да, freebsd раньше, нынче opensolaris из-за необходимости кукожить на рабочем месте контейнеры и зфс. дома — виндовс.
не подумайте плохого, я пробовал линагз держать на десктопе. ну да, можно жить, вполне. только он не может предложить ничего что требуется для работы или досуга, а значит лично для меня он бесполезен. кстате, самым отвратным линагзом об который я марался был как раз таке fedora (или тогда он еще fedore core назывался), а самыми приятными были gentoo и arch. правда когда надоедает вечная компиляция и пляска вокруг передовых технологий весьма симпатично смотрится debian. но в любом случае, какая бы симпатичная у него не была обертка линагз остается линагзом…
долбоебы-недолбоебы, но произнести эту мерзопакость в слух правильно у меня язык отвалится. да, я презираю линагз: Р
насчет «zfs очень грузит систему» — не согласен. да, на любимый линугсятниками морально устаревший металолом его ставить глупо, да. а на новеньких серверах очень задорно крутится и вобщем-то ставит под сомнение вообще существования аппаратных RAID-контроллеров.
«это попытки ухода от xorg.conf» — это желание не пидорестроителей, это xorg пошел по пути plug-n-play под ручку с hal, что впрочем-то уж точно не плохо.
«Да, linux правильно произносится как «линукс».» — типа откровение? вас цепляет за душу? тогда «линагз-линагз-линагз-линагз-линагз-линагз-линагз-линагз» :D
вы вкурсе что в скором времени, например, для тендера для оборудования для СПД необходим будет (или уже необходим) пункт о том что оно произведено в роиссе? циско и жунипер носом поворотили строить заводы на территории роисси, т.е. альтернатив алкатель-люцент нет. и в этом контексте не вижу ничего плохого в тендере писать циско-специфичные штуки, например поддержку eigrp протокола, косвенно указывая на этого вендора.
и, да, лучше стабильно использовать что-то одно, пускай так всеми нелюбимое (необосновано?), чем прыгать от линагза к линагзу как всем хочется и иметь перманентно меняющуюся инфраструктуру…
в openbsd, да, pf nat давно уже как gre passthrough. во freebsd до 7ой ветки включительно нет. в 8ке вроде проскакивал порт свежего pf. поэтому возможно оно уже.
я сам очень сторонник и любитель pf, но что есть, то есть. в 8ку вроде портировали свежи pf, так что возможно там уже нет проблем с gre. :)
у вас ipfw тут только для того чтобы загонять траффик в dummynet. :( в рассылках пробегал патч для управления dummynet'ом напрямую из pf:
lists.freebsd.org/pipermail/freebsd-pf/2007-October/003849.html
people.freebsd.org/~remko/patches/dummynet_pf.tar.gz
насчет судьбы его мне мало известно, но судя по всему он до сих пор не принят как-то :( однако, использования сендвича фиреволов тоже не решение проблемы. в данном случае на мой взгляд самый лучший вариант использовать ng_nat вместо pf. а чтобы оно протекало, да, надо будет слегка потанцевать :)
насчет информации, ну блин, я же не статью пишу :) я так, в камментах ерундой страдаю :) вовсе не значит что то что я говорю это догматичная истина. :(
однако, мой опыт говорит о весьма заметном снижении производительности при nat'е. :(
вычитал в комментах что таке не по отдельному. ну да ладно. :(
ойли? а что тогда 7200 + npe-G2 при нате ласты заворачивает? да чо уж нат, она и при обычном форвардинге ласты завернет гораздо раньше чем до гигобита доживет.
странно вообще от тебя слышать про нат такое. Оо
вообще маршрутизация выполняется на cef, что есть на любом cisco router'е или почти на любом. netflow export выполняется почти там же, поэтому утилизация при netflow export'е почти не меняется. а вот операция nat'а выполняется софтварно, т.е. на процессоре. или просто так спицально для nat'ов продают ace модуль за кучу денег для 6500-7600 решений?
данные «жуниперы» относятся к линейке J-series, что есть вобщем-то офисные маршрутизаторы, точнее фиреволы. по-умолчанию с junos 9.Х они работают во flow-based режиме и превращаются в пакетный маршрутизатор путем добавления нескольких магических комманд и переводом в packet-based режим. они целиком софтовые, т.е. и менеджмент устройства и форвардинг выполняется на _одном_ процессоре. да и если посмотреть во внутирь будет виден обычный писюк с целероном 2.5ГГц на борту :) однако, если нет желание маршрутизировать более гигобита трафика, то J-series очень вкусное решение. но, конечно, семплить с него нетфлоу или резать полисерами трафик на несколько тысяч абонентов при этом странная затея, примерно такая же как и натить при помощи cisco 7200 + npe-G2 :)
я понимаю что в pf altq'ой не порежешь как думминетом по маске пер ойпи таблицу из префиксов парой строчками в конфиге, но раз был сделан выбор на ipfw + dummynet, то почему нельзя было использовать тогда уж ng_nat, которые уже наверно как вечность стабилен и готов к использованию (да-да, иногда что-нибудь ломают в нем, но если не жить на блейд-эдж технологий, то все будет успешно работать). во freebsd кстате есть тьма ядерных натов, большая часть из которых умеет работать с ipfw :) помимо ng_nat сюда можно отнести и ipnat от анахронизма в виде ipfilter. к тому же, до недавненго времени во freebsd pf nat не умел gre через себя пускать, а с ftp он так и не дружит особо. держит ftp-proxy или как его на лупбаке?
кстате, сам по себе pf и его nat, и его шейпер весьма и весьма шустры. возможно шустрее и ipfw. тут какбэ я не очень хочу разжигать холивары между любителями ipfw и pf. но вот как-то так, да.
а главная унылость схемы заключается в концепции резервирования. например, почему на каждом 4350 именно по отдельному аплинку? что, при необходимости проапгрейдить на одном из них junos будете опускать целиком весь аплинк? чем это все аргументировано? отстутвием пары килобаксов на память для 4350 чтобы уместить пару таблиц full-view в него? т.е. какбэ получается при выходе из строя всего лишь одного из 4350 мы теряем и маршрутизатор и второй аплинк. :( имхо не очень хорошо.
далее, ваша схема и приведенные конфиги противоречат друг другу, что из них правильно? если схема, то получается совсем все печально. зачем вам фуллвью, если выбор маршрута все равно выбирается на основании наличия дефолтного префикса от писюковых натошейперов? т.е. фактически сравнения всей фуллвью по атрибутам бгп и выбора наилучших маршрутов между двумя таблица от двух провайдеров не происходит. зачем тогда это все нужно?
мне кажется надо чуть лучше все таки готовиться и писать такие статьи, ну или хотя бы понимать о чем идет речь.
пс: и да, поллинг не есть хорошо. на хорошие сетевые карты опять же не хватило денег или не хватило терпения докрутить гайки в sysctl?
ппс: все эти писироутиры — это все как-то не айс :) cisco isg — вот это айс :)
впрочем ладно, кто во что горазд, тот так и строит. :(
бай зэ вей, мне вот очень интересно, в каком месте вы тут производите учет проданных абонентам услуг?