Перейти к содержимому
Калькуляторы

Andy52280

Активный участник
  • Публикации

    156
  • Зарегистрирован

  • Посещение

О Andy52280

  • Звание
    Студент
    Студент

Контакты

  • ICQ
    Array
  1. Жаль, что тема заглохла. Очень любопытное решение.
  2. Cisco так умеет? Относительно cisco не в курсе, однако в реальной практике очень бы пригодилось.
  3. Спасибо, это удобно, однако хотелось бы таки разделять статистику, чтобы в разные анализаторы трафика собирать разные NetFlow потоки, например разложив на несколько правил с -j NetflowX по ipset. Может быть есть вариант с отдельным Netflow-proxy приложением, которое разделяет NetFlow-статистику на несколько дестинейшенов на основе списка сетей, фигурирующих в потоках? Можно это как хотелку оформить? ;)
  4. Хотелось бы отправлять NetFlow статистику на 2 разных коллектора, причем в идеале с группировкой по IP, скажем для трафика, в котором фигурирую IP из подсети А - на один коллектор, а для остального - на другой. Есть какие-нибудь соображения каким образом это можно реализовать?
  5. не нужно на neighbor клиента делать default-originate - отдайте ему маршрут (0.0.0.0/0) от вышестоящего маршрутизатора
  6. Клиенты это весьма условные. Просто несколько машин шарят как белые адреса из общей AS, так и держат кучу серых адресов. Если не затруднит - выложите пример для cisco. localpref давно используем для распределения исходящего трафика из нашей AS в мир на разные апстримы, но вот в рамках управления трафиком внутри одной AS ни одного примера мне не попадалось
  7. не подходит по 2 причинам 1) там iBGP 2) хотелось бы рулить исключительно со стороны роутеров local pref как раз и распространяется внутри АС и рулится со стороны рутеров все машины и роутеры и клиенты находятся в одной AS есть примерчик именно с 0/0? что-то я затрудняюсь что-то путевое наваять в этом контексте с localpref
  8. эм.. ну конечно вариант, но как-то кривовато =)
  9. не подходит по 2 причинам 1) там iBGP 2) хотелось бы рулить исключительно со стороны роутеров
  10. От quagga уходим. Про причины не буду распространяться - не хотелось бы поднимать флейм.
  11. Хотелось бы заанонсить в BGP (bird) default-gw с 2 роутеров (AR,BR) на двух клиентов (AC,BC) таким образом, чтобы клиент AC получил дефолт с большим приоритетом от AR, а клиент BC - соответственно от BR. Т.е. в нормальном режиме AC слал пакеты в интернет только через AR, BC - через BR, но при вылете любого из AR/BR - клиенты AC,BC продолжали работу через оставшийся роутер. Подскажите, пожалуйста, как это реализовать на bird?
  12. Как фильтровать понятно - непонятно как с наименьшей нагрузкой на c6500 перенести трафик с DST_IP из реестра в сторону прокси (как там прозрачно отпроксировать с фильтрацией в общих чертах понятно), далее принять трафик от прокси и отправить его в интернет. Вот собственно именно в части, касающейся c6500 и есть некоторые сомнения.
  13. Нужна именно фильтрация - если в реестре будет IP крупного портала, то "низя" должны получать только запросы на определенный url. Остальной трафик должен вернуться на тот же 6500 и уже побежать в сторону интернета, а не снова в сторону прокси
  14. Речь шла не о полной блокировке по IP, а о перенаправлении трафика, у которого DST IP из списка zapret-info на очистку в сторону прокси. Подразумевается, что легитимный трафик со стороны прокси должен беспрепятственно уходить в интернет через ту же c6500. Или достаточно будет повесить PBR на трафик, приходящий с интерфейса, к которому подключен прокси - в сторону одного из апстримов? PBR перебьет проанонсированный со стороны прокси BGP-анонс с /32 префиксами и трафик побежит. Эта схема будет работать?
  15. Засада в том, что 6500 у нас бордером => от прокси трафик на эти ресурсы должен пойти снова через 6500 соответственно вариант с динамикой, насколько я понимаю, отпадает