Книга: Документация NetAMS

Расхождение в статистике с провайдером

Расхождение в статистике с провайдером

Иногда пользователи NeTAMS задают вопрос: «У меня расхождение в статистике с провайдером 3%. А у моего друга вообще 30%. Почему это ваш NeTAMS неправильно считает?»

NeTAMS считает правильно.

Давайте разберемся, как это выглядит на практике и из–за чего возможно расхождение.

В общем случае все выглядит следующим образом: к провайдеру извне (Интернет) на пограничный роутер приходят один или несколько линков, дальше трафик попадает в провайдерскую внутреннюю сеть, после чего перенаправляется на роутер доступа, к которому подключены вы сами. Способ такого подключения может быть очень разным: это или ваш персональный выделенный канал, или разделяемый ресурс (беспроводная сеть или общий ethernet). Далее, трафик попадает на ваш сервер учета (где работает NeTAMS или его flow–коллектор), далее трафик доставляется абонентам вашей сети.

Вы, понятное дело, считаете трафик при помощи NeTAMS. Как это делает провайдер? Вариантов несколько:

• NetFlow (на роутере Cisco)

• SNMP (Cisco или поддерживающее такой механизм устройство)

• ip accounting (на роутере Cisco)

• RADIUS (любое поддерживающее устройство)

По определению, NetFlow учитывает трафик ТОЛЬКО НА ВХОДЕ НА ИНТЕРФЕЙС. Это значит, что посчитанный (читай — добавленный вам в счет) трафик может потом быть отброшенным или модифицированным различными механизмами: access–list, policy routing, NAT, и т.п. С другой стороны, сгенерированный самим роутером или кем–то еще в провайдерской сети трафик в вашу сторону — не посчитается.

Счетчики SNMP, наоборот, снимаются на выходе с интерфейса, однако в них нет разделения по протоколам и портам, зачастую единственно что возможно получить — это количество переданных байт в обе стороны. Если вы связаны с провайдером по ethernet, например, то вам посчитаются все ethernet–броадкасты и IP–броадкасты. Вам зачтутся за полезную нагрузку ethernet–заголовки пакета и ip–заголовки: на маленьких пакетах это до 50%. NeTAMS считает только unicast–пакеты, причем берет за полезную нагрузку длину IP–пакета без layer2–заголовка. ip accounting вроде бы также считает на выходе.

Для учета через RADIUS нужно соединение, поддерживающее aaa accounting, т.е. это применимо только к (псевдо)коммутируемым соединениям вроде dialup или VPN–туннелей, а не к типичному ethernet–подключению.

Итак, то что вас насчитал ваш провайдер — это совсем не то, что оказалось на входе канала в вашу сторону. Далее, при передаче трафика к вам данные имеют большой шанс потеряться. Это касается перегруженных каналов, или таких где ошибок по определению много. Если у вас xDSL–подключение на 2 мегабита, а пользователей ЛВС сотни, это означает что трафик в вашу сторону из интернета к провайдеру может временами превышать эти 2Мбит/с, и он учтётся, но при попадании в низкоскоростной канал к вам — будет неизбежно потерян при переполнении пакетных буферов марштуризатора провайдера. При использовании радиоканала данные могут просто «потеряться» в эфире. Кто говорит вам «мы вас по радио подключили на 11 мегабит, какие там потери?» — смело гоните в шею обманщиков. 11 мегабит — это канальная скорость при максимальном уровне сигнала в режиме точка–точка. На практике получается–50% за счет коррекции ошибок, еще–5%..30% за счет коллизий (вы конечно не одни в сети), еще–5%-30% за счет неустойчивой связи (расстояние, помехи, кривые антенны) и снижении скорости передачи. В итоге вместо «11 мегабит» легко может оказаться 200 килобит и 50% ретрансмитов пакетов.

Наиболее надежным и «безопасным» можно считать подключение к выделенному порту коммутатора провайдера через оптической волокно и пару трансиверов на скорости 100 мегабит или 1 гигабит: в таком канале вряд ли что «пропадет».

Даже если на входящую сетевую плату вашего сервера пришло ровно то, что вам посчитал провайдер, это еще не значит что вы сами все посчитали верно. Сплошь и рядом встречаются ошибки настройки файервола, когда какой–то трафик просто не попадает на учет, какой–то попадает дважды. Ваш сервер тоже генерирует трафик, особенно если у вас там почта или веб. Трансляция адресов также может слегка искажать подсчет. Вывод: нарисуйте схему своей сети и распечатайте таблицы правил firewall, посмотрите что считается, а что летит мимо. Проверьте, что в конфигурационном файле NeTAMS заведены все клиенты. Используйте учет по всей внутренней подсети с параметром no–local–pass.

Наконец, никто не застрахован от влияния «человеческого фактора». Автору известен случай, когда провайдер «случайно» приписал в своем биллинге чужую подсеть, и просил платить за нее.

Подведем итоги. Если расхождения «в вашу пользу», можно, в меру совести, забыть о проблеме. Если вам начисляют «больше», то все зависит от того, «на сколько больше»:

• 0.1% до 1% - вам повезло — это очень хороший показатель точности, можно ничего не делать

• 1% до 10% - ошибки в канале — проверьте загрузку линка в сторону провайдера, ошибки в эфире, «неправильные» правила firewall, неучтенный юнит в конфигурации NeTAMS

• 10% до 30% - возможно это «человеческая» ошибка — неучтенный юнит или недонастроенный firewall

• 100% - трафик посчитан дважды — проверьте правило учета пакетов в NeTAMS

В случае необходимости детального разбирательства можно порекомендовать вести мониторинг юнита типа «сеть» средствами service monitor, запрашивать лог–файлы провайдера и вручную сравнивать цифры, делать выборки из таблиц RAW и SUMMARY вручную и опять же сравнивать с провайдерской детализацией, и думать, думать, думать…

Оглавление книги