Комментарии 78
А если умрет l3 switch?
Ну Л3 свитч ставится обычно не один, а несколько :) по 12 домов на него цепляется. Да и можно с VRRP поиграться
Мне статья пришлась очень по душе.
Вот за такие статьи я и люблю хабр! Спасибо.
кстати по оспф-у там косяки у меня. можно было не прописывать
в router ospf 1
network
а сделать redistribute local.
статья и куски конфигов в ней очень старые)
в router ospf 1
network
а сделать redistribute local.
статья и куски конфигов в ней очень старые)
Не получится. Если не писать network то в этой сети (на этом линке) ОСПФ не заведется.
router ospf 1
router-id 172.16.48.32
log-adjacency-changes
redistribute connected metric 2 subnets
redistribute bgp 65000 metric 4 metric-type 1 subnets
network 10.249.0.8 0.0.0.3 area 0.0.0.0
default-information originate metric 100
!
я имел ввиду примерно вот такую конфигурацию :)
router-id 172.16.48.32
log-adjacency-changes
redistribute connected metric 2 subnets
redistribute bgp 65000 metric 4 metric-type 1 subnets
network 10.249.0.8 0.0.0.3 area 0.0.0.0
default-information originate metric 100
!
я имел ввиду примерно вот такую конфигурацию :)
Ну а я имел ввиду, что совсем отказаться от
network 10.249.0.8 0.0.0.3 area 0.0.0.0
не получится. Правда есть способ не анонсировать служебную сеть
10.249.0.8/30
Надо написать
network 10.249.0.8 0.0.0.0 area 0.0.0.0
Тогда ОСПФ на интерфейсе поднимется, но сеть /30 анонсироваться не будет.
network 10.249.0.8 0.0.0.3 area 0.0.0.0
не получится. Правда есть способ не анонсировать служебную сеть
10.249.0.8/30
Надо написать
network 10.249.0.8 0.0.0.0 area 0.0.0.0
Тогда ОСПФ на интерфейсе поднимется, но сеть /30 анонсироваться не будет.
Не обязательно перечислять все сети в network, если у вас софт выше чем 12.3(11)T.
Можно воспользоватся командой ip ospf ID area Area_ID, в контексте интерфейса.
Я пробовал здесь — techoover.blogspot.com/2008/05/vpn-ospf-over-gre-ipsec.html
Можно воспользоватся командой ip ospf ID area Area_ID, в контексте интерфейса.
Я пробовал здесь — techoover.blogspot.com/2008/05/vpn-ospf-over-gre-ipsec.html
Реализация интересная, как решается кого как шейпить?
При новых тарифах переписывать шейпер?)
При новых тарифах переписывать шейпер?)
для того чтобы прописать в /boot/loader.conf
kern.hz=«2000»
не обязательно пересобирать ядро.
kern.hz=«2000»
не обязательно пересобирать ядро.
Мощная статья. Но читается довольно трудно: я плохо разбираюсь в *нике, кто-то — в циске, кто-то в задачах полной избыточности.
У меня возник ряд вопросов: сервера (шейперы) стоят в-основном для связи с биллинговыми приложениями? Что используется для биллинга? Как считается трафик?
ПО какому принципу шейпите? Почему это нельзя сделать на 3560?
ИМХО, для ядра коммутации стоило бы поставить хотя бы парочку 3750 в стеке. Как раз для этого придумано.
Вы используете одновременно 2 канала? Как решается проблема с НАТ трансляциями? Трансляции делают шейперы, насколько я понял? А почему не сделать на Джуниперах? Они поддерживают stateful NAT?
У меня возник ряд вопросов: сервера (шейперы) стоят в-основном для связи с биллинговыми приложениями? Что используется для биллинга? Как считается трафик?
ПО какому принципу шейпите? Почему это нельзя сделать на 3560?
ИМХО, для ядра коммутации стоило бы поставить хотя бы парочку 3750 в стеке. Как раз для этого придумано.
Вы используете одновременно 2 канала? Как решается проблема с НАТ трансляциями? Трансляции делают шейперы, насколько я понял? А почему не сделать на Джуниперах? Они поддерживают stateful NAT?
А как на 3550/3560 сделать шейп для конкретного IP-адреса?
И не rate-limit возможно, а именно shape с очередью.
И не rate-limit возможно, а именно shape с очередью.
имел ввиду на порту. При ШПД очень часто клиент=интерфейс коммутатора.
Кстати, провайдеру скорее нужно делать не шейпер, а полисер (резать жестко, а не «в среднем»), иначе не ровен час — будут постоянные перегрузки железа.
при не очень широких полосах шейпер будет лучше.
во-первых, при загрузке канала на полную клиентом он будет наблюдать заметные потери пакетов, во-вторых, много трафика, предназначенного клиенту будет доходить до шейпера, загружая внешний канал.
во-первых, при загрузке канала на полную клиентом он будет наблюдать заметные потери пакетов, во-вторых, много трафика, предназначенного клиенту будет доходить до шейпера, загружая внешний канал.
WRED + policer на UDP?
Вам виднее — я не провайдер. Просто мне интересно, для пополнения собственной копилки решений.
Собсно, вскорости надо будет выползать из cisco-only решений, отсюда и интерес.
А вы предоставляете доступ по езернету? И при этом тарифы примерно как на АДСЛе?
Вам виднее — я не провайдер. Просто мне интересно, для пополнения собственной копилки решений.
Собсно, вскорости надо будет выползать из cisco-only решений, отсюда и интерес.
А вы предоставляете доступ по езернету? И при этом тарифы примерно как на АДСЛе?
ам… вообще «шейпить или полисить?» тонкий такой вопрос с кучей там всяких обстоятельств :( но есть о чем подумать, да. :)
Для биллинга используем дописанный UTM5, все скорости тарифов как и добавление и удаление из таблиц используем самописным модулем, поэтому для изменения скорости тарифа на всех маршрутизаторах достаточно поправить циферки в веб интерфейсе :) 3560 занимаются коммутацией и маршрутизацией пирингового и локального траффика, поэтому нарезание полос на нем не совсем уместно. Да одновремено используется два канала, весь NAT осуществляется прямо на шейперах. NAT на джуниперах не используем в связи с тем, что тупо не справятся при текущих потоках траффика
Не работал с UTM5 — он каким стандартом на вход данные требует? НетФлоу поддерживает?
Получается, что Джуниперы эти — совсем дохлые? Странно: НАТ не более нагруженная операция, чем маршрутизация. Во всяком случае у меня циски валились от НАТа только когда сеть цепляла червя.
шейпите по адресу источника, т.е. коммутационная сеть работает на скоростях выше тарифных. Перегрузок нет?
А как вы добиваетесь, чтобы пользователя не видели друг друга? PPTP? PPPoE?
Получается, что Джуниперы эти — совсем дохлые? Странно: НАТ не более нагруженная операция, чем маршрутизация. Во всяком случае у меня циски валились от НАТа только когда сеть цепляла червя.
шейпите по адресу источника, т.е. коммутационная сеть работает на скоростях выше тарифных. Перегрузок нет?
А как вы добиваетесь, чтобы пользователя не видели друг друга? PPTP? PPPoE?
Нетфлоу умеет, им и сливаем все с шейперов. Не, через джуниперы траффика много льется + несколько бгпфулвью.
Шейпим по адресу источника и по адресу назначения. А зачем добиватся чтобы юзеры друг друга невидели?) Нет такой нужды, предоставляем абонентам полный доступ к локальной сети и соседним операторам которые с нами в пиринге на скорости порта (до 100мбит/с), единственное что на уровне доступа ограничиваем — это режем броадкаст и нетбиос, вещание мультикастом и привязываем с помощью ACL выданный IP адрес абоненту на его порт
Шейпим по адресу источника и по адресу назначения. А зачем добиватся чтобы юзеры друг друга невидели?) Нет такой нужды, предоставляем абонентам полный доступ к локальной сети и соседним операторам которые с нами в пиринге на скорости порта (до 100мбит/с), единственное что на уровне доступа ограничиваем — это режем броадкаст и нетбиос, вещание мультикастом и привязываем с помощью ACL выданный IP адрес абоненту на его порт
А чем рулите такое кол-во ACL? Получается, что у вас все порты — L3? Или вы делаете vlan access-map?
Просто интересно.
Пользователей обычно делят (и я тоже небольшим провайдерам когда рисую картинки рекомендую) дабы не было беды, когда одна зараженная машина легко заражает соседей и в итоге лежит вся сеть и компы все болеют. Мне было бы неприятно обнаружить заразу на компе и отсутствие Инета :)
Я понимаю и плюсы: все всех видят, игрухи там, файлопомойка… Но ИМХО, так уже делать просто опасно. Я обычно рекомендую провайдерам (как правило, уже хлебнувшим :)) делать полноценный ДМЗ, с общими сервисами. МОжно за денеШку пользователям выделять там квоты, сервисы и пр. А хотят пириться — е-муль им в помощь :)
Просто интересно.
Пользователей обычно делят (и я тоже небольшим провайдерам когда рисую картинки рекомендую) дабы не было беды, когда одна зараженная машина легко заражает соседей и в итоге лежит вся сеть и компы все болеют. Мне было бы неприятно обнаружить заразу на компе и отсутствие Инета :)
Я понимаю и плюсы: все всех видят, игрухи там, файлопомойка… Но ИМХО, так уже делать просто опасно. Я обычно рекомендую провайдерам (как правило, уже хлебнувшим :)) делать полноценный ДМЗ, с общими сервисами. МОжно за денеШку пользователям выделять там квоты, сервисы и пр. А хотят пириться — е-муль им в помощь :)
не. vlan access-map делать не можем) на доступе используем Dlink DES-3526 и его весьма неплохие возможности. Ставить каталисты на доступ к физлицам — недешевое удовольствие да и совсем бесполезное а случаи с флудом или вирусными эпидемиями много беды не приносят, по крайней мере не затрагивают всех пользовалей. На каждый дом делаем свой отдельный влан
Я все же не понял, что и где фильтруется при помощи ACL?
И про деление пользователей: понятно, что каждому свою сеть — плохо, каждому свой ВЛАН — можно, но накладно. Но есть ещ технология private vlan, а также её дешевый аналог — protected ports.
Используя port protected все юзвери в одном ВЛАНе в рамках коммутатора, но видят только гейтвей и то, что вы явно разрешите.
И про деление пользователей: понятно, что каждому свою сеть — плохо, каждому свой ВЛАН — можно, но накладно. Но есть ещ технология private vlan, а также её дешевый аналог — protected ports.
Используя port protected все юзвери в одном ВЛАНе в рамках коммутатора, но видят только гейтвей и то, что вы явно разрешите.
Если уж пользователей делить — то надо делить совсем, т.е. — каждому по VLAN'у. А это уже совсем другие деньги и на уровне доступа, и на агрегации, и в ядре…
А если хочется сэкономить и убрать локал с ядра, то тогда уж лучше действительно выпустить всех в один большой L3-сегмент, но порезать на уровне L2 все потенциально опасное. К этому уже пришли многие большие операторы (та же Корбина в Москве), я у себя на сети делал также: около 3 с половиной тысяч человек в одной L3-сети чувствовали себя совершенно нормально. Современные железки L2 позволяют нормально зафильтровать все, чем могут пользователи повредить друг другу (автор комментарием выше тоже пишет — бродкаст, нетбиос и т.п.)… По крайней мере у меня никаких проблем не было…
А делить клиентов на отдельные L3-подсети в целях борьбы с вирусней и так далее — это уже прошлый век…
А если хочется сэкономить и убрать локал с ядра, то тогда уж лучше действительно выпустить всех в один большой L3-сегмент, но порезать на уровне L2 все потенциально опасное. К этому уже пришли многие большие операторы (та же Корбина в Москве), я у себя на сети делал также: около 3 с половиной тысяч человек в одной L3-сети чувствовали себя совершенно нормально. Современные железки L2 позволяют нормально зафильтровать все, чем могут пользователи повредить друг другу (автор комментарием выше тоже пишет — бродкаст, нетбиос и т.п.)… По крайней мере у меня никаких проблем не было…
А делить клиентов на отдельные L3-подсети в целях борьбы с вирусней и так далее — это уже прошлый век…
Угу. про что я и говорю, но имхо все-же еще стоить бить сеть на вланы. По влану на дом — самое то, а на агрегации держать Л3 коммутаторы для терминации домовых вланов. Делать один влан на 3к юзером имхо чревато, хотя доводилось работать и с такими сетями и оно прекрасно работало и работает до сих пор :)
см ответ топикстартеру: private vlan
Я с трудом себе представляю, как порезать на L2 многие бяки. Броадкаст с мультикастом — довольно легко. А торренты/скайпы/сервера? Часто и такая задача ставится (правда скорее не в домовых сетях, тут я до кучи написал :))
Я с трудом себе представляю, как порезать на L2 многие бяки. Броадкаст с мультикастом — довольно легко. А торренты/скайпы/сервера? Часто и такая задача ставится (правда скорее не в домовых сетях, тут я до кучи написал :))
Неее… Все эти private vlan, как бы они у каждого вендора ни назывались, — это все костыли. Либо от бедности, либо от неумения настроить все нормально на уровне доступа. Т.е. сколько-то лет назад смысл был: можно было покупать дешевые коммутаторы на доступ (у которых нет ничего, только private vlan), а резать все где-нибудь на агрегации. Но сейчас такой проблемы с оборудованием нет и взять на доступ нормальную полнофункциональную железку, которая сразу все и порежет — вполне реально. Уже несколько лет как… Т.е. это все, конечно, мое личное мнение, а не истина в последней инстанции, но я действительно не вижу смысла грузить локалом агрегацию и ядро, когда есть возможность по сути на те же деньги разрулить его там же на доступе…
Во-первых, давайте все-таки разделять распределенные ethernet-сети (т.е. пресловутые «домовые») и корпоратив. В корпоративе совсем другие требования и совершенно иная специфика. Там, по-моему, VLAN на пользователя — это вообще единственный вариант с моей точки зрения. :-)
А во-вторых, «многие бяки» тоже надо разделять. Если мы говорим о фильтрации по адресам/портам/протоколам — это без проблем. На L2 уровне фильтровать по заголовкам IP сейчас умеют любые китайцы, не говоря уже о более серьезных людях. Вопрос же фильтрации по контенту — он зачастую и софтовыми вещами в ядре не вполне успешно решается, не то что железом на уровне доступа… Но с другой стороны у того же Длинка уже много-много лет есть Packet content filtering, который вообще по любому содержимому пакета фильтрует — возможности открываются по сути безграничные. :-) Не в курсе — может уже кто-то еще успел у себя это внедрить… Какая-нибудь EdgeCore или типа того… Если внедрили, то вообще шоколадно — а то очень многие выбирают ДЛинки именно из-за этой фичи…
Во-первых, давайте все-таки разделять распределенные ethernet-сети (т.е. пресловутые «домовые») и корпоратив. В корпоративе совсем другие требования и совершенно иная специфика. Там, по-моему, VLAN на пользователя — это вообще единственный вариант с моей точки зрения. :-)
А во-вторых, «многие бяки» тоже надо разделять. Если мы говорим о фильтрации по адресам/портам/протоколам — это без проблем. На L2 уровне фильтровать по заголовкам IP сейчас умеют любые китайцы, не говоря уже о более серьезных людях. Вопрос же фильтрации по контенту — он зачастую и софтовыми вещами в ядре не вполне успешно решается, не то что железом на уровне доступа… Но с другой стороны у того же Длинка уже много-много лет есть Packet content filtering, который вообще по любому содержимому пакета фильтрует — возможности открываются по сути безграничные. :-) Не в курсе — может уже кто-то еще успел у себя это внедрить… Какая-нибудь EdgeCore или типа того… Если внедрили, то вообще шоколадно — а то очень многие выбирают ДЛинки именно из-за этой фичи…
Семантика ACL фильтрации DES3526.
Создаётся профиль ACL в котором определяется какие байты будут сравниваться в Ethernet кадре. Определяется отступом (offset) от начала Ethernet кадра. Возможно указать любой набор байт в диапазоне от 0 до 79.
Создаётся правило из профиля и конкретные значения байтов, набор которых указан в профиле, а так же порты коммутатора, к которым применяется данное правило ACL
Создаётся профиль ACL в котором определяется какие байты будут сравниваться в Ethernet кадре. Определяется отступом (offset) от начала Ethernet кадра. Возможно указать любой набор байт в диапазоне от 0 до 79.
Создаётся правило из профиля и конкретные значения байтов, набор которых указан в профиле, а так же порты коммутатора, к которым применяется данное правило ACL
ахахаха Ж)) на софтой J-series снимаете netflow sampling? :D они ведь по-другому не умеют. да и железку ушатываете не понять чем ) и да, как на это все смотрят метрологи, когда вы билленгуете по скажем каждому 100ому пакету? есть сертификат и бумажки? :)
> Получается, что Джуниперы эти — совсем дохлые? Странно: НАТ не более нагруженная операция, чем маршрутизация. Во всяком случае у меня циски валились от НАТа только когда сеть цепляла червя.
ойли? а что тогда 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 :)
ойли? а что тогда 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 :)
хм. да, cisco сама заявляет что мол падением производительности при nat'е можно принебречь. мол так оно мало. ( www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml#qa7 )
однако, мой опыт говорит о весьма заметном снижении производительности при nat'е. :(
однако, мой опыт говорит о весьма заметном снижении производительности при nat'е. :(
Ты прям как порох :)
Я ведь в Жуниперах — сам знаешь, поэтому в вопросе ключевым словом было эти :)
НАТ сам по себе не очень жруч. Особенно если записи не слишком часто меняются. Память да, могут откушать. Но поиск соотв. правила в конфиге и применение — не сумасшедшая нагрузка. ip input съедает почти 100% по НАТу только при червивом заражении: там МАССА сессий полуоткрытых создается. И циске (как и любой железке) становится трудно
Я ведь в Жуниперах — сам знаешь, поэтому в вопросе ключевым словом было эти :)
НАТ сам по себе не очень жруч. Особенно если записи не слишком часто меняются. Память да, могут откушать. Но поиск соотв. правила в конфиге и применение — не сумасшедшая нагрузка. ip input съедает почти 100% по НАТу только при червивом заражении: там МАССА сессий полуоткрытых создается. И циске (как и любой железке) становится трудно
Проглядел статью мельком, так что возможно что-то не до конца вкурил… Вообще, имхо, статью бы лучше на несколько разбить, а то букв слишком много…
Что используете таблицы и tablearg для шейпинга в ipfw — это хорошо (в инете до сих пор много старых мануалов со старыми конфигами, от которых плакать хочется), но зачем вам pf? Советую: переходите на ядерный ipfw nat, который появился в семерке. Все функции libalias (а значит по дефолту — нет необходимости ковыряться, например, с проксирование активных ftp, т.к. все это работает из коробки), отсутствие необходимости городить лишний огород и к тому же — существенный прирост производительности. Какую полосу вы шейпите и НАТите? Еще около года назад (когда я работал в телекоме :-) ) я как раз решал все эти вопросы и после профилирования через hwpmc убедился, что pf тормозит — дай Боже! Вот здесь подробнее: forum.nag.ru/forum/index.php?showtopic=47497
pf — это вообще файрволл для домохозяек. :-) Если надо побыстрому выпустить в инет офис и есть время только для написания двух строчек — альтернативы pf отсутствуют. :-) Но для серьезного провайдинга — это все фигня. К тому же он на несколько процессоров не раскладывается до сих пор по-моему…
В общем, мой вам совет — откажитесь от pf и перейдите полностью на ipfw. Серверу сильно полегчает и избавитесь от костылей (от тех же дополнительных прокси для активного FTP). :-)
Что используете таблицы и tablearg для шейпинга в ipfw — это хорошо (в инете до сих пор много старых мануалов со старыми конфигами, от которых плакать хочется), но зачем вам pf? Советую: переходите на ядерный ipfw nat, который появился в семерке. Все функции libalias (а значит по дефолту — нет необходимости ковыряться, например, с проксирование активных ftp, т.к. все это работает из коробки), отсутствие необходимости городить лишний огород и к тому же — существенный прирост производительности. Какую полосу вы шейпите и НАТите? Еще около года назад (когда я работал в телекоме :-) ) я как раз решал все эти вопросы и после профилирования через hwpmc убедился, что pf тормозит — дай Боже! Вот здесь подробнее: forum.nag.ru/forum/index.php?showtopic=47497
pf — это вообще файрволл для домохозяек. :-) Если надо побыстрому выпустить в инет офис и есть время только для написания двух строчек — альтернативы pf отсутствуют. :-) Но для серьезного провайдинга — это все фигня. К тому же он на несколько процессоров не раскладывается до сих пор по-моему…
В общем, мой вам совет — откажитесь от pf и перейдите полностью на ipfw. Серверу сильно полегчает и избавитесь от костылей (от тех же дополнительных прокси для активного FTP). :-)
А ядерный ipfw nat уже достаточно отлажен? Все на pf из-за того, что боязно до сих пор переходить. Как оно себя поведет при траффике 300мбит/с в обе стороны (суммарно 600) и 100к pps? pf справляется, но действительно — нагрузка на железо не радует
> А ядерный ipfw nat уже достаточно отлажен?
Зачем вы пользуетесь FreeBSD, если не доверяете STABLE? ;-) В этом же и бонус Бзди по сравнению с Линуксом: можно практически не тратить свое время на исследования надежности и тупо довериться мантейнерам. :-)
Так вот, все с ipfw nat в порядке — проверено на личном опыте. Или ng_nat можете попробовать, если нетграф препочитаете — он даже дольше в порядке, чем ipfw nat. :-)
> Как оно себя поведет при траффике 300мбит/с в обе стороны (суммарно 600) и 100к pps?
Есть мнение, что поведет лучше, чем pf. У меня трафик был поменьше — порядка 400мбит суммарно и 75kpps, но и комп похуже был — Атлон какой-то…
Ну и в любом случае, на таких объемах уже и ядро тюнить надо… У вас, кстати, эта тема, ИМХО, не до конца раскрыта. Например, сказано, что используются карточки Intel, а переменных в sysctl вы по ним никаких меняете… А там ведь можно подкрутить и загрузку по прерываниям уменьшить сильно… Ну это я уже так — побрюзжать. :-)
Зачем вы пользуетесь FreeBSD, если не доверяете STABLE? ;-) В этом же и бонус Бзди по сравнению с Линуксом: можно практически не тратить свое время на исследования надежности и тупо довериться мантейнерам. :-)
Так вот, все с ipfw nat в порядке — проверено на личном опыте. Или ng_nat можете попробовать, если нетграф препочитаете — он даже дольше в порядке, чем ipfw nat. :-)
> Как оно себя поведет при траффике 300мбит/с в обе стороны (суммарно 600) и 100к pps?
Есть мнение, что поведет лучше, чем pf. У меня трафик был поменьше — порядка 400мбит суммарно и 75kpps, но и комп похуже был — Атлон какой-то…
Ну и в любом случае, на таких объемах уже и ядро тюнить надо… У вас, кстати, эта тема, ИМХО, не до конца раскрыта. Например, сказано, что используются карточки Intel, а переменных в sysctl вы по ним никаких меняете… А там ведь можно подкрутить и загрузку по прерываниям уменьшить сильно… Ну это я уже так — побрюзжать. :-)
Что касается поддержки многопроцессорности/многоядерности ipfw то же довольно грустен. По крайней мере dummynet в 7.2 напрочь незнает про такую радость. Держим 5500килохомячков. Один внешний канал на котором freeBSD, шейпинг(табличка на тариф), нетфлоу и фулвью. Некоторое время был гигабитный канал наверх, но железка выжала только 400-500. dummynet съел 100% одного ядра а остальные 7 стояли в idle.
Посему сижу познаю дао netgraph и мечтаю о больших кошках и джуниперах.
Железо к слову 2хXeno E5420… 2500 MHz
Посему сижу познаю дао netgraph и мечтаю о больших кошках и джуниперах.
Железо к слову 2хXeno E5420… 2500 MHz
Да, dummynet был и пока остается одноядерным… Это печально.
Но вы уверены, что у вас именно dummynet выжрал? Вообще сам по себе он много жрать не должен — NAT больше жрет. Проглядел сейчас maillist'ы — все пишут, что 400-500 — это для dummynet'а семечки. Может, настроено чего неправильно было? io_fast было включено? Попробуйте профилировать ядро через hwpmc — сможете посмотреть, кто реально процессор жрет.
Кошки и Жуниперы — на самом деле не панацея…
Вообще, по тематике работы высоконагруженных шейперов и НАТов некоторое время назад были шикарные статьи на Наге. Шикарность прежде всего в том, что сравнивается большой спектр разного железа с указанием конкретных названий, что обычно редкость. Почитайте, если не видели:
nag.ru/news/17045/
nag.ru/news/17443/
Но вы уверены, что у вас именно dummynet выжрал? Вообще сам по себе он много жрать не должен — NAT больше жрет. Проглядел сейчас maillist'ы — все пишут, что 400-500 — это для dummynet'а семечки. Может, настроено чего неправильно было? io_fast было включено? Попробуйте профилировать ядро через hwpmc — сможете посмотреть, кто реально процессор жрет.
Кошки и Жуниперы — на самом деле не панацея…
Вообще, по тематике работы высоконагруженных шейперов и НАТов некоторое время назад были шикарные статьи на Наге. Шикарность прежде всего в том, что сравнивается большой спектр разного железа с указанием конкретных названий, что обычно редкость. Почитайте, если не видели:
nag.ru/news/17045/
nag.ru/news/17443/
вам можно посоветовать внедрить балансировку шейперов.
т.е. выделить шейпинг на две отдельные машины и балансировать через них трафик.
способов — куча. у меня балансировка сделана на втором уровне с помощью etherchannel, src-ip.
т.е. выделить шейпинг на две отдельные машины и балансировать через них трафик.
способов — куча. у меня балансировка сделана на втором уровне с помощью etherchannel, src-ip.
Немасштабируемо :(
/me статью в закладки
wkt спалился
За что я люблю хабр, так это за то, что к статье, в которой я не нашёл и десятка знакомых слов, уже 44 комментария с дельными советами автору! Писец… ЧСВ втоптано в плинтус))
кстати, а вы пиринг поднять не хотите?
унылая статья, унылая концепция границы и ядра спд :( таких затейников-домушников полроисси. и да, два фиревола — это пять. вобщем дальше я не осилил прочитать. :(
впрочем ладно, кто во что горазд, тот так и строит. :(
бай зэ вей, мне вот очень интересно, в каком месте вы тут производите учет проданных абонентам услуг?
впрочем ладно, кто во что горазд, тот так и строит. :(
бай зэ вей, мне вот очень интересно, в каком месте вы тут производите учет проданных абонентам услуг?
Рассказывайте свою концепцию и как предлагаете :) А почему вам не понравилось то что файрвола два?
потому что с одной стороны кто-то там плачется что с производительностью плохо, а с другой стороны никого не смущает гонять трафик через два фиревола и ожидать при этом чудес. :)
я понимаю что в 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 — вот это айс :)
я понимаю что в 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 — вот это айс :)
> например, почему на каждом 4350 именно по отдельному аплинку?
вычитал в комментах что таке не по отдельному. ну да ладно. :(
вычитал в комментах что таке не по отдельному. ну да ладно. :(
сленга многовато. Похоже автор (ты) пытаешься скрыть что-то :)
Либо неумение писать правильно (гигабайт), либо «плаванье» в теме :)
ЗЫ Это в твоем стиле написанное замечание :)
Либо неумение писать правильно (гигабайт), либо «плаванье» в теме :)
ЗЫ Это в твоем стиле написанное замечание :)
если речь про гигОбайт или гигАбайт, то не придерайтесь. если речь о том что я путаю биты с байтами, то покажите где. вроде не путаю, может очепятался :(
насчет информации, ну блин, я же не статью пишу :) я так, в камментах ерундой страдаю :) вовсе не значит что то что я говорю это догматичная истина. :(
насчет информации, ну блин, я же не статью пишу :) я так, в камментах ерундой страдаю :) вовсе не значит что то что я говорю это догматичная истина. :(
да, вы правы Ж) я всегда много не договариваю, так, только по верхушкам скачу :) могу и договорить, но тогда это потянет на отдельную статью, а ее писать, проверять орфографию и прочей ерундой заниматься у меня особо желания нет :( извиняйте если я вот так коряво :)
pfnat лучшее решение из всех, что я пробовал на фре
а dummynet лучшее решение для шейпинга
так что не вижу ничего ужасного в юзании двух фаеров.
ipnat — течет память и вешается ядро
ng_nat — течет память
вот ipfw kernel nat не пробовал, это да. для меня проще оказалось вообще отказаться от ната и раздать всем паблики
а dummynet лучшее решение для шейпинга
так что не вижу ничего ужасного в юзании двух фаеров.
ipnat — течет память и вешается ядро
ng_nat — течет память
вот ipfw kernel nat не пробовал, это да. для меня проще оказалось вообще отказаться от ната и раздать всем паблики
используя pf nat как объяснять абонентам почему gre не работает? про ftp так и быть промолчим :)
я сам очень сторонник и любитель 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. а чтобы оно протекало, да, надо будет слегка потанцевать :)
я сам очень сторонник и любитель 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. а чтобы оно протекало, да, надо будет слегка потанцевать :)
когда я юзал pfnat, года полтора назад, gre через него работал.
а ftp да, с этим проблемы.
а ftp да, с этим проблемы.
ойли? прямо таке несколько туннелей с одним dstip? соль проблемы в том что pf nat во freebsd не умеет (не умел) разделять gre туннели по Key и ставить в оба конца не нулевые значения.
в openbsd, да, pf nat давно уже как gre passthrough. во freebsd до 7ой ветки включительно нет. в 8ке вроде проскакивал порт свежего pf. поэтому возможно оно уже.
в openbsd, да, pf nat давно уже как gre passthrough. во freebsd до 7ой ветки включительно нет. в 8ке вроде проскакивал порт свежего pf. поэтому возможно оно уже.
отличная статья
я бы конечно кое-что изменил =)
я бы конечно кое-что изменил =)
Коллега, пишите в комментариях что именно и как :)
P.S. Есть еще масса решений этого вопроса, как гласит истина и она права кстати «спроси мнение 3-х провайдеров и получи 4 возможных решения» :)
P.S. Есть еще масса решений этого вопроса, как гласит истина и она права кстати «спроси мнение 3-х провайдеров и получи 4 возможных решения» :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отказоустойчивый узел передачи данных