Andy52280

Жаль, что тема заглохла. Очень любопытное решение.

Cisco так умеет? Относительно cisco не в курсе, однако в реальной практике очень бы пригодилось.

Спасибо, это удобно, однако хотелось бы таки разделять статистику, чтобы в разные анализаторы трафика собирать разные NetFlow потоки, например разложив на несколько правил с -j NetflowX по ipset. Может быть есть вариант с отдельным Netflow-proxy приложением, которое разделяет NetFlow-статистику на несколько дестинейшенов на основе списка сетей, фигурирующих в потоках? Можно это как хотелку оформить? ;)

Хотелось бы отправлять NetFlow статистику на 2 разных коллектора, причем в идеале с группировкой по IP, скажем для трафика, в котором фигурирую IP из подсети А - на один коллектор, а для остального - на другой. Есть какие-нибудь соображения каким образом это можно реализовать?

не нужно на neighbor клиента делать default-originate - отдайте ему маршрут (0.0.0.0/0) от вышестоящего маршрутизатора

Клиенты это весьма условные. Просто несколько машин шарят как белые адреса из общей AS, так и держат кучу серых адресов. Если не затруднит - выложите пример для cisco. localpref давно используем для распределения исходящего трафика из нашей AS в мир на разные апстримы, но вот в рамках управления трафиком внутри одной AS ни одного примера мне не попадалось

не подходит по 2 причинам 1) там iBGP 2) хотелось бы рулить исключительно со стороны роутеров local pref как раз и распространяется внутри АС и рулится со стороны рутеров все машины и роутеры и клиенты находятся в одной AS есть примерчик именно с 0/0? что-то я затрудняюсь что-то путевое наваять в этом контексте с localpref

эм.. ну конечно вариант, но как-то кривовато =)

не подходит по 2 причинам 1) там iBGP 2) хотелось бы рулить исключительно со стороны роутеров

От quagga уходим. Про причины не буду распространяться - не хотелось бы поднимать флейм.

Хотелось бы заанонсить в BGP (bird) default-gw с 2 роутеров (AR,BR) на двух клиентов (AC,BC) таким образом, чтобы клиент AC получил дефолт с большим приоритетом от AR, а клиент BC - соответственно от BR. Т.е. в нормальном режиме AC слал пакеты в интернет только через AR, BC - через BR, но при вылете любого из AR/BR - клиенты AC,BC продолжали работу через оставшийся роутер. Подскажите, пожалуйста, как это реализовать на bird?

Как фильтровать понятно - непонятно как с наименьшей нагрузкой на c6500 перенести трафик с DST_IP из реестра в сторону прокси (как там прозрачно отпроксировать с фильтрацией в общих чертах понятно), далее принять трафик от прокси и отправить его в интернет. Вот собственно именно в части, касающейся c6500 и есть некоторые сомнения.

Нужна именно фильтрация - если в реестре будет IP крупного портала, то "низя" должны получать только запросы на определенный url. Остальной трафик должен вернуться на тот же 6500 и уже побежать в сторону интернета, а не снова в сторону прокси

Речь шла не о полной блокировке по IP, а о перенаправлении трафика, у которого DST IP из списка zapret-info на очистку в сторону прокси. Подразумевается, что легитимный трафик со стороны прокси должен беспрепятственно уходить в интернет через ту же c6500. Или достаточно будет повесить PBR на трафик, приходящий с интерфейса, к которому подключен прокси - в сторону одного из апстримов? PBR перебьет проанонсированный со стороны прокси BGP-анонс с /32 префиксами и трафик побежит. Эта схема будет работать?

Засада в том, что 6500 у нас бордером => от прокси трафик на эти ресурсы должен пойти снова через 6500 соответственно вариант с динамикой, насколько я понимаю, отпадает

а по какому-нибудь acl нельзя в wccp трафик кинуть?

Собственно размышления на тему zapret-info Это возможно? Поделитесь, пожалуйста реализацией.

Просто хотелось убедиться, что приобретя железку с SFP+ или XFP я ее смогу нормально состыковать со своей c6500 где есть только XENPAK и X2 Возможно есть какие-то неочевидные проблемы, скажем у XFP, насколько я понял, поддерживаются разные варианты скоростей в районе 10Г (9.95 ~ 11.1), в то время как у XENPAK жестко (10.3125). Это несколько напрягает и дает возможность предположить, что модуляция сигнала тоже может отличаться.

Сейчас на рынке присутствует оборудование с поддержкой различных форм-факторов для оптических модулей 10Г Собственно хотелось бы выяснить, будет ли гарантированно работать друг с другом на скоростях 10Г оборудование с оптическими модулями разных форм-факторов и какие при этом есть подводные камни На данный момент точно знаю, что не наблюдается никаких проблем, если на одном конце оптической линии стоит модуль XENPAK, а на втором - X2. Однако нет уверенности что будет если будут следующие варианты соединений: X2-XFP X2-SFP+ XENPAK-XFP XENPAK-SFP+ XFP-SFP+ Подскажите, пожалуйста, какие сочетания гарантированно работоспособны и на какие грабли можно наступить?

Для Samsung есть очень любопытный проект: TheDark SmartTV Media Center IMHO наиболее функционален.

Собственно subj. Пишите Ваши варианты в личку.

Хочу прикупить супервизор на eBay, однако несколько смущает вопрос апгрейда FeatureSet. Если в новом супервизоре будет базовый IOS, можно ли установить на него ADVANCED IP SERVICES NPE с купленного ранее такого же супервизора? Каким образом это делается? Нет ли привязки к железу?

Круто, когда можно отмиррорить аплинк на комп. Достаточно часто это сделать нереально. Не задумывались над задачей анализа NetFlow для этих целей? IMHO менее затратное решение.

Самый очевидный шаг - проагрегируйте список адресов до подсетей. Насколько я вижу достаточно много адресов идет подряд - так что как минимум до /31 или /30 можно будет адреса объединять => количество записей в листе может заметно сократиться.

Есть такая табличка ipset -N BAD-PORTS bitmap:port range 135-1512 ipset -A BAD-PORTS 135 ipset -A BAD-PORTS 137-139 ipset -A BAD-PORTS 144 ipset -A BAD-PORTS 445 ipset -A BAD-PORTS 1512 хотелось бы на ее основе зафильтровать транзитный трафик tcp/udp на эти порты с любым сочетанием src-ip dst-ip так и не смог подобрать работающий вариант пытался делать так iptables -A FORWARD -p tcp -m set --match-set BAD-PORTS dst -j DROP iptables -A FORWARD -p udp -m set --match-set BAD-PORTS dst -j DROP Прошу прощения - разобрался - просто забыл в ядро помимо ip_set собрать xt_set