Уфаныч

В природе есть версия 2.9.2-15 Поделитесь changelog, плиз. И опытом, как пошла в работу? А то что-то 2.9.2-14 на конфиге от 2.9.2-09 с трапом запустилась. :( ну и была отложена.

Поясняю. Была жалоба на исходный (упрощённый, как я понимаю) набор из трёх правил ipfw, первые два - на шейпинг исходящего трафика, последнее - разрешить всё. Так как правила на шейпер подразумевают исходящий трафик (нахрена шейпить входящий,он уже у нас), но в правилах отсутствует ключевой слово "out", и есть подозрения, что правил (когда то было)/(будет) несколько больше, я и предложил ДО этих правил перманентно исключить из проверки (пустого интерфейса) весь входящий трафик. Путём добавления "allow all from any to any in" перед ними. Добавленное правило содержит только одну микрокоманду ipfw и выполняется быстрее всего. Проверка на интерфейс выполняется для пустого интерфейса несколько дольше (один вызов подпрограммы). Есть мысль насчёт "оптимизировать ipfw". У ipfw есть замечательная вещь - keep-state (и check-state). Возможно построить правила таким образом, чтобы в где-то было так: 100 check-state #должно быть одним из первых правил. Перенаправит пакет (как входящий так и исходящий) #на правило фаервола 2000 или 2010 или ещё какое, но сразу на микрокоманду правила! то есть на skipto ... (набор правил) 2000 skipto NNN10 all from any to table(1) keep-state // таблица клиентов с тарифом 1 2010 skipto NNN20 all from any to table(2) keep-state // таблица клиентов с тарифом 2 ... (ещё набор правил) NNN10 pipe 1 all from any to any out xmit интерфейс-к-клиенту // отшейпить только исходящий для тарифа 1 в сторону клиента NNN11 allow all from any to any NNN20 pipe 2 all from any to any out // отшейпить только исходящий для тарифа 2 и к клиенту, и в апстрим NNN21 allow all from any to any таким образом, если пакет добрался до правила 2000 (а первый пакет соединения проскочит мимо check-state) (он уже не отбрасывается по правилам фильтрации, и весь последующий flow тоже будет легитимным,) для него на keep-state-правиле создаётся запись в таблице динамических правил, соответствующая его протоколу, IP-адресам и портам (id пакета). Следующий же пакет, попадающий под этот id, быстрым шагом со строки 100 попадает на 2000, затем так же быстро на NNN10, и тут уже шейпится. Процедура внесения id пакета для TCP происходит намного реже, чем частота прохождения пакетов в потоке этого flow - вот выигрыш по сравнению с поиском IP по таблице для каждого пакета. Для UDP есть осложнение в виде времени жизни UDP-flow, задаваемого net.inet.ip.fw.dyn_udp_lifetime. И net.inet.ip.fw.dyn_short_lifetime для других протоколов. Процедура поиска соответствия пакета в хэш-таблице завязана на net.inet.ip.fw.dyn_buckets, который не может быть больше 64к. Этот лимит начинает действовать, когда хэш-таблица пуста. Остаётся вопрос - будет ли поиск по хэш-таблице быстрее, чем исходные поиск IP в таблице и взятие tablearg И второй вопрос - сколько памяти отъест ipfw под динамические правила для кучи клиентов. В принципе, если в правилах нет других keep-state и limit, то эту схему можно протестировать под боевой нагрузкой на каком нибудь узком круге клиентов. Оценить количество правил и требуемую память можно, поместив перед имеющимся блоком правил для шейпера одно единственное правило: skipto "следующее правило" all from any to any keep-state и net.inet.ip.fw.dyn_count скажет, сколько динамических правил он насчитал. ipdw -d show/list покажет их все. Есть подозрение, что на IPv6 схема с keep-state будет более затратной по памяти и времени поиска, но хэш там не по полному ip-адресу, а по 64 битам адреса, только по исходникам не ясно, первым или последним, а проверять лень.

Об оптимизации ipfw: 03000 pipe tablearg ip from any to table(4) { xmit vlan11 or xmit vlan12 } // Incoming traffic shaping 3000 pipe tablearg ip from table(5) to any xmit vlan3918 // Outgoing traffic shaping Позволю себе заметить, что с таким построением правила вы проверяете не только исходящий трафик, но и входящий. Нет ключевого слова out. Ведь, не смотря на указание xmit if, у входящего этот if ещё пуст, его проверка впустую тратит время. Предлагаю первым правилом сделать allow all from any to any in Второе, о чём хотелось бы сказать - размеры таблиц. rn_match - это поиск по дереву, соответствующему таблице ipfw. Довольно затратная операция. Может, стоит переписать правила таким образом, чтобы уменьшить размер таблиц или вообще отказаться от них? Ну и напоследок - netflow, наверное, стоило бы снимать на другой машине, зеркалируя на неё трафик. А можно поточнее, как про картину так и про таймауты?

С большой вероятностью Вы упёрлись в net.inet.ip.fastforwarding=1 Попробуйте значение 0 Ещё можно потюнить в /boot/loader.conf net.isr.maxthreads=12 net.isr.bindthreads=1 но это если только будет особая нужда и в 'top -SHP' будут перекосы по ядрам можно будет сделать net.isr.maxthreads=6 net.isr.bindthreads=1 тогда маршрутизацией пакетов будет нагружен только один кристалл из Ваших двух.

Там есть интересная карта по распределению IP -адресов. Из которой видно, что исчерпание IPv4 как то ещё не скоро наступит. Есть вообще огромные пустые блоки адресов /9 и /10, и чуть ли не /8. Да и загруженность других диапазонов отнюдь не критическая.

Собственно это и есть главная проблема В чём проблема? Зафорвардить поток на прокси-сервер? man preferred-firewall Настройить squid в transparent-режиме? man squid.conf http_port, опция intercept Сделать squid без лишних опций? В свете того, что через сквид будет иди трафик только тех, кого нужно фильтровать - так ли важен обратный маршрут мимо сквида? Сколько такого трафика? А если сквид с mem-only-cache? Всё равно большую часть именно тех, кого нужно фильтровать, придётся зарезать (хм, хотя, vk.com/idXXXX так не прокатит, но именно таких страниц от vk немного) А вот всю AS vk на сквид заворачивать совсем не нужно :) А если не сквид, то, например, privoxy, tinyproxy Не выдумывайте себе проблем.

Если оборвут, ляжет на пол вся незакреплённая линия. Если ляжет под ноги/колёса, то весь кабель на замену.

Вот тут все советователи радиоканалов как то забыли, что оборудование из статьи вообще то просто оптический транспондер, который легко прожуёт и PON и другое WDM 1310/1550. WI-FI-ethernet-устройства тут точно в пролёте. Разные категории и уровни OSI, Так что кто-то опять сравнил тёплое с мягким. А что касается конкретно этой установки - она своё дело делает. Заказчик доволен. Кстати, любители Wi-Fi могут дружно гордится от того, что вынуждены использовать технологию, придуманную как "точка-многоточек", в режиме "точка-точка". Как там у вас с полным дуплексом? Справедливости ради, было бы неплохо взглянуть на статистику оптического линка у медиаконвертера, но видимо, то устройство так не умеет.

Хм. Просвятите. В Российском законодательстве нет закона, регулирующего оборот порнографии. А в Украинском - есть?

UP Второй день у УСИ для абонентов тарифов с динамическими адресами недоступны ДНС-сервера. Вообще никакие. У статиков всё отлично. Такое ощущение, что динамикам зарезали 53 UDP порт. Вот интересно, все 300000++ (по всей области) не работают или фрагментами? И где же заявленная ИСО9000-2001? Или она подтверждает, что именно такие результаты компания будет стабильно получать?

Хм. Их поиска активных тем исчезло название раздела, в котором тема находится. Very bad.

Самое главное в эксплуатации УПСов - чем меньше его нагрузка, тем дольше живут аккумуляторы, ибо если ток разряда греет провода от акк :( , то конец такого аккумулятора очень близок. Так что оценивайте ещё и замену акк. при частой/долгой работе на них. Конечно, Smart-ы более аккуратно к ним относятся, но всё же - токи разряда под нагрузкой огромны. А что касается генератора и УПС - AFAIK УПСу с его ШИМом (двойное преобразование) почти пофиг и форма, и частота, а вот если двойного преобразования нет - тут всякие фокусы возможны.

Посмотрел список IP, увидел знакомые... 90.150.*.* и 90.151.*.* - это PPPoE ADSL Уралсвязьинформа Екб. официально список присутствует вроде тут... http://ekt.usi.ru/home/ek/internet/xdsl/servises/ давите их...

Контур, кстати, уже протянул второй линк к своим серверам...Новость от К-Э Правда, собирались долго... но клиентов потеряли очень немного.

в порядке бреда... а может там vlan? а сетевуха его не пускает? хотя вроде должна....

Хы. А это что? http://noc.rtcomm.ru/cgi-bin/cust.cgi Я ведь не с пустого места спрашивал.... хотя, может я не совсем прав насчёт этого URL, но работы там всё же перечислены... Как тогда они уведомляют? почтой?

Собственно, вопрос - есть такой URL у ТТК? У РТКОММ есть. Хотел найти и у ТТК - яндекс не знает. Форумчане, поделитесь ....