RTFM && WTFN - backup

Необходимые знания по HA:

• Identify the concepts, benefits and operation of HA
  • HA features and characteristics
  • Deployment requirements and considerations
  • Сhassis cluster characteristics and operation
  • Cluster modes
  • Cluster and node IDs
  • Redundancy groups
  • Cluster interfaces
  • Real-time objects
  • State synchronization
  • Ethernet switching considerations
  • IPSec considerations
  • Manual failover
• Demonstrate knowledge of how to configure, monitor and troubleshoot clustering
  • Cluster preparation
  • Cluster configuration steps
  • Monitoring and troubleshooting

Два бренчевых srx можно объединить в кластер (High Availability Cluster aka HA) который обеспечивает:

• Работу control plane в режиме active-standby.
  Т.е. одновременно думать кластер может только одной нодой, в результате этого при фейловере перестартовывают протоколы маршртуизации (bgp, ospf).
• Работу data plane в active-active режиме.
  На каждой ноде одновременно могут работать разные reth и rsw интерфейсы.
• Полный фейловер tcp\udp сессий.
  После фейловера без разрыва будут работать nat, ipsec, alg и процессы связаные с аутентификацией.
• Синхронизацию конфигураций и сессий между нодами кластера.

• В кластере максимум может быть только два устроуства.
• Устроуства должны быть одной и той же модели.
• Должен стоять одинаковый софт.
• Набор модулей расширения должен быть одинаковым и они должны устоновлены стоять в одинаковые слоты.
• Ноды кластена должны быть соединены двумя линками.
  Желательно,что бы это были прямые соединения, но допускается соединение через коммуататоры.

Кластер состоит из следующийх составных частей:

• Cluster-id - номер ноды
• Redudancy groups (RG)
• Интерфейсы кластера:
  • fxp0 - выделенный порт для управления
  • fxp1 - интер
  • fab0/1 -
  • swfab -
  • reth -

Уникальный номер кластера который используется при формировании виртуального мак-адреса reth интрефейса.
До junos XXX cluster-id мог принимать значения от 1 до 15, после junos XXX от 1 до 255.
Это нужно для того, что в одном L2-сегменте\организации\датацентре могло одновременно работать несколько кластеров и их мак-адреса не пересекались.
Так же в формировании мак адреса участвует номер reth интерфейса (см. ниже).

root@srx-test> set chassis cluster cluster-id 15 node 0 reboot
Successfully enabled chassis cluster. Going to reboot now

Номер ноды в кластере, может быть 0 или 1.
Номер используется при формировании имени интерфейса.

Имя интерфейса в srx работающего не в кластере:
(media type)-(fpc slot #)/(pic slot #)/(port #) = ge-0/0/3

Имя интерфейсов srx работающих в кластере (на примере srx650):
node0: (media type)-(node-id*max_fpc_slot + fpc_slot_#)/(pic slot #)/(port #) = ge-0/0/3
node1: (media type)-(node-id*max_fpc_slot + fpc_slot_#)/(pic slot #)/(port #) = ge-9/0/3

RG это логическая группа объединяющая ресурсы srx. К ресурсам (элементам, объектам) относятся routing engine и интерфейсы.
RG и, соответственно, элементы входящие в неё могут быть активны только на одной ноде кластера, на второй ноде кластра они будут находится в резерве.
Номера RG могут принимать значения от 0 до 255.
RG0 зарезервирована, в нее всегда входят RE обоих нод.
RG[1..255] предназначены для размещения избыточных (redundant) интерфейсов. В одной RG максимум может быть 15 reth интерфейсов.
RG не заисят друг от друга, RG0 и RG2 может быть активной на node0, а RG1 активной на node1.

RG может находиться в трех состояниях:

• Blank - cтартовое состояние
• Primary - активное состояние
• Secondry - резервное состояние

RG может может переходить между этим состояниями в любых направлениях.

• RG находится в активном состоянии когда работает на ноде с более высоким приоритетом.
• По дефолту ноды имеют одинаковый приоритет для RG0, если хочется его можно поменять.
  Для всех остальных RG приоритет надо обязательно выставлять руками.
• Если обе ноды переключили в кластер одновременно, то node0 будет активной для RG0.
• Если ноды переключались в кластер не одновременно, то активной станет нода которая первой загрузится.
  Кластер не будет обращать внимание на приоритет ноды пока не будет дана команда preempt.
  Команду preempt можно дать только для RG[1..255].

Что бы RG[1..255] автоматически переключались между нодами кластера srx должен следить за наличием линка на интерфейсах входящих в RG.
Каждая RG имеет порогог срабатывания. В штатном состоянии этот порог имеет значение 255.
Каждому интерфейсу дается вес от 1 до 255, при падении линка на интерфейсе его вес вычитатется из порога, когда значение порога становится равным 0, происходит переключение между нодами.

chassis {                               
    cluster {                           
        reth-count 2;                   
        redundancy-group 0 {            
            node 0 priority 100;        
            node 1 priority 1;          
        }                               
        redundancy-group 1 {            
            node 0 priority 100;        
            node 1 priority 1;          
            interface-monitor {         
                fe-0/0/0 weight 255;    
                fe-1/0/0 weight 255;    
            }                           
        }                               
    }                                   
}  

Reth это логический интерфейс который объединяет по одному физическому интерфейсу с каждой ноды кластера. Физические интерфейсы должны быть одинакового типа (fe-, ge-, etc) но при этом могут находится в разных слотах.
Интерфейс reth будет активным пока есть линк хотя бы на одном физическом интерфейсе. Передавать и принимать трафик (если только не используется LAG) может только один из физический интерфейсов, второй интерфейс, который находится на secondary node, всегда в резерве.
У интерфейса reth есть виртуальны мак адрес который формируется с использованием cluster-id и номера reth интерфейса.

Пример:

{primary:node0}
admin@aer-12-srx3-n0> show interfaces reth0      
Physical interface: reth0, Enabled, Physical link is Up
  Interface index: 128, SNMP ifIndex: 544
  Link-level type: Ethernet, MTU: 1518, Speed: 100mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
  Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 0
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x0
  Current address: 00:10:db:ff:30:00, Hardware address: 00:10:db:ff:30:00
....

00:10:db:ff:30:00 - мак адрес от кластера в котором cluster-id максимум может быть 15, где:

• Первые 3 октета (1-24 бит) 00:10:db - MFG код указывающий на Juniper
• 4 октет (25-32 бит) ff - зарезервированное значение
• первая половина 5 октета (33-36 бит) 3 - номер cluster-id 3
• вторая половина 5 октета (37-40 ьит) 0 - зарезервированное значение
• 6 октет (41-48 бит) 00 - номер интерфейса reth0

Настройка reth0

interfaces {
    fe-0/0/0 {
        description aer-12-sw1/p44;
        fastether-options {
            redundant-parent reth0;     
        }                               
    }                                   
   gr-0/0/0 {                          
        unit 1 {     
...
   fe-1/0/0 {
        description aer-12-srx3/p30;
        fastether-options {
            redundant-parent reth0;
        }
    }
...
    reth0 {
        vlan-tagging;
        redundant-ether-options {
            redundancy-group 1;
        }
        unit 166 {                      
            description ROUTER-LINKNET1;
            vlan-id 166;
            family inet {
....

Спец интерфейс для управления нодами кластера, т.н. out-of-bound management
В брaнчевых srx под fxp0 зарезервирован один из имеющихся интерфейсов, для каждой можели свой, для srx650 0/0 (ge-0/0/0). В srx уровня дата-цент сразу есть fxp0.

Настройка интерфейсов fxp0:

groups {
    node0 {
        system {
            host-name aer-12-srx3-n0;
        }
        interfaces {
            fxp0 {
                description port0/6_to_aer-12-ilo/p16;
                unit 0 {
                    family inet {
                        address 10.10.160.26/24;
                    }
                }
            }
        }
    }
    node1 {
        system {
            host-name aer-12-srx3-n1;
        }
        interfaces {
            fxp0 {
                description port0/6_to_aer-12-sw5/p29;
                unit 0 {
                    family inet {
                        address 10.10.160.27/24;
                    }
                }
            }
        }
    }
}

Надо быть внимательным с маршрутизацией до сети 10.10.160.0/24 т.к. если кто-то, например, захочет пройти к 10.10.160.2 через aer-12-srx3, то в сторону этой машины он пройдет именно через интерфейс fxp0.
А вот обратый трафик уже может и не дойти т.к. не факт на 10.10.160.2 есть обратный маршрут ну и fxp0 мы не определяем в зоны безопасности. Заверуть обратный трафик через fxp0 никогда не пробовал.

Маршрут до сети 10.10.160.0/24 на primary ноде:

{primary:node0}
admin@aer-12-srx3-n0> show route 10.10.160.1 

inet.0: 582 destinations, 625 routes (582 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.160.0/24   *[Direct/0] 21w0d 11:53:31
                    > via fxp0.0

На secondary ноде будет что-то типо “Routing subsystem not started”, точной формулировки не помню.

Интерфейс fxp1 используется для подключения т.н. control-link, на обоих нодах интерфейст называется одинаково.
На хайенд srx под контол линк предсмотренно два выделенных порта (по состоянию на 2012 год софт позволяет использовать только один порт). Надо подключаться в Port0 если RE стоит слоте 0 и в порт Port1 если RE стоит в слоте 1. Расположение порта надо отдельно указать в конфиге.
На бранчевых srx под контрол линк зарезервировани один из имеющихся интерфейсов. на srx650 это 0/1 (ge-0/0/1 и ge-9/0/1). Интерфейс fxp1 появляется после перевода srx в кластерный режим и перезагрузки.

Интерфейсам fxp1 srx назначает адреса из зарезервированных областей:

• srx650 node0 - Destination: 128/2, Local: 129.16.0.1, Broadcast: 191.255.255.255
• srx100 node0 - Destination: 128/2, Local: 129.48.0.1, Broadcast: 191.255.255.255

Через контрол линк работает проприетарый протокол TNP который используется для синхронизации конфигураций, состояний сессий, контроля достуности соседней ноды

TNT—Trivial Network Protocol. This Juniper Networks proprietary protocol provides communication between the >Routing Engine and the device's packet forwarding components.

Если число потерь hearbeat пакетов достигло порога или просто пропал линк на порту fxp1, но при этом порты fab0/1 работают номально, то нода которая данный момент является secondary для RG0 пеходит в режим disabled. А все отальные RG переходят на primary ноду.

Что бы secondary ноду вернуть в кластер её надо перегрузить. Можно настроить автоматическую перезагрузку disabled ноды командой control-link-recover на уровне [edit chassis cluster].
Идея с автоматической перезагрузкой ноды мне никогда не нравилась, не делал.

Интерфейс fxp1 на srx100:

admin@aer-12-srx3-n0> show interfaces fxp1              
Physical interface: fxp1, Enabled, Physical link is Up
  Interface index: 2, SNMP ifIndex: 2
  Type: Ethernet, Link-level type: Ethernet, MTU: 1514
  Device flags   : Present Running
  Link flags     : None
  Current address: 64:64:9b:e1:73:47, Hardware address: 64:64:9b:e1:73:47
  Last flapped   : Never
    Input packets : 924478893 
    Output packets: 1315038536

  Logical interface fxp1.0 (Index 4) (SNMP ifIndex 14) 
    Flags: SNMP-Traps Encapsulation: ENET2
    Input packets : 924478893 
    Output packets: 921265218
    Protocol inet, MTU: 1500
      Flags: Is-Primary
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 128/2, Local: 129.48.0.1, Broadcast: 191.255.255.255
    Protocol tnp, MTU: 1500
      Flags: Is-Primary
      Addresses
        Local: 0x1300001

Тезисно:

• Используются для соединения data plane обоих нод кластера
• fab0@node0, fab1@node1
• Должны быть одинакового типа - fe-, ge- и т.д.
• Через fab0\1 происходит синхронизация сессий, а так же может бегать трафик когда data plane работает в active/active режиме.
  Разобраться чем отличается session synchronization (fab) от session state (fxp1)
• Если падает data-link, то secondary нода переходит в режим disabled (как fxp1), но вернуть к жизни ноду можно только перезагрузкой.
• fab не определяется в зоны → не поддерживает политики безопасности, нет фильтров.
• Поддерживает джамбо фреймы (до 8980 байт), не поддерживает фрагментацию.
• В отличии от fxp1 можно самому определить интерфейсы которые будут fab0\1.

Вставить вывод show interface fab0 + определение физики под fab

Тезисно:

• Два интерфейса, по одному на каждой ноде
  Уточнить
• Передача только L2 трафика.
• swfab0@node0, swfab1@node1.
• Используются интерфейсы подерживающие Ethernet switching.
• Ноды кластера должны быть соединены напрямую кабелем, через коммутаторы нельзя.
• Точно так же мониторится состочние линка, но при падении кластер не разваливается.
  При падении swfab на каждой образуется свой L2 домен.
• Не поддерживаются фильтры, политики, логические интерфейсы.
• Поддерживаются джамбо фреймы, размер такой же как на интерфейсах которые опредены в “srx-коммутатор”.

TODO
Разобраться с тем можно к портам “srx-коммутатора” привязать L3-интерфейс vlan.XXX.
Можно ли его определять в RG и как он себя поведет при обрыве swfab.

Можно нарастить количество физических интерфейсов (до двух) которые используются для организации fab и swfab линков.

Тезисно:

• Интерфейсы должны быть одинаковыми.
• Поддерживается балансировка:
  • fab - по одному линку (который имеет наименьший номер) пределается RTO и heartbeat (или fabric probes??), по второму трафик data plane при работе в активном режиме.
  • swfab - L2 трафик балансируется между обоими линками.
• Через оба линка передаются fabric probes.
  При отсутстии fabric probes на одном из линков хайенд srx через 6 секунд поймет, что линк упал, а бранчевый srx поймет через 20 секунд.
  Восстанавливается линк с задержной в 30 секунд.

RTO (real time object) - через rto синхронизируются сессии.

Только хайенд srx (srx5000, srx3000, srx1400) поддерживают второй контрол линк.
Линки не балансируются, работает только один.

Под контлол линки можно взять 10 и 11 порты SYSIO кaрты (базовая карта с медными и оптичесими портами вкл консольный порт).

Что бы получить второй порт под контрол линк нужен SCM (SRX Clustering Module).
SCM вставляется слот RE, но не выполяет функции RE.

Мутно, нужно две SCB карты в которые будут вставлены RE, при этом второй RE не будет работать как RE.
Второй RE нужен что бы на второй SCB был физический порт который можно отдать под контрол линк.

RTO (real time objects) это специальные пакеты которые предаются между нодами через data link и содержат в себе информацию о состоянии и количестве сессий. Через RTO сессии синхронизируются между нодами и в случае падения основной ноды сессии уже бубут на второй ноде и трафик пойдет.
Основое назначение rto → consistncy and stability session.