Перейти к содержимому
Калькуляторы

usachaa

Пользователи
  • Публикации

    9
  • Зарегистрирован

  • Посещение

О usachaa

  • Звание
    Абитуриент
  1. Да именно когда есть толпа айпи даже не из одних подсетей, и часть надо загнать даже в общие шейперы, когда у юзера несколько айпишек, а канал должен быть общий.Работа уже ведется в этом направлении. Я решаю задачу с несколькими ip у пользователя даже из разных сегментов, заведеним одного общего класса для пользователя, и в него как дочерние классы для каждого его IP . С использыванием imq трафик всех сетей проходит по одному интерфейсу и это становится возможным. Ну как мы и думали, у меня не совсем получится такое, ибо уже реально пересекаться будут это раз. А во вторых юзеров столько что архитектура давно уже не на одном шлюзе. Есть локальная типа точка обмена трафиком куда включаю шлюзы (на компах или аппаратные) которые маршрутизируют трафик на пиров, или в другие точки обмена трафиком, на аплинки и т.п. И туда же включаются шлюзи доступа юзеров в инте. Посему на шлюзах доступа в инет есть только интерфейс включения в точку обмена трафиком, и вланы где юзеры. В такое архитектуре резервирование на важных направлениях легко делается (для аплинков через бгп, просто 2 роутера включения) для юзерских шлюзов шлюз на подхвате что переведет на себя вланы и конфиг упавшего шлюза, или горячее всегда все заведено только поднять интерфейсы, типа для випов или для юриков. Вот такое. А так как есть уже могут быть пересечение 2 байт последних, то тут через марк уже не как :(. Ладно работаем дальше как что все попробуете и поймете надо или нет :). Еще есть одна идея, но пока не придумал как реализовать. Типа по хешу находим нужный айпи, а в хеше храним цепочку куда надо прыгнуть, и прыгаем в нее. Типа когда надо в зависимости от юзера надо специфичные для него правила применить. У нас практически также. Несколько роутеров близнецов. На каждом часть вланов при падении одного hearbeat поднимает у себя недостающие линки другого. Трафик между эти роутерами отдельная песня. Но смысл в решении похожий. Кстати еще рац. предложение, можно в лог писать realm маршрутов. Откуда пришло ушло. Тоже очень полезная информация. И с iptables тоже вяжется хорошо.
  2. Да именно когда есть толпа айпи даже не из одних подсетей, и часть надо загнать даже в общие шейперы, когда у юзера несколько айпишек, а канал должен быть общий.Работа уже ведется в этом направлении. Я решаю задачу с несколькими ip у пользователя даже из разных сегментов, заведеним одного общего класса для пользователя, и в него как дочерние классы для каждого его IP . С использыванием imq трафик всех сетей проходит по одному интерфейсу и это становится возможным.
  3. А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?. Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него. нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте. Ну если это даст выиграш в производительности, то да нужная штука будет. Хотя "tc filter add dev ethX parent 1:0 protocol ip fw" очень шустро раскидывает пакеты по иерархии. При рейте в 400тыс пакетов/сек опрофайл показывает что классификатор потребляет ресурсов на уровне 0.5-0.7% более подробно опиши как у тебя сейчас работает в целом (iptable и tc правила как проходит трафик), и я укажу место про которое я говорю. Немного подробностей, чтобы вам было понятнее. Имеется роутер с кучей гигабитных интерфейсов Intel 82571EB(PCIE,NAPI, 2 TX HANDLER). Со стороны клиентов на него приходит около 50 vlan на bond группу из 4 интерфейсов. В каждом влане от 60 до 180 юзверей. "Клиентские" интерфейсы переименовываются c cli.XXX для оптимизированного группового применения правил iptables, также "Пиринговые" в peer.XXX, а "Интернетные" в up.xxx. Используются несколько imq псевдоинтерфейсов, для организации шейпов по направлениям. Локальный, пиринговый, интернет. На примере локального трафика. Первое: Заворачиваем локальный трафик(между клиентами) на imq0 интерфейс. Необходимо использовать MARK, так как imq не полная эмуляция и указывать с -i/-o imq0 не получается, тем более маркировка пригодится ниже. Маркируем весь локальный трафик 4, и по этому марку заворачиваем в imq0. В mangle FORWARD имеем. 6559M 6287G MARK all -- cli+ cli+ 0.0.0.0/0 0.0.0.0/0 MARK xset 0x4/0xffffffff 6559M 6287G IMQ all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4 IMQ: todev 0 Второе На imq0 построена htb иерархия классов с именами из последних двух октетов в хексе. Пример (192.168.16.133) -> 16.133-> 1085 В mangle POSTROUTING имеем 6555M 6284G IPMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4 IPMARK dst ip and 0xffff or 0x10000 IPMARK перемаркирует весь трафик промаркированный выше 4(локальный), исходя из двух последних октетов dst IP, пример (192.168.16.133) -> 16.133-> 1085 Новый MARK на трафик dst ip 192.168.16.133 будет 1085. В итоге мы имеем что весь трафик на устройстве imq0 промаркирован. Третье. Классификатор. Раскидываем трафик по пользовательским классам на imq0. Одной командой. /sbin/tc filter add dev imq0 parent 1:0 protocol ip fw Весь трафик попадает согласно маркировке в одноименные классы. Что имеем в итоге, минимум правил в iptables/tc, прекрасную маштабируемость, настройки никак не зависят от количества абонентов. Остается только следить за двумя моментами. Чтоб не появились в сети ip с одинаковыми двумя последними октетами, иначе попадут в один класс, посему приходится следить за заведением новых серых сетей, чтоб они 3 октетом не пересеклись с имеющимися реальными сетями, и за своевременном созданием классов в иерархиях, иначе весь трафик что не нашел для себя класса по марку попадает в дефолтный класс с низкой скоростью 1bit/s(фактически банится).
  4. А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?. Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него. нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте. Ну если это даст выиграш в производительности, то да нужная штука будет. Хотя "tc filter add dev ethX parent 1:0 protocol ip fw" очень шустро раскидывает пакеты по иерархии. При рейте в 400тыс пакетов/сек опрофайл показывает что классификатор потребляет ресурсов на уровне 0.5-0.7%
  5. А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?. Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.
  6. Понял наконец что вы имеете ввиду. Тоесть соединение открылось через одну пару sif<->dif и в процессе поменялись итнерфейсы. Да такое возможно. Надо разделять на две записи и больше, агрегировать и по этим полям надо.
  7. В netflow потоке экспортируемом ipt_NETFLOW есть поля sif dif (ifindex интерфейсов) в записях, вот их требуется продублировать в формате данных получаемых через /proc. Данные по абоненту считаются по направлениям. Направление Интернет, направление сетей соседних оперторов получаемых через точки обмена трафиком, и тд. Одна сеть может быть доступна через разные каналы в разные моменты времени, и агрерировать по сетям не получается, приходится списки сетей постоянно обновлять. Необходимо знать откуда пришел пакет, и через какой порт он покинул роутер. Использование IMQ не отражается никак на netflow данных собранный средствами ipt_NETFLOW, там sif = индексу физического интерфейса откуда пришел трафик, а dif = индексу через который он покинул роутер.
  8. Да именно два поля в ipt_ipcad_flow_checkpoint. sif и dif что имеют место быть в netflow формате, и которые вот вы недавно фиксили для ядер 2.6.28 и выше. Просто фактические интерфейсы откуда пакет пришел и через какой интерфейс покинул хост. Практической пользы от записи промежуточных интерфейсов типа IMQ наверное нет.
  9. Реальная штука. Протестировано на потоке больше 2Gb/s. Посчитанный ipt_NETFLOW трафик практически равен трафику связки ipcad+libpcap+PF_RING что радует, разница всего 0.05% причем в большую сторону. В данный момент работают обе схемы для сравнения за длительный период. Предлагаю еще в ipacct формат добавить два поля sif dif , что позволит оперативно считать и здесь направления трафика не по сетям (при подлючении к точкам обмена трафиком, их количество достигает многих тысяч и постоянно динамически меняется) а по интерфейсам что правильнее и удобнее.