https://opennet.me/openforum/vsluhforumID6/498.html Здравствуйте. Помогите достоверно измерить траффик. <br>Наша сеть имеет выход в сеть одного оператора сотовой связи. Мы к ним подключаемся по ethernet, далее они пробрасывают нас тунелем до своей точки доступа (в другом городе) и мы связываемся уже от нее со своими объектами по GSM сети оператора. Это подключение используется только для опроса sim карт. Схема такая:<br><br>Cisco2951 (GRE Tunel - Gi2/0.25) - встроеный коммутатор SM-ES3-24-P (fa0/5) - Сеть оператора - Объекты (sim)<br><br>Пару месяцев назад счет от оператора пришел на порядок выше чем за предидущие месяцы. При этом кол-во сим карт и кол-во данных передаваемых через них не поменялось. Поэтому встал вопрос как бы измерить сколько мы передаем и получаем, и не лехзет ли в канал что лишнее.<br>На ум пришел NBAR он и по протоколам раскидает и общее кол-во покажет.<br>Для чистоты эксперимента было решено отключить опрос (с помощь acl) всех объектов кроме одного. А для контроля измерять трафик еще и с помощью service policy (по конкретному ip) и зазеркалировав порт https://opennet.me/openforum/vsluhforumID6/498.html#12 Wed, 13 Feb 2013 22:19:06 GMT &gt; Ошибаетесь, при определенных условиях циска сама теряет данные и UDP далеко не <br>&gt; всегда винеоват, как самый яркий пример - cisco catalyst 65-ой серии, <br>&gt; SUP32 и SUP720 туефлоу поддерживают, но если вы БЕЗ специальной карты <br>&gt; попытаетесь снять с них нетфлоу - расхождение может быть в сотни <br>&gt; процентов, например snmp насчитает 100G, а нетфлоу - только 5G :) <br>&gt; И связано это со скоростью образования новых потоков и максимальным количеством <br>&gt; одновременно отслеживаемых, если потоки появляются достаточно быстро - циска их просто <br>&gt; "теряет".<br><br>Не вижу тут ограничений по протоколу netflow - только производительности оборудования (и багов IOS). А при его закупке каждый сам решает кто кому злобный буратино.<br><br><br> https://opennet.me/openforum/vsluhforumID6/498.html#11 Tue, 12 Feb 2013 06:30:34 GMT &gt;&gt; У циски английским по белому написано - нетфлоу не есть инструмент для <br>&gt;&gt; учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ <br>&gt;&gt; ГАРАНТИРУЕТСЯ воббще и никак...<br>&gt;&gt; Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это <br>&gt;&gt; действительно было, если в нетфлоу чего-то нет - это вовсе не <br>&gt;&gt; значит, что ничего небыло :) <br>&gt; UDP от сенсора к коллектору. Вот 0.(9) Ваши. Ниочем если сенсор и <br>&gt; коллектор в одной правильной локалке.<br><br>Ошибаетесь, при определенных условиях циска сама теряет данные и UDP далеко не всегда винеоват, как самый яркий пример - cisco catalyst 65-ой серии, SUP32 и SUP720 туефлоу поддерживают, но если вы БЕЗ специальной карты попытаетесь снять с них нетфлоу - расхождение может быть в сотни процентов, например snmp насчитает 100G, а нетфлоу - только 5G :) И связано это со скоростью образования новых потоков и максимальным количеством одновременно отслеживаемых, если потоки появляются достаточно быстро - циска их просто "теряет".<br> https://opennet.me/openforum/vsluhforumID6/498.html#10 Tue, 12 Feb 2013 03:55:29 GMT &gt; У циски английским по белому написано - нетфлоу не есть инструмент для <br>&gt; учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ <br>&gt; ГАРАНТИРУЕТСЯ воббще и никак...<br>&gt; Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это <br>&gt; действительно было, если в нетфлоу чего-то нет - это вовсе не <br>&gt; значит, что ничего небыло :) <br><br>UDP от сенсора к коллектору. Вот 0.(9) Ваши. Ниочем если сенсор и коллектор в одной правильной локалке.<br><br><br> https://opennet.me/openforum/vsluhforumID6/498.html#9 Thu, 07 Feb 2013 07:51:04 GMT &gt;&gt; Считать надо где-то "дальше".<br>&gt; Вот я так и понял. Тока не понимаю почему. Может если изменить <br>&gt; сабинтерфейс на физический полноценный , то лучше будет? Или на тунеле <br>&gt; вообще не померить точно?<br><br>Конечно не померить, тунель траф учел, а физика его не выплюнула по каким-то причинам - это для примера.<br> https://opennet.me/openforum/vsluhforumID6/498.html#8 Thu, 07 Feb 2013 07:45:07 GMT &gt; Считать надо где-то "дальше".<br><br>Вот я так и понял. Тока не понимаю почему. Может если изменить сабинтерфейс на физический полноценный , то лучше будет? Или на тунеле вообще не померить точно?<br><br><br> https://opennet.me/openforum/vsluhforumID6/498.html#7 Thu, 07 Feb 2013 07:36:31 GMT &gt;&gt; netflow, не?<br>&gt; попробывал netflow, одновременно запустил nbar на роутере <br>&gt; На tunel 0 (IN посчитал одинаково с NBAR, OUT - в 2.5 <br>&gt; раза меньше чем у NBAR) <br>&gt; На gi2/0.25 ( IN netflow почему то не посчитал, OUT - одинаково) <br>&gt; Как говориться: Человек с двумя часами никогда не уверен, который час.) <br><br>Считать надо где-то "дальше".<br> https://opennet.me/openforum/vsluhforumID6/498.html#6 Thu, 07 Feb 2013 07:31:28 GMT &gt;[оверквотинг удален]<br>&gt;&gt; gi2/0.25 из-за того что сначала тифк посчитал траффик, апотом сработал acl.<br>&gt;&gt; Так?<br>&gt;&gt; Но почему service policy насчитал меньше? Даже если отбросить из того что <br>&gt;&gt; насчитал nbar лишнее (ospf, unknown и прочее (около 0.03 в сумме)) <br>&gt;&gt; то все равно разница в два раза.<br>&gt;&gt; И тем более подсчет dumeter удивляет поскольку он дожен был показать сумму <br>&gt;&gt; in + out.<br>&gt;&gt; Воопщем вопрос в том где (в какой точке) правильно мерить траффик, который <br>&gt;&gt; посчитает оператор ну и какими средствами.<br>&gt; netflow, не?<br><br>У циски английским по белому написано - нетфлоу не есть инструмент для учета, а инструмент мониторинга и отладки и достоверность в нетфлоу НЕ ГАРАНТИРУЕТСЯ воббще и никак...<br>Короче, если в нетфлоу что-то есть - то с вероятностью 0.99999 это действительно было, если в нетфлоу чего-то нет - это вовсе не значит, что ничего небыло :)<br> https://opennet.me/openforum/vsluhforumID6/498.html#5 Thu, 07 Feb 2013 06:56:15 GMT &gt; netflow, не?<br><br>попробывал netflow, одновременно запустил nbar на роутере<br><br>На tunel 0 (IN посчитал одинаково с NBAR, OUT - в 2.5 раза меньше чем у NBAR)<br>На gi2/0.25 ( IN netflow почему то не посчитал, OUT - одинаково)<br><br>Как говориться: Человек с двумя часами никогда не уверен, который час.)<br><br> https://opennet.me/openforum/vsluhforumID6/498.html#4 Thu, 07 Feb 2013 06:46:13 GMT &gt; 1. Это понятно, думаю пров считает со всеми заголовки чтобы помаксимому (честно говоря договора не видел и не знаю указываются ли на каком уровне идет таррификация)<br>&gt; 2. Это тоже понятно, но в моем случае когда есть интерф. Tunel0, который начинается на gi2/0.25 должно быть так:<br><br>IN/Out на tunel 0 должен быть меньше чем IN/OUT на gi2/0.25 (потому что на gi2/0.25 считается вместе с gre заголовками а на Tun0 без). Или я не прав?<br>Ведь у меня выход на тунельном интерфейсе вышел гораздо больше выхода на физическом (IN правда как положено меньше).<br>И вообще на тунеле направления IN/OUT совпадают с IN/OUT на физическом интерфейсе к которому он привязан?<br>