Juniper – Connecting Core Switch virtual chassis to SRX cluster

Đã 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;
    }
}

Juniper SRX VPN Troubleshooting

>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.  

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. 

Cấu hình truyền hình IPTV FPT với tường lửa pfSense

Nhà mạng FPT triển khai IPTV (truyền hình FPT) dựa trên giao thức IGMP, vì vậy cần phải có router hỗ trợ IGMP Proxy mới sử dụng được.

Đối với pfSense, pfSense đã tích hợp sẵn IGMP Proxy, tuy nhiên vẫn cần một số cấu hình nữa mới chạy được IPTV FPT, cách thực hiện như sau.

1. Mô hình triển khai

Firewall có 4 cổng igb0-4. Trong đó:

  • Cổng igb0 sẽ port WAN kết nối PPPoE đến nhà mạng FPT (cắm vào converter hoặc router FPT ở mode bridge)
  • Cổng igb1 chưa dùng
  • Cổng igb2 là cổng LAN bình thường dùng để cắm đến các thiết bị truy cập internet sử dụng dãy IP 192.168.10.0/24
  • Cổng igb3 là cổng dành riêng để cắm IPTV sử dụng dãy IP 192.168.20.0/24

2. Tạo interface WAN cho IPTV

Khi tạo kết nối PPPoE trên pfsense, mặc định sẽ có 1 interface PPPoE được tạo ra trên cổng vật lý đó. IGMP không thể đi chung đường PPPoE, vì vậy cần tạo thêm 1 cổng WAN nữa trên igb0 dành cho lưu lượng multicast.

Trên pfSense, vào Interface => Assignment. Chọn cổng igb0 từ danh sách Available Network Port và bấm Add

Đặt các thông số như sau:

  • Description: 1_WAN1_PAYTV_P0
  • IPv4 Type: Static
  • IPv6 Type: None
  • IPv4 Address: 169.254.254.232/32 (IP này có thể đặt tùy ý vì nó chỉ dùng để đại diện cho interface, miễn là không trùng với IP LAN và WAN)
  • IPv4 Gateway: None

3. Tạo interface LAN cho IPTV

Trên pfSense, vào Interface => Assignment. Chọn cổng igb3 từ danh sách Available Network Port và bấm Add

Đặt các thông số như sau:

  • Description: 4_IPTV_P3
  • IPv4 Type: Static
  • IPv6 Type: None
  • IPv4 Address: 192.168.20.1/24
  • IPv4 Gateway: None

Sau khi cấu hình port, vào Services => DHCP Server và chọn Interface 4_IPTV_P3

Cấu hình các thông tin như sau:

  • Range: 192.168.20.10 -> 192.168.20.20 (có thể mở rộng hoặc thu hẹp range tùy nhu cầu)
  • DNS: 210.245.31.220, 210.245.31.221 (bắt buộc dùng cặp DNS này, nếu không sẽ không phân giải được các tên miền nội bộ của IPTV)

4. Cấu hình IGMP Proxy

Sau khi cấu hình xong Interface, tiếp theo là cấu hình IGMP Proxy.

Vào Services => IGMP Proxy và chọn Enable IGMP => Save

Tại IGMP Proxy, bấm Add và lần lượt thêm 2 proxy như sau:

  • Interface: 1_WAN1_PAYTV_P0 (Port WAN tạo ở bước trước)
  • Type: Upstream Interface
  • Networks (Add mỗi net riêng trên 1 dòng, cảm ơn bạn Phạm Hồng Dương đã hỗ trợ thông tin này)
    • 0.0.0.0/24
    • 217.166.0.0/16
    • 213.75.0.0/16
    • 10.0.0.0/8
  • Interface: 4_IPTV_P3 (Port LAN tạo ở bước trước)
  • Type: DownstreamInterface
  • Networks: 192.168.20.0/24

5. Cấu hình rule firewall LAN

Vào Firewall => Rules và cấu hình các Rule như sau trên Interface 4_IPTV_P3:

Rule 1: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

  • Action: Pass
  • Interface: 4_IPTV_P3
  • Protocol: Any
  • Source: 4_IPTV_P3_net
  • Destination: Any
  • Bấm Display Advanced và đánh dấu chọn Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.

Rule 2: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

  • Action: Block
  • Interface: 4_IPTV_P3
  • Protocol: Any
  • Source: 4_IPTV_P3_net
  • Destination: 3_LAN_P2_net (ở đây chọn lớp mạng của port igb2 là port LAN theo như mô hình triển khai)

Mục đích của Rule này là để chặn không cho traffic multicast của IPTV tràn sang LAN gây nghẽn

Kiểm tra để chắc chắn thứ tự Rule như sau


6. Cấu hình rule firewall WAN

Tương tự, trên Interface 1_WAN1_PAYTV_P0 cấu hình các rule sau:

Rule 1: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

  • Action: Pass
  • Interface: 1_WAN1_PAYTV_P0
  • Protocol: UDP
  • Source: any
  • Destination: Network 224.0.0.0/4
  • Bấm Display Advanced và đánh dấu chọn Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.

Rule 2: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

  • Action: Pass
  • Interface: 1_WAN1_PAYTV_P0
  • Protocol: IGMP
  • Source: any
  • Destination: Network 224.0.0.0/4
  • Bấm Display Advanced và đánh dấu chọn Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.

Kiểm tra để chắc chắn thứ tự Rule như sau

Sau khi hoàn tất, Apply Config trên pfsense để nhận cấu hình rule mới


7. Cấu hình Bridge

Sau khi cấu hình xong Firewall, vào Interface => Assignment, sang tab Bridges và bấm Add

Tại đây chọn 2 port 1_WAN1_PAYTV_P0 và 4_IPTV_P3 (là port WAN và LAN của IPTV, giữ phím Ctrl khi chọn để chọn cùng lúc nhiều port), đặt tên tại Description và bấm Save

Lúc này, trên Bridge sẽ hiện card Bridge0, lúc này đầu thu đã có thể nhận tín hiệu truyền hình.

Chúc các bạn thành công.

Juniper EX4300 Series – Configuration Template

As promised here’s the current template I’m using to configure the Juniper EX4300 series switches in my environment. Please feel free to provide corrections or updates based on your own experiences.

We’ll touch on the following configuration topics; OSPF, VLANs, DHCP relay, DHCP snooping, MAC limiting, rate limiting, BFD, TACACS+, SYSLOG, SNMP, RSTP, and BPDU filtering(blocking).

Let’s start by setting the hostname of the switch and the timezone.

set system host-name B99-SW01-EAST
set system time-zone America/New_York

Let’s set the root password, we’ll also add an ‘admin’ user later.

set system root-authentication plain-text-password 
{enter local root password}
{confirm local root password}

In this case I’m using TAC_PLUS so let’s configure TACACS+ authentication. In the example below X.X.X.X is the IP address of your our TACACS+ server and Y.Y.Y.Y is the management IP address of loopback address of the switch itself.

set system tacplus-server X.X.X.X
set system tacplus-server X.X.X.X secret tac_plus_shared_secret_here
set system tacplus-server X.X.X.X single-connection
set system tacplus-server X.X.X.X source-address Y.Y.Y.Y

Let’s change the order of the authentication sources, making TACACS+ the first choice.

Continue reading “Juniper EX4300 Series – Configuration Template”