Документация NetAMS
- Название:Документация NetAMS
- Автор:
- Жанр:
- Издательство:netams.com
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Документация NetAMS краткое содержание
Документация NetAMS - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Теперь надо определить, как отличить «российский» и «зарубежный» трафик, и как это делает ваш провайдер. Все основано на глобальной маршрутизации в Интернете, которая осуществляется по протоколу BGP. Грубо говоря, все сети, подключенные к интернету, принадлежат некоей Автономной Системе (AS), которая представляет собой набор IP–сетей (адресных пространств), находящихся под единым управлением. Владелец и руководитель автономной системы определяет политику маршрутизации своих подсетей через своих соседей–провайдеров или крупных организаций, имеющих свои автономные системы. Все такие системы соединены логическими связями друг с другом так, что любая машина в интернете может быть связана с любой другой машиной посредством нескольких (3–7) автономных систем, каждая из которых образована несколькими маршрутизируемыми сетями. Более того, протокол позволяет выбирать оптимальный путь пользуясь большим количеством передаваемой между автономными системами вспомогательной информации, и т.д. Возвращаясь к нашему случаю, ваш провайдер определил маршрутизацию российского трафика (т.е. сетей, принадлежащих российским AS, их список известен) через один канал, а всего остального — через другой, и за другие деньги. Соответственно, и со своих клиентов взимается разная плата.
Теперь, если вы хотите у себя учитывать разделение трафика так, как это делает у себя ваш провайдер, вам по–хорошему надо бы поднять у себя маршрутизатор (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% ретрансмитов пакетов.
Наиболее надежным и «безопасным» можно считать подключение к выделенному порту коммутатора провайдера через оптической волокно и пару трансиверов на скорости 100 мегабит или 1 гигабит: в таком канале вряд ли что «пропадет».
Читать дальшеИнтервал:
Закладка: