Компания
34,88
рейтинг
24 июня 2014 в 10:20

Разное → Настойка можжевельника: готовим Juniper SRX. Часть 1

juniper — можжевельник (англ.)

Намедни в мои цепкие лапы попали два Juniper SRX 550. Попали не просто так, а для организации надежного ipsec и NAT-шлюза, а также OSPF-роутера. Ну а так как главное для нас — надежность, то именно с нее и начнем.

Для того, чтобы обеспечить отказоустойчивость сервисов, критично важные узлы обычно дублируют. Для ЦОДов это уже практически стандарт — N+N или хотя бы N+1. При этом устройства могут работать как независимо друг от друга, так и в кластере. Для обоих типов есть свои плюсы и минусы, но если нужен не просто роутинг/свитчинг, но нечто более «интеллектуальное» (например, те же NAT или IPSec), то без кластера тут точно не обойтись. Так что при плановом апгрейде в качестве замены Cisco 7201 рассматривались именно роутеры, способные работать в кластере. В связи с этим ASR 1k отправился лесом (как и ISR), ASA не рассматривалась (потому как готовить ее не умею), а VSS из Cat6503 — это уж слишком жирно и в плане цены, и в плане съедаемой электроэнергии.

Герой нашего рассказа. (Здесь и далее — картинки с официального сайта Juniper)

Так что после поисков (недолгих) выбор пал на Juniper SRX 550, и выбор, на мой взгляд, оказался правильным.
Juniper SRX — решение уровня филиала/головного офиса (branch office/HQ) для организации VPN, доступа в интернет и фильтрации трафика вплоть до L7.

Это весьма удачная линейка, успешно конкурирующая с семейством ASA от Cisco. Хотя позиционируется она как фаерволы, по факту это полноценное решение для маршрутизации и фильтрации трафика, а также организации VPN. Область применения – от маленьких офисов до ЦОДов. Возможности – от IPSec до VPLS (включая Zone-based NAT, Firewall, IPS/IDS и антивирусную защиту). К этому стоит добавить вменяемую политику лицензирования (привет, Cisco!), обилие поддерживаемых интерфейсов (существуют карты для xDSL, E1/T1 transport, ethernet switching, а также модели с поддержкой 3G/LTE) и на выходе мы получим практически идеальное «пограничное» решение для энтерпрайза (как центрального офиса, так и филиалов). Практически – потому что нет пока, увы, полноценной поддержки телефонии, и еще кучи всего, что есть, например, в том же ISR. А в остальном – просто супер.

Внутри – полноценный JunOS со всеми вытекающими. Соответственно, если есть опыт в настройке другого оборудования Juniper, то проблем не возникнет совершенно.

Перво-наперво, из двух SRX соберем один кластер, который обеспечит нам HA, сотрудникам — стабильную связь, а админам — крепкий и здоровый сон. Для этого между устройствами потребуется два линка – data и control. Управление, при этом, у каждого может быть свое. Младшие серии SRX поддерживают только Active-Standby кластеризацию, при которой одно устройство будет заниматься обработкой трафика, а другое – периодически с ним синхронизироваться, вплоть до состояния TCP и IPSec сессий, чтобы, если с первым чего случится, сразу же взвалить на себя его обязанности без простоя для пользователя. Схема довольно распространенная на сегодняшний день, Juniper ничего нового изобретать не стал. Для старших линеек, позиционируемых в ЦОД, возможна Active-Active работа.



1. Готовим линки
Управление у нас будет жить на портах ge-0/0/0 каждого маршрутизатора. Он же будет fxp0.
Далее собираем fabric-link (data) и control-link (signaling). fabric собирается на портах ge-0/0/2; control – на ge-0/0/1. При этом control будет обозначаться как fxp1. И при этом еще эти интерфейсы device-specific, т.е. управляться может каждое устройство в отдельности (ниже я покажу, как настроить роутинг для управления обеими нодами сразу).
Подробнее про назначение этих линков можно почитать прямо на сайте Juniper (английская мова).

Остальные порты можно использовать как угодно по своему желанию.

2. Собираем кластер
Собираем кластер тривиальной командой:

set chassis cluster cluster-id <0-15> node <0-1> reboot

Где 0-15 это id стека (на самом деле 1-15, 0 это inactive stack). Номер стека влияет на генерируемый virtual mac для внешнего reth-интерфейса, поэтому если у вас в сети больше одной пары srx, cluster id у них должны различаться.
0-1 это номер ноды. Соответственно, для сборки кластера мы должны на каждой ноде выполнить эту команду, при этом cluster id должен быть одинаковым, а node id различаться.

После ребута интерфейсы на второй ноде будут именоваться как ge-9/0/x во избежание путаницы.

3. Настройка

Теперь настраиваем управление
#Тут все стандартно - настраиваем hostname и ip
set groups node0 system host-name jpsrx550-1
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.1.241/24
 
set groups node1 system host-name jpsrx550-2
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.1.242/24
 
#Тут настраиваем т.н. backup-router,
#чтобы достучаться можно было не только до active-ноды, но и для standby
set groups node0 system backup-router 192.168.1.1
#Destination можно указать любой, хоть 0.0.0.0/0,
#но я ограничился только сетью, из которой будет производиться управление
set groups node0 system backup-router destination 192.168.0.0/24
       
set groups node1 system backup-router 192.168.1.1
set groups node1 system backup-router destination 192.168.0.0/24
 
#А этой строчкой мы, собственно, применяем изменения.
#При этом настройки применяются не ко всему кластеру в целом, а отдельно к каждой ноде.
set apply-groups "${node}"


Собираем fabric-интерфейсы, по которым роутеры будут обмениваться данныим
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-9/0/2


4. Failover
Redundancy Groups — это виртуальный интерфейс, включающий в себя порты с обеих нод. Один из интерфейсов находится в состоянии Active, второй – в standby. Как только active-нода по какой-либо причине выходит из строя, или на active-интерфейсе пропадает линк, трафик переключается на бэкапную ноду. При этом агрегированные интерфейсы (ae) добавлять в reth-группы нельзя.
Сборка Redundancy Groups
#Настраиваем failover-группы, т.н. redundancy-group,
#в которых определяем, какая нода будет главной, а какая – не очень
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
# Так же можно выставить приоритеты конкретных интерфейсов
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-9/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-9/0/4 weight 255


Теперь самое интересное – т.н. reth-интерфейсы. Это не portchannel в классическом понимании, это именно failover-пары. Т.е. со стороны коммутатора это просто будут два порта с одинаковыми настройками.
Настройка reth-групп
#В лучших традициях Juniper, нужно заранее указать,
#сколько reth-интерфейсов мы хотим использовать:
set chassis cluster reth-count 2
 
#Сначала интерфейсы попарно собираем в reth-пары
#Со стороны коммутатора это будут обычные порты, не объединенные
#в etherchannel!
set interfaces ge-0/0/4 gigether-options redundant-parent reth1
set interfaces ge-9/0/4 gigether-options redundant-parent reth1
 
set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-9/0/3 gigether-options redundant-parent reth0
 
#Потом определяем, к каким redundancy-группам они будут относиться.
#Я решил не усложнять и оставить всех в одной
set interfaces reth1 redundant-ether-options redundancy-group 1     
set interfaces reth0 redundant-ether-options redundancy-group 1
 
#reth-интерфейсы ведут себя, по сути, как обычные routed-порты.
#Т.е. можно ровно так же вешать на них ip, создавать sub-if и т.д.
set interfaces reth1 unit 0 family inet address 192.168.1.1/24   
set interfaces reth0 unit 0 family inet address 10.10.10.200/24
 
#Т.к. правила у нас будут zone-based (но о правилах и политиках в следующий раз),
#то не забываем записать интерфейс в нужную зону
set security zones security-zone untrust interfaces reth0.0
set security zones security-zone trust interfaces reth1.0


Как вы, наверное, могли заметить, с помощью приоритетов можно настроить failover-группы так, что оба устройства будут задействованы примерно равномерно. Это, разумеется, не полноценная active-active работа, но зато, например, можно «разложить» нагрузку на оба устройства.

Применяем изменения:

commit


5. Легкие штрихи
Кластер мы настроили, остались мелкие штрихи, которые потом, думаю, обязательно пригодятся:
Наводим красоту
#Назначаем hostname кластера
set system host-name jpsrx550-X
#Устаналиваем часовой пояс
set system time-zone Europe/Moscow
#Настраиваем DNS. Здесь лучше всего
#прописать ваш внутренний DNS,
#это позволит резолвить имена клиентов
set system name-server 8.8.8.8
set system name-server 8.8.4.4
#Настраиваем доп. пользователя
set system login user admin uid 2000
set system login user admin class super-user
set system login user admin authentication encrypted-password "XXXXXXXXXXXXXX"
#Syslog, куда будут капать наши логи
set system syslog host 192.168.1.100 any any
#Сервер точного времени
set system ntp server 192.168.1.2 prefer
#Настройки SNMP
set snmp location DataCenter
set snmp contact "noc@nixman.info"
set snmp community public authorization read-only
#Для зоны trust разрешаем все _входящие_ подключения.
#Все, что идет не роутеру, а дальше, регулируется policy
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
#Разрешения можно задавать не только для всей зоны, но и для каждого интерфейса в этой зоне
set security zones security-zone trust interfaces reth0.0 host-inbound-traffic system-services all
#Снаружи нас можно только пинговать
set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust host-inbound-traffic system-services traceroute


Снова говорим commit и проверяем
admin@jpsrx550-X> show chassis cluster status
Cluster ID: 1
Node                  Priority          Status    Preempt  Manual failover
 
Redundancy group: 0 , Failover count: 1
    node0                   100         primary        no       no
    node1                   1           secondary      no       no
 
Redundancy group: 1 , Failover count: 4
    node0                   0           secondary      no       no
    node1                   0           primary        no       no
 
{primary:node0}
admin@jpsrx550-X> show chassis cluster interfaces
Control link status: Up
 
Control interfaces:
    Index   Interface        Status
    0       fxp1             Up
 
Fabric link status: Up
 
Fabric interfaces:
    Name    Child-interface    Status
                               (Physical/Monitored)
    fab0    ge-0/0/2           Up   / Up
    fab0
    fab1    ge-9/0/2           Up   / Up
    fab1
 
Redundant-ethernet Information:
    Name         Status      Redundancy-group
    reth0        Down        1
    reth1        Down        1
    reth2        Down        1
    reth3        Down        Not configured
    reth4        Down        Not configured
    reth5        Down        Not configured
 
Redundant-pseudo-interface Information:
    Name         Status      Redundancy-group
    lo0          Up          0
 
Interface Monitoring:
    Interface         Weight    Status    Redundancy-group
    ge-9/0/4          255       Down      1
    ge-0/0/4          255       Down      1
    ge-9/0/6          255       Down      1
    ge-0/0/6          255       Down      1
    ge-9/0/3          255       Down      1
    ge-0/0/3          255       Down      1


Диагностика работы кластера:

show chassis cluster statistics
show chassis cluster control-plane statistics
show chassis cluster data-plane statistics
show chassis cluster status redundancy-group 1

На этом кластер можно считать готовым к работе.

P.S. Конфиги, по возможности, убрал под спойлеры, думаю, так правильней. Если надо достать — пишите в комментариях.
Автор: @Night_Snake

Комментарии (24)

  • 0
    если у нас аплинк по 3G/LTE, то как нам поможет кластер?
    • 0
      Под рукой таких устройств нет, но если 3g-модемы будут установлены в оба устройства, то проблем возникнуть не должно, кмк.
      • 0
        ну так там же ppp и для полноценного failover должна быть поддержка на стороне оператора.

        а кластером мы от какой беды пытаемся защититься?
        • 0
          ну у вас будет просто две независимых ppp-сессии, вот и все.

          Защититься мы пытаемся от выхода из строя одной из железок, либо от нарушения связности с одним из устройств (т.е. failover происходит как при падении одной из нод, так и по падению портов в redun-группе
          • 0
            Защититься мы пытаемся от выхода из строя одной из железок, либо от нарушения связности с одним из устройств

            Это самые простые и наименее вероятные сценарии. Рассматривайте другой сценарий: «control plane встал колом, пакеты не ходят, фейловера нет».
            • 0
              Это не главный бордер в сети, тут достаточно предусмотреть именно эти сценарии.
          • 0
            >ну у вас будет просто две независимых ppp-сессии, вот и все.

            так там будут разные адреса и failover будет означать разрыв всех сессий.

            >Защититься мы пытаемся от выхода из строя одной из железок

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

            >либо от нарушения связности с одним из устройств

            тогда и свитчи надо резервировать, и опять же — вопросы питания. а так — srx стоят рядом и требуют линка между ними(который тоже надо будет резервировать ведь? :)))

            если железки стоят в одной(или соседних) стойке — тут тоже масса проблем.

            вообщем, я о том, что честное резервирование подразумевает неслабые вложения в инфраструктуру и вот просто пара железок мало чем помогут. да и ту же задачу можно решить куда более дешевыми способами :)
            • 0
              так там будут разные адреса и failover будет означать разрыв всех сессий

              Увы, увы :( Но для меня такой задачи не стояло, и даже девайсов под рукой нет, чтобы можно было как-то протестировать возможные варианты.

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

              В каждой железке два БП «по умолчанию» (в смысле что мы по умолчанию к каждой покупаем второй БП, это очевидные вещи). Они стоят в ЦОДе с резервированием упсами и ДГУ. Так что тут все гуд.

              >тогда и свитчи надо резервировать, и опять же — вопросы питания. а так — srx стоят рядом и требуют линка между ними(который тоже надо будет резервировать ведь?
              uplink/downlink идут на разные пары коммутаторов, линки между ними — это прямые патчкорды между стойками. В принципе, их тоже можно резервировать — главное, чтобы портов хватило, а то придется еще и карточки интерфейсные покупать ;)

              >вообщем, я о том, что честное резервирование подразумевает неслабые вложения в инфраструктуру и вот просто пара железок мало чем помогут. да и ту же задачу можно решить куда более дешевыми способами :)
              Я сейчас рассматриваю вполне конкретную модель оборудования и описываю вполне конкретные методы failover, которые она предоставляет. Я не претендую ни разу на всеобъемлющую статью по резервированию сетевой инфраструктуры, способную работать в условиях ядерной войны.
  • +1
    Что-то я вас не понял.
    если нужен не просто роутинг/свитчинг, но нечто более «интеллектуальное» (например, те же NAT или IPSec), то без кластера тут точно не обойтись.

    Ничего «интеллектуального» в этих технологиях нет. Да, NAT не терпит асимметрии, но на это есть SNAT, синхронизирующий таблицы. Для IPSec единственным правильным решением является создание независимых туннелей на независимых устройствах, желательно по независимым каналам связи, а репликация SA между устройствами не нужна.

    Кластеризацией вы лишь создали огромную единую точку отказа в виде единого control plane у кластера. А говорите, хотите крепкого сна… Теперь вы будете со страхом выполнять любые действия на кластере. Особенно — нечто глобальное вроде обновления. А когда есть независимые устройства — просто мягко уводите пакеты с одного из них, делаете на нем что хотите, возвращаете трафик, на пару дней оставляете поработать, потом те же самые действия на другом устройстве выполняете. Без влияния на сервис, без риска положить второе устройство манипуляциями с первым.

    В общем, думаю, сейчас эйфория от упрощения администрирования пройдет, и спустя месяцы/годы вы придете к тому, что никогда и нигде не будете иметь дела с кластерами, пока есть хоть какой-то выбор.
    • 0
      Для меня еще важный фактор — это упрощение конфигурации. Я разделяю ваш скепсис по поводу кластеров, так что стараюсь их использовать по минимуму. Однако здесь другой случай — у меня порядка сотни с лишним ipsec-туннелей, делать резервную сессию для каждого — нереально. Отслеживать актуальность всей сотни подключений — тем более. Так что кластеризация в данном случае была необходима, имхо. Про риски вставшего раком control plane знаю, но учитывая, что это не единственный кластер в сети, и cp раком вставал даже у шеститонника в VSS… Считаю это неизбежным злом :)
      • +2
        у меня порядка сотни с лишним ipsec-туннелей

        DMVPN. FlexVPN. Какие-нибудь жуниперовские аналоги. В центре будет один туннель. На споках тоже. Пора переходить.
        делать резервную сессию для каждого — нереально. Отслеживать актуальность всей сотни подключений — тем более.

        На несколько часов развлечений, если руками, и примерно столько же — скриптом. Отслеживать можно любой системой мониторинга или скриптами.
        и cp раком вставал даже у шеститонника в VSS

        Ага-ага. Я сталкивался с кластерными проблемами на ВСЕХ видах кластеров, включая и ASA, и VSS, и стеки, и так далее.
        • 0
          DMVPN. FlexVPN. Какие-нибудь жуниперовские аналоги. В центре будет один туннель. На споках тоже. Пора переходить.

          Конкретизирую — сотня туннелей с сотней разных заказчиков через голый интернет. Тут никаких DMVPN не прокатит
          На несколько часов развлечений, если руками, и примерно столько же — скриптом. Отслеживать можно любой системой мониторинга или скриптами.

          Нужно написать такой скрипт, потом еще сделать так, чтобы его поняли другие, потом сделать для него понятный для системы мониторинга вывод… проще было купить железку.
          • +1
            сотня туннелей с сотней разных заказчиков через голый интернет.

            Ой. Сочувствую. Лично у меня что ни туннель со сторонней организацией, то долгий траблшутинг и рекомендации по изменению их конфигурации/архитектуры, так как по ту сторону туннеля обычно сидят не сказать чтобы уж очень компетентные люди (хотя все поголовно — IT компании, большинство — интеграторы).

            Тогда, возможно, остается молиться на стабильность кластера.
      • 0
        > Однако здесь другой случай — у меня порядка сотни с лишним ipsec-туннелей, делать резервную сессию для каждого — нереально.

        а в чем проблема? неужели вы это руками делаете?

        >Отслеживать актуальность всей сотни подключений — тем более.

        неужели вы это руками делаете? :)
          • 0
            нуу… может, скажу банальность, но RADIUS?

            и у заказчиков тоже всё так же зарезервировано?
            • 0
              а при чем тут RADIUS?
              • 0
                у вас ipsec на сертификатах? psk? или что-то еще?

                просто можно за всем этим хозяйством ходить в radius.
                • 0
                  на PSK. При этом нужно новые туннели заводить в двух местах сразу, дружить с RADIUS, что само по себе отдельный геморрой, ибо радиус в наличии тока виндовый и админю его не я. Т.е. — еще и радиус свой поднимать. Куда ни кинь — сплошное пложение лишних сущностей
    • 0
      >Для IPSec единственным правильным решением является создание независимых туннелей на независимых устройствах, желательно по независимым каналам связи

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

      • 0
        Так я и говорю, что нужны независимые IPSec туннели с независимых устройств по независимым каналам связи. Внутри туннелей, само собой, IGP.
      • 0
        На дальнем конце туннелей — не мои устройства, так что IGP отпадает
        • 0
          Кстати, кто-то в посте писал про архитектуру, когда IGP при общении с контрагентами — RIP. Первая моя мысль была «идиоты, зачем откапывать и насиловать труп? Закопайте RIP обратно». Вторая мысль — «черт побери, разумно. Протокол DV, легко фильтруемый. Хуже, чем BGP, зато любой шарманкой поддерживается, в отличие от, и сопровождать его несложно. Много анонсов слать не надо, одна сеть туда, одна обратно. Быстрая сходимость не требуется, резерва все равно нет, некуда перемаршрутизировать. Получается, вариантов нет, и особых недостатков подхода тоже».
          • 0
            Возможно и интересно, но есть заказчики, которые и пальцем шевелить не будут ради тебя одного и настраивать динамику. Т.е. с одним-двумя-десятком договориться можно. Когда заказчиком являешься ты, и сам говоришь настройки туннеля (и их немного) — тоже можно. Во всех остальных случаях чем проще, тем лучше

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное