Особенности применения Ethernet агента системы LANBilling в сетях, в которых применяется NAT/Masquerade (маскирование) при средних и больших объемах потребления трафика абонентами.

Ввиду того, что оператора, прежде всего, интересует объем именно абонентского трафика и распределение этого трафика по адресам абонентов, в случае если оператор применяет маршрутизатор на базе PC то, возможны три основных схемы снятия статистических данных с Ethernet интерфейсов маршрутизатора. Все они подробно описаны в документации на стр. 9 - 12.

  Однако если на сервере доступа применяется маскирование (masquerade) или трансляция (NAT) то, количество возможных вариантов сокращается до двух, каждый имеет свои достоинства и недостатки.

1. Снятие статистических данных с внешнего по отношению к абонентской сети интерфейса маршрутизатора, подключенного к сети оператора верхнего уровня. Далее я буду называть этот интерфейс "внешним".
2. Снятие статистических данных с внутреннего по отношению к абонентской сети интерфейса маршрутизатора, подключенного непосредственно к активному оборудованию абонентской сети. Далее я буду называть этот интерфейс "внутренним".

  Второй вариант (2) имеет два основных недостатка: (а) не позволяет получать данные о трафике, сгенерированного самим сервером. (б) В случае если на внутреннем интерфейсе организованы VLAN подсети или тунеллирование (VPN) (технологии изменяющие заголовки и содержание IP пакетов), то корректное снятие данных с интерфейса настроенного таким образом также проблематично. Кроме того, с формальной точки зрения более правильно обсчитывать именно канал который соединяет СПД (Сеть Передачи Данных) оператора с оператором верхнего уровня во избежание несоответствия статистик использования канала предоставленных оператором партнером и собственных данных.



  Первый вариант (1) лишен недостатков варианта 2, однако обладает одной существенной особенностью влияющей на функционирование системы: при снятии информации с внешнего интерфейса в условиях маскирования или транслирования адресов на сетевом уровне (в заголовках IP пакетов) присутствуют адрес, которым осуществляется маскирование или трансляция. При этом адреса клиентов (адреса фиктивной сети) на внешнем интерфейсе не присутствуют вовсе. А именно объем потребления трафика этими адресами и интересуют оператора в первую очередь.

  Одной из штатных функций Ethernet агента является возможность учета пакетов на внешнем интерфейсе. Снятие данных с этого интерфейса возможно, так же и в том случае если на сервере доступа, на котором установлен агент, используется NAT/Masquerade. Однако при фиксации прохождения пакета на сетевом уровне на внешнем интерфейсе в условиях маскирования агент вынужден "консультироваться" с ядром операционной системы (ОС) (а именно, с таблицами соответствия маскированных и немаскированных соединений) на предмет установления соответствия внутреннего адреса "по запросу которого был сгенерирован трафик с, как правило, реального адреса внешнего интерфейса". В последствии, именного внутренний адрес абонента, полученный в результате анализа, таблицы соответствий ядра заносится в БД. Этот алгоритм в терминах LANBilling обозначается как "алгоритм обратного преобразования маскированных адресов".

  В случаях, когда в комбинации с маскированием или транслированием адресов применяются технологии VLAN или/и VPN на внутреннем интерфейсе, то единственным способом получения данных на сетевом уровне является именно вариант №1 ввиду ограничений варианта №2 описанных выше.

  Однако при объеме месячного трафика более 100 Гб. (реальный объем в данном сравнении зависит от производительности сервера доступа) возможна ситуация при которой накладные расходы с которыми связан "алгоритм преобразования маскированных адресов" становятся достаточно велики и производительности сервера доступа уже становится недостаточно для корректной работы алгоритма. Накладные расходы в основном заключаются в анализе таблицы соответствии соединений ядра online. Следствием недостаточной производительности является частичная потери статистики, медленная работа и пр. Косвенными признаками подобной ситуации может служить 100% загрузка процессора (а), а также несовпадение статистики со статистикой оператора верхнего уровня (б).

  Увеличением производительности сервера доступа в данном случае проблема может решаться лишь частично, до тех пор, пока объем потребляемого маскированного трафика опять не превысит возможности сервера по обработке этого трафика. Поэтому для кардинального решения проблемы предлагается использовать схему, при которой учет трафика и VPN/VLAN технологии реализованы на одном сервере, а маскирование осуществляется на специально выделенном для этой задаче втором сервере. При этом второй, выделенный сервер для нужд маскирования может обладать и посредственной производительностью, достаточной лишь для осуществления маскирования канала соответствующей пропускной способности. Схема подобного решения изображена на рис.1.

Рис.1