wtyd

всего на nfqfilter завёрнуто все сервер на базе десктопа, камень i3-6100 Всёравно мало, тут люди 1-2 гигабита на TPROXY делали (отчёты об этом вроде были). Сквидой версии 2.7 фильтровали и всё работало. Правда, в то время реестр был меньше. Зачем весь трафик сливать ? Может хватит того, чтобы лить tcp со списком портов из реестра ? Не думаю, что там больше шестнадцати уникальных портов -- в одно редиректа правило влезет. Т.е. в РС лить можно весь трафик, а в nfqueue заворачивать только tcp и список портов. Остальной трафик просто роутить.

Наверное слишком много трафика попадает на фильтр. Пускайте на фильтр только трафик, предназначенный для проверки. как показывает практика если заворачивать только с IP из реестра, больше пропусков, меняются IP да и трафик то у меня всего 40-60 мегабит Это какого трафика у вас 40-60 мегабит ? 80+443 порты от клиента в сеть или всего ? В любом случае это "сквидовые" скорости, т.е. ядерный фильтр IMHO должен больше пережёвывать.

Так а в чём заковырка в этом случае ? По оспф известны как некстхопы, так и проблемные префиксы, почему бгп не может посмотреть их в таблице и рекурсивно узнать где они ? Почему пишет rib-failure ? На самом деле я пока ещё не уверен в корректности маршрутов в оспф, точнее, они там многие правильные, но не все. Причины пока не ясны. Непонятно следующее: почему rib-failure, когда в оспф есть маршрут до некстхопа пусть даже неправильный ?

Да, я хотел бы иметь один rr на grt, а все остальные роутеры сделать клиентами его, в т.ч. и vrf. Когда я так пробую сделать, то маршруты по бгп расползаются, но некоторые из них rib-failure, включая тот проблемный префикс, потому что в ospf ещё какая-то заковырка есть. В общем, разбираемся, пока дыру с не прохождением префикса ликвидировали, потом займёмся остальным бгп.

Мдя ... там в настройках вообще нет send community и соответственно вообще нет никаких комьюнити. Может афектить ?

Флапающий маршрут я нашёл, это из-за ospf было. На одном бордере в бгп была прописана network и она то анонсилать, то отзывалась. Маршрут на неё через ospf появлялся/исчезал. В общем, network убрал, с ним позже буду разбираться, а вот с бгп пока загадки :-). Поднял две брп сесси с бордера до grt и до vrf, всё заработало, но почему одной сессии не хватает, я уашпе вообще не понимаю :-). Почему-то с одной сессией rib failure, но все некст-хопики есть в ospf, почему так ? :-). Ещё идеологический вопрос: как можно организовать iBGP ? В нашем случае сделано примерно так: на роутерах подняты лупбаки /32, маршруты о которых распространяются по ospf, т.е. все роутеры знают о всех лупбаках в сети. Есть "ядро/роут-рефлектор", с которым все роутеры сети имеют iBGP. Идеологически же так правильно (как вариант) ?

А увидеть этот Route-Reflector Cluster-id хотя бы как-то можно ? Настроить нельзя, но хотя бы узнать, какой он в grt и какой в vrf как ? Я, кажется, знаю, в чём там дело :-). Сегодня попробуем переделать схему bgp. Там шеститонник на две части разделён с помощью vrf и в обеих его частях настроен рефлектор, надо сделать один рефлектор и тогда всё должно зафунциклировать.

в конфиге bgp router-id заданы явно и они разные для GRT и для vrf. Соседние ойпи адреса, отличаются на единицу. Так было давно сделано. ... т.е. я имею ввиду "bgp router-id", а где "route-reflector cluster-id" посмотреть ? Он наверное и не конфигурится. ...

router id разные, конфиг показать пока не могу ... слишком много исправлять :-( в выводе sh ip bgp nei <ip> есть вот такое: NEXT_HOP is always this router Sent Rcvd Prefix activity: ---- ---- Prefixes Current: 297 11 (Consumes 572 bytes) Prefixes Total: 594 45 Implicit Withdraw: 297 33 Explicit Withdraw: 0 1 Used as bestpath: n/a 11 Used as multipath: n/a 0 Outbound Inbound Local Policy Denied Prefixes: -------- ------- CLUSTER_LIST loop: n/a 12 <--- вот это вот смущает Bestpath from this peer: 26 n/a Suppressed due to dampening: 8 n/a Bestpath from iBGP peer: 2 n/a Total: 36 12 Number of NLRIs in the update sent: max 288, min 0 еслия правильно понял, то 12 префиксов были заденаены, аналогичное в vrf тоже есть денаи, их 4. Как узнать какие и почему ?

Ну тогда у нас вообще нет идей, почему эти префиксы по бгп не проходят. Врф говорит, что они адвертайзятся, а GRT говорит, что их не получает даже в received-routes. Никаких фильтраций на этих нейборах нет. Нсли некст-хоп достижим любым способом, то анонс в бгп должен пройти же ... а он не проходит и непонятно почему.

А маршруты на некст-хопы должны быть в бгп или они могут быть известны через другие протоколы ? В бгп их нет если что.

... а пример команды можно ? Просто что такое leaking пока не понятно. У нас на bgp между глобал и врф с обеих сторон указано next-hop self, наверное для этого ... хотя с другой стороны ibgp должно передавать next-hop неизменным.

Маршрут к некстхопу тех префиксов, которые не пролазят сквозь меж-vrf'ное bgp, есть, он известен через ospf. "sh ip bgp rib-fail" показывает несколько префиксов, но среди них нет проблемных префиксов. Про ibgp мультихоп я так выразился :-), просто нейборы не-connected, обычно у нас неборы connected либо между loopback'ами bgp настраивается.

Есть cisco 6500, в ней создан vrf, для обмена маршрутами между vrf и не-vrf используется ibgp. Почему-то между ними передаются не все маршруты. Пробовали рефлектор включать, даже с обеих сторон рефлектор включали - не помогло. Выглядит это так: если смотреть в врф, то маршруты адвертайзятся, а на не-врф их нет, даже если включить софтваре-реконфигурейшн. Проблема главным образом актуальна из-за того, что в одном из маршрутизаторов, который в vrf, появился ebgp, маршруты от которого в не-vrf не проходят. Пробовали с этого маршрутизатора (на котором ebgp) поднять мультихоп бгп с не-врф, тогда маршрут появляется, но это какой-то изврат и при этом другой префикс начинает примерно раз в 15 секунд флапать (приходит анонс этого префикса, потом приходит withdrawn). Для vrf что, bgp какой-то особенный ? Почему так может происходить ? Что можно попробовать сделать ? :-) P.S. Почему между vrf сделан ibgp и зачем там вообще vrf, не спрашивайте :-). Всё в пределах одной автономки. Так исторически сложилось. vrf там не нужен, но переделать нет возможности.

Вoт так всегда ... чтобы найти ошибку в своём позорном коде. надо сперва этот код на форум выложить :-). AutoCommit => 0 -- т.е. надо либо AutoCommit => 1 юзать, либо после вызова метода execute() делать commit. Прочитал же мануал, вроде понял, но всёравно тупо с него скопипастил пример и не исправил, что за привычка так делать ? :-).

Есть примерно такой код на перле #!/usr/bin/perl use strict; use warnings; # use ... use Data::Dumper; use DBI; our $dbh; # remote psql data base hendler our $sn = "DBI:Pg:dbname=test;host=192.168.0.5;port=5432;"; our $ins; $dbh = DBI->connect($sn, 'vasia', 'derparoll',{AutoCommit => 0,pg_server_prepare => 1}); $ins = $dbh->prepare_cached("INSERT INTO mytable (username,starttime,stoptime,sessiontime,calledstationid,callingstationid,calldirection) VALUES (?,TO_TIMESTAMP(?),TO_TIMESTAMP(?),?,?,?,?)"); my @res; push(@res,"test1"); push(@res,"1"); push(@res,"2"); push(@res,"3"); push(@res,"src1"); push(@res,"dst1"); push(@res,"IN"); my $q = $ins->execute(@res); print ("ins->execute = $q\n"); $q = $ins->finish(); print ("ins->finish = $q\n"); $q оба раза при печати показывает "1", типа одна строка инсертится, но когда смотрю в базе, то новых строк не добавляется. Если делать то же самое, но с использованием $dbh->do($insertstring) , то данные в таблицу вставляются. Почему так получается?

В общем, работает как-то странно. Дело точно не в шлюзе, т.к. если зацепить шлюз напрямую в smg, то факсы ходят. Если зацепить этот voip шлюз через fusionpbx, то факты не ходят, но они релеятся :-). Т.е. если настроить релей факсов, то это работает. Почему напрямую не работает непонятно.

Именно от сайта получает 404 ? AFAIK программа ркн ругается в любом случае, если при проверке она не получает стандартную "заглушку" системы фильтрации контента. Поговорить с инспектором, показать результаты. Эта программа не идеальна, она сама содержит ошибки. У нас программа выдаёт разные результаты, если её несколько раз запустить с одним и тем же списком -- наводит на размышления :-). Либо у нас фильтрация так работает, либо программа так работает.

По бгп заворачиваю, трафика не более 15 Мбит. Суммарно полоса 20+ гбпс. Там же с ip-адресами в реестре неоднозначности: не для всех "ресурсов" указаны ip, у https азартных игровых сайтов очень часто меняется dns-записи (разбираться по каждому такому url с ркн можно, но лучше не допускать). В предлагаемом способе фильтрации вроде как проверяется имя домена при ssl-handshake вроде бы. Ещё минусом использования bgp является невозможность этого делать в случае мелких сеток (без fv, с ядром на cisco 3750 и т.д.), т.е. когда железо не позволяет 20K+ маршрутов добавить. Для ваших объёмов наверное схема с bgp лучше подходит. Для мелких полос трафика наверное можно весь трафик от клиентов pbr'ом завернуть в РС с nfqfilter и там либо сразу роутить, либо сперва в nfqueue запустить. Фильтр для заворота в nfqueue наверное можно на u32 какой-то придумать, чтобы матчить http-запросы.

Могу ошибаться, но там в http-заголовке запроса может передаваться что-то типа "Content-type=bla-bla", это и есть mime-type. SCE на это смотрит. Надо крутить настройки, но я пока не знаю какие. Почему при прочих равных условиях у одних людей блокирует, у других - нет, непонятно :-).

Интересно, а можно ли заворачивать трафик в nfqueue каким-нибудь специфичным u32 матчем (1-3 правила), а не весь исходящий tcp трафик от клиентов ? Чтобы снизить нагрузку на ЦПУ. Просто вчера наткнулся на google:generate-netfilter-u32-dns-rule.py, попробовал на своих DNS -- работает. Подумал, а почему бы для nfqfilter так же не сделать ? Только не знаю как :-).

Пока не используем, но очень следим :-), наверное это самый перспективный и самый высокопроизводительный опенсорс проект по блокировке zapretinfo. Почитайте эту тему, тут много отчётов по проверкам, багрепортов и исправлений.

При настройке шлюзов оставили по-умолчанию, нам и в голову не приходило, что кто-то на sip будет факсы хотеть :-). Т.е. скорее всего Т38 отключен (по-умолчанию). На сколько я понял, факсовый аппарат должен сам уметь Т38, так ведь ? Если верить вики, то Т38 был разработан в 1998 году, аппараты стали делать скорее всего в 2000+, высока вероятность, что нет поддержки Т38 в факсовом аппарате у клиента. Завтра снова будем пробовать, как раз шлюз принесли ещё один.

Есть fusionpbx (выбрали из-за мультитенантности), есть абоненты, которые к нему подключаются через шлюзы. Сам fpbx выходит в мир через sip гейтвеи. Звонки работают, но некоторым людям нужны ***s факсы. Т.е. они подключают факс в шлюз и у них факсы не ходят. Есть сомнения по поводу того, что в умолчальной конфигурации fpbx что-то не так с настройками для факсов, думаю, что должно работать "из коробки", но почему-то не работает. Так же есть мнение, что факсы не работают из-за шлюзов. Подскажите, что всё-таки посмотреть в fpbx на предмет прохождения факсов через него ? Может быть со шлюзами что-то не так ? Шлюзы q-tech, хотя есть разные. Где вероятнее всего проблема ? Как лучше решить проблему прохождения факсов ? В наших экспериментах без шлюзов fax2email работает, но надо чтобы fax2fax через fpbx проходили в том числе и через шлюзы. Для проверок у нас нет на 100% рабочего факса :-), т.е. мы в имеющемся не уверены, это осложняет жизнь ...

Не знаю, попробуйте посмотреть это: http://forum.nag.ru/forum/index.php?showtopic=85135&st=40&p=953058entry953058 - команды cli У меня Number of HTTP GET установлен в 10. Нагрузка на CPU практически не возросла. http://forum.nag.ru/forum/index.php?showtopic=78575&st=140&p=827990entry827990 - посты 148, 150 Спасибо, будет пробовать. У нас сейчас HTTP Browsing, а не * . А где выставляется/смотрится "Number of HTTP GET" ?