On Fri, 23 May 2003 12:21:39 +0400
"Andrey Zimin" <horgi@mtu.ru> wrote:
> это-то как раз просто решается на всех схемах - через кого пакет поехал,
> на того и считаем.
> Если мы говорим о пакете в сторону "D", то это однозначно определяется
>текущей табличкой роутинга у "А"
>
>
Если С и B подключены не последственно к тому пограниченому роутеру кудою трафик
влетел, а если нет?
> 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)_)
> > >
> > >
> > >
--
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
