не соглашусь, странно

Не одно устройство не дает информации куда и сколько ходил человек

это и - и возможностей больше

Не одно устройство не дает информации куда и сколько ходил человек

Это в идеале, я говорю достаточно было бы допилить торч или видимо я не совсем понимаю его работу

есть бот

который считает плюсы и минусы

почему я в никсах могу нетстат смотреть

а в торче он зависает

?

не соглашусь, странно

ОК. Поясню Системы IDS/IPS анализируют все пакеты на свои сигнатуры. 1. Это дорого по ЦПУ 2. Если у вас нет подписки на сигнатуры, то смысла в этом нет. Это как сейчас поставить антивирус с базой 2010 года

с историей?

это мне вопрос?

почему я в никсах могу нетстат смотреть

с истрией?

видимо мне

и я задумался сразу, как мне за период смотреть

?

сейчас NetFlow Analyzer для двух интерфейсов халява

Да нету единого правильного рисунка. кто к чему привык. А этот откуда стянули?

Я этой пользуюсь. )

И по ней в основном и учу

дейтсивтельно покруче будет) надо себе забрать

Ну схемка у Ильи всяко понятней чем схемка кинутая Евгением . Вроде всё то же , но геометрическое размещение утомляет глаза. Трудно с одного взгляда понять что за чем идет А относительно схемки их айпитейблсов лучше тем что показывает точки очередей

Эту можете не искать. Переделка из старого Simple Packet Flow которая была в MTCTCE, с учетом всех изменений. Сам рисовал )))

о блин, тогда вдвойне спасибо ?

чего то там нехватает

в очереди же можно отправлять 2 раза

до роута и после

чего то там нехватает

IPSec например. Инкапсуляциии, MPLS, Bridge не хватает. Они редко нужны

в очереди же можно отправлять 2 раза

Да, можно 2 раза. Если поставить RouterOS v5.x

Вот RouterOS 5x

Здесь Global-in есть. А 6 версии его нету

И в 6 версии Simple Queues это отдельный процесс. Тогда как в 5 версии там втихаря Queue-tree создавалось

хм странно а я в 6 в прероутинге...

нда

угу, вижу. а на деле чем это обернулось для пользователя? я о отсутвии Global-in так же , раз зацепили очереди, в чем отличие древовидных от симплов по нагрузке на проц. Почему то симплы сильней грузят проц. Была версия что из-за того что в simple родительские очереди тоже проверяют трафик на условия, а в НТВ родительские получаю трафик от kind-очередей и не проверяют на свои условия, сразу работают с тем трафиком

хм странно а я в 6 в прероутинге...

http://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6 http://wiki.mikrotik.com/images/thumb/2/2f/Pfd.png/1600px-Pfd.png

угу, вижу. а на деле чем это обернулось для пользователя? я о отсутвии Global-in так же , раз зацепили очереди, в чем отличие древовидных от симплов по нагрузке на проц. Почему то симплы сильней грузят проц. Была версия что из-за того что в simple родительские очереди тоже проверяют трафик на условия, а в НТВ родительские получаю трафик от kind-очередей и не проверяют на свои условия, сразу работают с тем трафиком

Например отсутсвием проблем с NAT. Что касается нагрузки на проц, то надо считать Queue-tree вместе с нагрузкой Firewall который маркирует трафик. Далее. Если у вас многоядрная платформа (CCR), то Queue-Tree вешается на ядро (одно дерево-один процесс). Simple Queue разбегается по ядрам (одна очередь - один процесс)

щас найду тот пост Олега. кину скрины

Олега щас , нету где то слинял, так что напишу я, как я это понял. Он маркировал пакеты. и уже по пакет-маркам пробовал организовывать очереди, сначала симплы, а потом древовидные, и сравнивал результат. Проц АМД 8 ядер.

Не готов комментировать. Возможно, надо было поменять порядок Simple Queue чтобы наиболее "жирные" были сверху. Возможно что на x86 это работает как-то по другому.

ну точный ответ не требуется. просто думал может на вскидку помнится в чем разница между такими типами очередей.

А чем отличается глобал от интерфейса

это где, в очередях что ли?

А чем отличается глобал от интерфейса

Global весь трафик. Interface трафик идущий с итерфейса

а маркировка

?

конмарк на исходящий в инет а внутри конмарка пакет макр для исх и вх очередей?

или без конмарка?

а можно ли повесить pcq на interface queue

сразу с лимитами

ну конмарк нужен только для обособления отдельного конекта. если ты работаешь с хостом вообще то можно обойтись без конмарка и работать сугубо по СРЦ/ДСТ адресу, по них вешать пакетмарки. Ну это чисто ИМХО

без htb

а можно ли повесить pcq на interface queue

а кто ж мешает то? но нафига тебе две очереди на интерфейсе? не забывай что там еще лежат апаратные очереди, доступа к которым у тика нет

вот вместо аппаратных

он вроде позволяет менять

НЕТУ

Дим. глянь свойство Only hardware queue

там стоит NONE

типа для апаратных очередей ничего не юзать.

типа если есть на железяке очередь - славно, пусть сама ковыряется. Нету? ну так и мы лезть не будем. ИМХО получается что ROS апаратными очередями рулить не может

Хм, а что должно получится с такой очередью на езер5? а то я слабо могу визуализировать себе инфу.

ERROR: S client not available

в теории очереди это через процесор, тоесть трафик на роутинге. А вот если очередь на интерфейсе то она и локальный трафик начнет обрабатывать?

ИМХО очереди на интерфейсах это попытка сделать подобие умного свитча с управлением пропускной способностью в локалке, но по сути это от лукавого и использовать не стоит - только геморой себе наживешь ?

вот незнай

зато оно так без манглов можно легко поделить поравну на все срц

ню ню. а что оно будет считать СРЦ? твой адрес или адрес "с той стороны" конекта? У меня позиция простая - до конца не понимаешь принцип работы то не лезь. вот и не лезу в очереди в таких местах. Ну до тех пора пока в голове не смогу разложить как оно будет работать в каждой ситуации.

то что проц не проц, так это для того трафика который пошел через проц наверно. срц будет считатся то что написано как src addr в ip заголовке -)

вроде нет

во времена РОС5 были даунлоад и аплоад. и оно считалось по тому в какой интерфейс входит трафик. если в тот за которым наш локальный адрес то это аплоад. если в интерфейс ВАН то это даунлоад, не зависимо что там в пакетах. Мы говорили "вот наш пул адресов" и оно делило что аплоад что даунлоад на основании входящего интерфейса. Ну это ЕСЛИ Я НИЧЕГО НЕ ПУТАЮ. а такое очень возможно

а сейчас нет даулоад и аплоад? о_О

как я понимаю для микротика оно всегда аплоад

но на разных интерфейсах

а сейчас нет даулоад и аплоад? о_О

а сейчас не интересовался, так что врать не хочу

а сейчас нет даулоад и аплоад? о_О

сейчас есть только ГЛОБАЛ

нету родителей глобальных ИН и АУТ кажись. а в 5 версии были

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

а крашеный трафик он как то дефолтно очередью учитывается или нужно мануально распихивать?

какой какой? с пакетмарками шоле?

нет, очереди идентифицируют трафик на основании пакетмарков. это для них ключевой идентификатор трафика

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

Может Илья найдет свободную минутку и раскажет ?

dscp

tos

PCQ на интерфейс теоретически повесить можно. Но только один. И вопрос, что тогда делать с классификатором трафика. В принципе очереди сейчас работают на выходном интерфейсе, поэтому можно попробовать на WAN и на LAN повесить РАЗНЫЕ PCQ

это ты предлагаешь в качестве идентификаторов или хочешь услышать о этих технологиях? Не торопи коней, человек только пришел, а сразу все вопросами засыпали

он привычный я знаю

-)

И, кстати, если глянете, то на Wireless и на hotspot висит SFQ для выравнивания пропускной.

мне интересно отрабатывает оно свое бест эффорт без доп настроек

ну на вайрлес да. правда не задумывался почему

мне интересно отрабатывает оно свое бест эффорт без доп настроек

На wireless там на него завяано ampdu и WMM

ну эт понятно но sfq red не умеют резать пополам

там нет лимитов