[PPP]

Т.е. Juniper SRX650 подойдёт для задач?

Поясните, пожалуйста, какого объема BGP таблицы формировать от ISP? Т.е. до какого уровня фильтровать подсети?

И NAT! Стабильно будет обрабатывать 1500 пользователей?

[NikBSDOpen]

Ну, для примера. Собрал стенд на 650. Специально попробовал и загнал в него 2FV. Вот, данные после того, как все маршруты влезли.

 

inet.0: 454675 destinations, 908940 routes (454674 active, 0 holddown, 2 hidden)

show chassis routing-engine

Routing Engine status:

Temperature 31 degrees C / 87 degrees F

CPU temperature 31 degrees C / 87 degrees F

Total memory 2048 MB Max 1577 MB used ( 77 percent)

Control plane memory 1104 MB Max 740 MB used ( 67 percent)

Data plane memory 944 MB Max 840 MB used ( 89 percent)

CPU utilization:

User 5 percent

Background 0 percent

Kernel 2 percent

Interrupt 0 percent

Idle 92 percent

Model RE-SRXSME-SRE6

 

Завернул в него NAT пользователей, только конечно не полторы тысячи, а ~800 активных. Повесил полисер порядка 30Mbit/s на пользователя с небольшим барстом. Загрузка увеличилась на ~25-30 процентов. В общем совсем не критично.

IDP, UTM на этой железке не включал, тестовую лицензию не захотел запрашивать. Но как только включить доп сервисы, вот тогда будет весело. И вот в тот момент нужно будет думать, чем жертвовать. Урезать префиксы или использовать UTM, IDP.

 

На одном из удаленных офисов я резал префиксы, на другом ничего не резал, так как сетка была транзитная, но там за SRX стоял еще старенький SSG520M, с контрактом и доп. сервисами, стоял в transparent mode.

Ну а как порезать, все просто, "методом научного тыка", взлетит или нет. Создаете полис стейтмент приблизительно такого вида:

 

policy-statement import-from-test-24 {

term RFC-1918 {

from {

route-filter 0.0.0.0/0 exact; <---- эта строка фильтрует дефолт

route-filter 127.0.0.0/8 orlonger;

route-filter 10.0.0.0/8 orlonger;

route-filter 172.16.0.0/12 orlonger;

route-filter 192.168.0.0/16 orlonger;

route-filter 169.254.0.0/16 orlonger;

route-filter 224.0.0.0/3 orlonger;

}

then reject;

}

term A-R {

from {

route-filter 0.0.0.0/0 upto /24;

}

then reject;

}

term A-R-ALL {

from {

route-filter 0.0.0.0/0 orlonger;

}

then accept;

}

}

 

Дефолт обрезать или нет, на свое усмотрение.

 

Стабильно будет обрабатывать 1500 пользователей?

 

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

[PPP]

NikBSDOpen

Спасибо за очень развёрнутый ответ!

[NikBSDOpen]

Забыл добавить, если режете префиксы больше, чем /24 (по /23 /22), то не фильтруйте деволт, упадет сосед - потеряете связанность.

[PPP]

NikBSDOpen

Скажите, пожалуйста, насколько результативно использование HA кластера на двух SRX650? Схема подключения двух железок к двум провайдерам выглядит более симпатично, если они в кластере.

[NikBSDOpen]

Результативно...Сложный вопрос. Коллеги поправят, если что, но я считаю, кластер обеспечит просто отказоустойчивость. Тут нужно прежде всего для себя решить, что конкретно Вы хотите достичь, ставя srx в кластер.

Отказоустойчивось?

Увеличение кол-ва nat трансляций?

Больше IPsec VPN соединений?

Для схемы все в одном?

Мое личное мнение (повторюсь, если ошибаюсь, то коллеги возможно поправят) не использовать кластер из двух SRX-650. А !возможно пойти по такой схеме. В качестве "бордера" купить mx-5(10), за ним поставить в кластер два SRX240H2 для NAT. В таком виде, из расчета того, что собираетель собирать кластер из 650, бюджет сильно не "перекроете".

И каждая железка будет выполнять свою прямую обязанность.

В будущем, если нужно будет наростить мощность, можно будет докупать железки более доступного ценового ряда, да и MX5 при желании всегда можно "превратить" в mx80.

 

P.S. Брак по Jun железкам по большому счету не велик. Для сравнения за последние 5 лет у меня 3 недели назад "глюканул" только старенький J4350 (стал беспречинно перегружаться) хоть на него и был активный контракт, снял крышку, продул, заменил память и все.

Изменено 28 июня, 2013 пользователем NikBSDOpen