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

Теперь, если вы хотите у себя учитывать разделение трафика так, как это делает у себя ваш провайдер, вам по–хорошему надо бы поднять у себя маршрутизатор (Cisco, FreeBSD/Zebra,…), поднять на нем сессию iBGP с провайдером, получать от него таблицу роутинга (она часто меняется) и импортировать ее в вашу программу учета трафика. Существует возможность пользоваться менее точной, но более короткой базой ru–networks.txt, построенной на основании таблицы выделенных организациям блоков IP–адресов, которую у себя поддерживает RIPE. В настоящий момент она содержит в себе список около 400 сетей, которые можно назвать «Российскими». Никто не гарантирует, что ваш провайдер будет получать трафик от некоторых таких сетей не через зарубежные каналы, однако я надеюсь, что точность такого разделения будет вполне приемлемой.

Файл ru–networks.txt находится в каталоге addon дистрибутива. К сожалению, летом 2004 года RIPE прекратило поддержку файла, используемого скриптом для построения этого списка, так что дальнейшее расширение базы «русских сетей» нетривиально.

NeTAMS поддерживает файл префиксов в форматах:

A.B.C.D /mask

A.B.C.D/mask

A.B.C.D/masklen

A.B.C.D /masklen

(разница — в пробеле перед маской). Где mask это представление в виде X.X.X.X, а masklen — в битовом, например: /24.

Также возможно использование символов ! — исключить сеть из списка, и # - комментарий (работает только в начале строки).

Таким образом один и тот же файл можно использовать и для NeTAMS, и для FreeBSD: ipfw table

Чтобы подсчитать RU трафик необходимо прописать:

policy name russian target file /usr/local/etc/ru–networks.txt

unit host name myhost ip 192.168.1.10 acct–policy russian

Помните, что совпадение пакета с прописанной сетью в файле означает совпадение политики: для подсчета зарубежного трафика используйте флаг инвертирования(!)

Иногда пользователи 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% ретрансмитов пакетов.