[CNick]

Добрый день,

 

Досталось в наследство немного оборудования Arbor Networks. Сапорта на него нет и покупать никто не хочет, а покрутить интересно. В связи с чем возник вопрос, а есть ли комьюнити пользователей продукции этой чудной компании? Я пока что ничего кроме нескольких хвалебных отзывов тут и на хабре не нашел, но технические детали никто не обсуждает, документации на нее тоже кот наплакал :(

 

Спасибо.

[triam]

Постучи в личку =)

[agr]

У Arbor'ов, AFAIK, основное направление - анти-DDoS. Есть здесь на форуме один чел под ником kostich, который анти-DDoS'ом профессионально занимается, помню что-то нелестное он про Арборы говорил, можете к нему еще постучаться.

[bifit]

Какое конкретно у Вас, CNick, оборудование Arbor для борьбы с DDoS'ом?

 

Из основного:

 

CP5500 - это коллектор (2U PC на Xeon'ах), на который приходит нетфлоу с маршуризаторов.

 

TMSxxxx - это митигатор, который осуществляет очистку трафика от DDoS-атак. Митигаторы у Арбора есть на двух платформах - обычные PC с Xeon'ами до 3 Gbps (1U или 2U) и ATCA-платформы с использованием сетевых процессоров XLP732 (MIPS-ядра) и производительностью от 5 до 40 Gbps.

 

Еще встречаются другие менее распространенные позиции.

 

Если есть конкретные вопросы по Арборам - задавайте здесь или на antiddos@bifit.com. Поможем.

 

Димитрий.

Изменено 7 сентября, 2013 пользователем bifit

[CNick]

Какое конкретно у Вас, CNick, оборудование Arbor для борьбы с DDoS'ом?

 

Несколько CP5500 с лидером и TMS разные 3050/1200. Основной функционал работает, но в ходе эксплуатации возникли мелкие неприятности, а в свете того что их в основном хвалят возник вопрос: это я дурак или все таки лыжи не едут :)

 

Из того что больше всего режет глаза это:

 

1. Неправильный подсчет трафика. По SNMP трафик считает правильно, но по netflow исходящий трафик в два раза ниже если он пришел с SVI и ушел в L3 интерфейс. Проблема была сколько помню на всех версиях Arbor OS. 5.6, 5.7 маршрутизаторы Cisco ASR, Nexus, 7206.

 

2. Автоматическая настройка значений в Profiled Detection не учитывает дневные пики трафика и значение получается чуть выше минимального трафика ночью. Коэффициентом максимум что получалось это завысить что бы перекрыть дневные пики, но тогда обнаружение атак в ночное время будет отрабатываться не правильно. Казалось бы в такой умной железке должны были это учесть.

 

3. Если в двух Managed object в match совпадает то работают они непойми как. Ожидал логики как в маршрутизации с best match на основе длинны префикса, но в некоторых случаях срабатывают оба, в некоторых только один. На эти грабли натыкался уже много раз, где нужно знать как железка принимает решения и какие метрики у разных значений, но в документации этого не нашел.

 

Ну и самое неприятное это отсутствие комьюнити и документации в открытом доступе. Первый раз столкнулся с вендором продукцию которого хвалят, но при этом никто не обсуждают технические детали.

 

 

 

Заранее спасибо за любой ответ. Очень давно хотел пообщаться с кем-то на эту тему. Если не узнать ответы на свои вопросы, то хотя бы послушать других людей, узнать на какие грабли наступали что бы быть готовым :)

[redefine]

CNick,

 

Коротко:

1. Вряд ли проблема в ПО Peakflow. Может все же посмотреть на active/inactive таймауты, семплинг и на прочие элементы конфигурации Flow? Например, Peakflow не любит AS и ip prefix агрегацию на 7600.

2. Должен учитывать, так как значение строится по 3 точкам (сегодня, вчера, неделя назад). Детали нужно выяснять.

3. Это зависит не столько от описания MO, сколько от Вашей таблицы маршрутизациии, т.к. источник статистики - корреляция Flow и BGP. Например, если у Вас 2 МО (1.1.1/24 и 1.1/16) и один маршрут в BGP (1.1/16), то трафик будет считаться в оба МО. Если же у Вас такие же объекты и 2 маршрута (1.1.1/24, 1.1/16), то LPM сработает и трафик на 1.1.1.250 посчитается только в объект 1.1.1/24.

 

Посмотрите мое ЛС и я смогу Вам ответить более подробно.