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”

Troubleshooting SRX chassis cluster

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”

Stacking (VSF) Aruba Switches

I noticed some shiny Aruba switches on the bench today, they were for a job my colleague is working on. (Note: Each switch in a stack should be the same, so these will need two stacks!)

Aruba Switch Stacking

I work on the occasional HP/Aruba core switch, but it’s been a while since I did any work on distribution switches like these. The first thing I learned, was there’s no dedicated stacking cable for them. They simply use a 10Gb (Twinax / DAC) cable. Which I suppose is pretty straight forward, but it means you lose an SFP+ port (which is a bit pants).*

Aruba Stack Cable

*Note: You can stack with 1GB cables, but you can’t mix and match!

So I said “Give me a shoult when you stack them and I’ll take a nosey!”

Solution

In the ‘land of Aruba’ this is called creating a VSF (Virtual Switching Fabric). As you can see from the photo, these are 2930F Switches, and you can stack up to four switches in a VSF. The same stacking method is used on the 5400R (v3) and 5412, where you can link two 5400R or 5412’s).

Also this method is NOT to be confused with ‘Fabric Stacking’ which is available on the 2920,2930M,3800,3810M models, (that is more like Cisco FlexStack, with a dedicated 100Gb stack cable).

So, assuming you have your switch new and fresh, connect in with your console cable, and dedicate a port to use for VSF.

Aruba-2930F-24G-PoEP-4SFPP# conf t
Aruba-2930F-24G-PoEP-4SFPP(config)# vsf member 1 link 1 ethernet 25
All configuration on this port has been removed and port is placed in VSF mode.

Then place the switch into a VSF domain

Aruba-2930F-24G-PoEP-4SFPP(config)# vsf enable domain 1
This will save the current configuration and reboot the switch.

The switch will ask for a reboot, let it do so.

Repeat the procedure on the second switch, (but this will be member 2).

Aruba-2930F-24G-PoEP-4SFPP# conf t
Aruba-2930F-24G-PoEP-4SFPP(config)# vsf member 1 link 1 ethernet 25
All configuration on this port has been removed and port is placed in VSF mode.
Aruba-2930F-24G-PoEP-4SFPP(config)# vsf enable domain 1
This will save the current configuration and reboot the switch.

Once again let the switch reboot. 

Post reboot you will see the ports are ‘re-numbered’ 1/{port-number} on vsf member 1, 2/{port-number} on vsf member 2 etc.

Aruba-2930F-24G-PoEP-4SFPP# show interfaces
Status and Counters - Port Counters

                                                                 Flow Bcast
  Port         Total Bytes    Total Frames   Errors Rx Drops Tx  Ctrl Limit
  ------------ -------------- -------------- --------- --------- ---- -----
  1/1          0              0              0         0         off  0    
  1/2          0              0              0         0         off  0    
  1/3          0              0              0         0         off  0    
  1/4          0              0              0         0         off  0    
<---------------Output Removed For The Sake Of Brevity-------------->   
  1/10         0              0              0         0         off  0    
  1/11         0              0              0         0         off  0    
  1/12         0              0              0         0         off  0    
  1/13         0              0              0         0         off  0  
<---------------Output Removed For The Sake Of Brevity--------------> 
  1/19         0              0              0         0         off  0    
  1/20         0              0              0         0         off  0    
  1/21         0              0              0         0         off  0       
  1/25         1,496,823,949  23,354,845     0         0         off  0
<---------------Output Removed For The Sake Of Brevity--------------> 
  2/1          0              0              0         0         off  0    
  2/2          0              0              0         0         off  0    
  2/3          0              0              0         0         off  0    
  2/4          0              0              0         0         off  0    
<---------------Output Removed For The Sake Of Brevity--------------> 
  2/22         0              0              0         0         off  0    
  2/23         0              0              0         0         off  0    
  2/24         0              0              0         0         off  0    
  2/25         1,536,016,322  23,966,915     0         0         off  0    
  2/26         0              0              0         0         off  0    
  2/27         0              0              0         0         off  0    
  2/28         0              0              0         0         off  0    
 

If you need to Stack 3 or 4 Switches then you need to add a second link, and create a ring;

i.e.

  • Switch 2 (2nd link now to switch 3) vsf member 2 link 2 ethernet 26
  • Switch 3 (1st link to switch 2 ) vsf member 2 link 1 ethernet 25
  • Switch 3 (2nd link to switch 4 ) vsf member 2 link 2 ethernet 26
  • Switch 4 (1st link to switch 3 ) vsf member 4 link 1 ethernet 25
  • Switch 4 (2nd link to switch 1 ) vsf member 4 link 2 ethernet 26

Useful Aruba VSF Commands

show vsf or show vsf detail :  Shows the list of provisioned chassis members.

show vsf link or show vsf link detail : Shows the state of vsf links for all members.

show vsf lldp-mad status : Shows LLDP MAD (Multi-Active Detection).

show vsftrunk-designated-forwarder : Shows designated forwarders for each trunk.

DISABLE SIP ALG ON FORTIGATE FIREWALLS

OVERVIEW

On Fortigate firewalls  SIP  Application Layer Gateway (SIP ALG) is enabled by default. This will cause problems with SIP VoIP phones registration and call processing.

We observed following problems when SIP ALG is active on Fortigate firewalls:

  1. SIP phones are unable to register on a remote phone system
  2. Calls are dropped after 5-15 min
  3. Incoming phone calls are not reaching the SIP phone(s)

RESOLUTION

Backup configuration of your firewall before making any changes

Run following commands from Fortigate firewall CLI

config system settings
set sip-helper disable
set sip-nat-trace disable
set default-voip-alg-mode kernel-helper-based
end

IMPORTANT Note: Since version 6.2.2. the CLI command is different:

config system settings 
set default-voip-alg-mode kernel-helper-based
set sip-expectation disable
set sip-nat-trace disable
end 

If you see an error while entering “set default-voip-alg-mode kernel-helper-based” , just ignore it.

Next we need to locate SIP entry in session helper list and delete it

config system session-helper
show

Scroll down until you see an entry for SIP, in our example it was number 13 but this may be different depending on model and software release. Now execute  following commands:

delete 13
end

The last set of commands disables processing of RTP protocol on the firewall

config voip profile
edit default
config sip
set rtp disable
end
end

Normally Fortigate firewalls do not require a reboot when you change configuration, but , it seems, in this case we need reboot it to activate session helper changes.

Last step – restart or power cycle all your SIP phones and devices.

Juniper Troubleshooting Commands

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.

      }

   }

Tiêu chuẩn suy hao mối hàn cáp quang

Tiêu chuẩn quốc gia – Tiêu chuẩn suy hao mối hàn cáp quang

TCVN 8665:2011 chuyển đổi từ TCN 68-160:1996 thành Tiêu chuẩn Quốc gia theo quy định tại khoản 1 Điều 69 của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật và điểm a khoản 1 Điều 6 Nghị định số 127/2007/NĐ-CP ngày 1/8/2007 của Chính phủ quy định chi tiết thi hành một số điều của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật.

TCVN 8665:2011 được xây dựng trên cơ sở Khuyến nghị G.651.1 (07/2007), G.652 (11/2009), G.653 (07/2010), G.655 (11/2009) của Liên minh Viễn thông Thế giới ITU-T.

TCVN 8665:2011 do Viện Khoa học Kỹ thuật Bưu điện biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

Các bạn có thể tải file về xem rất chi tiết và đầy đủ nhé:

Một số mức suy hao cho phép:

Dưới đây là các thông số tiêu chuẩn để đánh giá của một tuyến cáp quang

  • Quỹ công suất toàn tuyến (Switch to Switch): 28dBm
  • Suy hao toàn tuyến: yêu cầu <28dBm (khuyến cáo nên <25dBm, 3dBm dự phòng công suất suy giảm theo thời gian.
  • Mức phát của OLT là +3dBm +-2

Suy hao cho phép: cáp quang, mối hàn, đầu nối connector:

Về lý thuyết:

  • Suy hao cáp quang cho phép ở bước sóng 850nm: 3.5dBm/km (Cáp quang MM)
  • Suy hao cáp quang cho phép ở bước sóng 1300nm: 1.0dBm/km (Cáp quang MM)
  • Suy hao cáp quang cho phép ở bước sóng 1310nm: 0.35dBm/km (Cáp quang SM)
  • Suy hao cáp quang cho phép ở bước sóng 1550nm: 0.22dBm/km (Cáp quang SM)
  • Suy hao mối hàn cáp quang <0.1dBm (Thực tế suy hao < 0.05dBm)
  • Các suy hao do đầu nối connector: <0.5dBm (Đối với loại đầu nối SC/APC suy hao là 0.35dBm)

Tiếp theo mình sẽ hướng dẫn các bạn 2 phương pháp đo suy hao cáp quang:

1. Đo suy hao quang bằng máy đo công suất

1.1. Mục đích

Việc đo suy hao quang bằng máy đo công suất được sử dụng để xác định chính xác suy hao của cáp sợi quang.

Phương pháp đo suy hao quang bằng máy đo công suất quang sử dụng phương pháp đo suy hao xen.

1.2. Điều kiện đo

Dưới đây là những thiết bị cần để đo:

  1. Máy đo công suất quang.
  2. Nguồn sáng quang (có thể dùng converter, module quang (SFP)…)
  3. 02 bộ đầu nối (adapter).
  4. 02 dây nối (có đường kính lõi và vỏ giống như sợi cần đo).

1.3. Tiến hành đo

Bước 1: đặt tham chiếu.

Thiết lập đo

Quy trình:

– Đấu mỗi máy đo công suất và nguồn sáng với 1 dây nối và liên kết lại bằng 1 bộ nối (Hình 1.1);

– Bật nguồn máy đo công suất quang (để ở chế độ cần đo);

– Bật nguồn quang hiển thị là giá trị tuyệt đối (dBm);

– Thiết lập giá trị tuyệt đối này về giá trị tham chiếu và hiển thị giá trị tương đối (dB).

Bước 2: đo suy hao sợi quang sử dụng phương pháp đo suy hao xen.

Thiết lập đo:

Quy trình:

– Tháo một trong các dây nối, nối sợi quang cần đo vào như Hình 1.2.

– Giá trị hiển thị trên máy đo là suy hao xen của sợi quang cần đo.

2. Đo suy hao quang bằng máy đo phản xạ quang OTDR

2.1. Mục đích

Phương pháp đo suy hao bằng máy đo OTDR cáp quang sử dụng phương pháp đo suy hao phản xạ trở về.

Phương pháp này cho phép đánh giá suy hao trở về bằng đo công suất phản xạ của sợi quang.

2.2. Điều kiện đo

Máy đo OTDR

Các dây nối và phụ kiện:

  • Các bộ nối thích hợp;
  • Bộ ghép sợi quang;
  • Chất lỏng làm phù hợp chiết suất sợi;
  • Dao cắt sợi quang;
  • Kìm tuốt vỏ cáp và sợi quang;
  • Cuộn sợi đệm.

Trước khi tiến hành các phép đo bằng OTDR, cần phải kiểm tra máy OTDR đó để đảm bảo rằng nó có đủ khả năng đo toàn bộ chiều dài sợi quang hay không. Chiều dài tổng của cáp sợi quang được đo cần ngắn hơn phạm vi này.

2.3. Tiến hành đo

Dưới đây là các bước cần được tiến hành để thực hiện một phép đo bằng OTDR:

1. Nếu sợi quang cần đo không được nối với bộ nối, bóc cáp sợi quang ra và để cho sợi quang lộ ra khoảng 2m. Làm sạch và cắt sợi này.

2. Nối máy OTDR với sợi quang trên bằng một dây nối, cuộn sợi đệm (nếu được yêu cầu) và bộ chuyển đổi sợi quang trần (xem Hình 2.1). Nếu sợi quang đó được nối với bộ nối, thì nối máy OTDR với sợi đó bằng một dây nối và cuộn sợi đệm (nếu được yêu cầu). Cuộn sợi đệm là cuộn sợi quang trần nhỏ có độ dài sợi khoảng 1km, có thể cuộn được trên một lô nhỏ. Nó được sử dụng cho OTDR để loại vùng chết của OTDR. Vì thế sợi quang dùng làm cuộn đệm không được có bất kỳ sự dị thường nào.

3. Bật nguồn OTDR.

4. Thiết lập chế độ ứng với các tham số hoạt động thích hợp của OTDR, bao gồm bước sóng, chiết suất của sợi quang được đo và chế độ quét và phân giải của màn hiển thị.

5. Điều chỉnh độ phân giải của màn hiển thị để hiển thị toàn bộ sợi quang được đo.

6. Đo suy hao của tất cả các điểm dị thường, các mối hàn, các bộ nối và toàn bộ sợi quang.

7. Đo suy hao 2 điểm đầu-cuối của sợi quang.

8. Lặp lại tất cả các bước từ 1 đến 7 cho tất cả các bước sóng yêu cầu.

9. Ghi lại vị trí của OTDR cho những phép đo này.

10. Lặp lại các bước từ 1 đến 9 với máy đo OTDR được nối vào đầu kia của sợi quang. Sau đó tính giá trị trung bình của hai kết quả thu được. Nó sẽ cho ra một giá trị chính xác hơn:

Tổn haoOTDR = (Tổn haohướng A + Tổn haohướng B)/2

Comware7: Configuration commit delay

In the old days it was quite common to schedule a device reboot e.g. 5 min ahead when ‘tricky’ remote device changes had to be performed over an in-band connection such as SSH/telnet. In case the config changes provided the desired result, the reboot would be cancelled. When the changes would have resulted in a lost management connection, the reboot would have reverted the device state to the previous config (assuming no ‘save’ was done).

Comware 7 now has a similar feature but without the device reboot, so this is an online ‘swap’ of the configuration without the reboot delay.

Note: This command is a one-off command, it is not saved in config and it needs to re-entered every time it is needed.

First set the time in the future when the auto-rollback is supposed to happen

[5900G-1]configuration commit delay ?
 INTEGER<1-65535>  Delay time in minutes
[5900G-1]configuration commit delay 2

%Jan  1 04:11:58:463 2011 5900G-1 SHELL/5/SHELL_COMMIT_DELAY: A configuration rollback will be performed in 2 minutes.

Now a config change is made, for example, the G1/0/1 description is set to ‘demo’

[5900G-1]int g1/0/1
[5900G-1-GigabitEthernet1/0/1]description demo1

Review the running config with the applied change

[5900G-1-GigabitEthernet1/0/1]dis cur int g1/0/1


 #
 interface GigabitEthernet1/0/1
 port link-mode bridge
 description demo1
 #
 return

When the administrator does not confirm the applied changes with the ‘commit’ command within the set delay time, the device will automatically rollback the configuration.

%Jan  1 04:08:28:315 2011 5900G-1 SHELL/5/SHELL_COMMIT_ROLLBACK: The configuration commit delay is overtime, a configuration rollback will be performed.
%Jan  1 04:08:36:403 2011 5900G-1 SHELL/5/SHELL_COMMIT_ROLLBACKDONE: The configuration rollback has been performed.

Now the running config has been reverted to the state before the commit delay was entered

[5900G-1-GigabitEthernet1/0/1]dis cur int g1/0/1
 #
 interface GigabitEthernet1/0/1
 port link-mode bridge
 #
 return

When the admin decides that the changes are fine, the configuration commit can be used. This will cancel the pending timer.

Again some configuration change is made

[5900G-1-GigabitEthernet1/0/1]description demo2
 [5900G-1-GigabitEthernet1/0/1]quit

Now the configuration commit is used

[5900G-1]configuration commit
%Jan  1 04:09:30:268 2011 5900G-1 SHELL/5/SHELL_COMMIT: The configuration has been committed.

And the running configuration now contains the applied changes

[5900G-1-GigabitEthernet1/0/1]dis cur int g1/0/1
#
 interface GigabitEthernet1/0/1
 port link-mode bridge
 description demo2
 #
 return