Картуччо Опубликовано 12 декабря, 2012 · Жалоба На мелких маршрутизаторах циско особых вопросов нет, работает. Проблемы в ядре. 7606 вообще нормально не поддерживает (без доп плат ?), не говоря про ограничения, вообще не удалось экспорт организовать из-за особенностей топологии и использования VRF. ASR9006 - экспорт идёт, однако, словили проблемы, кроме времени глубокой ночи падает BFD ну и роутинг вслед за ним. Из переписки с поддержкой выяснилось, что процессоры на линейных картах тянут экспорт всего лишь смешных 150 Килопакетов, перегружались и отсюда проблемы с BFD. Huawei NE40E - экспорт есть, однако в ЧНН заметное расхождение с данными SNMP (с других железок) и изредка кратковременно маршрутизатор перестаёт отвечать на SNMP. Если сделать семплинг, то при соответстующем домножении на коэффициент, нетфлоу и снмп совпадает. Может чего не понимаю, но ведь для биллинга данные нетфлоу часто используются. А как это делать, если такая колбаса ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 12 декабря, 2012 · Жалоба Миррор в отдельный порт, а там писюк. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 12 декабря, 2012 · Жалоба Может чего не понимаю, но ведь для биллинга данные нетфлоу часто используются. А как это делать, если такая колбаса ? Похоже, что для биллинга оно часто используется только на 1/6 части суши. Поэтому всем вендорам пофиг. Но Juniper утверждает, что его Trio может netflow на line-rate. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 12 декабря, 2012 · Жалоба Миррор в отдельный порт, а там писюк. это хорошо, когда трафика in+out<10G, а дальше как? куча писюков и сплиттеров? =) в свое время использовал для этой цели rdr на sce, который преобразовывал в netflow, считает, кстати, довольно точно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 12 декабря, 2012 · Жалоба Зеркалирование, кстати, под СОРМ занято и тоже много головной боли вызывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 13 декабря, 2012 · Жалоба Миррор в отдельный порт, а там писюк. это хорошо, когда трафика in+out<10G, а дальше как? куча писюков и сплиттеров? =) в свое время использовал для этой цели rdr на sce, который преобразовывал в netflow, считает, кстати, довольно точно. radius accounting и netflow-sample. Зачем на таких скоростях сувать эту дрять в биллинг? Пускай по сессиям считает. А кто куда ходил посмотрите в неточном виде, никто не умрет, имхо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 13 декабря, 2012 · Жалоба SFLOW использовать никак не получится? Я использую SFLOW. Неточно - да, ненапряжно - да) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cmhungry Опубликовано 13 декабря, 2012 · Жалоба Может чего не понимаю, но ведь для биллинга данные нетфлоу часто используются. А как это делать, если такая колбаса ? Похоже, что для биллинга оно часто используется только на 1/6 части суши. Поэтому всем вендорам пофиг. Но Juniper утверждает, что его Trio может netflow на line-rate. Juniper этого не утверждает. Есть реализации в России, когда для целей биллинга используется inline ipfix с линейной карты на трио. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CityFox Опубликовано 13 декабря, 2012 · Жалоба Может чего не понимаю, но ведь для биллинга данные нетфлоу часто используются. А как это делать, если такая колбаса ? Похоже, что для биллинга оно часто используется только на 1/6 части суши. Поэтому всем вендорам пофиг. Но Juniper утверждает, что его Trio может netflow на line-rate. Juniper на MPC картах умеет только экспорт в формате IPFIX. Для экспорта netflow v5 нужен мультисервисный модуль MS-DPC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 13 декабря, 2012 · Жалоба Может чего не понимаю, но ведь для биллинга данные нетфлоу часто используются. А как это делать, если такая колбаса ? Похоже, что для биллинга оно часто используется только на 1/6 части суши. Поэтому всем вендорам пофиг. Но Juniper утверждает, что его Trio может netflow на line-rate. Juniper на MPC картах умеет только экспорт в формате IPFIX. Для экспорта netflow v5 нужен мультисервисный модуль MS-DPC. У которого есть проблемы с производительностью, если трафика больше 5.5gb/s А вообще Juniper анонсировали MS-PIC, обещают 2xMS-DPC performance, и самое главное - можно вставить в MX-80 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KPOXA.NET Опубликовано 13 декабря, 2012 · Жалоба Снимаю с 7606 с супером 3cxl, вполне нормально все считается, без потерь, с snmp сходится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 13 декабря, 2012 · Жалоба С 7606 однозначно есть аппаратные ограничения, если не ошибаюсь, то отметившийся в теме cmhungry здесь в одной из тем писал на эту тему :) Аппаратные ресурсы ограничены и при большом количестве сессий будут теряться данные. А проблема с экспортом получилась при ситуации, когда анализируемый трафик идёт в главной таблице, а нетфлоу коллектор находится в таблице VRF. Не смотря на наличие соответствующих настроек, до коллектора не доходило ничего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 14 декабря, 2012 · Жалоба Может чего не понимаю, но ведь для биллинга данные нетфлоу часто используются. А как это делать, если такая колбаса ? Похоже, что для биллинга оно часто используется только на 1/6 части суши. Поэтому всем вендорам пофиг. Но Juniper утверждает, что его Trio может netflow на line-rate. Juniper на MPC картах умеет только экспорт в формате IPFIX. Для экспорта netflow v5 нужен мультисервисный модуль MS-DPC. У которого есть проблемы с производительностью, если трафика больше 5.5gb/s А вообще Juniper анонсировали MS-PIC, обещают 2xMS-DPC performance, и самое главное - можно вставить в MX-80 Ага только цена там будет такая ... Самое правильное решение это мирроринг ( желательно пассивный ) и генерить на серваке с линуксом. Есть коммерческие системы http://www.ntop.org/products/ , но даже у нх цена в десятки раз ниже чем у ms-dpc. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 26 декабря, 2012 · Жалоба С 7606 однозначно есть аппаратные ограничения, если не ошибаюсь, то отметившийся в теме cmhungry здесь в одной из тем писал на эту тему :) Аппаратные ресурсы ограничены и при большом количестве сессий будут теряться данные. А проблема с экспортом получилась при ситуации, когда анализируемый трафик идёт в главной таблице, а нетфлоу коллектор находится в таблице VRF. Не смотря на наличие соответствующих настроек, до коллектора не доходило ничего. Да, на 1-2 гиг 76xx хватает, а далее не тянет. А зачем коллектор тыкать в VRF? Какой особый смысл? Похоже, что для биллинга оно часто используется только на 1/6 части суши. Поэтому всем вендорам пофиг. А что используют для биллинга на остальной части суши и как они детализации клиентам рисуют? Или не рисуют? Хорошо им тогда... Аж завидно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
joesm Опубликовано 26 декабря, 2012 · Жалоба Да, на 1-2 гиг 76xx хватает, а далее не тянет. 1-2 это как-то пессиместично. На данный момент больше 8Г и особых проблем не замечано. Счетчики Failed по нулям. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 26 декабря, 2012 · Жалоба 1-2 это как-то пессиместично. На данный момент больше 8Г и особых проблем не замечано. Счетчики Failed по нулям. симметрично сейчас трафика уже >10G, тут 7600 уже плохеет, а на меньшем все норм Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 26 декабря, 2012 · Жалоба зависит от наличия и типа DFC на платах на борту.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 26 декабря, 2012 · Жалоба У которого есть проблемы с производительностью, если трафика больше 5.5gb/s А вообще Juniper анонсировали MS-PIC, обещают 2xMS-DPC performance, и самое главное - можно вставить в MX-80 И тогда можно будет NAT на MX-80 замутить? Да, на 1-2 гиг 76xx хватает, а далее не тянет. 1-2 это как-то пессиместично. На данный момент больше 8Г и особых проблем не замечано. Счетчики Failed по нулям. Траф только с GRT снимаете или в том числе и с VRF? покажите конфиг плз и утилизацию tcam Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
joesm Опубликовано 27 декабря, 2012 · Жалоба Траф только с GRT снимаете или в том числе и с VRF? покажите конфиг плз и утилизацию tcam Только с global, в моем случае снимать данные о трафике клиентов сидящих в своих VRFах нет смысла. ip flow-cache timeout inactive 60 ip flow-cache timeout active 10 ! mls flow ip interface-full no mls flow ipv6 mls nde sender version 5 mls qos no mls acl tcam share-global mls cef error action reset ! L3 Forwarding Resources Module FIB TCAM usage: Total Used % Used 2 72 bits (IPv4, MPLS, EoM) 196608 10881 6% 144 bits (IP mcast, IPv6) 32768 9 1% detail: Protocol Used %Used IPv4 8832 4% MPLS 2049 1% EoM 0 0% IPv6 2 1% IPv4 mcast 4 1% IPv6 mcast 3 1% Adjacency usage: Total Used %Used 1048576 3592 1% L3 Forwarding Resources Module FIB TCAM usage: Total Used % Used 3 72 bits (IPv4, MPLS, EoM) 196608 10882 6% 144 bits (IP mcast, IPv6) 32768 9 1% detail: Protocol Used %Used IPv4 8833 4% MPLS 2049 1% EoM 0 0% IPv6 2 1% IPv4 mcast 4 1% IPv6 mcast 3 1% Adjacency usage: Total Used %Used 1048576 3592 1% L3 Forwarding Resources Module FIB TCAM usage: Total Used % Used 5 72 bits (IPv4, MPLS, EoM) 196608 10882 6% 144 bits (IP mcast, IPv6) 32768 9 1% detail: Protocol Used %Used IPv4 8833 4% MPLS 2049 1% EoM 0 0% IPv6 2 1% IPv4 mcast 4 1% IPv6 mcast 3 1% Adjacency usage: Total Used %Used 1048576 3595 1% L3 Forwarding Resources Module FIB TCAM usage: Total Used % Used EoM 0 0% 6% 144 bits (IP mcast, IPv6) 32768 9 1% detail: Protocol Used %Used IPv4 8833 4% MPLS 2049 1% EoM 0 0% IPv6 2 1% IPv4 mcast 4 1% IPv6 mcast 3 1% Adjacency usage: Total Used %Used 1048576 3592 1% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 27 декабря, 2012 (изменено) · Жалоба Да, на 1-2 гиг 76xx хватает, а далее не тянет. 1-2 это как-то пессиместично. На данный момент больше 8Г и особых проблем не замечано. Счетчики Failed по нулям. По нулям, да, но вот пугает, что интенсивность трафика к коллектору с 14 до 24 часов в "полке" на 15 Мбит... Синхронно второй процессор в "полке" на 65%. Скорости формирования потока экспорта явно недостаточно. Изменено 27 декабря, 2012 пользователем Tosha Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...