Автор: Виталий Солдатов, инженер филиала ООО "РН-Информ" в г. Красноярск
Статья опубликована в рамках конкурса "Формула связи"
В данной статье рассматривается сбор данных с маршрутизаторов Cisco для тарификации его в автоматизированной системе расчетов, даются советы по исключению паразитного трафика при «помегабайтном» учете, так же проводится разбор и анализ трафика средствами flow-tools и rrdtools.
С маршрутизаторов Cisco снять данные можно несколькими способами, например с помощью netflow или snmp-протокола. Нельзя сказать, что каждый из них настолько универсален, что другим можно пренебречь. Более того, в составе пакета netflow включены данные об интерфейсах в виде чисел, взятых из базы данных управления snmp. Вот так в комплексе и предполагается использовать netflow и snmp.
Как правило, каждая автоматизированная система расчетов (АСР) содержит в себе коллектор netflow, который представляет собой программное обеспечение, принимающее udp-пакеты на определенном порту. В самой АСР имеется возможность указания источников netflow — маршрутизаторов, в противном случае пакеты от неизвестного источника будут отброшены. Если настройка АСР согласно документации вопросов может не вызвать, то к «включению» netflow на маршрутизиторе необходимо чуть более вдумчиво. Для начала необходимо сформулировать условия тарификации. Наиболее часто встречающиеся сейчас — дифференцированные по зонам, например, «интернет», «город», «бесплатная локальная сеть». Исходя из тарифов с зонами «вытекает» методика сбора. Так, например, если тарифицируется только интернет, а все остальные услуги входят в абонплату, то логичнее организовать сбор netlow только на маршрутизаторе, который имеет непосредственное присоединение к оператору связи, продавшему вам полосу в интернет. Можно, конечно, собирать netflow со всех маршрутизаторов и хранить тарифицируемые за 0 руб. данные на приобретенной специально по такому случаю X терабайтной корзине 3 года согласно ЗоС. Ведь если у вас такая информация собирается и хранится, то получается, что вы обязаны ее предоставлять. А на нет — спроса нет. Сделаю небольшое отступление «как сдавать абонента».
Дешевле всего сдать абонента по логам radius-сессий, если доступ в интернет коммутируемый (PPPoE, PPTP). В стартовом аккаунтинговом пакете хранится информация о логине пользователя, ip-адресе, выданном при подключении. Если время и адрес источника совпадает — получите, распишитесь. Дороже, если приходится собирать информацию о том, «а кто из ваших абонентов в период с 01.07.09 по 01.10.09 посещал блог ekstremizm.livejournal.com и ..(список на трех листах прилагается)?» Еще дороже получается, если подобные запросы приходят, а вы собираете flows со всей вашей сети.
В общем, задумываясь о тарификации по 1 коп за гигабайт какого-нибудь аниме-трафика следует вспомнить о шкафах с терабайтными корзинами, где лежит «сырая» статистика, а не фильмы и все еще раз взвесить. Возможно, что от жадности вам придет озарение хранить не всю «сырую» статистику или внезапно вы введете просто абонплату за пользование местными ресурсами.
Итак, на маршрутизаторе включается netflow следующим образом:
Здесь 10.0.0.1 9996 адрес и порт, на котором «слушает» коллектор АСР. Строка «ip flow-export source» как бы говорит от какого адреса будет слать маршрутизатор данные коллектору. Необходимо в том случае, если маршрутизатор имеет несколько подключений к сети и маршрут с адресом коллектора получает динамически. Либо вы предоставляете услугу в MPLS-сети на PE-маршутизаторе, где интернет раздается абонентам через vrf INTERNET какой-нибудь и ACP не имеет доступа к бэкбону, а только к Lo0, находящемся в этом же vrf INTERNET.
Очевидно, что необходимо включить сбор данных на вашем «граничном» маршрутизаторе, которым вы подключились к оператору связи. Здесь можно понаблюдать эволюцию Cisco. Ранее декларировалось так: включайте ip route-cache flow на «железных» интерфейсах (и надо заметить что другой команды включения подсчета трафика в старых IOS не было). Позже появилось: для подинтерфейсов получите команду ip flow ingress. Теперь (IOS 12.4Т) имеем при включении ip route-cache flow на «железных» интерфейсах команду ip flow ingress на всех подинтерфейсах этого интерфейса, а самой команды ip route-cache flow больше не видать :
Это удобно лишь отчасти, так как в новые подинтерфейсы ip flow ingress придется добавлять вручную или повторять команду на физическом Gi0/0. Проверить сбор данных можно командами show ip flow export и show ip cache flow. В первом случае будет показано количество пакетов, переданных коллектору, а во втором — кэш, в котором происходит накопление данных прежде чем окончательно сформировать пакет для отправки коллектору. Этот кэш имеет собственные параметры и я редко встречал, чтобы их кто-то менял или вообще как-то использовал.
Что это значит? Активной длительной сессией, как правило, является tcp-сессия. Данные об этой сессии будут накапливаться на маршрутизаторе по-умолчанию в течение 30 минут и только потом пакет flow будет сформирован и отправлен коллектору. Чем это грозит? При выключении маршрутизатора данные по активным сессиям до 30 минут будут потеряны. Данные могут быть переданы коллектору в 00:01 следующих суток, а начался новый месяц. Могут быть переданы в 08:01, а у вас ночной трафик до 08:00 по льготным ценам. Если коллектор не анализирует метки времени в пакете (start,end timestamps), то у вас большие проблемы. Уменьшение времени кэширования позволяет существенно сгладить этот негативный момент за счет увеличения нагрузки на процессор, увеличения количества flows, увеличения занимаемого места на вашей терабайтой корзине. Из плюсов — наконец-то получился адекватный пятиминутный мониторинг трафика с ровными графиками, а не пиками раз в полчаса.
В заключение по кэшу хочу заявить, что все попытки испытать по метрологической теме netflow и кэша вызывают у меня улыбку. Как ЭТО сертифицировать?
Для создания зон/классов трафика необходимо включить snmp на маршрутизаторе, предварительно создав ACL для ограничения доступа.
Без этого в flows в качестве индекса интерфейсов будут всегда нули. ifindex persist необходим в случаях, когда АСР не оперирует названиями интерфейсов, а только индексами. «UTM», например. Есть ACP, которые регулярно обращаются к маршрутизатору и делают сопоставления индексов именам интерфейсов и уже в виде имен начинают обработку по правилам. «Старт-IP», например. Если взять коллектор flow-tools, который просто коллектор, а не АСР, то таких фич у него нет по понятным причинам. Коллектор должен только принимать пакеты и очень быстро их складывать на жесткий диск не загружая процессор своей работой.
Вот и подошли как-то сбоку к паразитному трафику. Очевидно, что если пакет был получен маршрутизатором в интерфейс SrcIf, имеющий какой-то индекс, отличный от нуля и передан в интерфейс DstIf, имеющий какой-то индекс, отличный от нуля, то пакет считается переданным. А если интерфейс с адресом DstIf был выключен/не было маршрута, то трафик дропнется в null и соответственно в DstIf будет ноль. Так будет, если вы предварительно прописали все ваши сети в null с большой административной дистанцией, например:
DstIf будет так же ноль, если трафик дропнулся на ACL. Например, абонент заплатил за персональный firewall. Не учитывая правила формирования индексов для DstIf, при работе с ACL можно выставить абоненту весь не полученный им флуд.
Какие еще гадости могут быть при подсчете трафика? Вы выдали абоненту дополнительную сеть из 256 адресов и смаршрутизировали на его интерфейс. Абонент разбил ее на кучу мелких сетей и пока не использует целиком. В случае, если ваш абонент не сделал у себя тоже самое что и вы с вашим блоком адресов, а именно «ip route 10.10.10.0 255.255.255.0 Null0 254», то он получит 30кратное увеличение паразитного трафика за счет правильного, по-вашему мнению, сбора данных. Ip flow ingress будет отрабатывать на возвращаемый от абонента пакет пока не кончится TTL. Правильным будет объяснить абоненту, что маршрутизацией необходимо заниматься и еще можно повесить ACL такому абоненту.
В АСР «Старт-IP» есть механизм, который позволяет формировать динамические правила для исключения подобной ситуации. Что-то вроде «если SrcIf и DstIf идентичны, то не тарифицировать». Понятно, что в «UTM» я такого не находил.
Казалось бы, что список правил для первой нетарифицируемой зоны TRASH готов. Для нормальной ACP - да, но не для «UTM». В этой простой программе нельзя указать индекс «0». Для программы это тоже самое, что параметр с интерфейсом вообще не используется, т.е. не TRUE вовсе. Пришлось поломать немного голову и создать дополнительный подинтерфейс, у которого, конечно же, индекс отличен от нуля, куда все сети были смаршрутизированы.
А на обратной стороне с адресом 10.255.255.254 эти же сети отправляются в null0. Кстати, посмотреть индексы на маршрутизаторе можно командой show snmp mib ifmib ifindex .
Решение дало интересный результат. Стало возможным увидеть количество паразитного трафика, проходящего через этот интерфейс. Предлагаю вашему вниманию «шум» на сеть из 512 адресов.
Что еще следует поместить в эту зону TRASH? Возможно, что некоторые из вас сталкивались с тем, что оператор складывал n раз трафик в биллинг и выставлял вам m*n денег. Рассказываю как это делается.
Существует куча из двух известных мне способов сбора трафика в неMPLS-сетях.
Первый из них — создание контура трафика. Сбор (почему-то русское слово использовать привычнее, чем нетфлоу аккаунтинг) включается на всех интерфейсах всех ваших маршрутизаторов за исключением тех, которыми эти ваши маршрутизаторы соединяются друг с другом. Соединения с маршрутизаторами других операторов в исключения не попадают. Исключаются только внутренние связи. Никакого дублирования нет в принципе, кроме случаев, когда на одной внутренней связи сбор все-таки включили. Такое может быть, если дали команду на физическом интерфейсе невзирая на подинтерфейс-аплинк. Все клиенты такого маршрутизатора повторно получат статистику через еще один ip flow ingress на пути прохождения пакета. Ловкость рук и никакого мошенничества с сертифицированной АСР, однако.
Во втором случае сбор трафика включается на всех интерфейсах всех маршрутизаторах. Внутренние связи исключаются путем внесения правил с интерфейсами в зону TRASH. Здесь должно иметь место слаженная работа оператора биллинга и сетевого инженера, который настраивает маршрутизаторы. В противном случае, при изменении топологии, интерфейсов произойдет накладка. Текучка кадров, низкая ответственность, увеличивают риск некорректного сбора данных.
Если еще осталось желание собирать данные по трафику с маршрутизаторов числом больше двух, то следует внимательнее относится к выбору АСР, персонала.
По зоне TRASH вроде бы все и теперь описывается зона/класс «локальная сеть». В биллинг вносятся все собственные адреса. Порядок зон/классов должен строго соблюдаться. Вероятнее всего, АСР будет обрабатывать правила до первого совпадения. Первым идет TRASH, так как он может содержать исключающие внутренние связи, далее идут «локальная сеть». Если вы хотите выделить какой-то кусок из «локальной сети» и тарифицировать его отдельно, то логичнее поставить правило с куском выше «локальной сети».
Далее идет зона/класс «город». Можно прописать все «городские сети», можно на каждый маршрутизатор через iBGP передать маршруты и в АСР прописать только интерфейсы, можно потренироваться с маркировкой трафика и полем TOS. Здесь наступают на .. кошелек межоператорские отношения. Если трафик вашего пира по «городу» ВНЕЗАПНО пойдет через ваш интернет канал, то от вас будет зависеть:
В качестве эксперимента реализована следующая конструкция подключения клиента (юр.лицо), когда по одному порту он получает интернет трафик, а по другому за отдельную абонплату получает доступ к «городским» сетям. Соответственно, клиент самостоятельно решает вопросы маршрутизации трафика. Думаю, что за отдельную плату можно установить iBGP-сессию и передать «городские» префиксы, еще за отдельную плату взять «CPE» на обслуживание. «Городское» подключение клиента зафильтровано на предмет доступа в/из интернет.
Заключительная зона/класс — это * (все что осталось). Тарифицируется как интернет трафик. На этом с АСР можно закончить и перейти к анализу трафика.
Маршрутизаторы Cisco могут передавать данные максимум двум коллекторам. В случае, если оба коллектора являются коллекторами АСР по ряду причин, то дальше можно не читать. Предполагается, что есть возможность все-таки отправить данные в коллектор flow-tools.
Параметры запуска коллектора зависят от цели использования. Пусть первая цель будет обыденная — сбор и подсчет трафика для контроля работы АСР.
При таком запуске в /data/flows будут автоматически создаваться каталоги 2009/2009-10/2009-10-20/ , где каждые 15 минут будут автоматически создаваться файлы вида ft-v05.2009-10-20.001500+0800 . Файлы лучше обрабатывать поочередно. Так меньше расходуется оперативная память и в итоге получается быстрее. Ниже в качестве примера приводится скрипт маленькой программы статистики (адреса изменены).
Стоить отметить, что awk при работе с очень большими числами начинает их приводить к виду 1e+18. Решение есть.
Создание разнообразных фильтров даст вам необходимую информацию. Например, объем передаваемых данных между вами и потенциальными пиринговыми партнерами.
Дальше про мониторинг все-таки. Для мониторинга нет необходимости хранить множество файлов и поэтому запускается коллектор со следующими параметрами:
Всего будет храниться 100 файлов, каталоги создаваться не будут, файлы создаются с интервалом в 5 минут.
Мониторинг вирусной активности. Вирусы характеризуются многочисленным сканированием достаточно большого количества адресов, а, как известно, маршрутизатор на каждое такое соединение генерирует flows и отправляет коллектору. В нормальном рабочем режиме этот поток данных достаточно предсказуем. Обратите внимание на недельный график:
Чтобы получить такой график необходимо обработать последний файл в коллекторе, при отсутствии базы данных rrd создать ее и занести туда данные, нарисовать график.
Скрипт ниже , запускаемый периодически, выполняет обработку файла и заносит данные в базу.
При превышении параметра, выставляемого вручную, происходит выборка по максимальному количеству пакетов от источников. Можно так же список отправить почтой. База создается один раз.
Чтобы окончательно не перегружать статью скриптами и примерами далее приведу графики, показывающие трафик различных приложений. Это удобно для настроек правил QoS, выяснения причин неполадок, да и вообще здорово, когда подобная информация перед глазами. Информация так же собирается в базы после обработки программами flow-report и т.п.
Репликация важного приложения по спутниковому каналу. Фильтр по адресам серверов.
Таким образом, обезличенный трафик, который привыкли видеть все в программах мониторинга можно разложить на составляющие. Я уже не говорю о том, что в случае чего можно проанализировав трафик принять адекватные меры для ограничения какого-нибудь потока данных или его полной блокировки. Например, обработка файла с сортировкой по количеству пакетов:
Статья рассматривает сбор данных с маршрутизаторов Cisco для тарификации в автоматизированной системе расчетов, дает советы по исключению паразитного трафика при «помегабайтном» учете, а также проводит разбор и анализ трафика средствами flow-tools и rrdtools.
Полный текст новости
у нас что, технические статьи без рекламы писать уже не принято?
хотя гораздо интереснее чем предыдущие две.....
я что то пропустил рекламу Роснефти...
А можно попросить автора чуть подробней и чуть доступней рассказать о мошенничестве с коллекторами данных биллинга? Весьма, весьма любопытная информация для инженерного бюрократа.
К сожалению, из меня программер, как из бутылки брахмаширас. :)
Антон не пиннай его, хотел как лучше, а получится как всегда.
А в коллектор реально можно скормить все, что душе угодно, соответствующее формату лога.
И будет абсолютно достоверная картинка для абонента.
С "метрологической поверкой".
Самое прикольное было кормить коллектор ланбиллинга по крону "минусовым" траффиком.
Уже много лет работает с Нетфлов+Старт IP. Скажу кратко кривое решение, как и все что от Инфосферы.
Давайте рассмотрим этот вопрос немного с другой стороны, а нужно ли вообще собирать эти данные? Может имеет смысл посмотреть в сторону (упаси бога Junipper, более глючного поделия просто нет) 7301 + ISG? с выбором услуг? А не тянуть лямку флов потоков. Тем более у реальных телекомов каналы уже давно перевалили гигабитную планку. И все что может отбросить нормально Flow поток тупо не справляется.
2 Гость_VEK_*:
можете и вовсе не использовать netflow, если вы этого зверя так сильно боитесь,
только вот когда прийдут письма из органов "предоставьте данные по абоненту" и "просим вас.. абонент с таким то IP в такое то время обменивался конфиденциальными данными с таким то IP", отсутствие flow-данных пагубно скажется в лучшем случае на вашей репутации, в худшем случае - на вашем положении.
Мне статья понравилась. И считаю, что кому нужно тот будет собирать эти данный. ИМХО.