Jump to content
Калькуляторы

Подсчет и анализ сетевого трафика

Статья рассматривает сбор данных с маршрутизаторов Cisco для тарификации в автоматизированной системе расчетов, дает советы по исключению паразитного трафика при «помегабайтном» учете, а также проводит разбор и анализ трафика средствами flow-tools и rrdtools.

 

Полный текст новости

Share this post


Link to post
Share on other sites

у нас что, технические статьи без рекламы писать уже не принято?

хотя гораздо интереснее чем предыдущие две.....

Share this post


Link to post
Share on other sites

я что то пропустил рекламу Роснефти...

Share this post


Link to post
Share on other sites

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

К сожалению, из меня программер, как из бутылки брахмаширас. :)

Share this post


Link to post
Share on other sites

Антон не пиннай его, хотел как лучше, а получится как всегда.

 

А в коллектор реально можно скормить все, что душе угодно, соответствующее формату лога.

И будет абсолютно достоверная картинка для абонента.

С "метрологической поверкой".

Share this post


Link to post
Share on other sites
Guest VEK

Уже много лет работает с Нетфлов+Старт IP. Скажу кратко кривое решение, как и все что от Инфосферы.

 

Давайте рассмотрим этот вопрос немного с другой стороны, а нужно ли вообще собирать эти данные? Может имеет смысл посмотреть в сторону (упаси бога Junipper, более глючного поделия просто нет) 7301 + ISG? с выбором услуг? А не тянуть лямку флов потоков. Тем более у реальных телекомов каналы уже давно перевалили гигабитную планку. И все что может отбросить нормально Flow поток тупо не справляется.

Share this post


Link to post
Share on other sites
Guest Анончик

2 Гость_VEK_*:

можете и вовсе не использовать netflow, если вы этого зверя так сильно боитесь,

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

Share this post


Link to post
Share on other sites
Guest Trider

Мне статья понравилась. И считаю, что кому нужно тот будет собирать эти данный. ИМХО.

Share this post


Link to post
Share on other sites
А можно попросить автора чуть подробней и чуть доступней рассказать о мошенничестве с коллекторами данных биллинга? Весьма, весьма любопытная информация для инженерного бюрократа.

К сожалению, из меня программер, как из бутылки брахмаширас. :)

Веселые картинки прилагаются. Мошенничества нет. Только ловкость рук.

post-55178-1259744432_thumb.jpg

Share this post


Link to post
Share on other sites

Безлимитки рулят. Однако, статья потрясающая и будет великолепно увидеть продолжение, хоть по теме, хоть по другим вопросам сферы. Навеяло мысль подсчитать отдельно разные потоки трафика, но провайдерам лучше этого не делать - анонимность дороже.

Share this post


Link to post
Share on other sites
я что то пропустил рекламу Роснефти...
а кто говорил про роснефть?

 

В АСР «Старт-IP» есть механизм, который позволяет формировать динамические правила для исключения подобной ситуации.................. Понятно, что в «UTM» я такого не находил.

это как омега и астон-мартин у Джеймся Бонда. :)

 

 

p.s. повторюсь по теме, статья зачет.

 

Share this post


Link to post
Share on other sites

Актуальность статьи - 2004 2005 год. Именно в этот период было максимальное количество материалов по этой теме. Примеры http://tula.bofh.ru/articles/383 или http://xgu.ru/wiki/NetFlow

На opennet по ключу netflow около сотни статей.

 

За это время произошла куча движений. Например, появилась команда netflow egress, которая в корне меняет модель сбора трафика. Все серьезные операторы столкнулись с потерей трафика netflow. Где информация о лимите flow таблицы в 256 кб, что делает неприемлемым измерение гигабитных трафиков из за дропов флоу? Где инфа о концепции счетчиков в джунипере, слова о sflow?

 

Да, на картинке вариант сбора статистики только с одним аплинком. Автор тонко намекнул что в задаче с подсчетом трафика на двух бордерах с двумя аплинками применение netflow связано с большим гемороем. Правда геморой этот описан на нескольких страницах документации того же абсолюта, прародтеля старт-IP и успешно настраивался в лохматом 2002 году.

 

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

Share this post


Link to post
Share on other sites
За это время произошла куча движений. Например, появилась команда netflow egress, которая в корне меняет модель сбора трафика. Все серьезные операторы столкнулись с потерей трафика netflow. Где информация о лимите flow таблицы в 256 кб, что делает неприемлемым измерение гигабитных трафиков из за дропов флоу? Где инфа о концепции счетчиков в джунипере, слова о sflow?
Об этом уже написано куча статей в 2001 году! :) Прилагается.

А еще появилась команда mpls netflow egress. И об этом писать? Откройте документации на биллинги для операторов (UTM,Lanbilling) и поищите там подобное. Они до сих пор продают решения указанных вами годов, а другие его используют.

 

Да, на картинке вариант сбора статистики только с одним аплинком. Автор тонко намекнул что в задаче с подсчетом трафика на двух бордерах с двумя аплинками применение netflow связано с большим гемороем. Правда геморой этот описан на нескольких страницах документации того же абсолюта, прародтеля старт-IP и успешно настраивался в лохматом 2002 году.
Акцент делался на ошибки внутри собственной сети. Количество роутеров не имеет значения.

 

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

juniper_network_accounting.pdf

Edited by vit

Share this post


Link to post
Share on other sites
Guest Анончик

2 Нерубящий инспектор:

Как бы правильно вы не прикидывали, есть такое в нашей законодательной базе как "Федеральный закон о связи", ст.64 п.1 которого гласит: Операторы связи обязаны предоставлять уполномоченным государственным органам, осуществляющим оперативно-розыскную деятельность или обеспечение безопасности Российской Федерации, информацию о пользователях услугами связи и об оказанных им услугах связи, а также иную информацию, необходимую для выполнения возложенных на эти органы задач, в случаях, установленных федеральными законами.

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

Share this post


Link to post
Share on other sites

2Антончик

Для оперов есть СОРМ, я же говорил про абонентов.

А вообще, мучаюсь вопросом

Пришел битый пакет на интерфейс рутера оператора для абонента . Рутер определих херовый пакет, надо откинуть. Подсчитал в статистике как принятый, и кака плохой и... Откинул, т.е. пакет до абонента не дошел. А для АСР рутер передаст информацию о количестве потребленного трафика абонентом с учетом битого пакета или без?

Возьмем кусок из реальной статистики кошки, на интерфейсе которой один клиент

 

452410605 packets output, 857947676 bytes

314209 output errors, 0 collisions, 4 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

 

т.е. вышло клиенту 452410605 пакетов из них 314209 плохих. Начислит бабосы АСР за 452410605

или за 452410605 - 314209?

 

Edited by Нерубящий инспектор

Share this post


Link to post
Share on other sites

Поправка. 452410605 пакетов передано без ошибок.

314209 раз были ошибки.

Из пакетов нельзя вычесть ошибки.

Если данные в АСР поступают путем опроса счетчиков интерфейса маршрутизатора по протоколу snmp, то будут переданы "packets output" только. "output errors" - это другой счетчик.

 

Если netflow, то я даже затрудняюсь вам ответить. Эксперимент бы поставить.. В вашем случае вы показываете клиентский интерфейс. В случае, если на данном роутере сбор данных организован через ip flow ingress (ip route-cache flow), то он попал в кеш как только прошел через аплинк роутера. 100% он будет передан в АСР, а вот что там будет в качестве Dif , я понятия не имею.

 

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

3845#sh int Serial0/0/0:0
Serial0/0/0:0 is up, line protocol is up
...
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 392
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/0 (size/max total/drops)
...

 

На указанном интерфейсе висит политика

3845#sh policy-map test
  Policy Map test
    Class test
      drop
    Class class-default
      fair-queue
3845#sh class-map test
Class Map match-all test (id 2)
   Match access-group name test
3845#sh access-lists test
Extended IP access list test
    10 permit icmp host xxxx host yyyyy (428 matches)

В netflow попадают данные

Sif  SrcIPaddress     Dif  DstIPaddress      Pr SrcP DstP  Pkts       Octets
00f4 xxxxxxxxxxx    0007 yyyyyyyyy        06 e516 17    73         3059
00f4 xxxxxxxxxxx    0000 yyyyyyyyy         01 0    800   20         1680

Где в первом случае записывается индекс интерфейса, так как это tcp-трафик (protocol 6 = tcp) и в класс с drop'ом он не попал.

Serial0/0/0:0: Ifindex = 7

А во втором (protocol 1 = icmp) = 0

 

Таким образом, если в АСР не анализируется Dif ( о чем я и пишу в своей статье) то с большой вероятностью абоненту будет засчитан всякий хлам. Так на помегабайтной выделенке с ограничением по скорости на порту клиента может быть "передан" объем данных, который физически невозможно передать в определенный промежуток времени.

Edited by vit

Share this post


Link to post
Share on other sites
Guest Серега

Статья отличная! Виталя - молодец! Почерпнул для себя много нового.

Share this post


Link to post
Share on other sites

Неплохая статья.

Кстати, в flow-tools есть утилита flow-dscan - "Detect scanning and other suspicious network activity", рекомендую.

Share this post


Link to post
Share on other sites

Статья супер. Но видать инспекторов других тут нет. А вообще челу надо орден дать. По сути его статья - как можно нае.... иметь абонента. Да тут как минимум орден за честь и гражданское мужество. Так что - хер фирма здаст свои узлы у нас, пока не будет челу премия. А насчет концепции счетчиков - ну расскажите тем, у кого были проблемы в молодости с учителями по ин. язу. Ну некому было учить и русскому языку. С провинции мы...

Share this post


Link to post
Share on other sites

 

Я Вас умоляю... любой биллингист знает десятки методов отыметь абонента. По действующей нормативке невиновных нет. А вот вам команда сверху

придет - кого пущать, кого не пущать, вы и под козырек.

Share this post


Link to post
Share on other sites

Виталий, если есть такая возможность, можете прокомментировать один из вопросов Sonne.

Как настроить sflow на 7600 (и какой IOS взять), сейчас он ест ТСАМ так же как полный нефлов, и лишь отливает в коллектор меньше за счет сэмплинга.

Share this post


Link to post
Share on other sites

Мне почему-то казалось, что нетфлов как счетчик для денег уже давно все операторы похоронили. Ан нет, есть еще архиевреи в сибирских селениях, открывающие америку в очередной раз.. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this