Здравствуйте. Помогите достоверно измерить траффик.
Наша сеть имеет выход в сеть одного оператора сотовой связи. Мы к ним подключаемся по 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.Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который посчитает оператор ну и какими средствами.
>[оверквотинг удален]
> Я предполагаю, что на тунеле выход в 4 раза больше чем на
> gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl.
> Так?
> Но почему service policy насчитал меньше? Даже если отбросить из того что
> насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме))
> то все равно разница в два раза.
> И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму
> in + out.
> Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который
> посчитает оператор ну и какими средствами.1. траф можно считать на разных уровнях - L2/L3/L4 и т.д.
2. тунель добавляет свой трафик (заголовки однако) чем меньше средний размер пакета - тем больше удельный вес тунельных заголовков.
> 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 на физическом интерфейсе к которому он привязан?
> Здравствуйте. Помогите достоверно измерить траффик.
> Наша сеть имеет выход в сеть одного оператора сотовой связи. Мы к
> ним подключаемся по 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
>[оверквотинг удален]
> Я предполагаю, что на тунеле выход в 4 раза больше чем на
> gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl.
> Так?
> Но почему service policy насчитал меньше? Даже если отбросить из того что
> насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме))
> то все равно разница в два раза.
> И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму
> in + out.
> Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который
> посчитает оператор ну и какими средствами.netflow, не?
> netflow, не?попробывал netflow, одновременно запустил nbar на роутере
На tunel 0 (IN посчитал одинаково с NBAR, OUT - в 2.5 раза меньше чем у NBAR)
На gi2/0.25 ( IN netflow почему то не посчитал, OUT - одинаково)Как говориться: Человек с двумя часами никогда не уверен, который час.)
>> netflow, не?
> попробывал netflow, одновременно запустил nbar на роутере
> На tunel 0 (IN посчитал одинаково с NBAR, OUT - в 2.5
> раза меньше чем у NBAR)
> На gi2/0.25 ( IN netflow почему то не посчитал, OUT - одинаково)
> Как говориться: Человек с двумя часами никогда не уверен, который час.)Считать надо где-то "дальше".
> Считать надо где-то "дальше".Вот я так и понял. Тока не понимаю почему. Может если изменить сабинтерфейс на физический полноценный , то лучше будет? Или на тунеле вообще не померить точно?
>> Считать надо где-то "дальше".
> Вот я так и понял. Тока не понимаю почему. Может если изменить
> сабинтерфейс на физический полноценный , то лучше будет? Или на тунеле
> вообще не померить точно?Конечно не померить, тунель траф учел, а физика его не выплюнула по каким-то причинам - это для примера.
>[оверквотинг удален]
>> gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl.
>> Так?
>> Но почему service policy насчитал меньше? Даже если отбросить из того что
>> насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме))
>> то все равно разница в два раза.
>> И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму
>> in + out.
>> Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который
>> посчитает оператор ну и какими средствами.
> netflow, не?У циски английским по белому написано - нетфлоу не есть инструмент для учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ ГАРАНТИРУЕТСЯ воббще и никак...
Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это действительно было, если в нетфлоу чего-то нет - это вовсе не значит, что ничего небыло :)
> У циски английским по белому написано - нетфлоу не есть инструмент для
> учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ
> ГАРАНТИРУЕТСЯ воббще и никак...
> Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это
> действительно было, если в нетфлоу чего-то нет - это вовсе не
> значит, что ничего небыло :)UDP от сенсора к коллектору. Вот 0.(9) Ваши. Ниочем если сенсор и коллектор в одной правильной локалке.
>> У циски английским по белому написано - нетфлоу не есть инструмент для
>> учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ
>> ГАРАНТИРУЕТСЯ воббще и никак...
>> Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это
>> действительно было, если в нетфлоу чего-то нет - это вовсе не
>> значит, что ничего небыло :)
> UDP от сенсора к коллектору. Вот 0.(9) Ваши. Ниочем если сенсор и
> коллектор в одной правильной локалке.Ошибаетесь, при определенных условиях циска сама теряет данные и UDP далеко не всегда винеоват, как самый яркий пример - cisco catalyst 65-ой серии, SUP32 и SUP720 туефлоу поддерживают, но если вы БЕЗ специальной карты попытаетесь снять с них нетфлоу - расхождение может быть в сотни процентов, например snmp насчитает 100G, а нетфлоу - только 5G :) И связано это со скоростью образования новых потоков и максимальным количеством одновременно отслеживаемых, если потоки появляются достаточно быстро - циска их просто "теряет".
> Ошибаетесь, при определенных условиях циска сама теряет данные и UDP далеко не
> всегда винеоват, как самый яркий пример - cisco catalyst 65-ой серии,
> SUP32 и SUP720 туефлоу поддерживают, но если вы БЕЗ специальной карты
> попытаетесь снять с них нетфлоу - расхождение может быть в сотни
> процентов, например snmp насчитает 100G, а нетфлоу - только 5G :)
> И связано это со скоростью образования новых потоков и максимальным количеством
> одновременно отслеживаемых, если потоки появляются достаточно быстро - циска их просто
> "теряет".Не вижу тут ограничений по протоколу netflow - только производительности оборудования (и багов IOS). А при его закупке каждый сам решает кто кому злобный буратино.