[pfexec]

Товарищ пишет про то, что если сливать маршруты в бордер в общую таблицу, то трафик вернувшийся с сервера фильтрации в эту же таблицу опять пойдет туда же а не в интернетики улетит. Но есть куча способов завернуть трафик как надо. Какой фильтр ты имеешь ввиду? Тот что как раз PBR? :D Да, в терминологии Juniper Filter-Based Forwarding.

у циски ***ая терминология просто. я имею ввиду фбф, про который вверху и написал.

Сливаете нужные /32 нужных ресурсов с фильтрующего сервера по бгп/оспф/статикой_и_соплями на коробку, а на фильтрующем сервере уже сквид/нгинкс/магия по URI матчит и блочит или насквозь пускает

ты вобщем то предлагаешь как раз маршрутизацией костыли навбивать. :)я так и решил

[DVM-Avgoor]

у циски ***ая терминология просто. я имею ввиду фбф, про который вверху и написал.

 

 

Тем не менее, это и есть тот самый PBR. И этот термин появился задолго до того как произвели первый джунипер. Так что не стоит проявлять нигилизм, и отвергать общепринятое.

ты вобщем то предлагаешь как раз маршрутизацией костыли навбивать. :)я так и решил

 

FBF (PBR) тоже костыль, как не крути это костыль сильнее даже чем VRF. Но это все касается только вопроса если у товарища бордер и только с одной глобальной таблицей.

Просто вариант с динамической маршрутизацией как обычно удобен тем что не надо будет на коробке ничего переконфигурять, мучая ее процессор от калькулятора.

Изменено 5 апреля, 2014 пользователем DVM-Avgoor

[rdc]

(не реклама) тут сверху часто попадается баннер со ссылкой на Carbon Reductor.

очень простое и эффективное решение - ставится на писюк, отзеркаливается исходящий 80 порт tcp, вопрос полностью решён.

[pfexec]

Так что не стоит проявлять нигилизм, и отвергать общепринятое.

еще как стоит учиться чему-то новому, а старое забывать как страшный сон. проблемы ***ости терминологий циски - это только проблемы циски и её фанбоев. но это уже вопрос религии. любишь мешать всё в кучу - пожалуйста, но неудивляйся что тебя никто не понимает.

FBF (PBR) тоже костыль, как не крути это костыль сильнее даже чем VRF. Но это все касается только вопроса если у товарища бордер и только с одной глобальной таблицей.

Просто вариант с динамической маршрутизацией как обычно удобен тем что не надо будет на коробке ничего переконфигурять, мучая ее процессор от калькулятора.

кококо. какая разница чем мучать процессор, апдейтами ненужного протокола маршрутизации или редкими коммитами ? ну и фильтр можно править и без коммитов. но бойца оспфа и патриота врфов ничем не остановить, ага. :) короче не очем тут говорить, вон товарищ предлагает самый лучший вариант: "карбон редактор". я щитаю надо брать. два!

[vurd]

А чем плохо решение "карбон редактор"? Без шуток. Оно как раз походу работает на базе описанной мной выше технологии с миррором порта.

Всё равно ставить сервер со сквидом или чем-то там еще, он может умереть, но ваш FBF\PBR продолжит гнать туда трафик, а "редактор" отсохнет и ничего не случится.

Так и в чем суть предвзятого отношения если можно тупо без потерь для чего-либо в сети решить проблему на "редакторе" а не выяпываться с 2-я юниперами, как предлагалось в начале?

[alks]

А чем плохо решение "карбон редактор"? Без шуток. Оно как раз походу работает на базе описанной мной выше технологии с миррором порта.

Всё равно ставить сервер со сквидом или чем-то там еще, он может умереть, но ваш FBF\PBR продолжит гнать туда трафик, а "редактор" отсохнет и ничего не случится.

Так и в чем суть предвзятого отношения если можно тупо без потерь для чего-либо в сети решить проблему на "редакторе" а не выяпываться с 2-я юниперами, как предлагалось в начале?

 

при трафике выше 10Г схема с карбон редуктором уже не айс, при внешнем мелком SRX все будет гут, и траф маленький ... ровно до тех пор пока в реестре не окажется vkontakte со всеми своими сетками ))