форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Маршрутизаторы CISCO и др. оборудование. (Учет трафика и статистика)
Изначальное сообщение		[ Отслеживать ]

"Достоверные измерения траффика"	+/–
Сообщение от Ivan Pomidorov (ok) on 30-Янв-13, 10:53
Здравствуйте. Помогите достоверно измерить траффик. Наша сеть имеет выход в сеть одного оператора сотовой связи. Мы к ним подключаемся по ethernet, далее они пробрасывают нас тунелем до своей точки доступа (в другом городе) и мы связываемся уже от нее со своими объектами по GSM сети оператора. Это подключение используется только для опроса sim карт. Схема такая: Cisco2951 (GRE Tunel - Gi2/0.25) - встроеный коммутатор SM-ES3-24-P (fa0/5) - Сеть оператора - Объекты (sim) Пару месяцев назад счет от оператора пришел на порядок выше чем за предидущие месяцы. При этом кол-во сим карт и кол-во данных передаваемых через них не поменялось. Поэтому встал вопрос как бы измерить сколько мы передаем и получаем, и не лехзет ли в канал что лишнее. На ум пришел NBAR он и по протоколам раскидает и общее кол-во покажет. Для чистоты эксперимента было решено отключить опрос (с помощь acl) всех объектов кроме одного. А для контроля измерять трафик еще и с помощью service policy (по конкретному ip) и зазеркалировав порт fa0/5 на встроенном коммутере, воткнув туда ноут с программой DUMeter. Итого: 1. На интерфейсах Tunel0 и gi2/0.25  - ip nbar protocol-discovery 2. На Tunel0 - service policy (которая ловит пакеты от конкретного ip к конкретному ip) 3. Dumeter ловитвсе что выходит и входит с/на порт fa0/5 На мой взгляд все измерения должны быть примерно равны т.к. опрос идет только с одного хоста одной конкретной симки (это обеспечено acl и проверено) разница должна быть только из за того что 1 и 3 измерения будут ловить траффик динамической маршрутизации, а 3-е еще и какое то общение ноута с сетью. Но это мелочь. В результате получилось (я округлил до МБ): 1. Tunel0        in 0.28   out 1.95 1. Gi2/0.25      in 0.48   out 0.49 2. ServPol(Tun0) in 0.22   out 0.26 3. Dumeter       in 0.1 Я предполагаю, что на тунеле выход в 4 раза больше чем на gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl. Так? Но почему service policy насчитал меньше? Даже если отбросить из того что насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме)) то все равно разница в два раза. И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму in + out. Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который посчитает оператор ну и какими средствами.
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Достоверные измерения траффика"	+/–
Сообщение от fantom (ok) on 30-Янв-13, 12:11
>[оверквотинг удален] > Я предполагаю, что на тунеле выход в 4 раза больше чем на > gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl. > Так? > Но почему service policy насчитал меньше? Даже если отбросить из того что > насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме)) > то все равно разница в два раза. > И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму > in + out. > Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который > посчитает оператор ну и какими средствами. 1. траф можно считать на разных уровнях - L2/L3/L4 и т.д. 2. тунель добавляет свой трафик (заголовки однако) чем меньше средний размер пакета - тем больше удельный вес тунельных заголовков.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Достоверные измерения траффика"	+/–
	Сообщение от Ivan Pomidorov (ok) on 07-Фев-13, 10:46
	> 1. Это понятно, думаю пров считает со всеми заголовки чтобы помаксимому (честно говоря договора не видел и не знаю указываются ли на каком уровне идет таррификация) > 2. Это тоже понятно, но в моем случае когда есть интерф. Tunel0, который начинается на gi2/0.25 должно быть так: IN/Out на tunel 0 должен быть меньше чем  IN/OUT на gi2/0.25 (потому что на gi2/0.25 считается вместе с gre заголовками а на Tun0 без). Или я не прав? Ведь у меня выход на тунельном интерфейсе вышел гораздо больше выхода на физическом (IN правда как положено меньше). И вообще на тунеле направления IN/OUT совпадают с IN/OUT на физическом интерфейсе к которому он привязан?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Достоверные измерения траффика"	+/–
Сообщение от Юра (??) on 30-Янв-13, 13:33
> Здравствуйте. Помогите достоверно измерить траффик. > Наша сеть имеет выход в сеть одного оператора сотовой связи. Мы к > ним подключаемся по ethernet, далее они пробрасывают нас тунелем до своей > точки доступа (в другом городе) и мы связываемся уже от нее > со своими объектами по GSM сети оператора. Это подключение используется только > для опроса sim карт. Схема такая: > Cisco2951 (GRE Tunel - Gi2/0.25) - встроеный коммутатор SM-ES3-24-P (fa0/5) - Сеть > оператора - Объекты (sim)   А у сотовика не поменялась-ли еденица тарификации и время сессии? Я уже раз наткнулся на такую бяку при изменении еденицы тарификации с 10 до 100 килобайт счет вырос в 3 раза.   У меня было так - за одну сессию(10 минут клиент съедал 9 кил) и все было более-менее сносно. Теперь за одну сессию потребления клиента увеличивает до 100(единица тарификации) и таким образом изменяется счет   Попробую посмотреть в этом направлении. Если будут дополнительные  вопросы пиши und6819(собака)rambler.ru
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Достоверные измерения траффика"	+/–
Сообщение от Gromophon (ok) on 31-Янв-13, 08:57
>[оверквотинг удален] > Я предполагаю, что на тунеле выход в 4 раза больше чем на > gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl. > Так? > Но почему service policy насчитал меньше? Даже если отбросить из того что > насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме)) > то все равно разница в два раза. > И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму > in + out. > Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который > посчитает оператор ну и какими средствами. netflow, не?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Достоверные измерения траффика"	+/–
	Сообщение от Ivan Pomidorov (ok) on 07-Фев-13, 10:56
	> netflow, не? попробывал netflow, одновременно запустил nbar на роутере На tunel 0 (IN посчитал одинаково с NBAR, OUT - в 2.5 раза меньше чем у NBAR) На gi2/0.25 ( IN netflow почему то не посчитал, OUT - одинаково) Как говориться: Человек с двумя часами никогда не уверен, который час.)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "Достоверные измерения траффика"	+/–
	Сообщение от fantom (ok) on 07-Фев-13, 11:36
	>> netflow, не? > попробывал netflow, одновременно запустил nbar на роутере > На tunel 0 (IN посчитал одинаково с NBAR, OUT - в 2.5 > раза меньше чем у NBAR) > На gi2/0.25 ( IN netflow почему то не посчитал, OUT - одинаково) > Как говориться: Человек с двумя часами никогда не уверен, который час.) Считать надо где-то "дальше".
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Достоверные измерения траффика"	+/–
	Сообщение от Ivan Pomidorov (ok) on 07-Фев-13, 11:45
	> Считать надо где-то "дальше". Вот я так и понял. Тока не понимаю почему. Может если изменить сабинтерфейс на физический полноценный , то лучше будет? Или на тунеле вообще не померить точно?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Достоверные измерения траффика"	+1 +/–
	Сообщение от fantom (ok) on 07-Фев-13, 11:51
	>> Считать надо где-то "дальше". > Вот я так и понял. Тока не понимаю почему. Может если изменить > сабинтерфейс на физический полноценный , то лучше будет? Или на тунеле > вообще не померить точно? Конечно не померить, тунель траф учел, а физика его не выплюнула по каким-то причинам - это для примера.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	6. "Достоверные измерения траффика"	+1 +/–
	Сообщение от fantom (ok) on 07-Фев-13, 11:31
	>[оверквотинг удален] >> gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl. >> Так? >> Но почему service policy насчитал меньше? Даже если отбросить из того что >> насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме)) >> то все равно разница в два раза. >> И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму >> in + out. >> Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который >> посчитает оператор ну и какими средствами. > netflow, не? У циски английским по белому написано - нетфлоу не есть инструмент для учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ ГАРАНТИРУЕТСЯ воббще и никак... Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это действительно было, если в нетфлоу чего-то нет - это вовсе не значит, что ничего небыло :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "Достоверные измерения траффика"	+/–
	Сообщение от LSTemp (ok) on 12-Фев-13, 07:55
	> У циски английским по белому написано - нетфлоу не есть инструмент для > учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ > ГАРАНТИРУЕТСЯ воббще и никак... > Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это > действительно было, если в нетфлоу чего-то нет - это вовсе не > значит, что ничего небыло :) UDP от сенсора к коллектору. Вот 0.(9) Ваши. Ниочем если сенсор и коллектор в одной правильной локалке.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "Достоверные измерения траффика"	+/–
	Сообщение от fantom (ok) on 12-Фев-13, 10:30
	>> У циски английским по белому написано - нетфлоу не есть инструмент для >> учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ >> ГАРАНТИРУЕТСЯ воббще и никак... >> Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это >> действительно было, если в нетфлоу чего-то нет - это вовсе не >> значит, что ничего небыло :) > UDP от сенсора к коллектору. Вот 0.(9) Ваши. Ниочем если сенсор и > коллектор в одной правильной локалке. Ошибаетесь, при определенных условиях циска сама теряет данные и UDP далеко не всегда винеоват, как самый яркий пример - cisco catalyst 65-ой серии, SUP32 и SUP720 туефлоу поддерживают, но если вы БЕЗ специальной карты попытаетесь снять с них нетфлоу - расхождение может быть в сотни процентов, например snmp насчитает 100G, а нетфлоу - только 5G :) И связано это со скоростью образования новых потоков и максимальным количеством одновременно отслеживаемых, если потоки появляются достаточно быстро - циска их просто "теряет".
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Достоверные измерения траффика"	+/–
	Сообщение от LSTemp (ok) on 14-Фев-13, 02:19
	> Ошибаетесь, при определенных условиях циска сама теряет данные и UDP далеко не > всегда винеоват, как самый яркий пример - cisco catalyst 65-ой серии, > SUP32 и SUP720 туефлоу поддерживают, но если вы БЕЗ специальной карты > попытаетесь снять с них нетфлоу - расхождение может быть в сотни > процентов, например snmp насчитает 100G, а нетфлоу - только 5G :) > И связано это со скоростью образования новых потоков и максимальным количеством > одновременно отслеживаемых, если потоки появляются достаточно быстро - циска их просто > "теряет". Не вижу тут ограничений по протоколу netflow - только производительности оборудования (и багов IOS). А при его закупке каждый сам решает кто кому злобный буратино.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

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