nerik

Да, вот не похоже. Судя по отчетам за прошлые дни проскакивали только эти ресурсы несколько раз, главное только http (https нет в отчете), блокировка по домену. Снял дамп-трафика с сервера 104.207.144.62, запрашивает мелкие пакеты, но эти сайты блокируются исправно, смотрел в течении дня. Во вчерашнем отчете их нет, зато полный треш по адресации гугла и фэйсбука)) @max1976, может есть проблема такая же при сборке http, как было при https с navalniy.com? Снять дамп пропуска не удается, т.к. на ПК блокируется исправно, ревизор пока по ним молчит. Кстати в радиочастотном говорят нет скринов, что заставляет еще больше задуматься.

Добрый день. Ни у кого не проскакивают пропуски по ресурсам hello.opentg.us и 12345.***rkn.us? Используем extfilter, но не из ветки exp. Вчера в отчете появились.

Используем zapretservice уже полгода, аптайм сервера тот же) Стоит ревизор и вручную делаем проверку для РКН, претензий со стороны них не получали. Единственное, что маловато функционала пока, например нет черного списка, но обещают в скором времени сделать. А так отвечают оперативно. Сами нас нашли, т.к. подключались к нам, ибо местные ребята)

Эх, прокси не вариант, 2,5G трафика)) Поэтому и смотрю, чем можно на MX редиректить или подсунуть трафик) Это конечно же временное решение, т.к. в планах покупать оборудование DPI. MX используется в качестве бордера. Абоненты мягко говоря задолбали, когда блочится youtube или жж.

Добрый день. Обращаюсь за помощью к гуру juniper :) С железкой еще разбираюсь, поэтому все ньюансы ее пока не понятны. Так как денег на оборудование DPI пока нет, нам приходится блокировать запрещенные сайты жестко на данной железке - с помощью списков filter. Возможно ли на mx80 делать перехват http-траффика на запрещенный сайт (используя данный список)? После делать какой-нибудь редирект на страницу, где будет написано, что сайт был заблокирован по требованию Роскомнадзора. Наткнулся на ссылку http://www.juniper.net/techpubs/en_US/junos12.3/topics/example/http-redirect-service-static-interface-example.html Поможет ли оно? Спасибо))

Всем доброго дня. Тема актуальна. Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет. В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо) Заранее спасибо.

Отходим от темы, я не писал что у меня проблема с перегрузкой трафика, шлюз выдерживает 700 Мегабит. Меня уже как год устраивают эти драйвера. Как только будет больше трафика и не будет резервов (новых шлюзов), вот тогда потестим стандартные драйвера. За информацию спасибо. А по факту сегодня 3 день как аномалий не было.

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

А смысл менять если с ним проблем не было, тем более асинхронный нат очень даже устраивает нас. При pf первый шлюз у нас прогоняет 700 Мегабит. Просто при использовании второго шлюза, мы сейчас через первый гоняем не более 300Мегабит. Проблема то заключается при входе трафика, так как взлетают input errs на сетевой, значит до pf не доходит. Если количество пакетов (с малым размером) будет больше, чем шлюз может прожевать, то он будет загибаться. через команду sysctl сначало добавляли. Да и перезагружали шлюз недавно (в sysctl.conf прописано). нет, взлетают все rx_kthread, от 90 до 100%. Стоит 4 так как у нас 8 ядер на шлюзе. По 4 отдаем на каждую сетевую. нет, сетевые две, внешние, двухпортовые, но используется только по одному порту, на вход и выход. Сейчас мы ожидаем когда проблема появится снова, чтобы точно сказать, что из-за количество пакетов становиться шлюзу плохо (поставили на мониторинг все магистрали на pps). Тогда будет все ясно.

На шлюзе кроме ната ничего нет, BGP на другом бордере. Шлюзы нужны для экономии выделенных адресов (используется pf). Сейчас подозреваю, что кто-то генерирует большое количество пакетов, тем самым ложится софтовый шлюз. tcpdump уже поставлен на мониторинг, будем анализировать его уже позже. По rx_int_delay, я видел, но параметр установлен. Счел это на баг самой сетевой. Но врятли это мешает, т.к. уже год все было отлично с этими параметрами. Насчет top я же писал, что взлетает в момент проблемы процесс rx_kthread до 100%. Какие-то пакеты переполняют буфер сетевой, а вот какие пока ещё неизвестно. Скорее всего дело в их количестве и в меньшем размере. Сейчас будем мониторить их.

Всем доброго дня. Коллеги прошу помощи в советах. Не могу понять кто валит наш шлюз, либо физик какой-то, либо странность в сети. Имеются два шлюза IBM для ната, перед ними есть bras в роли циски ASR1002. Оба шлюза под управлением FreeBSD 7.3 с yandex драйверами 1.36.2.17 (сетевые Intel® PRO/1000, хорошие сетевые, с трафиком не подводили). Работают они отлично и уже очень длительное время. После bras default-маршрут идет на первый шлюз, а на второй мы скинули 16 сетей (Для балансировки входящего в нашу сеть трафика, знаю что криво, но работает). Оба шлюза физически подключены в разные места (в разные коммутаторы), поэтому проблема точно не в физике (т.к. при переносе всего трафика на один из шлюзов, проблема повторяется). Теперь о самой проблеме. Вчера первый шлюз стал загибаться, процессы rx_kthread стали взлетать до 100%, тем самым съедать весь процессор. При выводе команды netstat -hw 1 (данные пока не сохранил) увидел, что копятся errs на input, при этом количество пакетов начинает падать (например с 60K до 3-4K, а ошибки возрастают до 6-7K). Суть в том, что длится это не долго, было вчера 3 раза и каждый такой сбой был от 3 до 10 минут. Bras (ASR1002) не загибается. Колбасит при этом первый шлюз очень даже не дурно. А вот со вторым шлюзом все нормально. Я думал, что это сам шлюз глючит, но когда я весь трафик перекинул на второй, второй стал тоже загибаться с такими же симптомами. tcpdump не выявил ничего плохого. Посмотрел дебаг сетевух: sysctl dev.em.2.stats=1 sysctl dev.em.2.debug=1 Единственное что я крутил у сетевух так это Коллеги помогите, пожалуйста. Подскажите, что за трафик такой может спровоцировать ошибки на сетевой при входе? Спасибо. P.S. Раньше когда трафика было много и шлюз был один, то при перегрузке ошибки появлялись на интерфейсе, но количество пакетов так сильно не падало (ну может на 2-3K, но не на 40K же). Когда появляется вышеописанная проблема, взлет трафика нет, по количеству пакетов сказать пока сложно, но вроде тоже не возрастает.

Ставил ситуация не менялась. На мультикаст натолкнуло то, что когда я циску вырубил, то шлюзы не видели в нейборах друг друга, по tcpdump видно было что они просто отсылали мультикаст hello-пакетами. В итоге когда сделал non-broadcast то все заработало, так как шлюзы стали отсылать helo пакеты напрямую друг другу и они подключились. Не получится, так как в cisco asr с ним проблема при использовании pppoe. Может все таки есть выход (без pwr)?

Перевел интерфейсы на шлюзе и циске в режим non-broadcast и указал друг другу neighbor. Все поднялось и не сбрасывает теперь маршруты. Видимо точно проблема в прохождении мультикаста. Главное в коммутаторе, котором подключена вся схема нет ничего блокирующего по мультикасту. Пробовал заменить коммутатор на другой ситуация та же. Может проблема в кваге. Во-общем щас на режиме non-broadcast все работает. Если можно то ещё вопрос: Можно ли как-нибудь через ospf заставить принудительно отправить траффик на один из шлюзов? Например подключился абонент с айпи 10.10.10.10, а ospf его трафик шлет только на 1.1.1.2 (а так он шлет и на 1.1.1.2 и на 1.1.1.3). А все остальные работали бы так как было.

Положил квагу на обоих шлюзах и на циске сделал clear ip ospf process. Поднял квагу на одном шлюзе и все тоже самое, маршруты сбрасываются и заново поднимаются. В логах шлюза 1.1.1.2: