Провайдер в конце месяца присылает бумажку по загрузке портов Frame Relay.
Мы на cisco 2621 считаем трафик по ip accounting.
Плюс к том же у нас есть трафик между клиентами, проходящий только через нашу cisco и не фиксируемый провайдером.
Разница у нас и провайдера достигает до 13 процентов на канал.
Вопрос:
Как провайдер считает загрузку порта.
Может ли сказываться такая разница, что провайдер считает по netflow, мы по ip accounting, если ли у кого статистика по расхождениям.
Может ли от того что провайдер считает именно по портам (хотя как это можно все равно netflow), а мы по адресам клиентов?
>Провайдер в конце месяца присылает бумажку по загрузке портов Frame Relay.
>Мы на cisco 2621 считаем трафик по ip accounting.
>Плюс к том же у нас есть трафик между клиентами, проходящий только
>через нашу cisco и не фиксируемый провайдером.
>Разница у нас и провайдера достигает до 13 процентов на канал.
>Вопрос:
>Как провайдер считает загрузку порта.
>Может ли сказываться такая разница, что провайдер считает по netflow, мы по
>ip accounting, если ли у кого статистика по расхождениям.
>Может ли от того что провайдер считает именно по портам (хотя как
>это можно все равно netflow), а мы по адресам клиентов?
провайдер у вас весь траффик считает, а вы IP accounting-ом только L3
Извини за неловкий вопрос весь это какой L.
netflow ВЕСЬ посчитает?
>Извини за неловкий вопрос весь это какой L.
>netflow ВЕСЬ посчитает?весь - это L2+L3
а откуда такая уверенность про нетфлоу? может ваш провайдер просто счетчики с интерфейса снимает? :))
Привет,Netflow смитает только IP трафик, поскольку route cache находиться внутри рутера и трафик доходит до него без всяких L2 украшений.
Выясните прежде всего как ваш провайдер считает трафик:
* По Netflow
* По SNMP, считывая счетчики интерфейсовFrame Relay сам по себе дает overhead но он вряд ли может достичь 10 процентов и более... Frame Relay - очень "легкий" протокол, расчитанный на цифровые линии связи с почти нулевым уровнем ошибок. Как пролегает физически связь между вами и вашим провайдером?
WWell,
>Выясните прежде всего как ваш провайдер считает трафик:
>* По Netflow
>* По SNMP, считывая счетчики интерфейсовДа кто же скажет как, коммерческая тайна.
>
>Frame Relay сам по себе дает overhead но он вряд ли может
>достичь 10 процентов и более... Frame Relay - очень "легкий" протокол,
>расчитанный на цифровые линии связи с почти нулевым уровнем ошибок. Как
>пролегает физически связь между вами и вашим провайдером?Оптоволокно.
А каким образом считывание счетчиков, где можно про это по подробнее?
>>Выясните прежде всего как ваш провайдер считает трафик:
>Да кто же скажет как, коммерческая тайна.Мне кажется, если ваш провайдер ужавает себя как компанию, он должен указать это как минимум в ваш 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,
>>>Выясните прежде всего как ваш провайдер считает трафик:
>>Да кто же скажет как, коммерческая тайна.
>
>Мне кажется, если ваш провайдер ужавает себя как компанию, он должен указать
>это как минимум в ваш 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,
Данные с МРТГ для этого не подойдут? Это одно и тоже?!
>Данные с МРТГ для этого не подойдут? Это одно и тоже?!Ну, "одно и то же"... MRTG - это приложение для снятия данных по SNMP и отображения их в виде график. Насколько мне известно, MRTG берет именно эти счетчики, но MRTG не ведет подсчет трафика, его интересует разница с предыдущего состояния, а вас интесерует накопление. Мне неизвестен быстрый способ "присобачить" MRTG для _точного_ подсчета трафика. Приближенную стоимость (с отклонением до. 5% от данных по Netflow) можно получить, если взять средние стоимости за период, которые MRTG подсчитывает, и помножить на время.
WWell,
Ответ провайдера"...
Для разных каналов трафик расчитывается по-разному.
В основном при помощи программного обеспечения для Cisco( ip accounting )."Я чего то не поналя это как для разных каналов по-разному?
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#Пробую счетчики в ноль выставить не один типа не подходит?!
Абсолютно аналогичная ситуацтия (по методике подсчёта у нас и Прова) Расхождения не более 3 процентов. Но не всегда.
Во-первых как часто снимаешь аккунтинг и каков буффер? Намёк на то что у Вас теряется часть записей. В своё время я уменьшил кратность снятия с 10 до 5 минут.
Во-вторых у меня бывают просто ломовые расхождения в отдельные(выходные, праздничные) дни вплоть до 100% И это обяснимо- у меня есть IP НАТ ПУЛ(в циске 2620) и несколько десятков IP из выделеной мне провом подсети класса С, которые не используются. Так вот, если по этим адресам проходят хацкеры своими сканерами(а это частое вление) или намеренная атака, то на мои IP-адреса это траффик будет насчитан. Точно так же он будет и на у меня аккаутинге как входящий. Тонкость в том, что если аккаунтинг обрабатывается ТОЛЬКО для назначенных адресов + внутренних адресов типа 192.168.x.x (которые ходят в И-нет через НАТ) тогда получается разница (клиенты из ЛАН траффик не порождали а на НАТЕ он есть и выставлять его некому). В будни такой траффик просто съедаеться и сотавляет десятые процента.
И наконец, в-третьих, чистота провайдера(меня, кстати, поразило, что выставляется счет для ppp адресов для Serial интерфесов между моей и провайдерской цисками(модемами E1)).
>Абсолютно аналогичная ситуацтия (по методике подсчёта у нас и Прова) Расхождения не
>более 3 процентов. Но не всегда.
>Во-первых как часто снимаешь аккунтинг и каков буффер? Намёк на то
>что у Вас теряется часть записей. В своё время я уменьшил
>кратность снятия с 10 до 5 минут.Исключено, за счет буфера потерь нет.
>Во-вторых у меня бывают просто ломовые расхождения в отдельные(выходные, праздничные) дни вплоть
>до 100% И это обяснимо- у меня есть IP НАТ ПУЛ(в
>циске 2620) и несколько десятков IP из выделеной мне провом подсети
>класса С, которые не используются. Так вот, если по этим адресам
>проходят хацкеры своими сканерами(а это частое вление) или намеренная атака, то
>на мои IP-адреса это траффик будет насчитан. Точно так же он
>будет и на у меня аккаутинге как входящий. Тонкость в том,
>что если аккаунтинг обрабатывается ТОЛЬКО для назначенных адресов + внутренних адресов
>типа 192.168.x.x (которые ходят в И-нет через НАТ) тогда получается разница
>(клиенты из ЛАН траффик не порождали а на НАТЕ он есть
>и выставлять его некому). В будни такой траффик просто съедаеться и
>сотавляет десятые процента.
Исключено, провайдер обеспечивает маршрутизацию только на те адреса которые я ему указал, и на этим адресах есть хосты точно.>И наконец, в-третьих, чистота провайдера(меня, кстати, поразило, что выставляется счет для ppp
>адресов для Serial интерфесов между моей и провайдерской цисками(модемами E1)).Не знаю как это проверить.
>Исключено, провайдер обеспечивает маршрутизацию только на те адреса которые я ему указал,
>и на этим адресах есть хосты точно.
То есть у тебя ВСЕ хосты имеют маршрутизируемые адреса и НАТ не используется?>Не знаю как это проверить.
Затребуй у него статистику для каждого адреса, с дискретностью допусти 60 минут за прошедшие сутки, где были расхождения (при сложении его цифры должны совпасть). А затем договоись на какой-нить день о взаимной проверке с представлением тех же данных только с меньшей дискретностью. Если в этот день разница будет меньше, значит в проверочный день решили накручивать по-меньше. Хотя довольно примитивно и вычесляеться. Если пров умный вместо 13 дадут 8-9, если жадный то те же 13% (ихмо). На основании этих данных смотри где расхождения при необходимости затребуй меньшую дискретность, хоть каждую минуту(будут сильно сопротивляться)Да и что у тебя с широковещанием? Может в этом проблеиы? (Намёк то что для твоих броадкастов выставляется счёт =)
>>Исключено, провайдер обеспечивает маршрутизацию только на те адреса которые я ему указал,
>>и на этим адресах есть хосты точно.
>То есть у тебя ВСЕ хосты имеют маршрутизируемые адреса и НАТ не
>используется?есть одна сеть с натом, но какая разница пришел на нашу cisco на реальный адрес, выходит этот трафик с нашей cisco разбившись по локальным адресам, где тут потери.
>
>>Не знаю как это проверить.
>Затребуй у него статистику для каждого адреса, с дискретностью допусти 60 минут
>за прошедшие сутки, где были расхождения (при сложении его цифры должны
>совпасть). А затем договоись на какой-нить день о взаимной проверке с
>представлением тех же данных только с меньшей дискретностью. Если в этот
>день разница будет меньше, значит в проверочный день решили накручивать по-меньше.
>Хотя довольно примитивно и вычесляеться. Если пров умный вместо 13 дадут
>8-9, если жадный то те же 13% (ихмо). На основании этих
>данных смотри где расхождения при необходимости затребуй меньшую дискретность, хоть каждую
>минуту(будут сильно сопротивляться)А от сравнения не уйдешь, придется срвнивать.
Вот еще могут дать вырезку только по затребованным на маршрутизацию мной адресам, а смаршрутизировать еще какие то на самом деле, хотя бы теже адреса внешних интерфейсов cisco.
>
>Да и что у тебя с широковещанием? Может в этом проблеиы? (Намёк
>то что для твоих броадкастов выставляется счёт =)Frame Relay не широковещательная среда.
Может быть связано расхождение с тем, что провайдер считает
ip accounting по Frame Relayмы считаем
ip accounting по Ehternet
>есть одна сеть с натом, но какая разница пришел на нашу 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 (или больше в зависимости от активности скана)
>>есть одна сеть с натом, но какая разница пришел на нашу 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 (или больше в зависимости от
>активности скана)Товарищ прав. Ведь аккунтинг считается на порту только в одну сторону. Поэтому там на том интерфейсе, где НАТ, можно что-то упустить. И вообще, провайдер считает какой трафик ? Оба? или только один из входящий/исходящий на его интерфейс ?
Самое действенное - взять и сравнить данные с провайдерскими. Это проще, чем ломать голову.
Сравнить.
Если есть расхождение там миллон записей!
Так все же NetFlow это какой уровень?Какая из трех технологий снятия трафика дает наиболее точный (по объему) результат?!
NetFllow
SNMP
ip accounting
Whom How, как говориться в одном старом анекдоте:SNMP дает только количество IP трафика, прошедшего через интерфейс.
NetFlow говорит про каждый пакет (точнее, поток пакетов) с какого адреса на какой, по каким портам и в каком объеме идет трафик.
В идеальной ситуации оба метода должны совпасть. Я лично отдаю предпочтение NetFlow потому, что всегда могу показать клиенту когда какой трафик проходил к нему и от него.
WWell,
>Так все же NetFlow это какой уровень?
>
>Какая из трех технологий снятия трафика дает наиболее точный (по объему) результат?!
>
>
>NetFllow
>SNMP
>ip accountingа не так
SNMP
NetFllow
ip accounting
?
И наконец, в-третьих, чистота провайдера(меня, кстати, поразило, что выставляется счет для ppp адресов для Serial интерфесов между
моей и провайдерской цисками(модемами E1)).Позвольте не согласится в данном вопросе.Эти адреса,хоть и служебные
но они входят в PA блок провайдера,те через входящие каналы провайдера
трафик на эти адреса приходит(пусть и небольшой),ему он считается,почему провайдер не должен считать его вам? Точно так же,сложиваяся практика по фильтрации трафика.Хотите фильтровать,фильтруйте.Но не просите об этом своего провайдера-если он фильтрует-он попадает на ту сумму трафика,которую сбрасывает фильтр.Это достаточно очевидно.
еще один факт-сравнил тут ip accounting и netflow
расхождение 0.203% в пользу netflow.На большом трафике...
SNMP статистика-вообще по моему мнению никуда не годится.По ряду причин.
Самая главная-ненадежность (UDP) и большая неточность.Графики строить..
Взял первого попавшегося клиента - обсчитал по двум вариантам
нетфлоу и ип эккоунтинг
расхождение 0.627% на 1.7 гига
Вообще же мне мой провайдер сказал что меньше 4 процентов не стоит нервов
разборки.
Взял диалапный пул-10.5gb(ну да, почти и не продаем мы диалап),расхождение
двух методов 43928 байт. Так что .... не надо на зеркало.
>еще один факт-сравнил тут ip accounting и netflow
>расхождение 0.203% в пользу netflow.На большом трафике...
>SNMP статистика-вообще по моему мнению никуда не годится.По ряду причин.
>Самая главная-ненадежность (UDP) и большая неточность.Графики строить..Заверяю Вас что, NetFlow сбрасывает статистику по UDP.
О SNMP тут говорят не для прорисовки графиков а для снятия счетчиков.
Спорить не буду, можно привести кучу причин почему у Вас "совпало".
Если бы снятие ip accounting заключалось в хитрых перепетиях команд можно было бы поспорить, а то тут всего пару команд и ошибиться тут невозможно.
>Позвольте не согласится в данном вопросе.Эти адреса,хоть и служебные
>но они входят в PA блок провайдера,те через входящие каналы провайдера
>трафик на эти адреса приходит(пусть и небольшой),ему он считается,почему провайдер не должен
>считать его вам? Точно так же,сложиваяся практика по фильтрации трафика.Хотите фильтровать,фильтруйте.Но
>не просите об этом своего провайдера-если он фильтрует-он попадает на ту
>сумму трафика,которую сбрасывает фильтр.Это достаточно очевидно.Павел?!!
У меня есть предположение, что наши фирмы между собой уже договорились? :D
Хотя может я и ошибаюсь =\ По теме: сложившаяся практика - аргумент сильный, однако руководство(по крайней мере моей фирмы) смотрит в договор(он составлен также, как Вы выражаетесь, по устоявшейся практике), в договоре многие(в т.ч. и "фильтрацию") вещи можно трактовать двояко(мы это называли "навязанный траффик" а не "фильтрациия"). Дальше смотрим в законодательство... А о его состоянии в нашей области все знают. Вот и договариваются все какким-то образом- сложившаяся практика. И тут я с Вами полностью согласен.
Трафик по NetFlow составляет 0,97 от трафика по ip accounting.
При общем входящем трафике 52М за день.С чем это может быть связано что нетфлоу проигрывает.
>Трафик по NetFlow составляет 0,97 от трафика по ip accounting.
>При общем входящем трафике 52М за день.
Полностью согласен про меньше в сторну NetFlow по отношению ip accounting Правда по цифрам ничего сказать не могу- не проверял.
Значит 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
>Павел?!!
>У меня есть предположение, что наши фирмы между собой уже договорились? :D
Мы знакомы? Не очень понял.
>
>Хотя может я и ошибаюсь =\ По теме: сложившаяся практика - аргумент
>сильный, однако руководство(по крайней мере моей фирмы) смотрит в договор(он составлен
>также, как Вы выражаетесь, по устоявшейся практике), в договоре многие(в т.ч.
>и "фильтрацию") вещи можно трактовать двояко(мы это называли "навязанный траффик" а
>не "фильтрациия"). Дальше смотрим в законодательство... А о его состоянии в
>нашей области все знают. Вот и договариваются все какким-то образом- сложившаяся
>практика. И тут я с Вами полностью согласен.Не согласен.Интернет построен на принципе полносвязности сетей.Например,вас флудят из одной какой-нить сети класса С.Вы жалуетесь провайдеру,что он сделает? Ленивый - закроет фильтром(я бы сказал даже трафик шейпером этот блок),не ленивый попытается связаться с источником(в идеале).А провайдер вообще-скажет вам, читайте внимательно договор.
Потому как...
Давайте усложним задачу.У вас ваш блок под DDOS атакой,источник определить невозможно сразу. Что делает провайдер?
http://www.opennet.me/openforum/vsluhforumID10/528.html#4P. S. Интернет это IP. А не Ethernet, PPP, etc.
/poige
--
http://www.i.morning.ru/~poige/
А почему NetFlow отличается в меньшую сторону от ip accounting