[lagman]

И да, как там насчет NAT'а ?

Для ната возьмите любой транспорт, который через нат пройдет - и все будет ок :)

[SpheriX]

lagman

Вот и мне интересно. Чувак рассказывает какая классная штука NG, и тут же делает черезжопный пример. О чем это говорит ?

[lagman]

lagman

Вот и мне интересно. Чувак рассказывает какая классная штука NG, и тут же делает черезжопный пример. О чем это говорит ?

Спросите у "чувака", он не скрывает своего авторства. Я бы и без нетграфа сделал такое:

 

ifconfig gif0 create

ifconfig gif0 tunnel 1.2.3.4 5.6.7.8 up

ifconfig bridge0 create

ifconfig bridge0 addm fxp0 addm gif0 up

[nuclearcat]

Странно слышать такое от человека, ставящего 70 долларовый самосбор с линугзами на релейки.

Именно! Потому как он там уместен.

[lagman]

Именно! Потому как он там уместен.

Ну так какой самосбор, такая и армия. Как будет везде ынтерпрайз, тогда и будем равняться на прогрессивные армии :)

[nuclearcat]

Ну так какой самосбор, такая и армия. Как будет везде ынтерпрайз, тогда и будем равняться на прогрессивные армии :)

Когда работаешь за зарплату - не спорю.

А когда за процент - думаешь о надежном, cost effective решении, а не за бирочками и ынтырпрайзом гоняешься.

[Ivan_83]

То есть только через костыль в виде промиска? А почему не через бридж?

 

Поясните в чём костыль использования промиск?

 

Как можно бриджевать не включая промиск на сетевом адаптере?

 

 

[SpheriX]

Спросите у "чувака", он не скрывает своего авторства.

Меня нет на хабре и не предвидется.

Я бы и без нетграфа сделал

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

[NiTr0]

Естественно они сообщают об уже случившемся сбое.

дык как же тест может сообщать о надвигающемся сбое, если сбой уже случился-то? :)

 

Что непонятного-то?

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

и эти-то люди кричат, что синтаксис tc для htb qdisc непонятный и запутанный...

 

смарт является частью контроллера винта

да не является он частью контроллера. ибо в виде отдельного чипа не реализован еще.

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

[SpheriX]

Как можно бриджевать не включая промиск на сетевом адаптере?

Я ждал этого вопроса ;)

Никак, вот только функционал при просто сетевом интерфейсе в промиске и подключении полноценной реализации бриджинга несколько разный. Второй тунель до туда же в описаном варианте сделает кольцо с вполне предсказуемыми последствиями. Бридж же должен порвать кольцо и обеспечить отказоустойчивость. Естественно, в случае сложных конфигураций. Это к вопросу о придирках. Придираюсь в стиле БСДшиков.

[lagman]

подключении полноценной реализации бриджинга

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

[lagman]

дык как же тест может сообщать о надвигающемся сбое, если сбой уже случился-то? :)

Раньше узнаете о посыпавшемся винте, раньше замените, меньше вероятность потерять ценные данные. В дефолтном конфиге smartd готовый еженедельный полный тест есть. Который позволил диагностировать возникновение проблем уже у примерно десятка винтов и своевременно их заменить.

 

и эти-то люди кричат

Я - не кричу.

 

да не является он частью контроллера

У Вас и фирмварь не является частью контроллера винта, правда?

[pfexec]

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

мы же уже сравнивали tc и pipe + tablearg, где наглядно было видно где меньше букв и логичнее.

 

ng_car'ом конечно тоже можно, например mpd из коробки умеет вешать ng_car'ы ноды на ноды впн интерфейсов. просто и логично. сам нетграф это конструктор из которого воспользовавшись некоторой смекалкой можно собрать почти что угодно, завязаться на радуисы и так далее. хоть свой isg вкорячить.

The IPFIREWALL (IPFW)

Круто, роутим firewall-ом, лулзы, печалька. Хотя только что гыгыкали на утилиту ip.

несколько страниц назад я уже говорил про fib'ы и bird на freebsd. повторю еще раз. есть два способа управлять трафиком: filter based routing и policy based routing. в первом используем фаервол для того куда кинуть пакет, во-втором fib'ы. никто не заставляет "роутить фаерволом", более того, я уже говорил что роутить пакетным фильтром - это признак ФГМ терминальной стадии.

 

описаный тут вариант с ip и l2tp-туннелями гораздо симпатичнее того что писал ^rage^. но чтобы конструктивно его сравнить с netgraph'ом в аналогичных целях мне нужно как минимум попробовать жить с ip tools и решениями на базе его. но я не планирую этого делать ни сейчас, ни в близжайшем будущем.

 

ну и да, у freebsd есть и другие варианты делать ядерные туннели помимо нетграфа. есть ifconfig (gif|gre)X create и if_bridge куда можно совать вместе с влан интерфейсами это дело. да и использовать его как парент для влана интерфейса никто не мешает так то. количество строчек и их очевидность рискует быть даже меньше чем у примера с ip. чо уж.

Ну и по NG, чтобы два раза не вставать. Чем больше вы про него тут пишете, тем больше создается ощущение, в том, что создан он от безысходности.

каждый инструмент создается для какой то цели. иметь гибкую сетевую модель которую можно использовать везде - такая была цель у netgraph'а и она выполнена. иметь гибкую дисковую подсистему - цель geom'а, и она тоже выполнена. в чем тут безисходность не понятно. может в том что нету тысячи однотипных инструментов для выполнения одной задачи в угоду религиозным предпочтениям масс ? ну я думаю что это не надо.

А когда за процент - думаешь о надежном, cost effective решении, а не за бирочками и ынтырпрайзом гоняешься.

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

[taf_321]

Ну так какой самосбор, такая и армия. Как будет везде ынтерпрайз, тогда и будем равняться на прогрессивные армии :)

 

По лету один Мегателеком организовывал канал связи для своего местечкового представительства. Привезли какой-то джунипер, чтобы он и интернет шлюзовал, и VPN до головного охфиса натягивал. 2 дня их местный эникейщик и спец из Хабаровска имели БДСМ, ну вот не хотит хваленый мегаджунипер подывать pppoe, хоть тресни. Когда подняли pppoe выяснили, что по нему vpn уж он точно отказывается подымать. За день до открытия филиала подарили им от лица компании желтушнейший DI-804HW, который у них там так до сих пор и работает. А джунипер в шкафчике в упаковке лежит, для отчетности. Цена блинка 50 баксов в базарный день, цена того джунипера $1000.

[taf_321]

аждый инструмент создается для какой то цели. иметь гибкую сетевую модель которую можно использовать везде - такая была цель у netgraph'а и она выполнена. иметь гибкую дисковую подсистему - цель geom'а, и она тоже выполнена. в чем тут безисходность не понятно. может в том что нету тысячи однотипных инструментов для выполнения одной задачи в угоду религиозным предпочтениям масс ? ну я думаю что это не надо.

 

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

 

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

 

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

 

Как думаешь, решения на фряхе, которые наколеночны чуть больше, чем все, выживут в строгом соответствии с твоими требованиями?

Изменено 4 февраля, 2012 пользователем taf_321

[Deac]

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

Модуль рулит ASIC-ами, во FreeBSD ему делать нечего.

[pfexec]

По лету один Мегателеком организовывал канал связи для своего местечкового представительства. Привезли какой-то джунипер, чтобы он и интернет шлюзовал, и VPN до головного охфиса натягивал. 2 дня их местный эникейщик и спец из Хабаровска имели БДСМ, ну вот не хотит хваленый мегаджунипер подывать pppoe, хоть тресни. Когда подняли pppoe выяснили, что по нему vpn уж он точно отказывается подымать. За день до открытия филиала подарили им от лица компании желтушнейший DI-804HW, который у них там так до сих пор и работает. А джунипер в шкафчике в упаковке лежит, для отчетности. Цена блинка 50 баксов в базарный день, цена того джунипера $1000.

vpn'ы поверх pppoe печальная затея хоть где. не понимаю зачем так жить. насчет конкретного сценария ничего не прокомментирую, потому что выбираю провайдеров только с ipoe, посему банально не сталкивался с таким. и не понимаю, почему купив железно за $1k не было возможности договориться с провайдером об ipoe и жить спокойно.

Если NG настолько гибкая, мощная и надежная вещь, то почему тот же джунипер в своей ОС этим не пользуется, а запиливает собственный ядерный модуль, сведя всю задачу остальной части ОС только к как можно быстрой и эффективномой передаче пакета с данным от сетевухи к ядру и обратно?

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

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

о каких локах речь ? если что на J только одноядреные процессоры. ну а на SRX на каждое отдельное ядро вешается отдельная подсистема. модуль не засвечивают и не будут засвечивать по тем же причинам по которым cisco не торопится показывать внутренности ios'а или microsoft внутренности windows. маркетинг и конкурентные преимущества. если любой писюк сможет делать то же что делает такой же писюк но с junos'ом, то смысла в j-series резко поубавится. мипс-порт не дает никаких конкурентных преимуществ, его и вернули.

Как думаешь, решения на фряхе, которые наколеночны чуть больше, чем все, выживут в строгом соответствии с твоими требованиями?

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

Модуль рулит ASIC-ами, во FreeBSD ему делать нечего.

речь про fwdd/flowd в софтовых коробках.

[NiTr0]

У Вас и фирмварь не является частью контроллера винта, правда?

Не является. Ибо во-первых фирмвари в том контроллере - кот наплакал, реально - только загрузчик, необходимый для загрузки собссно фирмвари с блинов. У сигейтов к примеру на плате всего 64к флэшка, а объем фирмвари на блинах - эдак под мегабайт... Так что учите матчасть.

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

 

мы же уже сравнивали tc и pipe + tablearg, где наглядно было видно где меньше букв и логичнее.

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

[Deac]

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

На это есть queue, с io_fast=1

[SpheriX]

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

Самому понятно, что спросил ?

На это есть queue, с io_fast=1

Поворот в разные повороты разными по диаметру рулями, да.

[Deac]

Поворот в разные повороты разными по диаметру рулями, да.

Как-то слишком тёмно изъясняешься, слишком по линуховски. :)

Что конкретно, в связке pipe + queue + tablearg не устраивает?

[taf_321]

vpn'ы поверх pppoe печальная затея хоть где. не понимаю зачем так жить. насчет конкретного сценария ничего не прокомментирую, потому что выбираю провайдеров только с ipoe, посему банально не сталкивался с таким. и не понимаю, почему купив железно за $1k не было возможности договориться с провайдером об ipoe и жить спокойно.

 

Вот так получилось, что иначе нельзя. Про ipoe only расскажи тем, кому только ADSL светит и никаких альтернатив. Ну и опять же, у толпы народа ipsec'и через pppoe живут себе и не чихают. бухгалтерии, карточные терминалы, телефоны, видеоконференции и видеонаблюдение бегает и не спотыкается. А вот у ынтерпрайза не срослось.

 

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

А что сейчас-то мешает им сделать? Бери и применяй, а самопил на свалку.

 

о каких локах речь ?

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

[SpheriX]

Deac

Инструмент не один.

[Deac]

Инструмент не один.

Налицо явное незнание предмета.

Инструмент один, называется DUMMYNET.

[nuclearcat]

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

Есть принципиальная разница в классе специалиста:

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

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

2)Может применить типовые решения. Работодателю будет стоить или средств поставить такому кондиционирование+гарантированное питание+энтерпрайз решения на 140 точках, или нервов убедить его, что это нецелесообразно. Естественно такой специалист будет стремиться к наименьшему гемморою для себя любимого, и начхать ему на расходы работодателя. Соответственно зарплата его будет грустной, "в рамках рынка". С большим шансом, что если контора большая, и таких много - их будут "оптимизировать" и увольнять, а то и вообще отдадут админство в оутсорс.