Trước khi bắt đầu cấu hình cluster, hãy xóa hết cấu hình hiện có để tránh lỗi phát sinh  trong quá trình cấu hình cluster. Trong mỗi thiết bị srx thực hiện các bước sau:

Đầu tiên, hãy xóa tất cả các logical interface dùng cho control link/plane(ge-0/0/1) & Data/fabric link/plane(ge-0/0/2). 

***Note: Control link và Data link khác nhau ở mỗi model SRX

delete system host-namedelete vlans delete interfaces vlan delete security delete interfaces ge-0/0/1 delete interfaces ge-0/0/2 delete interfaces ge-0/0/3 unit 0 family ethernet-switching delete interfaces ge-0/0/4 unit 0 family ethernet-switching

Sau khi xoá kiểm tra và chắc chắn rằng  không còn ethernet-switching nào 

root@srx1# show | match ethernet-switching | count
Count: 0 lines
[edit]
root@srx1#

Sau đó, kết nối vật lý hai thiết bị và đảm bảo rằng chúng là cùng một loại. 

Ví dụ, trên SRX340 kết nối cổng control ports trên node 0 và node 1.

***Lưu ý: Đối với các thiết bị SRX300, SRX320, SRX340 và SRX345, hãy kết nối ge-0/0/1 trên node 0 với ge-0/0/1 trên node 1.

1. Cấu hinh hai thiết bị ở chế độ cluster và khởi động lại. Việc cấu hình được thực hiện trên cả hai thiết bị

On node 0:
---------------
user@host> set chassis cluster cluster-id 1 node 0 reboot

On node 1:
---------------
user@host> set chassis cluster cluster-id 1 node 1 reboot

Sau khi khởi động lại kiểm tra tại dấu nhắc của srx1 node0, bạn sẽ thấy dấu nhắc thay đổi như bên dưới: 

{hold:node0}
root@srx1>
{secondary:node0}
root@srx1>
{primary:node0}
root@srx1>

Kiểm tra tình trạng cluster

root@srx1> show chassis cluster status
Cluster ID: 1
Node                  Priority          Status    Preempt  Manual failover

Redundancy group: 0 , Failover count: 1
    node0                   1           primary        no       no
    node1                   1           secondary      no       no

Sau khi cluster được thiết lập, đối với thiết bị SRX340 interface ge-0/0/1 trên node 1 sẽ chuyển thành ge-5/0/1.

 2. Cấu hình tên thiết bị và địa chỉ IP quản lý cho mỗi thiết bị, việc cấu hình chỉ thực hiện trên node đầu tiên (srx-node0)

set groups node0 system host-name srx-nd0
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.33.1/24
set groups node1 system host-name srx-nd1
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.33.2/24

3. Cấu hình ‘apply-groups’

set apply-groups "${node}"

4. Định nghĩa các interfaces được sử dụng cho kết nối fab (data plane links for RTO sync) bằng cách sử dụng các interfaces ge-0/0/2 từ mỗi node. Việc cấu hình các liên kết fabric chỉ thực hiện trên node đầu tiên (srx-node0)

set interfaces fab0 fabric-options member-interfaces  ge-0/0/2
set interfaces fab1 fabric-options member-interfaces  ge-5/0/2

# Sau khi commit, cấu hình cũng sẽ đồng bộ vào node srx-node1. Bây giờ hãy kiểm tra cluster interfaces status 

root@srx1> show chassis cluster interfaces
Control link 0 name: fxp1
Control link status: Up

Fabric interfaces:
Name    Child-interface    Status
fab0       fe-0/0/5          up
fab0
fab1       fe-2/0/5          up
fab1
Fabric link status: Up

5. Thiết lập redundancy group 0 cho Routing Engine failover properties và thiết lập redundancy group 1  cho tất cả các interfaces. Một cluster không có redundancy group là vô dụng.  RG0 được sử dụng cho control plane và RG1 sẽ là RG dịch vụ.

set chassis cluster reth-count 2
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100

6. Thiết lập interface monitoring để giám sát tình trạng của các interface và kích hoạt redundancy group failover . 

****** Lưu ý: Juniper không khuyến nghị interface monitoring  cho redundancy group 0 vì nó khiến control plane chuyển từ node này sang node khác trong trường hợp xảy ra lỗi interface.

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-5/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-5/0/4 weight 255

#Hãy kiểm tra cluster configuration

{primary:node0}
root@SRX> show configuration chassis cluster

reth-count 2;
redundancy-group 0 {
    node 0 priority 200;
    node 1 priority 100;
}
redundancy-group 1 {
    node 0 priority 200;
    node 1 priority 100;
    preempt;
    interface-monitor {
        ge-0/0/3 weight 255;
        ge-0/0/4 weight 255;
        ge-5/0/3 weight 255;
        ge-5/0/4 weight 255;
    }
}

7. Thiết lập các redundant ethernet (reth) và chỉ định redundant interface cho 1 zone.

set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-5/0/3 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 198.51.100.1/24

set interfaces  ge-0/0/4 gigether-options redundant-parent reth1
set interfaces  ge-5/0/4 gigether-options redundant-parent reth1
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 203.0.113.233/24 

set security zones security-zone Trusted
set security zones security-zone Untrusted
set security zones security-zone Trusted host-inbound-traffic system-services all
set security zones security-zone Untrusted host-inbound-traffic system-services all
set security zones security-zone Untrust interfaces reth1.0
set security zones security-zone Trust interfaces reth0.0

#Nếu bạn muốn tạo một subinterface với vlan tagging, hãy làm như sau

set interfaces reth0 vlan-tagging
set interfaces reth0 unit 150 vlan-id 150
set interfaces reth0 unit 150 family inet address 192.168.150.200/24
set interfaces reth1 unit 0 family inet address 10.16.9.1/24

set security zones security-zone Trusted interfaces reth0.150
set security zones security-zone Untrusted interfaces reth1.0

Các lệnh kiểm tra và xác minh cấu hình 

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

show configuration

root@srx# run show configuration
## Last commit: 2017-08-07 16:41:31 GMT+6 by root
version 15.1X49-D90.7;
groups {
    node0 {
        system {
            host-name srx-nd0;
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 192.168.33.1/24;
                    }
                }
            }
        }
    }
    node1 {
        system {
            host-name srx-nd1;
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 192.168.33.2/24;
                    }
                }
            }
        }
    }
}
apply-groups "${node}";
system {
    auto-snapshot;
    time-zone GMT+6;
    root-authentication {
        encrypted-password "$5$ZsCeZsruXu$TZ8Kvvzb/mxQOMqf8AxJkFqW.r5OZFnrdagxRl8LSH."; ## SECRET-DATA
 
    }
    services {
        ssh;
        telnet;

        }
    }
 
}
chassis {
    cluster {
        reth-count 2;
        redundancy-group 0 {
            node 0 priority 200;
            node 1 priority 100;
        }
        redundancy-group 1 {
            node 0 priority 200;
            node 1 priority 100;
            preempt;
            interface-monitor {
                ge-0/0/3 weight 255;
                ge-0/0/4 weight 255;
                ge-5/0/3 weight 255;
                ge-5/0/4 weight 255;
            }
        }
    }
}
security {
    screen {
        ids-option untrust-screen {
            icmp {
                ping-death;
            }
            ip {
                source-route-option;
                tear-drop;
            }
            tcp {
                syn-flood {
                    alarm-threshold 1024;
                    attack-threshold 200;
                    source-threshold 1024;
                    destination-threshold 2048;
                    timeout 20;
                }
                land;
            }
        }
    }
    nat {
        source {
            rule-set nsw_srcnat {
                from zone Internal;
                to zone Internet;
                rule nsw-src-interface {
                    match {
                        source-address 0.0.0.0/0;
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
    policies {
        from-zone Internal to-zone Internet {
            policy All_Internal_Internet {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone Internal;
        security-zone Internet {
            screen untrust-screen;
        }
        security-zone Trusted {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
            interfaces {
                reth0.0;
            }
        }
        security-zone Untrusted {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
            interfaces {
                reth1.0;
            }
        }
    }
}
interfaces {
    ge-0/0/3 {
        gigether-options {
            redundant-parent reth0;
        }
    }
    ge-0/0/4 {
        gigether-options {
            redundant-parent reth1;
        }
    }
    ge-5/0/3 {
        gigether-options {
            redundant-parent reth0;
        }
    }
    ge-5/0/4 {
        gigether-options {
            redundant-parent reth1;
        }
    }
    fab0 {
        fabric-options {
            member-interfaces {
                ge-0/0/2;
            }
        }
    }
    fab1 {
        fabric-options {
            member-interfaces {
                ge-5/0/2;
            }
        }
    }
    fxp0 {
        unit 0 {
            family inet;
        }
    }
    reth0 {
   
        redundant-ether-options {
            redundancy-group 1;
        }
        unit 0 {
            family inet {
                address 198.51.100.1/24;
            }
        }
    }
    reth1 {
        redundant-ether-options {
            redundancy-group 1;
        }
        unit 0 {
            family inet {
                address 203.0.113.233/24;
            }

Đã có rất nhiều nhầm lẫn về việc làm thế nào để kết nối 2 switch chạy  virtual chassis với SRX cluster. mọi người thường  thêm nhiều interface vật lý và tạo ra nhiều interface RETH trên SRX sau đó gán các chức năng khác nhau cho mỗi interface RETH.

Phương pháp này không có khả năng mở rộng cao và sau một thời gian, các bạn sẽ gặp phải một mớ hỗn độn không thể quản lý được.

Cá nhân tôi thích tạo một interface RETH duy nhất với nhiều sub interface, mỗi interface tương ứng với L2 VLAN trên switch. 

Đối với các trường hợp không yêu cầu đặc biệt tôi thường chọn cơ chế Active/Passive cho SRX Cluster. Theo kinh nghiệm của tôi Active / Active không hoạt động tốt trong SRX Chassis Cluster. Nó cũng gây khó khăn trong việc quản lý và vận hành. Không có lợi ích thực sự trong cơ chế Active / Active và gây ra các vấn đề nghiêm trọng trong thiết bị được sử dụng với lượng traffic cao. Tùy chọn khác của tôi là sử dụng SRX làm “Router on a Stick ” –  Các switch chạy ở L2 và thực hiện tất cả L3/Routing/Security trên SRX.

SRX là thiết bị cực kỳ mạnh mẽ sử dụng nó theo cách này mang lại khả năng bảo mật, theo dõi phiên, định tuyến và kiểm soát tốt hơn. Thiết kế này cũng sẽ hoạt động tốt khi giảm tải các chức năng định tuyến cho switch L3.

Ví dụ bên dưới hai liên kết hoạt động trên mỗi switch vật lý, nhưng có thể mở rộng dễ dàng. Việc thêm nhiều liên kết vật lý để tăng dung lượng thực sự rất dễ và nó không ảnh hưởng đến cấu hình thực tế. Thiết kế tương tự có thể được sử dụng với nhiều switch, miễn là chúng là số chẵn

Phía SRX có 8 liên kết được kết nối với Cluster, 4 liên kết với mỗi thiết bị. Mỗi thành viên kết nối với Interface Aggregated khác nhau trên switch (ae0 – node0, ae1 – node1), nhưng chỉ một ae / node sẽ hoạt động tại một thời điểm (đây là cách hoạt động của cụm Chassis).

Phía EX: ae0 bao gồm 8 liên kết vật lý trên mỗi VC (4 cho mỗi thành viên). Mỗi thành viên có 2 Interface trong ae0 và 2 trong ae1. 

Như bạn có thể thấy trong sơ đồ, lỗi của 1 thành viên EX hoặc / và 1SRX sẽ không làm gián đoạn lưu lượng và 2 đường trục liên kết sẽ   được duy trì. Tăng lên 3 trung kế liên kết sẽ yêu cầu thêm liên kết vào mỗi nhóm.

Configuration

1. SRX

Interface reth1 được gán cho RE1. Tôi sử dụng weight=100, vì vậy việc chuyển đổi dự phòng (failover) có thể do lỗi của 3 liên kết trở lên. Chúng tôi muốn ngăn ngừa lỗi VC gây ra failover Chassis Cluster RE, vì các thiết bị được nối cáp đồng bộ.

> show configuration chassis cluster
control-link-recovery;
reth-count 3;
redundancy-group 0 {
    node 0 priority 100;
    node 1 priority 1;
}
/* To Core Switch */
redundancy-group 1 {
    node 1 priority 1;
    node 0 priority 100;
    preempt;
    inactive: hold-down-interval 180;
    interface-monitor {
        ge-0/0/4 weight 100;
        ge-0/0/5 weight 100;
        ge-0/0/6 weight 100;
        ge-0/0/7 weight 100;
        ge-5/0/4 weight 100;
        ge-5/0/5 weight 100;
        ge-5/0/6 weight 100;
        ge-5/0/7 weight 100;
    }
}

Sau đó, tôi sử dụng subinterface để gán IP cho mỗi VLAN. Mỗi subineterface sau đó được gán cho security zone, routered, etc. 

> show configuration interfaces reth0
vlan-tagging;
redundant-ether-options {
    redundancy-group 1;
}
unit 1 {
    vlan-id 1;
    family inet {
        address 10.0.0.1/26;
    }
}
unit 2 {
    vlan-id 2;
        address 10.0.0.65/26;
    }
}
unit 3 {
    vlan-id 3;
    family inet {
        address 10.0.0.129/25;
    }
} 

Physical Interfaces:

ge-0/0/4 {
    description "Link to EX-01 ae0:ge-0/0/46";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-0/0/5 {
    description "Link to EX-01 ae0:ge-1/0/47";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-0/0/6 {
    description "Link to EX-01 ae0:ge-0/0/44";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-0/0/7 {
    description "Link to EX-01 ae0:ge-1/0/45";
    gigether-options {
        redundant-parent reth1;
    }
}



ge-5/0/4 {
    description "Link to EX-01 ae1:ge-1/0/46";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-5/0/5 {
    description "Link to EX-01 ae1:ge-0/0/47";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-5/0/6 {
    description "Link to EX-01 ae1:ge-0/0/45";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-5/0/7 {
    description "Link to EX-01 ae1:ge-1/0/44";
    gigether-options {
        redundant-parent reth1;
    }
}
 

2. EX Virtual Chassis

Configuration is as simple as creating VLANs and assigning the phyiscal inerfaces to ae as per diagram above:

ae0 {
    description "links to SRX-01 node0";
    aggregated-ether-options {
        minimum-links 2;
        link-speed 1g;
        }
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members all;
            }
        }
    }
}
ae1 {
    description "links to SRX-01 node1";
    aggregated-ether-options {
        minimum-links 1;
        link-speed 1g;
    }
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members all;
            }
        }
    }
}


ge-0/0/44 {
    description "ae0:Link to SRX-01 ge-0/0/6";
    ether-options {
        802.3ad ae0;
    }
}
ge-0/0/45 {
    description "ae1:Link to SRX-01 ge-5/0/7";
    ether-options {
        802.3ad ae1;
    }
}
ge-0/0/46 {
    description "ae0:Link to SRX-01 ge-0/0/4";
    ether-options {
        802.3ad ae0;
    }
}
ge-0/0/47 {
    description "ae1:Link to SRX-01 ge-5/0/5";
    ether-options {
        802.3ad ae1;
    }
}


ge-1/0/44 {
    description "ae1:Link to SRX-01 ge-5/0/6";
    ether-options {
        802.3ad ae1;
    }
}
ge-1/0/45 {
    description "ae0:Link to SRX-01 ge-0/0/7";
    ether-options {
        802.3ad ae0;
    }
}
ge-1/0/46 {
    description "ae1:Link to SRX-01 ge-5/0/4";
    ether-options {
        802.3ad ae1;
    }
}
ge-1/0/47 {
    description "ae0:Link to SRX-01 ge-0/0/5";
    ether-options {
        802.3ad ae0;
    }
}

>show security ike security-associations 1.1.1.1 detail
>show security ike security-associations inactive
>show security ike active-peer
>show security ipsec security-associations vpn-name my_vpn
>show security ipsec security-associations vpn-name my_vpn traffic-selector t1
>show security ipsec inactive-tunnels
>show security ipsec statistics
>show interfaces st0.0 extensive

>show security flow session interface st0.0

>request security ike debug-enable local 173.167.224.13 remote 99.182.0.14 level 15

level 15 is a hidden command

>show security ike debug-status
>show log kmd

The below can narrow the output

>sh>show log kmd | match "ike|initiator|responder" 
>request security ike debug-disable

To troubleshoot inactive VPN 

>sh>show log kmd# set system syslog file kmd-logs daemon info
# set system syslog file kmd-logs match KMD
# commit

> show log kmd-logs | match peer_IP

To show number of packets through the tunnel use the command below. Narrow done by using “index”. As in the example below, a lot of packets are encrypted, but nothing back from neighbor:

srxA-2> show security ipsec security-associations          
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131073 ESP:3des/sha1 e9618669 664/  unlim   -   root 500   192.168.11.1    
  >131073 ESP:3des/sha1 eda114c0 664/  unlim   -   root 500   192.168.11.1    

srxA-2> show security ipsec statistics index 131073  
ESP Statistics:
  Encrypted bytes:            15368
  Decrypted bytes:                0
  Encrypted packets:            113
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Reading the Logs:

Phase 1:
The following is an example from Kmd Log.   The most recent message is listed at the bottom. The above steps may display IKE Phase 2 and/or Phase 1 messages as below.   

Successful VPN connection:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2)

Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

Failing due to phase 1 proposal mismatch:

Phase-1 [responder] failed with error(No proposal chosen) for local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 011359c9 ddef501d – 2216ed2a bfc50f5f [-1] / 0x00000000 } IP; Error = No proposal chosen (14)

Resolution: Confirm that all phase 1 proposal elements match exactly on both peers. Confirm external interface is correct.

Failing due to unrecognized peer:

Unable to find phase-1 policy as remote peer:2.2.2.2 is not recognized.KMD_PM_P1_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-1 [responder] failed for p1_local=ipv4(any:0,[0..3]=1.1.1.2) p1_remote=ipv4(any:0,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 18983055 dbe1d0af – a4d6d829 f9ed3bba [-1] / 0x00000000 } IP; Error = No proposal chosen (14)

Resolution: Confirm peer ID type is correct (IP address, hostname, or user@hostname). Once peer ID type is confirmed then also confirm the ID itself is correct.

Failing due to pre-shared key mismatch:

1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { e9211eb9 b59d543c – 766a826d bd1d5ca1 [-1] / 0x00000000 } IP; Invalid next payload type = 17 Phase-1 [responder] failed with error(Invalid payload type) for local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)

Resolution: Re-enter pre-shared key on both peers to ensure that they match.

Failing due to phase 2 proposal mismatch:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 – 6b0d3933 f0bc8e26 [0] / 0x1747248b } QM; Error = No proposal chosen (14)

Resolution: Confirm all phase 2 elements match exactly on both peers. Confirm tunnel policy exists.

Failing due to phase 2 proxy ID mismatch:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2) Failed to match the peer proxy ids p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)KMD_PM_P2_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-2 [responder] failed for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 41f638eb cc22bbfe – 43fd0e85 b4f619d5 [0] / 0xc77fafcf } QM; Error = No proposal chosen (14).

Resolution: Confirm that tunnel policy has correct address book entries as well as application or service. Check to see if manual proxy-id configured on gateway.

If there are no messages; make sure the correct IP address was used.   It is also possible that the Kmd Log filled up with other messages, so try to ping across the tunnel in order to attempt to bring the VPN up again.  If there are still no messages, refer to KB10100- How to Troubleshoot a Site-to-Site VPN Tunnel that wont come up.

Phase 2:
Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

Where 2.2.2.2 is the IP address of the remote firewall in question.  

•  Yes – See KB10093 – How to Troubleshoot a Site-to-Site VPN that is up, but, is not Passing Traffic 
• No   – Continue with Step

The most common Phase 2 errors are:

Message: 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 – 6b0d3933 f0bc8e26 [0] / 0x1747248b } QM; Error = No proposal chosen (14)

Meaning:  The JUNOS device did not accept any of the IKE Phase 2 proposals that the specified IKE peer sent.

Action: Check the local VPN configuration. Either change the local configuration to accept at least one of the remote peer’s Phase 2 proposals, or contact the remote peer’s admin and arrange for the IKE configurations at both ends of the tunnel to use at least one mutually acceptable Phase 2 proposal. 

For assistance, see KB10123 – Received Message: Error = No proposal chosen (14).            

Message: Failed to match the peer proxy ids p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)

Meaning:  No policy found matching the specified attributes

Action: The proxy-id must be an exact “reverse” match.  For example, the address book entries must have the same number of netmask bits, the list of services must match as well as the port numbers.  If any of these fields don’t match, the Phase 2 will fail.  Check the address and/or service book entries. 

SRX chassis cluster bundles two devices together to provide high-availability. The cluster nodes must be the same model, have the cards placed in the same slots and must run the same software version. In addition at least two interconnect links must be present (one control and one fabric link). In newer releases the SRX supports dual fabric (high-end and branch SRXs) and dual control links (high-end SRXs only). The ports used for fabric link are defined through configuration. The definition of the ports for the control link on the other hand is not so flexible. The high-end SRXs (1000 and 3000 series) have dedicated ports for that and the 5000 series uses the ports on the SPC cards. On the branch SRX devices revenue ports (fixed ones) are converted to control ports.

Hardware preparation (card placement and cabling) is the initial task for creating the cluster. (The following link contains helpful information about cluster interconnections: http://www.juniper.net/techpubs/en_US/junos12.2/topics/task/operational/chassis-cluster-srx-series-hardware-connecting.html) The next step is to enable clustering on the  devices. On branch device the configuration must NOT contain any configuration of the interfaces that will be converted to control links for cluster to form correctly. The following commands provide an easy way to get rid of any potential dangerous configuration

• delete interfaces
• delete security
• delete system host-name (leaving the host-name collides with the group configuration)

Continue reading “Troubleshooting SRX chassis cluster”

Managing configuration

>configure exclusive – Ngăn người khác sửa đổi trong khi ở chế độ cấu hình

#status –  Hiển thị người dùng hiện đang đăng nhập

#compare (filename | rollback n)

#commit | display detail – debug commit

#commit check

#commit comment

#commit confirmed

#commit at  [tt:mm | yyyy-mm-dd hh:mm | reboot], to cancel:

>clear system [commit | reboot ]

>show system commit

>show configuration

#load {set}  {merge | replace | override } {relative} [terminal | file] – paste – Ctrl+D to end

# show |   # compare (filename | rollback n)

# show |  display set

# show |  display changed

# show |  display detail

# show |  display omit statement

Configuration modification commands:

#annotate “xxxxx” – Chú thích cấu hình

#activate/deactivate

#copy / delete / rename – works with wildcards, e.g. delete fe*

#rename – string in configuration

#replace pattern

#protect / unprotect a statement

#exit configuration-mode

#quit

>show system rollback 10

>show system rollback compare 10 12

>show system commit

System

>show version {detail}

>request system reboot | power-off

>file [copy | list | delete | show | rename ]

>show system storage

>show chassis hardware detail

>show chassis alarms

>show chassis environment

>show chassis craft-interface – show router LED alarms

>show configuration | display detail

>show system users – ai đã đăng nhập vào hệ thống

>request system logout use username – forcefully logout a user

>request message all message “log out now”

>show system boot-messages – boot log

Interfaces/Hardware:

Hiển thị thông tin về bộ nhớ, nhiệt độ CPU, tải và thời gian hoạt động:

>show chassis routing engine 

Để xem phần cứng và SFP
Tổng quan về phần cứng
> show chassis hardware

fpc nào đang sử dụng
> show chassis fpc

Để hiển thị những chi tiết pic được lắp đặt trong một slot:
> show chassis pic pic-slot 0 fpc-slot 0

Xem công suất của fibre interface:
> show interfaces diagnostics optics

Logging

#set system syslog file messages any info à để lưu tất cả các logs vào tập tin

>show log messages | match LOGIN | match “Mar 16”

>file list detail /var/log = ls –al (to see permitions, etc.)

>clear log messages  – Để xoá nội dung tập tin Logs

>monitor start       messages  à Giám sát trực tiếp

>monitor list

>monitor stop à Stop giám sát

For more detailed information about a process, under the process level:

#set traceoptions file filenamefil world-readable

#set traceoptions flag all

>help syslog à Hiển thị thông tin logs hệ thống

Security Policies

View security policy:

> show security policies from-zone Proxy-DMZ to-zone Inside details

To check if traffic will pass through the security policies (useful when not able to generate traffic):

> show security match-policies from-zone Outside to-zone Inside protocol  xxx source-ip xxx source-port xxx destination-ip   xxx  destination-port xxxx

General Monitoring and troubleshooting

>monitor traffic interface ge-0/0/0

>monitor interface ge-0/0/0

>monitor traffic interface ge-0/2/3 matching “proto 89” write-file ospf.cap – matches proto 89 and writes it in ospf.cap

>show security flow session … options

>show system statistics – all packet types statistics for a device

>test policy             

Routing

>show route 
>show route terse – nice concise output with the following information: A-active, Destination, P-protocol, Prf-preference, Metric1,2 Next-hop, AS Patch)
>show route protocol [static|direct|ospf]
>show route forwarding-table to see active routes in the forwarding table

Troubleshoot OSPF

>show route forwarding-table à to see active routes in the forwarding table

>show route protocol ospf

>show ospf overview

>show ospf interaces

>show ospf neighbor

>show ospf dataset detail

>show ospf neighbor [extensive]

>clear ospf neighbor [192.168.254.225]

>show ospf statistics
>show ospf interface [extensive]
>show ospf route [abr|asbr|extern]
>show route protocol ospf 
 
>show ospf database [summary|brief]
>show ospf database [router|network|netsummary|asbrsummary|extern|nssa]
>show ospf database router advertising-router 10.0.3.3 detail
>show ospf database router area 0 extensive 
>show ospf database area 0 lsa-id extensive
>clear ospf database purge

>show ospf log

Troubleshoot NAT

+ Source

>show security nat source summary

>show security nat source rule

>show security nat source pool

+ Static

>show security nat static rule

+ Destination

>show security nat destination summary

>show security nat destination pool

>show security nat destination rule

>show security flow session

Firewall

>show firewall
>show firewall log
>clear firewall [all|filter-name|counter-name]
>show interfaces filters
>show interfaces policers
>show policer

******

Set Firewall Filter to count packets through the SRX:

# show interfaces ge-0/0/0

ge-0/0/0 {

   unit 0 {

      family inet {

         filter {

            input icmp-filter;

         }

         address 1.1.1.1/30; ## This address was already set on the interface

      }

   }

}

# show firewall family inet filter icmp-filter

icmp-filter {

   term 1 { ## This is the main term which will count the packets.

      from {

         source-address 3.3.3.3;

         destination-address 1.1.1.1;

         protocol icmp;

      }

      then {

         count icmp-counter; ## The icmp-counter will show the bytes/packets incrementing

         accept; ## This will accept the packets if you don’t want them to be dropped. You can use – “drop” or “reject” and/or “log” here.

      }

   }

— JUNOS 11.4R10.3 built 2013-11-15 06:56:20 UTC
{primary:node0}
root@FIREWALL-PRI-SRX240> 

root@FIREWALL-PRI-SRX240> request routing-engine login node 1
€
— JUNOS 11.4R10.3 built 2013-11-15 06:56:20 UTC
{secondary:node1}
root@FIREWALL-PRI-SRX240>

Please note that this describes the process to upgrade an HA pair at JunOS code pre-11. Newer versions of the JunOS code allow for upgrading without corrupting the policy of the peer devices.

!! Note: interface names are the physical and not logical names
!! The following assumes node0 is master and node1 is backup
01.) download package to /var/tmp on both devices
02.) Disable node1\'s interfaces by running the following on node0. Commit will replicate to node1
  set interfaces ge-8/0/0 disable        [-- Should be node1's interfaces, NOT node0's
  set interfaces ge-8/0/1 disable
  set interfaces ge-8/0/2 disable
  set interfaces ge-8/0/3 disable
  set interfaces ge-8/0/4 disable
  set interfaces ge-8/0/5 disable
  set interfaces ge-8/0/6 disable
  set interfaces ge-8/0/7 disable
  set interfaces ge-8/0/8 disable
03.) Disable requiring three way handshake for session on node 0 (primary)
  set security flow tcp-session no-syn-check
  set security flow tcp-session no-sequence-check
04.) Save on node 0 (primary)
  commit
05.) Disconnect the fiber link (fab# interfaces) and the control interface cables
06.) Commit on both devices
07.) Upgrade node 1 (Backup)
  request system software add /var/tmp/junos-srx1k3k-10.4R3.4-domestic.tgz no-validate no-copy
  request system reboot
08.) Perform the following on node 1 (currently backup and now newly upgraded) to verify
  show version
  show chassis cluster status
  show chassis fpc pic-status
09.) After running "show chassis fpc pic-status," wait for the slots to come online, not Present before going to step 10
10.) Node 0 then Node 1, perform ALL the following commands
  delete interfaces ge-8/0/0 disable
  delete interfaces ge-8/0/1 disable
  delete interfaces ge-8/0/2 disable
  delete interfaces ge-8/0/3 disable
  delete interfaces ge-8/0/4 disable
  delete interfaces ge-8/0/5 disable
  delete interfaces ge-8/0/6 disable
  delete interfaces ge-8/0/7 disable
  delete interfaces ge-8/0/8 disable
  set interfaces ge-0/0/0 disable
  set interfaces ge-0/0/1 disable
  set interfaces ge-0/0/2 disable
  set interfaces ge-0/0/3 disable
  set interfaces ge-0/0/4 disable
  set interfaces ge-0/0/5 disable
  set interfaces ge-0/0/6 disable
  set interfaces ge-0/0/7 disable
  set interfaces ge-0/0/8 disable
11.) Save on both devices at same time  !! IMPORTANT TO BE DONE AT THE SAME TIME !!
  commit
12.) Verify that node1 has correctly taken over as master (if input increasing on monitor command, it has taken over)
  show security flow session summary
  run monitor interface traffic
13.) On node 0:
  request system software add /var/tmp/junos-srx1k3k-10.4R3.4-domestic.tgz no-validate no-copy
  request system reboot
14.) On node 0, after upgrade:
  show version
  show chassis cluster status
  show chassis fpc pic-status
15.) Wait for all interfaces to come "online" after "show chassis fpc pic-status" command
16.) Node 1 then Node 0 (this will failover so node0 is now master again)
  delete interfaces ge-0/0/0 disable
  delete interfaces ge-0/0/1 disable
  delete interfaces ge-0/0/2 disable
  delete interfaces ge-0/0/3 disable
  delete interfaces ge-0/0/4 disable
  delete interfaces ge-0/0/5 disable
  delete interfaces ge-0/0/6 disable
  delete interfaces ge-0/0/7 disable
  delete interfaces ge-0/0/8 disable
  set interfaces ge-8/0/0 disable
  set interfaces ge-8/0/1 disable
  set interfaces ge-8/0/2 disable
  set interfaces ge-8/0/3 disable
  set interfaces ge-8/0/4 disable
  set interfaces ge-8/0/5 disable
  set interfaces ge-8/0/6 disable
  set interfaces ge-8/0/7 disable
  set interfaces ge-8/0/8 disable
17.) Save on both devices at same time
  committ
18.) Reconnect control plane cable
19.) Veryify node0 is primary
  run show chassis cluster status
20.) Reboot Node1 and connect fab# interface cables between nodes while device is rebooting
21.) Verify node0 is still passing traffic
  run monitor interface traffic
22.) Wait for all interfaces to come "online"
  show chassis fpc pic-status
23.) Verify group 2 failover shows priority
24.) Re-enable interfaces on node1 and check for proper tcp sequence checks (run on node0, commit will replicate to node1)
  delete interfaces ge-8/0/0 disable
  delete interfaces ge-8/0/1 disable
  delete interfaces ge-8/0/2 disable
  delete interfaces ge-8/0/3 disable
  delete interfaces ge-8/0/4 disable
  delete interfaces ge-8/0/5 disable
  delete interfaces ge-8/0/6 disable
  delete interfaces ge-8/0/7 disable
  delete interfaces ge-8/0/8 disable

  delete security flow tcp-session no-syn-check
  delete security flow tcp-session no-sequence-check
25.) commit
26.) Verify failover group (group 0 and 1 should show primary or secondary and priorities)
  run show chassis cluster status
    26.a) If group 2 is not showing with priorities and status on node1 is "disabled", another reboot may be necessary. This is related to the fab# interfaces
    26.b) When node1 comes back online, verify fab interfaces are showing up and give a minute or 2 for "show chassis cluster status" to show priorities and status
    26.c) May take time due to sessions being synchronized
27.) Run on node0 to download and install IDP updates if needed. Status is for verifying progress of download or install
  run request security idp security-package download full-update
  run request security idp security-package download status

  run request security idp security-package install
  run request security idp security-package install status
28.) Verify versions match on both nodes and verify they are up to date
  run show security idp security-package-versionrun show
  run request security idp security-package download check-server
    28.a) Failover may be required to download IDP if no internet access on node0 (Per Juniper) or versions do not match