ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА

http://www.okna03.ru/ регулировка фурнитуры пластиковых окон.











     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[inet-admins] Re: =?KOI8-R?Q?=EE=E5=F4!-=C6=CC=CF=D5_=C9_=D0=D2=CF=DE=C9=C5.?=



Приветсвую!

Ко всему этому нужно добавить, что в схеме с учетом по входящему
трафику, есть еще одна проблема. А именно "Вассал моих вассалов".
Например:
 
Допустим
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 http://info.east.ru/rus/inetadm.html


-- 
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 http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.