форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Маршрутизаторы 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. "Разница в статистике с провайдером"
	Сообщение от Асен Тотин 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. "Разница в статистике с провайдером"
	Сообщение от Асен Тотин 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. "Разница в статистике с провайдером"
	Сообщение от Асен Тотин 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. "Разница в статистике с провайдером, ВСЕ ЖЕ ЧТО ТОЧНЕЕ?!!!"
	Сообщение от Асен Тотин on 31-Июл-03, 20:58  (MSK)
	Whom How, как говориться в одном старом анекдоте: SNMP дает только количество IP трафика, прошедшего через интерфейс. NetFlow говорит про каждый пакет (точнее, поток пакетов) с какого адреса на какой, по каким портам и в каком объеме идет трафик. В идеальной ситуации оба метода должны совпасть. Я лично отдаю предпочтение NetFlow потому, что всегда могу показать клиенту когда какой трафик проходил к нему  и от него. WWell,
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	21. "Разница в статистике с провайдером, ВСЕ ЖЕ ЧТО ТОЧНЕЕ?!!!"
	Сообщение от gru2003 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 on 04-Авг-03, 15:35  (MSK)
http://www.opennet.dev/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ообщить модератору | Наверх

Удалить

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

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