DimaM

Если по простому: 1) L3 включение СКАТ (т.е. между абонентами и скат есть L3-устройство ( маршрутизатор) ) абоненты-...-роутер1-СКАТ-роутер2(бордер)-интернет на роутере2 для NAT пула IP адресов (белых) прописываете маршрут на роутер1 и на этом все роутер1 ничего про эти белые адреса не знает, так как он имеет дело уже с серыми адресами, который получаются после прохода через скат аналогично роутер2(бордер) ничего не знает про серые адреса 2) L2 включение СКАТ (терминация PPPoE/VLAN/QinQ производится на СКАТ , между абонентскими CPE и СКАТ только свичи) абоненты-СКАТ-...бордер-итернет в этом случае у СКАТ есть IP (пусть и виртуальный) - весь входящий из инета трафик маршрутизируем на этот IP

говоря про СКАТ КЭШ: обновления ПО кешируются практически со 99% эффективностью (один раз загрузился из инет - 100 раз раздался из локалки), так что маленький вы оператор или большой, значения не имеет кроме того большой плюс кеширования, что обновления ставятся из кэша значительно быстрее через сеть, например винда 10 ставится с нуля практически на порядок быстрее вот с фильмами и торрентами да - тут размер имеет значение, тк у маленького оператора низкая повторяемость (все смотрят разное) статистику удобно анализировать через ipfix (netflow v10), который экспортируется со СКАТ, и всякие аналитические базы типа Splunk или бесплатный ELK - там можно делать красивые отчеты и дэшборды коннекторы для ipfix можно найти почти для всего но в принципе можно пройтись и grep/awk по текстовому log, который получается на выходе ipfixreceiver даже в netflow статистике есть информация о хостах (причем не только открытый HTTP, но и защищенный HTTPS/QUIC) - по ней можно сопоставить объемы и хосты также есть подробная статистика Clickstream в которой есть полные URL - по ней в приницпе можно заранее посчитать эффективность кеширования еще плюс, то что файловая система открыта - удаление из кеша - это просто удаление файла, также можно подгрузить что-то свое или даже подменить :) например обновление avast, которой загружается отсюда http://uupdate.avast.com/files/emupdate/avast_17_5_r5_b8_271.cab попадет в файл с названием /data/exts/cab/uupdate.avast.com/files/emupdate/avast_17_5_r5_b8_271.cab т.е. фактически url это и есть путь к файлу на файловой системе но есть засада - после инсталляции надо самому периодически тюнить кеш под себя, все крутилки для этого есть, но производитель этим не занимается

Не меньше 100 операторов Проверьте что у вас при подключении вход/выход на платформе не перепутаны, in_dev должен смотреть в сторону абонентов

Докатились, гигабит для абонентов уже не торт, тут уже десятку предлагают (10 Гбит/c) https://www.bahnhof.se/

против гугла слабо, а оператор никуда не денется PS надо взглянуть, кто на самом деле платит за размещение GGC, очень сомневаюсь, что это гугл, скорее некая шарашкина контора, с которой взять нечего

итград за комиссию оказывает техподдержку 1 (иногда 2) линии : принимает звонки, отвечает на типовые запросы, 3 линия ТП это уже точно вас эспертс многие западные компании так работают, у того же оракл начальные уровни ТП осуществляются через его местных партнеров

>Решили ли эти вопросы? их и не было никогда в коммерческой версии наверное все дело в nginx завтра посмотрю

посмотрите пример отчетов по протоколам и направлениям, который идут со скат версией nfsen elasriflow любопытная вещь, надо будет посмотреть, а то splunk слишком дорого

Это не фейк, это бред. РКН хочет быстро всех перевести на новый метод блокировки по дельтам - очень уж блокировка в течении 6 минут привлекательна, и затребовали реквизиты всех операторов, которые "переходят" (и которых у скат > 550), иначе не дадут льготный период (2 недели без штрафов). Как собрать хоть что-нибудь ? Разве что письмо разослать. Но есть операторам плюс после перехода: для доступа к реестру не будет нужна ЭП, с которой вечный геморрой - денег стоит и продлять нужно не забывать.

берут пример с китайцев, у которых национальная карта unionpay принимается везде, даже там где нет visa/mastercard тем более есть планы интегрировать эти системы (мир и unionpay)

pps мы не скрываем, но и типовой цифры как у коммутатора нет, есть нижняя цифра на которую мы ориентируемся: на типовом операторском трафике (так называемый Internet MIX) при всех включенных dpi сервисах pps должен быть не меньше 3,5 млн на каждый 10Г линк сравнивать dpi (в котором nat это 5%) с чистым nat по pps конечно можно, но не совсем корректно: можно предположить что у чистого nat, если он написан не криво, pps будет выше PS но это не про linux/freebsd я говорю, где pps ниже и этому наверное ничто не поможет

:) как ни странно эти числа совпадают: по коду поддержка NAT составляет 5% от общей функциональности и кушает он дополнительные 5%

Кстати, сейчас проходит battle года : СКАТ, РДП и Huawei схлестнулись в тендере на поставку NAT в Virgin Connect (того самого Брэнсона, который владеет кучей бизнесов, в т.ч. авиакомпанией Virgin и строит Space Ship One для полетов в космос), это их филиал в России и там сотни гигов трафика. Для справки: похожий тендер уже был 2015 г в Ростелеком и там 70% выиграл РДП и 30% Huawei.

*) в домашних роутерах есть UPnP, PMP и прочие технологии, которые невозможны у операторов **) СКАТ имеет производительность 100 Гбит/c на 1 Rack Unit, но лишь 5% от CPU кушает собственно NAT, остальное это распознавание протоколов, шейпинг/приоритезация, BRAS, СОРМ и прочие сервисы ***) в 2017 "первые" места берет продукт, который сейчас существует только на бумаге - в этом мире все возможно за хорошую цену, а за нас говорит количество наших клиентов

Очень даже взаимосвязаны и недоNAT - это одна из причин уменьшения доли трафика торрентов. Ведь даже сейчас у торрентов 20% (а 3 года назад было больше 40%) трафика - это очень неплохо и это могла бы быть прямая экономия для оператора, если не выпускать торрент за пределы оператора и его пиринга. Как пример: В Беларуси (по крайней мере в Минске) есть дешевый межоператорский пиринг при дорогом интернет, а в пиринге есть всебелорусский ретрекер, на котором почти "всё есть". Казалось бы - ура! - сэкономим 20% на трафике, загнав торренты в пиринг с помощью приоритезации торрентов на СКАТ. СКАТ умеет выборочно ограничивать раздачи с внешних IP адресов в пользу адресов из пиринга, проверяя, что эти раздачи в пиринге есть, иначе он их не ограничивает, т.е. действует не наугад, ограничивая все торренты подряд или просто полагаясь на эффективность ретрекера, как в других решениях, а точечно и эффективно. У крупного оператора [цензоред], у которого почти у всех абонентов временные белые адреса, такое решение работает отлично. А что мы получили в Беларуси? Почти 90% пиров не могут связаться друг с другом, т.к. оба пира (абонента) сидят за операторскими NAT, которые далеко не CGNAT и эти NAT тупо не пускают их друг к другу, так как NAT в Linux (а также FreeBSD, Vyatta, Microtik, RDP и пр - это либо простой port restricted NAT, либо частичная имитация CGNAT). Как известно, port restricted NAT пропустит входящий запрос, только если у него source port сохранился, но этого не произойдет, так как NAT другого абонента выбирает source порт случайным образом. Там же, где оператор использует честный CGNAT (СКАТ, A10) , раздача торрентов работает (даже если качающий абонент за недоNAT) Вообщем никакие dht, peer exchange и BEP22 это дело не исправят, т.к. тут дело в NAT. Раздавать помогают только белые адреса, teredo, ipv6 и то что, не все клиенты сидят за port restricted NAT, а без большого количества раздающих торренты постепенно задыхаются. PPS Раз я не поленился и все это написал, то в порядке компенсации еще немного саморекламы : ко всеобщему счастью все больше и больше операторов в России и СНГ (включая Украину) выбирают СКАТ. На сегодня нас уже больше 550 ! Аллилуйя! :)

Жаль что CGNAT есть только в заголовке статьи, а в самой статье его нет: что это такое, в чем его преимущество, как проверить что у вас настоящий CGNAT, а не лажа какая-то. А тем временем недо-NAT на тазиках Linux/FreeBSD почти убил такую полезную вещь как ретрекеры в IX и прочих пирингах, которые еще недавно здорово позволяли экономить на трафике.

Из РКН прислали письмо кого перевести на новую схему, остальных не надо, по крайней мере пока. К сожалению все старые проблемы сохранились и с новой схемой обновлений, из которых главные: 1) то что оператору обновление становится доступно через 5-9 минут, если сравнивать с датой обновления, указанной в файле dump.xml или dump_delta.xml + оператору надо дать какое время на обработку списка и его загрузку во все dpi на сети, но РЧЦ ориентируется только на дату из реестра, которая "ни о чем" и вероятно указывает на время, когда он только начал формироваться 2) расхождения списков в Ревизоре и на DPI (Ревизор проверяет по устаревшим спискам в результате "находит" исключенные из реестра сайты, но известны также случаи, когда он про urgent записи узнавал раньше оператора и сразу бросался их проверять) 3) мусор в реестре (русские буквы в разных кодировках, якоря и просто баги) Раз уж что-то дорабатывали, то хотя бы эти древние проблемы могли бы решить.

наверное надо умножить на 3 или при построении отчета в source оставить только коллектор с протоколами (убрать _as)

конечно можно: в инструкции по настройке nfsen как раз указано 2 коллектора с агрегацией по протоколам и направлениям, в параметре netflow указывается, какие коллекторы будут использоваться через сумму (параметр по сути bitmask), пример 1 + 8 -> netflow=9

Используйте экспорт с агрегацией по протоколам (netflow=1) - он компактный и поэтому как раз для таких графиков подходит, собственно его допиленный nfsen поддерживает "их коробки", для органов снимайте netflow=8 без замены портов.

что говорит yum info nfdump ?

Если не заморачиваться с дельтами, от которых сомнительная польза, то перепиливать почти ничего: 1. Поменять url на новый, добавив в него авторизацию https://login:passowrd@.... 2. Запрос с ЭЦП и ждать его выполнения делать не надо , а загружаем сразу результат с помощью того же GetResult, но в качестве codestring указываем "preved medved" (ну или все что угодно)

Неделю назад перешли. И верно: ЭЦП не нужна. Скорость применения обновлений сократилась до минуты.

IMHO на стороне dpi поддержка дельт - это лишнее: загрузить с локального диска полный список на dpi занимает сотые доли секунды, что там можно сэкономить ?

Во первых не надо было подписывать каждый запрос заново, достаточно подписать запрос один раз, для чего достаточно бесплатной версии криптопро, скопировать запрос и подпись на сервак и пользоваться ими целый год. PS Но даже этот совет уже устарел, т.к. ЭЦП для забора списков больше не требуется.