The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Достоверные измерения траффика"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы 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 | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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