Возможно, но в исходных условиях было сказано «IP -> Country Code». Для этого достаточно и урезанной версии. Далее, с учетом того, что анонсы более специфичные, чем /24, фильтруются, можно считать, что все адреса из блока /24 с вероятностью приближающейся к 1 будут иметь один Country Code (и один Organization Id), соответственно, и проверку можно значительно ускорить / упростить за счет другой структуры таблицы в БД.
Кто сказал, что не устроил? Просто ниша моего решения несколько другая — хотелось консольное приложение, которое бы позволило быстро получить обощенную информацию либо по уже существующему PCAP-файлу, который собран чем-то другим (типа sflowtools — путем скармливания файла с данными непосредственно приложению), либо аналогично быстро обобщить данные того же tcpdump-а (e. g. tcpdump -n -c 1000 -i eth0 -w — | сумматор). Честно говоря, меня бы гораздо больше устроило, если бы у tcpdump-а появилась фича выдачи обобщенной информации — тогда бы мне не пришлось ничего писать :)
Я в самой статье этот момент, к сожалению, упустил — хотелось именно а) консольное, б) заточенное под максимально распространенный и поддерживаемый коллекторами формат данных и в) без лишних свистелок. Так, чтобы можно было зайти на сервер с мобильного устройства в консоль 80x25 и получить необходимые данные.
IMHO NetFlow обладает слишком большим оверхедом для задач оценки трафика. Для оценки достаточно объема информации, предоставляемой sFlow / jFlow. Количество пакетов, требующих обработки, в этом случае получается кардинально меньшим, нежели в схеме mirror/SPAN + linux box с ipt_netflow + коллектор. Схема сети получается более гибкая, по сравнению с mirror/SPAN, поскольку коллектор никак не привязывается к конкретному коммутатору. Да и в bottleneck SPAN-интерфейса мы никак не упираемся. И в производительность процессора для разбора PCAP.
КМК, для каждой задачи — свой инструмент. И, опять же, КМК, для оценки профиля трафика, NetFlow — не лучший выбор.
Большое количество — это сколько? При прочих равных sFlow на несколько порядков менее прожорлив, а потрафиковых тарифов я уже и не упомню, чтобы нужно было туда-сюда с точностью до байта считать.
В общем и целом работает. Из весьма полезных фич — прием данных по NetFlow, с mirror-портов и «родная» сигнализация на тему DoS/DDoS. Поскольку тоже perl-овый и подерживает плагины, весьма просто допилить под свои нужды, хотя, конечно, он потолще одного скрипта получается.
Касательно взаимосвязи между объектами в RIPEdb: www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types
Я в самой статье этот момент, к сожалению, упустил — хотелось именно а) консольное, б) заточенное под максимально распространенный и поддерживаемый коллекторами формат данных и в) без лишних свистелок. Так, чтобы можно было зайти на сервер с мобильного устройства в консоль 80x25 и получить необходимые данные.
Впредь буду формулировать мысли аккуратнее.
КМК, для каждой задачи — свой инструмент. И, опять же, КМК, для оценки профиля трафика, NetFlow — не лучший выбор.