BiTel

Уважаемые коллеги, подскажите пожалуйста.

Установили C7201 с софтом 12.2(33)SRC3. Возник вопрос по экспорту нетфлоу. А именно: имеет ли смысл включить ip flow в обе стороны, т.е. ip flow ergress/ingress на каждом интерфейсе? И как поведет себя логика АСР? Просто ведь ранее потоки нетфлоу экспортировались только о входящем трафике, а сейчас можно экспортировать как данные о входящем, так и о исходящем трафике интерфейса....

_________________
God Bless Linux! and blessings to FreeBSD!

делай привязки в биллинге не только по ipадресам, а и по интерфейсам
в этом случае можно мониторить столько интерфейсов и цисок сколько нужно не заботясь о задвоении трафиков
только snmp ifindex persist включи, что бы номера интерфейсов не "плавали"

Спасибо! Это понятно, что привязки к интерфейсам надо делать. Так и делаю.

Но! Получил следующую ситуацию:

Привязал диапазон внутренних, но в то же время реальных адресов к одному из правил. В статистике, получил исходящий трафик через определенный интерфейс договора на это правило привязки - как исходящий трафик! Что не правда! Это т же диапазон - за внутр. интерфейсами циски, а не за внешним, коим является указанный интерфейс договора?!

Поэтому вопрос, может надо включить flow ergress/ingress, т.е. в обе стороны?

Просьба помочь.

_________________
God Bless Linux! and blessings to FreeBSD!

Я не понял твоей проблемы.
В каждом флоу пакете есть поля src_if, dst_if, src_ip, dst_ip
включай на всех интерфейсах все что можно во все стороны и отлавливай нужный тебе трафик на нужных интерфейсах

например, клиент А и Б подключены через нацать маршрутизаторов канал к которым приходит в твою циску на интерфейс 23, следовательно
трафик на клиента А это dst_ip =<client A ip> and dst_if = 23
трафик от клиента А это scr_ip = <client A ip> and src_if = 23
тоже самое для клиента Б и всех остальных кто приходит к тебе через интерфейс с номером 23

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

где проблема то ?

проблемы когда флой генерится только от входящего трафика, тогда правила привязки сложные и составляются по правилу раз трафик пришел значит он куда то должен уйти (что кстати не всегда верно, как и то что трафик может образовываться на самой циске, например воип), раз есть возможность теперь генерить флой и от входящего и от исходящего трафика, то врубай и наслаждайся

Понятно, что надо включать в обе стороны....

Просто никак не могу описать ситуацию....

Может так:

есть сеть1, которая подключена реально на инт. 5, например, есть есть которая на инт. 6, и есть сеть которая на 7.

Но есть общий аплинк, который с номером 10, например. На нем, суть большинство трафика, направленного на вышестоящий маршрутизатор.

Так вот, я сделал привязку которая мачит сначала сеть 5 вх, сеть 5 исх, далее так же 6 и 7. Последнее правило мачит 0 - 255.

Привязал это разбиение к инт. 100 и получил трафик, который как ИСХОДЯЩИЙ (что странно) от сети 5, например - составляет 90 процентов всего пропущенного трафика, а вот правило, которое должно было уловить все остальное - 3-4 %....

_________________
God Bless Linux! and blessings to FreeBSD!

давай в реальных цифрах, а то так можно пальцы сломать пытаясь что то объяснить
я например так и не понял используешь ли ты в правилах привязку к номерам интерфейсов или только по IP адресам

Да, используется привязка договоров к интерфейсам, при этом схема, по которой мачится трафик - как в предыдущем посте.

Т.е. сейчас рассматривается случай, когда мы на одном договоре имеем один интерфейс.

_________________
God Bless Linux! and blessings to FreeBSD!

извини, я щас специально еще два раза перечитал, и ну вот нифига не понял, напрочь, вначале у тебя интерфейсы 5, 6 и 7, потом правило которое 0-255, которое ты привязываешь к интерфесу 100, на котором это правило "например" ловит 90% трафика который пропущен

я не пил, и не курил сегодня, а ты ?

Интерфейс 100 - общий аплинк рутера.

_________________
God Bless Linux! and blessings to FreeBSD!

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

У меня тут смутные сомнения, ты случаем не про правила "привязки услуг" говоришь ? А то они тебе в твоей задаче совсем не нужны. Все что надо это описать интерфейсы в модуле IPN и затем при назначении клиенту адресов просто ставить "галку" на том интерфесе который к нему "ближе".

Это понятно, но как обсчитать пропускаемый трафик через аплинк?! Т.е. весь трафик, который прошел через аплинк. Просто для того что бы потом сравнить с тем, что отгрузился на клиентов...

_________________
God Bless Linux! and blessings to FreeBSD!

м.... смотно помнится что в документации описывалось как перекидывать блоки адресов с договора на договор
т.е. заводится фейковый договор, на него вешается целиком адресный блок твой AS и потом с этого договора перекидываются адреса на договора клиентов, таким образом на фейковом договора остается трафик который не упал ни на один из клиенских договоров
сам не пробовал, на сколько это удобно не знаю

вариант второй, трафик собираем flow-tools (ну я бы в любом случае собирал им, а не java коллектором, ибо во первых масса утилит для анализа накопленных flows, во вторых оно все же быстрее ибо на цэ написано), затем запускаем два коллектора BGNetflow, настраиваем их одинаково и обо натравливаем на один и тот же каталог flow-ов созданных flow2bitel.sh

данные одного коллектора привязываем к фейковому договору на котором цепляем полный блок адресов, хоть 0.0.0.0 - 255.255.255.255 (если правильно расписаны правила привязки услуг)
данные второго коллектора используем для привязки клиентов

одно но, на фейковом договоре ты не сможешь посмотреть статистику никакую о том "кто из IP сожрат так дофига трафика", объемы в базу BGBilling пишутся для блока адресов целиком.

За методику - спасибо. Буду думу думать... В любом случае, пока не удалось собирать корректно трафик пропущенный через аплинк рутера...

_________________
God Bless Linux! and blessings to FreeBSD!