The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Разница в статистике с провайдером"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение [Проследить за развитием треда]

"Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 30-Июл-03, 17:05  (MSK)
Провайдер в конце месяца присылает бумажку по загрузке портов Frame Relay.
Мы на cisco 2621 считаем трафик по ip accounting.
Плюс к том же у нас есть трафик между клиентами, проходящий только через нашу cisco и не фиксируемый провайдером.
Разница у нас и провайдера достигает до 13 процентов на канал.
Вопрос:
Как провайдер считает загрузку порта.
Может ли сказываться такая разница, что провайдер считает по netflow, мы по ip accounting, если ли у кого статистика по расхождениям.
Может ли от того что провайдер считает именно по портам (хотя как это можно все равно netflow), а мы по адресам клиентов?
  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "Разница в статистике с провайдером" 
Сообщение от Volume Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 30-Июл-03, 17:34  (MSK)
>Провайдер в конце месяца присылает бумажку по загрузке портов Frame Relay.
>Мы на cisco 2621 считаем трафик по ip accounting.
>Плюс к том же у нас есть трафик между клиентами, проходящий только
>через нашу cisco и не фиксируемый провайдером.
>Разница у нас и провайдера достигает до 13 процентов на канал.
>Вопрос:
>Как провайдер считает загрузку порта.
>Может ли сказываться такая разница, что провайдер считает по netflow, мы по
>ip accounting, если ли у кого статистика по расхождениям.
>Может ли от того что провайдер считает именно по портам (хотя как
>это можно все равно netflow), а мы по адресам клиентов?


провайдер у вас весь траффик считает, а вы IP accounting-ом только L3

  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 30-Июл-03, 17:47  (MSK)
Извини за неловкий вопрос весь это какой L.
netflow ВЕСЬ посчитает?
  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Разница в статистике с провайдером" 
Сообщение от Volume Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 30-Июл-03, 20:51  (MSK)
>Извини за неловкий вопрос весь это какой L.
>netflow ВЕСЬ посчитает?

весь - это L2+L3
а откуда такая уверенность про нетфлоу? может ваш провайдер просто счетчики с интерфейса снимает? :))

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "Разница в статистике с провайдером" 
Сообщение от Асен Тотин emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 30-Июл-03, 21:03  (MSK)
Привет,

Netflow смитает только IP трафик, поскольку route cache находиться внутри рутера и трафик доходит до него без всяких L2 украшений.

Выясните прежде всего как ваш провайдер считает трафик:
* По Netflow
* По SNMP, считывая счетчики интерфейсов

Frame Relay сам по себе дает overhead но он вряд ли может достичь 10 процентов и более... Frame Relay - очень "легкий" протокол, расчитанный на цифровые линии связи с почти нулевым уровнем ошибок. Как пролегает физически связь между вами и вашим провайдером?

WWell,

  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 08:19  (MSK)

>Выясните прежде всего как ваш провайдер считает трафик:
>* По Netflow
>* По SNMP, считывая счетчики интерфейсов

Да кто же скажет как, коммерческая тайна.


>
>Frame Relay сам по себе дает overhead но он вряд ли может
>достичь 10 процентов и более... Frame Relay - очень "легкий" протокол,
>расчитанный на цифровые линии связи с почти нулевым уровнем ошибок. Как
>пролегает физически связь между вами и вашим провайдером?

Оптоволокно.

А каким образом считывание счетчиков, где можно про это по подробнее?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "Разница в статистике с провайдером" 
Сообщение от Асен Тотин emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 12:31  (MSK)
>>Выясните прежде всего как ваш провайдер считает трафик:
>Да кто же скажет как, коммерческая тайна.

Мне кажется, если ваш провайдер ужавает себя как компанию, он должен указать это как минимум в ваш Service Level Agreement - ведь считывание трафика и есть одна из гарантий на качество услуги. Методика считывания не мжет никоим образом быть коммерческой тайной - это все равно, чтоб ваш телеком не объяснил вам как он тарифирует телефонные разговоры... Если у вас нет Service Level Agreement - затребуйте такой с указыванием всего, что вас интересует.

>А каким образом считывание счетчиков, где можно про это по подробнее?

Самый простой способ - SNMP. Можно каждые N минут (чаще всего 5) считывать счетчики на интерфейсах, заносить в базу данных и отчитывать трафик. Не то, чтоб лучший способ, но если выполнить на совесть, будет работать верно.

Подробнее прочитать можно в любом материале Cisco, где говориться про SNMP. Вам нужны:

1. SNMP доступ к рутеру - чаще всего достаточно порписать ваш хост в ACL 1 и прописать в рутере SNMP Key типа:

snmp-server community Community_Key RO 1

2. Любой SNMP software, например snmpget для UNIX.

3. SNMP OID (Object Identifier), соответствующий данному интерфейсу - можно поискать в Интернете.

WWell,

  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 14:41  (MSK)
>>>Выясните прежде всего как ваш провайдер считает трафик:
>>Да кто же скажет как, коммерческая тайна.
>
>Мне кажется, если ваш провайдер ужавает себя как компанию, он должен указать
>это как минимум в ваш Service Level Agreement - ведь считывание
>трафика и есть одна из гарантий на качество услуги. Методика считывания
>не мжет никоим образом быть коммерческой тайной - это все равно,
>чтоб ваш телеком не объяснил вам как он тарифирует телефонные разговоры...
>Если у вас нет Service Level Agreement - затребуйте такой с
>указыванием всего, что вас интересует.
>
>>А каким образом считывание счетчиков, где можно про это по подробнее?
>
>Самый простой способ - SNMP. Можно каждые N минут (чаще всего 5)
>считывать счетчики на интерфейсах, заносить в базу данных и отчитывать трафик.
>Не то, чтоб лучший способ, но если выполнить на совесть, будет
>работать верно.
>
>Подробнее прочитать можно в любом материале Cisco, где говориться про SNMP. Вам
>нужны:
>
>1. SNMP доступ к рутеру - чаще всего достаточно порписать ваш хост
>в ACL 1 и прописать в рутере SNMP Key типа:
>
>snmp-server community Community_Key RO 1
>
>2. Любой SNMP software, например snmpget для UNIX.
>
>3. SNMP OID (Object Identifier), соответствующий данному интерфейсу - можно поискать в
>Интернете.
>
>WWell,


Данные с МРТГ для этого не подойдут? Это одно и тоже?!

  Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "Разница в статистике с провайдером" 
Сообщение от Асен Тотин emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 15:32  (MSK)
>Данные с МРТГ для этого не подойдут? Это одно и тоже?!

Ну, "одно и то же"... MRTG - это приложение для снятия данных по SNMP и отображения их в виде график. Насколько мне известно, MRTG берет именно эти счетчики, но MRTG не ведет подсчет трафика, его интересует разница с предыдущего состояния, а вас интесерует накопление. Мне неизвестен быстрый способ "присобачить" MRTG для _точного_ подсчета трафика. Приближенную стоимость (с отклонением до. 5% от данных по Netflow) можно получить, если взять средние стоимости за период, которые MRTG подсчитывает, и помножить на время.

WWell,

  Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 16:31  (MSK)
Ответ провайдера

"...
Для разных каналов трафик расчитывается по-разному.
В основном при помощи программного обеспечения для Cisco( ip accounting )."

Я чего то не поналя это как для разных каналов по-разному?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

10. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 17:06  (MSK)
sun# snmpget 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9                        
interfaces.ifTable.ifEntry.ifOutOctets.9 = Counter32: 1176514080
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 a 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not IpAddress)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 i= 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not INTEGER)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 u 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not Unsigned32)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 s 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not OCTET STRING)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 x 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not OCTET STRING)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 d 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not OCTET STRING)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 n 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad object type: n
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 o 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not OBJECT IDENTIFIER)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 t 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not Timeticks)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 a 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not IpAddress)
sun# snmpset 213.221.1.161 public interfaces.ifTable.ifEntry.ifOutOctets.9 b 0
interfaces.ifTable.ifEntry.ifOutOctets.9: Bad variable type (Type of attribute is Counter32, not BITS)
sun#

Пробую счетчики в ноль выставить не один типа не подходит?!

  Рекомендовать в FAQ | Cообщить модератору | Наверх

11. "Разница в статистике с провайдером" 
Сообщение от gru2003 Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 17:24  (MSK)
Абсолютно аналогичная ситуацтия (по методике подсчёта у нас и Прова) Расхождения не более 3 процентов. Но не всегда.
Во-первых как часто  снимаешь аккунтинг и каков буффер? Намёк на то что у Вас теряется часть записей. В своё время я уменьшил кратность снятия с 10 до 5 минут.
Во-вторых у меня бывают просто ломовые расхождения в отдельные(выходные, праздничные) дни вплоть до 100% И это обяснимо- у меня есть IP НАТ ПУЛ(в циске 2620) и несколько десятков IP из выделеной мне провом подсети класса С, которые не используются. Так вот, если по этим адресам проходят хацкеры своими сканерами(а это частое вление) или намеренная атака, то на мои IP-адреса это траффик будет насчитан. Точно так же он будет и на у меня аккаутинге как входящий. Тонкость в том, что если аккаунтинг обрабатывается ТОЛЬКО для назначенных адресов + внутренних адресов типа 192.168.x.x (которые ходят в И-нет через НАТ) тогда получается разница (клиенты из ЛАН траффик не порождали а на НАТЕ он есть и выставлять его некому). В будни такой траффик просто съедаеться и сотавляет десятые процента.
И наконец, в-третьих, чистота провайдера(меня, кстати, поразило, что выставляется счет для ppp адресов для Serial интерфесов между моей и провайдерской цисками(модемами E1)).
  Рекомендовать в FAQ | Cообщить модератору | Наверх

12. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 17:30  (MSK)
>Абсолютно аналогичная ситуацтия (по методике подсчёта у нас и Прова) Расхождения не
>более 3 процентов. Но не всегда.
>Во-первых как часто  снимаешь аккунтинг и каков буффер? Намёк на то
>что у Вас теряется часть записей. В своё время я уменьшил
>кратность снятия с 10 до 5 минут.

Исключено, за счет буфера потерь нет.

>Во-вторых у меня бывают просто ломовые расхождения в отдельные(выходные, праздничные) дни вплоть
>до 100% И это обяснимо- у меня есть IP НАТ ПУЛ(в
>циске 2620) и несколько десятков IP из выделеной мне провом подсети
>класса С, которые не используются. Так вот, если по этим адресам
>проходят хацкеры своими сканерами(а это частое вление) или намеренная атака, то
>на мои IP-адреса это траффик будет насчитан. Точно так же он
>будет и на у меня аккаутинге как входящий. Тонкость в том,
>что если аккаунтинг обрабатывается ТОЛЬКО для назначенных адресов + внутренних адресов
>типа 192.168.x.x (которые ходят в И-нет через НАТ) тогда получается разница
>(клиенты из ЛАН траффик не порождали а на НАТЕ он есть
>и выставлять его некому). В будни такой траффик просто съедаеться и
>сотавляет десятые процента.


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

>И наконец, в-третьих, чистота провайдера(меня, кстати, поразило, что выставляется счет для ppp
>адресов для Serial интерфесов между моей и провайдерской цисками(модемами E1)).

Не знаю как это проверить.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

13. "Разница в статистике с провайдером" 
Сообщение от gru2003 Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 17:42  (MSK)
>Исключено, провайдер обеспечивает маршрутизацию только на те адреса которые я ему указал,
>и на этим адресах есть хосты точно.
То есть у тебя ВСЕ хосты имеют маршрутизируемые адреса и НАТ не используется?

>Не знаю как это проверить.
Затребуй у него статистику для каждого адреса, с дискретностью допусти 60 минут за прошедшие сутки, где были расхождения (при сложении его цифры должны совпасть). А затем договоись на какой-нить день о взаимной проверке с представлением тех же данных только с меньшей дискретностью. Если в этот день разница будет меньше, значит в проверочный день решили накручивать по-меньше. Хотя довольно примитивно и вычесляеться. Если пров умный вместо 13 дадут 8-9, если жадный то те же 13% (ихмо). На основании этих данных смотри где расхождения при необходимости затребуй меньшую дискретность, хоть каждую минуту(будут сильно сопротивляться)

Да и что у тебя с широковещанием? Может в этом проблеиы? (Намёк то что для твоих броадкастов выставляется счёт =)

  Рекомендовать в FAQ | Cообщить модератору | Наверх

14. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 18:08  (MSK)
>>Исключено, провайдер обеспечивает маршрутизацию только на те адреса которые я ему указал,
>>и на этим адресах есть хосты точно.
>То есть у тебя ВСЕ хосты имеют маршрутизируемые адреса и НАТ не
>используется?

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


>
>>Не знаю как это проверить.
>Затребуй у него статистику для каждого адреса, с дискретностью допусти 60 минут
>за прошедшие сутки, где были расхождения (при сложении его цифры должны
>совпасть). А затем договоись на какой-нить день о взаимной проверке с
>представлением тех же данных только с меньшей дискретностью. Если в этот
>день разница будет меньше, значит в проверочный день решили накручивать по-меньше.
>Хотя довольно примитивно и вычесляеться. Если пров умный вместо 13 дадут
>8-9, если жадный то те же 13% (ихмо). На основании этих
>данных смотри где расхождения при необходимости затребуй меньшую дискретность, хоть каждую
>минуту(будут сильно сопротивляться)

А от сравнения не уйдешь, придется срвнивать.

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

>
>Да и что у тебя с широковещанием? Может в этом проблеиы? (Намёк
>то что для твоих броадкастов выставляется счёт =)

Frame Relay не широковещательная среда.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

15. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 18:14  (MSK)
Может быть связано расхождение с тем, что провайдер считает
ip accounting по Frame Relay

мы считаем
ip accounting по Ehternet

  Рекомендовать в FAQ | Cообщить модератору | Наверх

16. "Разница в статистике с провайдером" 
Сообщение от gru2003 Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 18:36  (MSK)
>есть одна сеть с натом, но какая разница пришел на нашу cisco на >реальный адрес, выходит этот трафик с нашей cisco разбившись по >локальным адресам, где тут потери.

Ну я ж оъбяснял. Допустим прошолся хацкерный сканер по нат пулу a.b.c.193 a.b.c.254 netmask 255 по 52 пакета 4056б на каждый IP(реальная ситуация). Провайдер посчитал, ты в аккауунтинге записал, НО в ЛАН этот траффик НЕ попл(или у тебя дыра). Затем ты считаешь траффик для IP-ЛАН (192.168.x.x) а там аккаунтигга для IP 192.168.x.x НЕТ. Вот и накапливаеться за день мегабайт под 100- 200 (или больше в зависимости от активности скана)

  Рекомендовать в FAQ | Cообщить модератору | Наверх

17. "Разница в статистике с провайдером" 
Сообщение от ataman Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 18:42  (MSK)
>>есть одна сеть с натом, но какая разница пришел на нашу cisco на >реальный адрес, выходит этот трафик с нашей cisco разбившись по >локальным адресам, где тут потери.
>
>Ну я ж оъбяснял. Допустим прошолся хацкерный сканер по нат пулу a.b.c.193
>a.b.c.254 netmask 255 по 52 пакета 4056б на каждый IP(реальная ситуация).
>Провайдер посчитал, ты в аккауунтинге записал, НО в ЛАН этот траффик
>НЕ попл(или у тебя дыра). Затем ты считаешь траффик для IP-ЛАН
>(192.168.x.x) а там аккаунтигга для IP 192.168.x.x НЕТ. Вот и накапливаеться
>за день мегабайт под 100- 200 (или больше в зависимости от
>активности скана)

Товарищ прав. Ведь аккунтинг считается на порту только в одну сторону. Поэтому там на том интерфейсе, где НАТ, можно что-то упустить. И вообще, провайдер считает какой трафик ? Оба? или только один из входящий/исходящий на его интерфейс ?
Самое действенное - взять и сравнить данные с провайдерскими. Это проще, чем ломать голову.


  Рекомендовать в FAQ | Cообщить модератору | Наверх

18. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 19:42  (MSK)
Сравнить.
Если есть расхождение там миллон записей!


  Рекомендовать в FAQ | Cообщить модератору | Наверх

19. "Разница в статистике с провайдером, ВСЕ ЖЕ ЧТО ТОЧНЕЕ?!!!" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 19:53  (MSK)
Так все же NetFlow это какой уровень?

Какая из трех технологий снятия трафика дает наиболее точный (по объему) результат?!

NetFllow
SNMP
ip accounting

  Рекомендовать в FAQ | Cообщить модератору | Наверх

20. "Разница в статистике с провайдером, ВСЕ ЖЕ ЧТО ТОЧНЕЕ?!!!" 
Сообщение от Асен Тотин emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 20:58  (MSK)
Whom How, как говориться в одном старом анекдоте:

SNMP дает только количество IP трафика, прошедшего через интерфейс.

NetFlow говорит про каждый пакет (точнее, поток пакетов) с какого адреса на какой, по каким портам и в каком объеме идет трафик.

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

WWell,

  Рекомендовать в FAQ | Cообщить модератору | Наверх

21. "Разница в статистике с провайдером, ВСЕ ЖЕ ЧТО ТОЧНЕЕ?!!!" 
Сообщение от gru2003 emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 31-Июл-03, 21:04  (MSK)
>Так все же NetFlow это какой уровень?
>
>Какая из трех технологий снятия трафика дает наиболее точный (по объему) результат?!
>
>
>NetFllow
>SNMP
>ip accounting

а не так
SNMP
NetFllow
ip accounting
?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

22. "Разница в статистике с провайдером" 
Сообщение от pavel Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 03:37  (MSK)
И наконец, в-третьих, чистота провайдера(меня, кстати, поразило, что выставляется счет для ppp адресов для Serial интерфесов между
        моей и провайдерской цисками(модемами E1)).

Позвольте не согласится в данном вопросе.Эти адреса,хоть и служебные
но они входят в PA блок провайдера,те через входящие каналы провайдера
трафик на эти адреса приходит(пусть и небольшой),ему он считается,почему провайдер не должен считать его вам? Точно так же,сложиваяся практика по фильтрации трафика.Хотите фильтровать,фильтруйте.Но не просите об этом своего провайдера-если он фильтрует-он попадает на ту сумму трафика,которую сбрасывает фильтр.Это достаточно очевидно.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

23. "Разница в статистике с провайдером" 
Сообщение от pavel Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 06:08  (MSK)
еще один факт-сравнил тут ip accounting и netflow
расхождение 0.203% в  пользу netflow.На большом трафике...
SNMP статистика-вообще по моему мнению никуда не годится.По ряду причин.
Самая главная-ненадежность (UDP) и большая неточность.Графики строить..
  Рекомендовать в FAQ | Cообщить модератору | Наверх

24. "Разница в статистике с провайдером" 
Сообщение от pavel Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 06:19  (MSK)
Взял первого попавшегося клиента - обсчитал по двум вариантам
нетфлоу и ип эккоунтинг
расхождение 0.627% на 1.7 гига
Вообще же мне мой провайдер сказал что меньше 4 процентов не стоит нервов
разборки.
  Рекомендовать в FAQ | Cообщить модератору | Наверх

25. "Разница в статистике с провайдером" 
Сообщение от pavel Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 06:42  (MSK)
Взял диалапный пул-10.5gb(ну да, почти и не продаем мы диалап),расхождение
двух методов 43928 байт. Так что .... не надо на зеркало.
  Рекомендовать в FAQ | Cообщить модератору | Наверх

26. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 08:56  (MSK)
>еще один факт-сравнил тут ip accounting и netflow
>расхождение 0.203% в  пользу netflow.На большом трафике...
>SNMP статистика-вообще по моему мнению никуда не годится.По ряду причин.
>Самая главная-ненадежность (UDP) и большая неточность.Графики строить..

Заверяю Вас что, NetFlow сбрасывает статистику по UDP.

О SNMP тут говорят не для прорисовки графиков а для снятия счетчиков.

Спорить не буду, можно привести кучу причин почему у Вас "совпало".

Если бы снятие ip accounting заключалось в хитрых перепетиях команд можно было бы поспорить, а то тут всего пару команд и ошибиться тут невозможно.


  Рекомендовать в FAQ | Cообщить модератору | Наверх

27. "Разница в статистике с провайдером" 
Сообщение от gru2003 Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 11:06  (MSK)
>Позвольте не согласится в данном вопросе.Эти адреса,хоть и служебные
>но они входят в PA блок провайдера,те через входящие каналы провайдера
>трафик на эти адреса приходит(пусть и небольшой),ему он считается,почему провайдер не должен
>считать его вам? Точно так же,сложиваяся практика по фильтрации трафика.Хотите фильтровать,фильтруйте.Но
>не просите об этом своего провайдера-если он фильтрует-он попадает на ту
>сумму трафика,которую сбрасывает фильтр.Это достаточно очевидно.

Павел?!!
У меня есть предположение, что наши фирмы между собой уже договорились? :D
Хотя может я и ошибаюсь =\ По теме: сложившаяся практика - аргумент сильный, однако руководство(по крайней мере моей фирмы) смотрит в договор(он составлен также, как Вы выражаетесь, по устоявшейся практике), в договоре многие(в т.ч. и "фильтрацию") вещи можно трактовать двояко(мы это называли "навязанный траффик" а не "фильтрациия"). Дальше смотрим в законодательство... А о его состоянии в нашей области все знают. Вот и договариваются все какким-то образом- сложившаяся практика. И тут я с Вами полностью согласен.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

28. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 13:19  (MSK)
Трафик по NetFlow составляет 0,97 от трафика по ip accounting.
При общем входящем трафике 52М за день.

С чем это может быть связано что нетфлоу проигрывает.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

29. "Разница в статистике с провайдером" 
Сообщение от gru2003 Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 20:30  (MSK)
>Трафик по NetFlow составляет 0,97 от трафика по ip accounting.
>При общем входящем трафике 52М за день.
Полностью согласен про меньше в сторну NetFlow по отношению ip accounting Правда по цифрам ничего сказать не могу- не проверял.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

30. "Разница в статистике с провайдером" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 01-Авг-03, 22:46  (MSK)
Значит NetFlow интересен только подробной информацией но не  трафиокм?!!! Очень жаль.
Еше вопрос я пытаюсь экспорить flow-export данные в mysql
sun# flow-export -d5 < ft-v05.2003-07-31.033000+0400 > -f3 -u root:1:localhost:3306:netflow:raw
flow-export: processed 168 flows
  sys:   seconds=0.024 flows/second=6814.033665
  wall:  seconds=0.012 flows/second=13536.379019
flow-export: Exported 168 records
sun#
Экспортер отчитывается об успешном экспорте.
ОДНАКО в логах базы не видно что бы к ней коннектились и таблица пуста!!!
Никто не встречался с такой проблемой.
NetFlow 0.66
  Рекомендовать в FAQ | Cообщить модератору | Наверх

33. "Разница в статистике с провайдером" 
Сообщение от pavel Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 19-Авг-03, 07:32  (MSK)

>Павел?!!
>У меня есть предположение, что наши фирмы между собой уже договорились? :D
Мы знакомы? Не очень понял.
>
>Хотя может я и ошибаюсь =\ По теме: сложившаяся практика - аргумент
>сильный, однако руководство(по крайней мере моей фирмы) смотрит в договор(он составлен
>также, как Вы выражаетесь, по устоявшейся практике), в договоре многие(в т.ч.
>и "фильтрацию") вещи можно трактовать двояко(мы это называли "навязанный траффик" а
>не "фильтрациия"). Дальше смотрим в законодательство... А о его состоянии в
>нашей области все знают. Вот и договариваются все какким-то образом- сложившаяся
>практика. И тут я с Вами полностью согласен.

Не согласен.Интернет построен на принципе полносвязности сетей.Например,вас флудят из одной какой-нить сети класса С.Вы жалуетесь провайдеру,что он сделает? Ленивый - закроет фильтром(я бы сказал даже трафик шейпером этот блок),не ленивый попытается связаться с источником(в идеале).А провайдер вообще-скажет вам, читайте внимательно договор.
Потому как...
Давайте усложним задачу.У вас ваш блок под DDOS атакой,источник определить невозможно сразу. Что делает провайдер?


  Рекомендовать в FAQ | Cообщить модератору | Наверх

31. "Разница в статистике с провайдером" 
Сообщение от poige emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 04-Авг-03, 15:35  (MSK)
http://www.opennet.me/openforum/vsluhforumID10/528.html#4

P. S. Интернет это IP. А не Ethernet, PPP, etc.

/poige
--
http://www.i.morning.ru/~poige/

  Рекомендовать в FAQ | Cообщить модератору | Наверх

32. " poige" 
Сообщение от A Clockwork Orange Найти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 04-Авг-03, 19:07  (MSK)
А почему NetFlow отличается в меньшую сторону от ip accounting

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру