azlozello

Может у вас стоит защита типа "нельзя отправлять и получать пакеты с одинаковым src-dst портом"?

Нифига не ок. Хотя возможно у меня старая версия бинда.

Только как подгрузить такое кол-во зон? Подгружает быстро пару десятков из списка и дальше по одной зоне в 2-4 секунды. Соответственно в этот момент bind на запросы не отвечает.

Полный и абсолютный 0 по всем направлениям! Подозреваю глюк где то был. Переставил другую систему и теперь хоть 20% рисует на ядрах :)

Чему же радоваться? На лицо явный глюк :) Тут у людей и на 150кппс уже тормоза начинаются.

[root@localhost ~]# uname -a Linux localhost 2.6.27.25-78.2.56.0.140asp.i686 #1 SMP Tue Jul 7 16:58:15 EDT 2009 i686 i686 i386 GNU/Linux [root@localhost ~]# lspci 01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) [root@localhost ~]# ethtool -i eth2 driver: e1000e version: 1.0.15-NAPI firmware-version: 5.11-2 bus-info: 0000:01:00.1 [root@localhost ~]# ethtool -i eth3 driver: e1000e version: 1.0.15-NAPI firmware-version: 5.11-2 bus-info: 0000:01:00.0 Intel® Core2 Quad CPU Q8200 @ 2.33GHz Иперфом генерится поток ~280kpps пакетами по 64к Тупой форвардинг. На проце 0 загрузки. Дропов нет. Как это понимать?

Оптимальнее для чего? :) Разумеется включайте. Менее 64к на порт у ежей нельзя на сколько я знаю. А больше и не нужно. Хуже уж точно не будет.

Такой мега девайс наверно будет стоить от 1к$ Вот если бы туда ещё ASIC запихнули то можно было бы собирать на коленках вещи а-ля жунипер ;)

del как бы не совпадает с логикой хешей :) не лучше бы использовать change?

кусок из скрипта: А не лучше ли до фантазировать с использованием хешей если вдруг клиентов много?

Почему нельзя повлиять? Опция ecn в RED что тогда делает как не заставляет источник понизить скорость?Может я не так понял? :) ECN -- это уведомление о перегрузке (переполнении приемного буфера). RED -- это дисциплина для предотвращения переполнения очереди, а не для шейпинга. Нельзя вносить задержки контролируемой величины не отправляя пакеты, почему это неочевидно? Задача RED заключается в том, чтобы сообщить отправителю о возможности перегрузки, и отправитель должен адаптироваться к этой ситуации.Маршрутизатор осуществляет пометку пакетов с помощью бита-флага СЕ. Отправитель должен реагировать на этот флаг так, как если бы произошла потеря пакета. Это и есть механизм ECN "Explicit Congestion Notification". Но так как это не получило широкого распространения то и работает это далеко не во всех случаях.

Почему нельзя повлиять? Опция ecn в RED что тогда делает как не заставляет источник понизить скорость?Может я не так понял? :) Например есть трафик промаркированный DSCP в 3 разных класса + нулевой. Как наиболее разумно пропустить через входящий интерфейс этот трафик в соответствии с метками и обрезать общий канал например до 500мбит? С исходящим то всё понятно. Но непонятно как это сделать с входящим.

А если входящий трафик уже промаркирован ToS/DSCP?

Не совсем то чего хочется. А хочется как обычно странного :) Есть свитч L3 способный принять по BGP без усилий 60к префиксов в память (в FIB только 17к) Есть 2 аплинка с FV и IX примерно 4к префиксов. Необходимо сбалансировать 2 канала в мир. FV никому отдавать не нужно. Что порекомендуете?

Может расскажете рецепт приготовления "мухоморов"? ;) Очень интересная темка.

Дабы не плодить темы. 1. Никто не поделится свежей прошивкой для Quidway S5624P? 2. Пользовался ли кто BGP на этой железке? Сколько маршрутов реально держит?

Так почитайте в мануале что такое ACL Там практически всё как у ciscо Например запрещаем всяко заразно: Console(config)#access-list ip extended test Console(config-ext-acl)#deny TCP any any destination-port 135 Console(config-ext-acl)# deny UDP any any destination-port 135 Console(config-ext-acl)# deny TCP any any destination-port 445 Console(config-ext-acl)#exit Console(config)#access-list ip mask-precedence in Console(config-ip-mask-acl)#mask protocol any any destination-port Console(config-ip-mask-acl)#exit Console(config)#interface ethernet 1/1 Console(config-if)#ip access-group test in Дальше додумаете. Обратите внимание на mask-precedence Нужно описывать этими масками порядок правил.

+1 u32 + хеш могут творить чудеса. А если "хочется странного" то исходники вам в руки :)

А во сколько раз Juniper EX3200 дороже ES4624? ;)

Группа должна быть обозначена статически.Типа: mvr group 225.0.2.0 255 и только на эту группу будут подписываться.

Quidway® S5300 хорошие штуки. Жаль что нам в рамках партнерской программы не предлагают их за не дорого :)

ES4624-SFP без проблем принимает UA-IX но во время заливки таблицы ему разумеется плохо :) 35.7Mpps с головой.

Да, скриптец в общем обычный, один раз загенерил и забыл. Всё работает на change/replace и сбоев я не замечал. 2stmp лично у меня на машине крутится шейпер (16к правил), биллинг, sflow анализатор, DHCP, apache, mysql, bind и т.д. + ipset, потому load average несколько больше. Машинка 2-х процессорная, но как мы знаем в процессорных прерываниях (для трафика) участвуют только 2 ядра (т.к. 2 сетевые). Трафик порядка 300-400мб.

UTM5 нормально считает большие потоки NetFlow, по крайней мере > 4k абонентов проблем не наблюдается. Не нужно путать понятие РЕАЛЬНОГО времени. 1 секунда это уже не реальное время. А по сему я не вижу разницы между 1 секундой и 300 секундами. Это всего лишь время агрегации данных и сверка счетов. Я даже представить себе не могу технологии биллинга считающего трафик в РЕАЛЬНОМ времени :D

а сколько IP выдаете клиентам в VLAN? /29 серые. особо не заморачиваемся. А если адреса не серые? unnumbered? Сколько девайсов с этой фичей в данный момент на рынке? 1-2?Вот основной минус использования vlan на юзера. Всё остальное мего удобно и прозрачно. vlan + opt82 = красота. Плюшки типа логина-пароля реализуются без напряга средствами биллинга. А пока будем юзать чрезмерно умный доступ с привязкой sip-mac :)