это-то как раз просто решается на всех схемах - через кого пакет поехал,
на того и считаем.
Если мы говорим о пакете в сторону "D", то это однозначно определяется текущей
табличкой роутинга у "А"
Good luck !
======================
Andrey Zimin | AVZ7-RIPE
MTU-Intel ISP
Moscow, Russia
======================
----- Original Message -----
From: "Alexey G Misurenko" <mag@caravan.ru>
To: <inet-admins@info.east.ru>
Sent: 23 мая 2003 г. 12:03
Subject: [inet-admins] Re: НЕТ!-флоу и прочие.
> Приветсвую!
>
> Ко всему этому нужно добавить, что в схеме с учетом по входящему
> трафику, есть еще одна проблема. А именно "Вассал моих вассалов".
> Например:
>
> Допустим
> 1) Есть провайдер "A"
> 2) У провайдера "A" есть клиенты "B" и "С"
> 3) Есть организация "D" которая в свою очередь
> является клиентом как "B" так и "С".
>
> В данной схеме
> D мажет получать ресурсы через "A", как по цепочке
> A-B-D, так и по A-C-D.
>
> А теперь вопрос, как в "входящей" схеме учета трафика
> провайдер "А" поймут кому ("B" или "С") засчитывать трафик
> "D"?
>
> В схеме с "исходящим" учтом, возникают трудности
> если необходим диффиринцированный подход к учету трафика.
>
>
> > Привет,
> >
> > все ездит по кругу, вот и мы вернулись опять к интересному вопросу... ;)
> >
> > с постулатом о флет-рейтах и сла согасен безусловно, но увы жизнь суровей.
> >
>
> Целиком согласен.
>
>
> > давай попробуем описать идеальную схему сбора статистики по трафику,
> > а потом, без потрясания седыми гениталиями, посмотреть что имеем в железе и
>софте, ОК? =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
>
>
> --
> WBR, Alexey G Misurenko ( MAG-RIPE | MMAGG-RIPN )
> CTO of Caravan ISP Phone: +7 095 3632252
>
> =============================================================================
> "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
>
=============================================================================
"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
