Привет,
все ездит по кругу, вот и мы вернулись опять к интересному вопросу... ;)
с постулатом о флет-рейтах и сла согасен безусловно, но увы жизнь суровей.
давай попробуем описать идеальную схему сбора статистики по трафику,
а потом, без потрясания седыми гениталиями, посмотреть что имеем в железе и
софте, ОК? =8)
каков он, идеальный протокол сбора сетевой статистики?
1) безусловно пуш-технология, т.е. дивайс сам должен хотеть сгрузить
накопленную статистику.
бум расшифровывать почему?
2) транспортный протокол желательно конфигурируемый, потому как ТСП и ЮДП имеют
свои плюсы и минусы, причем примерно равнозначные. Но и в том и другом случае
крайне
желателен контроль канала и фейловер механизмус.
3) сеть состоит из множества дивайсов, как избавится от дублирования рекордов
об одном и том-же потоке?
мне известно три принципиальных метода:
а) пограничный: учет только входящего(или исходящего) трафика и только на
границах сети.
минусы: - все границы должны быть обсчитанны, в незаткнутую дырку лезет
контробанда, причем не только для этой дырки.
б) гнездовой: считаем трафик на кустомерские порты на всех границах гнезда (в
пределе - отдельновзятого дивайса)
минусы: сложности временной синхронизации для разнотипого трафика, если он
тащится через общий
интерфейс(ББ, например несет россию-зарубеж) и тут ты либо выгружаешь на эдж
полное бгп(причем и оно не гарантирует, ибо пути
внешнего трафика твоей таблицей не контролируются), либо поморачиваешся
вычитанием сколектированной в другом месте статистики из
общей и отдельным представлением и того и другого в билл.
в) портовой: считаем ин и аут на портах.
минусы: те-же что и в б) + непонятное избавление от дублей, особенно для
кастомеров с двумя и более
линками и с-нным трафиком между ними.
4) что коллектируем и как агрегируем?
мне кажется что идеальным был-бы метод локального конфигурирования уровня
детализации и агрегации на дивайсе, причем для каждого
(саб)интерфейса пораздельно. Кому-то нужны порты, кому-то сети, кому-то
интерфейсы.
Для статистики по входящему трафику мне кажется важно наличие следующих полей.
с возможностью выгружать только потребный набор:
VPN, интерфейс(и не плывущий от гребанного snmp), SRC|DST IP или агрегированный
по желанию net c маской, proto, port, dscp/prec,
SRC/DST AS от локальной таблички, и ес-нно, SRC/DST EthMAC(где возможно) или
pvc, или прочее L2-сервис обрамление, таймштамп начала
и конца коллектирования, ну и байты с пакетами ес-нно.
продолжаем? =8)_)
Good luck !
======================
Andrey Zimin | AVZ7-RIPE
MTU-Intel ISP
Moscow, Russia
======================
----- Original Message -----
From: "Dmitri Kalintsev" <dek@hades.uz>
To: <inet-admins@info.east.ru>
Sent: 23 мая 2003 г. 02:44
Subject: Re: Re[2]: [inet-admins] Производительность 7206
> Yo dudes,
>
> Netflow сосёт. Поверь мне, как человеку два года проработавшему на фирму,
> для которой была сделана своя версия нетфлов (v6), которая признана самым
> массивным и комплексным решением на базе нетфлова во всём Asia Pacific
> регионе, и по запросам которой написана и переписана добрая половина всего
> кода нетфлова в цыско IOS. Ещё раз: netlow sucks. Don't do netflow. Он не
> скалируется, он жрёт ресурсы, он ломается, egress нетфлов только-только
> соску начинает сосать в не-VRF варианте (и когда он ходить начнёт я сказать
> забоюсь). У жунипера есть прекрасная фича: SCU/DCU (единственное "но" - это
> применимо только на краю, т.е. там куда воткнуты непосредственно кастомеры,
> ибо эккаунтинг бакетов там не так много (если память мне не врёт, SCU - 128
> бакетов, DCU - 64, но это было в JunOS 5.6, и это могло поменяться). SCU
> позволяет мэтчить и считать байтики по BGP attributes префикса куда входит
> source IP пакетиков, например по AS PATH или коммунитям. И каунтеры с
> бакетов считываются по SNMP, по желанию, когда надо. Можно даже захреначить
> крон-жоб, чтобы на самом жунипере крутился и сливал счётчики, а на учётную
> станцию сливал раз в день (например).
>
> But after all - it's your life. ;)
>
> P.S. JFYI: у жунипера встроенный лимит в 7000 pps на интерфейсе fxp1 (это
> между RE и forwarding plane), и этот лимит и определяет магическое значение
> 7000 pps для нетфлова, которое он может переварить. (Да, иссесно этот fxp1
> поделён на queues (4 шт) и одним нетфловом перебить например кипэлайвы
> перебить не выйдет).
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
