Initial HPE Comware Switch Configuration

nitial configuration (Best Practices) for HPE Comware switches based on My deep personal experience and HPE reference guides, with focus on Security. Only the Best to the Best. Let’s go!

Out of box switch has no configuration but this is not truth. Switch will try to allocate IP address on Management port. With Zero Provisioning technology we can push basic configuration to the switch automatically by connecting Management port to Out of Band Network. In the next articles I will share the exacts steps.

Let’s connect to the new switch with USB to console cable.

Startup/Backup Configuration files

After switch is starting up press CTRL+D or CTRL+C to quit from auto configuration.

Enter to configuration mode with System-view. Configure hostname with sysname command. I recommend to set startup/backup configuration files with the same name as the switch and not the default name: startup.cfg. In case you have centralised backup server, it is nicer to have all backups with different names. Press save followed by file name (don’t forget .cfg extension). Same for the backup configuration file: save backup. With display startup command you can verify startup and backup configuration files.

RSA/DSA keys

1024-bit keys are become crackable between 2006 and 2010 and that 2048-bit keys are sufficient until 2030. The National Institute of Standards (NIST) recommends 2048-bit keys for RSA.

 

LLDP, STP

LLDP is not enabled by default. There is no way to enable LLDP on specific ports without enabled it globally. Enable LLDP globally and keep it only on switch to switch ports. Enter lldp global enable command. Spanning is also not enabled by default, so let’s enable it with stp global enable command. In addition strongly recommended in modern Networks move to dot1t path cost, enter stp pathcost-standard dot1t. (Be careful, it will recalculate stp cost on all links

VPN Instance (VRF-Lite)

In case that HPE device supports VPN Instance feature, I am strongly recommend to configure VPN Instance on Management interface (completely separate routing table for management). In addition, Static routes, NTP, SNMP, Syslog and TACACS configurations will run with VPN Instance feature.

ip vpn-instance mgmt command will create VPN Instance named mgmt. Then we need to bind management interface (it will delete IP address if you have one).

 int M-GigabitEthernet 0/0/0

ip binding vpn-instance mgmt

 description HPE-TEST

ip address 10.0.0.1 24

Login banner

To configure the banner that displays when the user logs in to a HPE switch, use the header login command. Use “%” in beginning of the banner and in the end.

header login %

************************************

*  Your Banner Here      *

************************************

%

Console password

By default there is no password on the console port. To configure the console to require authentication use the following commands:

line aux 0

 authentication-mode password

 user-role network-admin

 set authentication password simple 123456

 idle-timeout 5 0

SSH

For SSH connection let’s create local user admin with inbound protocol SSH only:

local-user admin class manage

 password simple 123456

 service-type ssh

 authorization-attribute user-role network-admin

#

line vty 0 63

 authentication-mode scheme

 user-role network-admin

 protocol inbound ssh

 idle-timeout 15 0

#

ssh server enable

 ssh server authentication-retries 5

 ssh server authentication-timeout 30

Hardening

Disable copyright info,USB port and unused services.

usb disable

undo copyright-info enable

In addition, if you have HTTP or Telnet running, please disabled it. HTTPS and DHCP can be also disabled, unless you are using them. Personal, I am using only CLI.

undo ip http enable

undo ip https enable

undo telnet server enable

undo dhcp enable

Version 1 of the SSH protocol has irremediable problems and multiple vulnerabilities. Strongly recommended to disable ssh v1 compatibility:

undo ssh server compatible-ssh1x

Verification can be done with display ssh server status command.

To verify TCP/UDP open ports use display tcp and display udp:

Enable BPDU protection, all access ports configure as edge ports (portfast). All unused ports should be moved to some unused VLAN and must be Shutdown. For example, we have 10 servers connected to first 10 ports:

vlan 666

description Null

name Null

*All unused ports will be configured in VLAN 666.

**Always put name and description after creating VLANs.

int range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/10

stp edged-port

Enable BPDU protection globally:

stp bpdu-protection

—————————————————————————————————————

In the next article I will share Best Practices for Monitoring configurations: NTPv4, Info Center (Syslog), SNMPv3 and TACACs.

IRF stack configuration (2 x HPE 5130 switches)

Introduction

In this article we will setup an IRF stack with two HP 5130 switches that run Comware OS.

What is IRF?

IRF (Intelligent Resilient Framework) is a proprietary virtualization/stacking technology used in some HPE switches. It has been developed originally by H3C, but later HPE acquired H3C.

IRF allows us to interconnect several switches and manage them as a single device. Besides that those interconnected switches form a single fabric and appear as a single node to other network devices.

IRF does not require any dedicated stacking modules, because it uses regular 10Gb Ethernet ports for stacking.

IRF Topology

Comware OS running switches support different number of switches in a stack depending on the switch model and the software version. The 5130 switches with the latest firmware support up to 9 switches in an IRF stack.

Switches can be interconnected in a ring or a daisy-chain manner. In this article we will configure two 5130-24G-4SFP+ (JG932A) switches as a single IRF stack. The topology of our stack is shown below:

The green links shown above are 10GbE connections.

Basic Concepts.

Below is a (very) short introduction to some of the concepts behind IRF technology. Please, read it, so you can understand why we make certain configuration changes on the switches.

IRF Member ID.

IRF Member ID is a unique ID that identifies a stack member. All switches in a stack should have different Member ID if we want them to form an IRF fabric. Default Member ID is 1. We will change Member ID of one of the switches.

IRF Member Priority.

Member priority is used to determine which switch will be selected as a master in our IRF stack. The switch with the higher priority will be elected the master. The default priority is 1.

IRF Port.

IRF Port is a logical interface on a switch used for communication with other stack members, and it should have at least one physical interface assigned to it. We can assign/bind several interfaces to an IRF port which will automatically become an aggregate link.

Configuration

Step 1. Configure IRF-SW1 (master)

Go to Switch 1 which we want to be a master and assign it a priority 32 (the default priority is 1) . The following commands will do this:

system-view
irf member 1 priority 32

You can then verify the settings on Switch 1 using display irf command:

You can see from the output that Member ID is 1 and Priority is 32

Step 2. Configure IRF Port on IRF-SW1

Now let’s create and configure our IRF port on Switch 1 which is required for IRF operation. We will create logical irf-port 1/1 and assign physical ports Ten-GigabitEthernet1/0/27 and Ten-GigabitEthernet1/0/28 to it. We should shutdown the physical interfaces before we can assign them to an IRF port. Below are the commands:

interface Ten-GigabitEthernet 1/0/27
shutdown

interface Ten-GigabitEthernet 1/0/28
shutdown

irf-port 1/1
port group interface Ten-GigabitEthernet1/0/27
port group interface Ten-GigabitEthernet1/0/28

Once you have added the physical ports to an IRF port you will see a message on the console, saying that you have to save your config and activate it using irf-port-configuration active command. Before doing this we will bring up our physical interfaces:

interface Ten-GigabitEthernet 1/0/27
undo shutdown

interface Ten-GigabitEthernet 1/0/28
undo shutdown

save
irf-port-configuration active

You can run display current-configuration and display irf configuration to verify the settings:

 

Step 3. Configure IRF-SW2 (slave)

Now let’s configure the Switch 2. The first thing we need to do is change its Member ID to 2, so it does not conflict with Switch 1. This will require a reboot. Run the following commands:

system-view
irf member 1 renumber 2
save
quit
reboot
You can run display irf command after reboot to make sure the new Member ID is in place:

Step 4. Configure IRF Port on IRF-SW2

Now we need to configure IRF port on Switch 2 and assign physical ports to it. We will create irf-port 2/2 and assign ports Ten-GigabitEthernet2/0/27 and Ten-GigabitEthernet2/0/28 to it. Note that all interface numbers now start with 2, because we have changed the Member ID of the switch.

Again, shutdown the interfaces before adding them to IRF port:

interface Ten-GigabitEthernet 2/0/27
shutdown

interface Ten-GigabitEthernet 2/0/28
shutdown

irf-port 2/2
port group interface Ten-GigabitEthernet2/0/27
port group interface Ten-GigabitEthernet2/0/28
The display current-configuration for the Switch 2 is shown below:

Now we can enable the interfaces and activate the IRF configuration:

interface Ten-GigabitEthernet 2/0/27
undo shutdown

interface Ten-GigabitEthernet 2/0/28
undo shutdown

save
irf-port-configuration active

Once you activate the IRF configuration, the Switch 2 will detect the Switch 1 and reboot. Note that Switch 2 will lose its current configuration, because it will become a member of a stack. Switch 1 will continue to operate, because it is a master.

Step 5. Verification

After Switch 2 boots up they will operate as a single logical unit. The display irf command confirms this:

As you can see, now we have a fully working IRF stack consisting of two HPE 5130 switches.

Conclusion

For further reading on IRF configuration you can have a look at this official guide from HP:

https://support.hpe.com/hpsc/doc/public/display?docId=c04771708

Thank you for reading 🙂

Script loadbalance multiwan PPPoE RouterOS 7

Các tính năng chính:

1. Script cho phép bạn gửi lưu lượng từ danh sách địa chỉ đặc biệt qua kết  nối pppoe cụ thể, bỏ qua luật cân bằng tải (Ví dụ: TV của bạn luôn phải đi qua pppoe-02).

2. Script hỗ trợ HAIRPIN-NAT

3. Script giải quyết vấn đề multiwan khi bạn đang xây dựng các đường hầm VPN ra (openvpn, wireguard, IPSec vv). Vui lòng xem phần hồ sơ pppoe.

4. Script thân thiện với CPU

Trong script giả định bạn có 2 liên kết WAN pppoe:

1. ether1 với pppoe-01 (FPT)

2. ether2 với pppoe-02 (VNPT)

Và 2 bridge LAN:

1. Bridge-lan-01 (ether3, ether4, ether5)

2. bridge-lan-02 (sử dụng sau này)

Stack-wise Virtual with Catalyst 9K Switches!

Gần đây, tôi đã cấu hình và triển khai nhiều Switch Cisco Catalyst 9K series. Thiết kế yêu cầu tính năng stack-wise virtual trên các thiết bị switch dòng 9606 và 9500. Vì vậy, tôi nghĩ rằng tôi sẽ dành một chút thời gian để chia sẻ với mọi người về stack-wise virtual là gì, cách cấu hình nó và một số lưu ý mà tôi đã tìm thấy trong quá trình này. 

Stack-wise là gì ?

Hãy bắt đầu với câu hỏi ? stack-wise virtual là gì ?

Tính năng Stacking đã tồn tại rất lâu trong các  thiết bị Switch Cisco Catalyst.  Bạn có thể thực hiện việc xếp chồng nhiều switch vật lý với nhau nhưng bảng MAC của chúng kết hợp với nhau thành 1 bảng MAC duy nhất. Về mặt logic, chúng là nhiều switch, nhưng với control plane chúng hoạt động như một switch. Vì vậy, toàn bộ switch được điều khiển như một switch duy nhất.

Stack-wise virtual là cách kết nối các thiết bị switch theo kiểu xếp chồng được sử dụng trên dòng switch 3K,  9300 trở lên và một số thiết bị switch dòng 2900.  Chú ý: Stack-wise virtual không được nhầm lẫn với Nexus VPC – Sự khác biệt chính ở đây là với Nexus VPC, các thiết bị switch vẫn hoạt động độc lập với nhau từ góc độ control plane và quản lý. Bạn đang quản lý hai switch riêng biệt. Với Stackwise-Virtual và VSS cũ hơn, bạn có hai switch vật lý nhưng bạn đang quản lý một switch duy nhất.

Tại sao sử dụng Stackwise ? 

Với Stackwise, chúng ta có thể giải quyết một cặp switch dự phòng như một switch logic duy nhất, thay vì quản lý hai switch riêng biệt. Nếu không sử dụng Stackwise thì sẽ phải chú ý thêm đến Spanning Tree và có thể thêm vào Giao thức dự phòng layer 3 First Hop như VRRP hoặc HSRP. 

Yêu cầu Stackwise

Có một số yêu cầu về OS cho Stackwise-Virtual tùy thuộc vào nền tảng phần cứng đang chạy.

  • 16.8.1 hoặc mới hơn cung cấp hỗ trợ cho Catalyst 3850XS và tất cả các thiết bị dòng 9500
  • 16.9.1 hoặc mới hơn trên dòng Catalyst 9400
  • 16.12.1 hoặc mới hơn trên các thiết bị Catalyst 9606 – dual sup – vì vậy chỉ có một card sup cho mỗi khung. Nếu cần quad supervisor sẽ cần IOS-XE 17.2.1 hoặc mới hơn.

Tôi nghĩ điều quan trọng cần bổ sung ở đây là hỗ trợ quad-sup không được tích hợp sẵn cho đến 17.2.1. Nếu dual sup trên mỗi khung và chạy phiên bản iOS previous đến 17.2.1 thì một cards sup trong mỗi chassis sẽ không được sử dụng. cards sup thậm chí sẽ không ở chế độ hot standby. Vì vậy, nếu cards sup trong khung lỗi thì Stackwise sẽ chuyển đổi dự phòng sang khung khác cho đến khi card sup bị lỗi được thay thế. 17.2.1 sẽ sử dụng đầy đủ cả bốn cards supervisor

Cáp

Bạn cũng sẽ cần tạo kết nối giữa các cặp switch. Có hai kết nối cho Switch Virtual Link và hai kết nối cho Dual Active Detection.

Liên kết Switch Virtual link được sử dụng để gửi control plane và data plane giữa hai thiết bị switch. Vì vậy, đây là kết nối tốc độ cao, băng thông lớn. Hình bên dưới các Switch Virtual Links là Cáp quang 40G QSFP.

Các Dual Active Detection links được sử dụng phát hiện lỗi để switch stand by có thể đảm nhận quyền điều khiển, nếu cần. Active Detection links có băng thông thấp hơn, nhưng các liên kết tốc độ cao được sử dụng. Hình bên dưới các liên kết này đang sử dụng kết nối 10G SR SFP + và LC-LC.

Licensing

Không có giấy phép cụ thể nào được yêu cầu cho Stackwise-Virtual. Đây là một tính năng có sẵn 

CẬP NHẬT: Hiện có yêu cầu cấp phép Network Advantage trên nền tảng CAT 9K.

Cấu hình

Configure Stack-wise Virtual ! tôi có 2 con Cat 9500. 

Trên switch 1:

switch#config t
switch(config)#
switch(config)#stackwise-virtual
Please reload the switch for Stackwise Virtual configuration to take effect
Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-stackwise-virtual)# domain 10
Switch(config-stackwise-virtual)#exit
Switch(config)#interface Hu1/0/51
Switch(config-if)# description STACKWISE-VIRTUAL
Switch(config-if)# stackwise-virtual link 1
WARNING: SVL configuration will be ignored  on lower (1G) speed.
WARNING: All the extraneous configurations will be removed for HundredGigE1/0/51 on reboot
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#interface Hu1/0/52
Switch(config-if)# description STACKWISE-VIRTUAL
Switch(config-if)# stackwise-virtual link 1
WARNING: SVL configuration will be ignored  on lower (1G) speed.
WARNING: All the extraneous configurations will be removed for HundredGigE1/0/52 on reboot
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#
Switch(config-if)#interface TwentyFiveGigE1/0/47
Switch(config-if)# description STACKWISE-VIRTUAL
Switch(config-if)# stackwise-virtual dual-active-detection
WARNING: All the extraneous configurations will be removed for TwentyFiveGigE1/0/47 on reboot.
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#interface TwentyFiveGigE1/0/48
Switch(config-if)# description STACKWISE-VIRTUAL
Switch(config-if)# stackwise-virtual dual-active-detection
WARNING: All the extraneous configurations will be removed for TwentyFiveGigE1/0/48 on reboot.
INFO: Upon reboot, the config will be part of running config but not part of start up config.
witch(config-if)#^Z
Switch#copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Switch#reload
Proceed with reload? [confirm]

Domain cho switch biết chúng đang ở trong domain nào. Khi hai switch cùng một domain, chúng biết rằng chúng được ghép nối với nhau. Trong cấu hình ví dụ này, domain là 10. Mọi domain có giá trị từ 1 đến 255 đều hợp lệ.

Mô tả cho các port kết nối là không bắt buộc, tôi làm điều đó chỉ vì lợi ích của người vận hành. Tôi là một kỹ sư triển khai nên sau khi hệ thống được triển khai, một nhóm kỹ sư khác sẽ vận hành nó. Tôi muốn gắn nhãn mô tả cho mọi thứ tôi làm để các kỹ sư theo dõi biết đó là gì. Nhưng bạn có thể thấy tôi định cấu hình các port tốc độ nhanh hơn cho Switch Virtual Link và các liên kết tốc độ thấp hơn cho Dual Active Detection links

Hãy chuyển sang Switch 2 !

Các lệnh trên switch 2 và switch 1 sẽ hoàn toàn giống nhau, ngoại trừ tập lệnh đầu tiên.

Switch#switch ren
Switch#switch renumber 2
WARNING: Changing the switch number may result in a configuration change for that switch.  The interface configuration associated with the old switch number will remain as a provisioned configuration. New Switch Number will be effective after next reboot. Do you want to continue?[y/n]? [yes]:
Switch#

Sau khi khởi động lại, đây sẽ là Switch 2. Trước khi reload, chúng ta cần định cấu hình các port Stackwise giống như chúng ta đã làm trên Switch 1. Đối với Switch 2, tôi sẽ bỏ qua các mô tả vì những port này sẽ không dính vào quá trình reload.

Switch#
Switch#config t
Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)#stackwise-virtual
Please reload the switch for Stackwise Virtual configuration to take effect
Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-stackwise-virtual)#domain 10
Switch(config-stackwise-virtual)#interface Hu1/0/51

Switch(config-if)# stackwise-virtual link 1
WARNING: SVL configuration will be ignored  on lower (1G) speed.
WARNING: All the extraneous configurations will be removed for HundredGigE1/0/51 on reboot
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#interface Hu1/0/52

Switch(config-if)# stackwise-virtual link 1
WARNING: SVL configuration will be ignored  on lower (1G) speed.
WARNING: All the extraneous configurations will be removed for HundredGigE1/0/52 on reboot
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#interface TwentyFiveGigE1/0/47

Switch(config-if)# stackwise-virtual dual-active-detection
WARNING: All the extraneous configurations will be removed for TwentyFiveGigE1/0/47 on reboot.
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#interface TwentyFiveGigE1/0/48

Switch(config-if)# stackwise-virtual dual-active-detection
WARNING: All the extraneous configurations will be removed for TwentyFiveGigE1/0/48 on reboot.
INFO: Upon reboot, the config will be part of running config but not part of start up config.
Switch(config-if)#exi
Switch(config)#exi
Switch#copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Switch#reload
Proceed with reload? [confirm]

Khi khởi động lại, một switch sẽ trì hoãn việc khởi động và đợi Switch 2 được phát hiện và tham gia vào stack. Sau khi cả hai switch được khởi động, bạn có thể sử dụng show switch để kiểm tra stack. Bạn có thể thấy HA Sync đang được tiến hành, như sau:

Bạn sẽ không thể sửa đổi cấu hình của switch cho đến khi HA Sync hoàn tất. Sẽ mất một vài phút. Để kiểm tra cấu hình Stackwise, hãy sử dụng show stackwise-virtual


witch#sho switch Switch/Stack Mac Address : b0c5.3ce8.0001 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Switch# Role Mac Address Priority Version State ------------------------------------------------------------------------------------- *1 Active b0c5.3ce8.3480 1 V02 Ready 2 Standby b0c5.3ce8.4a60 1 V02 HA sync in progress Switch#

 show stackwise-virtual

Switch#sho stackwise-virtual
Stackwise Virtual Configuration:
--------------------------------
Stackwise Virtual : Enabled
Domain Number : 10

Switch  Stackwise Virtual Link  Ports
------  ----------------------  ------
1       1                       HundredGigE1/0/51
                                HundredGigE1/0/52
2       1                       HundredGigE2/0/51
                                HundredGigE2/0/52

Switch#

Bạn sẽ thấy số của port thay đổi. Các port của switch 1 sẽ là 1/0/1 và switch 2 sẽ là 2/0/1. Con số đầu tiên là switch vật lý, vì vậy nếu là 1, chúng tôi đang giải quyết các port của Switch 1, nếu là 2 thì chúng tôi đang giải quyết các port của Switch 2. Số tiếp theo đề cập module, giống như một card có thể lắp vào. Số cuối cùng là số port. Vì vậy, 2/0/35 là port 35 trên Switch 2.

Trên Chassis Platforms

Quy trình tương tự này có thể được sử dụng trên Chassis Platforms Catalyst 9606. Tuy nhiên, khi khởi động lại, bạn sẽ nhận thấy điều gì đó hơi khác một chút trên số port. Các số port sẽ giống như 1/5/0/24 – 1 là Khung, 5 là Card – trên 9606 bạn có thể có 4 card ở các khe 1, 2, 5 và 6, với các khe 3 và 4 được dành riêng cho Supervisor cards – số 0 đề cập đến các module và hiện tại không có mô-đun nào có sẵn cho nền tảng 9606, nhưng điều đó có thể thay đổi và số cuối cùng là số port. Vì vậy, trong ví dụ trước, bạn có Chassis 1, line card là khe cắm 5, module 0 và port là 24.

Cảnh báo

Một số lưu ý quan trọng cần biết:

Port Channels nằm trong khoảng từ 1 – 192 trên dòng switch Cat 9K – điều này không dành riêng cho Stackwise Virtual. Trên các dong switch Catalyst cũ hơn, bạn có thể có 301, 405 hoặc 550. Bạn cần cập nhật cấu hình của mình để đảm bảo các Port Channels của bạn nằm trong phạm vi hợp lệ đó.

Ngoài ra, số Port Channels 127 và 128 được dành riêng cho Stackwise. Vì vậy, nếu bạn hiện đang sử dụng những số đó, bạn sẽ cần sửa đổi cấu hình của mình để sử dụng các Port Channels thay thế.

VLAN 4094 được dành riêng cho Stackwise. Vì vậy, nếu bạn đang sử dụng VLAN đó hiện tại, bạn sẽ cần phải có kế hoạch di chuyển VLAN đó sang một VLAN khác.

RouterOS 7 multiwan PPPoE loadbalance script

Script by [email protected]

Last edit 04/01/2022

Please try my RouterOS 7 multiwan PPPoE loadbalance script

Main features:
1) This script allows you to send traffic from special address lists via certain pppoe connection, bypassing the load balance logic (for example your TV should always go only via pppoe-02)
2) This script supports HAIRPIN-NAT
3) This script solves the multiwan issue when you are building outgoing VPN tunnels (openvpn, wireguard, IPSec etc). Please see the pppoe profile section.
4) This script is CPU friendly

In this script I assume you have 2 pppoe WAN links:
1) ether1 with pppoe-01 (FPT)
2) ether2 with pppoe-02 (VNPT)

And 2 LAN bridges:
1) bridge-lan-01
2) bridge-lan-02

Send your feedback to [email protected]

/interface/list/add name=WAN comment="For Internet"
/interface/list/add name=LAN comment="For Local Area Networks"


/interface pppoe-client
add disabled=no interface=ether1 name=pppoe-01 add-default-route=no user=fpt1 password=fpt1
add disabled=no interface=ether2 name=pppoe-02 add-default-route=no user=vnpt1 password=vnpt1


/interface/bridge/
add name=bridge-lan-01 comment=LAN1
add name=bridge-lan-02 comment=LAN2
/interface/bridge/port
add bridge=bridge-lan-01 interface=ether3
add bridge=bridge-lan-01 interface=ether4
add bridge=bridge-lan-01 interface=ether5


/interface/list/member/add interface=ether1 list=WAN comment="Uplink WAN for PPPoE-01"
/interface/list/member/add interface=ether2 list=WAN comment="Uplink WAN for PPPoE-02"
/interface/list/member/add interface=pppoe-01 list=WAN comment=PPPoE-01
/interface/list/member/add interface=pppoe-02 list=WAN comment=PPPoE-02 
/interface/list/member/add interface=bridge-lan-01 list=LAN
/interface/list/member/add interface=bridge-lan-02 list=LAN


/ip/neighbor/discovery-settings/set discover-interface-list=!WAN
/tool/mac-server/set allowed-interface-list=LAN
/tool/mac-server/mac-winbox/set allowed-interface-list=LAN


/ip/firewall/address-list
add address=0.0.0.0/8 comment="\"This\" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment="Loopback" list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment="TEST-NET-1" list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing" list=BOGONS
add address=198.51.100.0/24 comment="TEST-NET-2" list=BOGONS
add address=203.0.113.0/24 comment="TEST-NET-3" list=BOGONS
add address=224.0.0.0/4 comment="Multicast" list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS


/ip/dns/set servers=1.1.1.1,8.8.8.8

/ip/address/add interface=bridge-lan-01 address=192.168.88.1/24 comment="LAN1 IP"
/ip/address/add interface=bridge-lan-02 address=172.16.0.1/23 comment="LAN2 IP"

/routing/rule/add dst-address=192.168.88.0/24 table=main action=lookup comment="to LAN1"
/routing/rule/add dst-address=172.16.0.0/23 table=main action=lookup comment="to LAN2"

/ip/firewall/nat/add action=masquerade chain=srcnat comment="Masquerade WAN (non-ipsec)" ipsec-policy=out,none out-interface-list=WAN
/ip/firewall/nat/add action=src-nat chain=srcnat comment="Hairpin to LAN1" out-interface=bridge-lan-01 src-address=192.168.88.0/24 to-addresses=192.168.88.1
/ip/firewall/nat/add action=src-nat chain=srcnat comment="Hairpin to LAN2" out-interface=bridge-lan-01 src-address=172.16.0.0/23 to-addresses=172.16.0.1

/routing/table/add disabled=no fib name=rtab_pppoe-01
/routing/table/add disabled=no fib name=rtab_pppoe-02


/ip/firewall/mangle/add action=mark-connection chain=prerouting comment="Connmark in from PPPoE-01" \
    connection-mark=no-mark in-interface=pppoe-01 new-connection-mark=connmark_pppoe-01 passthrough=no
/ip/firewall/mangle/add action=mark-connection chain=prerouting comment="Connmark in from PPPoE-02" \
    connection-mark=no-mark in-interface=pppoe-02 new-connection-mark=connmark_pppoe-02 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark \
    comment="Address List via PPPoE-01" dst-address-list=!BOGONS dst-address-type=!local new-connection-mark=connmark_pppoe-01 \
    passthrough=yes src-address-list=Via_PPPoE-01
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark \
    comment="Address List via PPPoE-02" dst-address-list=!BOGONS dst-address-type=!local new-connection-mark=connmark_pppoe-02 \
    passthrough=yes src-address-list=Via_PPPoE-02

/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark \
    comment="LoadBalance transit connections via PPPoE-01" dst-address-list=!BOGONS dst-address-type=!local new-connection-mark=connmark_pppoe-01 \
    passthrough=yes per-connection-classifier=both-addresses-and-ports:2/0
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark \
    comment="LoadBalance transit connections via PPPoE-02" dst-address-list=!BOGONS dst-address-type=!local new-connection-mark=connmark_pppoe-02 \
    passthrough=yes per-connection-classifier=both-addresses-and-ports:2/1


/ip/firewall/mangle/add action=mark-routing chain=prerouting \
    comment="Routemark transit out via PPPoE-01" connection-mark=connmark_pppoe-01 \
    dst-address-type=!local in-interface-list=!WAN new-routing-mark=rtab_pppoe-01 passthrough=no
/ip/firewall/mangle/add action=mark-routing chain=prerouting \
    comment="Routemark transit out via PPPoE-02" connection-mark=connmark_pppoe-02 \
    dst-address-type=!local in-interface-list=!WAN new-routing-mark=rtab_pppoe-02 passthrough=no


/ip/firewall/mangle/add action=mark-routing chain=output \
    comment="Routemark local out via PPPoE-01" connection-mark=connmark_pppoe-01 \
    dst-address-type=!local new-routing-mark=rtab_pppoe-01 passthrough=no
/ip/firewall/mangle/add action=mark-routing chain=output \
    comment="Routemark local out via PPPoE-02" connection-mark=connmark_pppoe-02 \
    dst-address-type=!local new-routing-mark=rtab_pppoe-02 passthrough=no

/interface/bridge/add name=bridge-loopback comment="Loopback interface for emergency routing"
/ip/route/add distance=254 gateway=bridge-loopback comment="Emergency route"

/ip/route/add comment="Unmarked via PPPoE-01" distance=1 gateway=pppoe-01
/ip/route/add comment="Unmarked via PPPoE-02" distance=2 gateway=pppoe-02

/ip route add comment="Marked via PPPoE-01 Main" distance=1 gateway=pppoe-01 routing-table=rtab_pppoe-01
/ip route add comment="Marked via PPPoE-01 Backup" distance=2 gateway=pppoe-02 routing-table=rtab_pppoe-01

/ip route add comment="Marked via PPPoE-02 Main" distance=1 gateway=pppoe-02 routing-table=rtab_pppoe-02
/ip route add comment="Marked via PPPoE-02 Backup" distance=2 gateway=pppoe-01 routing-table=rtab_pppoe-02


/ppp profile
add name=profile-pppoe-01 comment="Add/remove route rule for pppoe-01" on-down="/routing/rule/ remove [find comment=\"From PPPoE-01 IP to Inet\"]" on-up=":if [:tobool ([/routing/rule/ find comment=\"From PPPoE-01 IP to \
    Inet\"])] do={\r\
    \n  /routing/rule/ set [find comment=\"From PPPoE-01 IP to Inet\"] \\\r\
    \n    src-address=\$\"local-address\" table=rtab_pppoe-01} else={\r\
    \n  /routing/rule/ add action=lookup comment=\"From PPPoE-01 IP to Inet\" src-address=\$\"local-address\" table=rtab_pppoe-01 }"

/interface/pppoe-client/set pppoe-01 profile=profile-pppoe-01

/ppp profile
add name=profile-pppoe-02  comment="Add/remove route rule for pppoe-02" on-down="/routing/rule/ remove [find comment=\"From PPPoE-02 IP to Inet\"]" on-up=":if [:tobool ([/routing/rule/ find comment=\"From PPPoE-02 IP to \
    Inet\"])] do={\r\
    \n  /routing/rule/ set [find comment=\"From PPPoE-02 IP to Inet\"] \\\r\
    \n    src-address=\$\"local-address\" table=rtab_pppoe-02} else={\r\
    \n  /routing/rule/ add action=lookup comment=\"From PPPoE-02 IP to Inet\" src-address=\$\"local-address\" table=rtab_pppoe-02 }"

/interface/pppoe-client/set pppoe-02 profile=profile-pppoe-02

SO SÁNH KIẾN TRÚC HAI NỀN TẢNG SMARTZONE VÀ ZONE DIRECTOR CỦA RUCKUS WIRELESS

Nguồn: https://www.ruckuswireless.com/

Dòng sản phẩm WLAN controller Zone Director nổi tiếng của Ruckus là một trong những sản phẩm chính đã giúp Ruckus từ một công ty khởi nghiệp năm 2008 với quy mô chỉ khoảng 100 nhân viên trở thành một công ty lớn trên thế giới về WLAN. Dòng sản phẩm này đang được sử dụng bởi hàng chục nghìn khách hàng, giúp họ dễ dàng cấu hình và quản lý mạng không dây của mình. Tuy nhiên, Ruckus không dừng lại ở đó, vào năm 2015, Ruckus đã giới thiệu một nền tảng WLAN controller mới – SmartZone, một thế hệ mới của controller nhằm giúp Ruckus Wireless tiếp cận được những nhu cầu/xu thế đang thay đổi của thị trường và khắc phục được các nhược điểm của nền tảng Zone Director.

Bài viết này sẽ so sánh sơ qua về kiến trúc giữa hai nền tảng Zone Director và SmartZone và áp dụng chúng vào việc thiết kế các mô hình mạng  như thế nào. Chúng ta sẽ bắt đầu với việc nhắc lại về các kiến trúc WLAN MAC.

1. CÁC KIẾN TRÚC WLAN MAC:

Có 3 kiến trúc WLAN MAC phổ biến trong mạng Wireless LAN 802.11, bao gồm:

Remote MAC, Split MAC và Local MAC

Remote MAC:

  • AP chỉ là PHY radio, toàn bộ việc xử lý của MAC layer được thực hiện tập trung;
  • Toàn bộ việc xử lý các tác vụ real-time và non-real-time đều được thực hiện bởi controller;
  • Kết nối PHY layer data giữa AP và controller;
  • Là kiến trúc ít phổ biến cho mạng WLAN;
  • Một ví dụ điển hình cho kiến trúc remote MAC là hệ thống LTE Active DAS.

Split MAC:

  • Việc xử lý MAC layer được phân chia cho cả AP và Controller;
  • Các chức năng xử lý real-time MAC layer được thực hiện tại AP;
  • Việc điều khiển được thực hiện thông qua giao thức LWAPP hoặc CAPWAP bởi controller tập trung;
  • Việc xử lý các tác vụ non-real-time hoặc near-real-time được thực hiện bởi Controller;
  • Integration Service (Chuyển đổi từ 802.11 WLAN Frame sang 802.3 Ethernet Frame) được thực hiện hoặc ở AP, hoặc ở Controller;
  • Kết nối giữa AP và Controller là Layer 2 / Layer 3;
  • Kiến trúc phổ biến cho các mạng WLAN;
  • Ruckus Wireless Zone Director được thiết kế dựa theo kiến trúc này.

Local MAC:

  • Việc xử lý MAC layer được thực hiện toàn bộ ở AP;
  • Việc xử lý các tác vụ Real-time, near real-time và non-real-time đều được thực hiện tại AP;
  • Toàn bộ các chức năng cơ bản đều được thực hiện tại AP vì vậy có khả năng hoạt động không phụ thuộc vào controller tập trung;
  • Các dịch vụ khác có thể được thực thi bởi chức năng điều khiển (vd: Quản lý cấu hình …);
  • Các hệ thông phân tán như controller dạng cloud thường lựa chọn kiến trúc này;
  • Ruckus Wireless Smart Zone được thiết kế dựa theo kiến trúc này.

Theo RFC 5412, bảng sau đây mô tả về kiến trúc SPLIT MAC và LOCAL MAC:

2. KIẾN TRÚC ZONE DIRECTOR MAC

Nền tảng Ruckus Wireless Zone Director được phát triển để nhắm vào các khách hàng doanh nghiệp vừa và nhỏ. Nền tảng này được thiết kế dựa trên một phiên bản tùy biến của kiến trúc Split MAC (được định nghĩa trong RFC 5412). Dưới đây là bảng các chức năng được phân chia thực hiện bởi AP và Zone Director.

Zone Director Split MAC: Vai trò và trách nhiệm:

Việc hiểu rõ từng vai trò và trách nhiệm (hay còn gọi là các chức năng) được phân công cho AP và Zone Director là rất quan trọng trong việc thiết kế một mạng WLAN. Dưới đây là một số điểm quan trọng nhất cần xem xét khi thiết kế:

2.1. Khả năng phục hồi

 Từ bảng trên ta có thể dễ dàng nhận thấy chức năng nào sẽ bị mất khi Zone Director bị lỗi. Các client đang kết nối tới hệ thống vẫn sẽ duy trì kết nối, tuy nhiên các client mới sẽ không thể kết nối vào hệ thống nếu không có controller. Các client cũng sẽ không thể roaming giữa các AP vì tất cả các association / re-association requests đều phải gửi đến controller.

Thuật toán Ruckus SmartMesh chạy trên các AP cho phép mỗi AP tính toán các đường uplink. Tuy nhiên, chức năng SmartMesh topology change (cho phép Mesh AP kết nối với đường uplink mới) sẽ không thực hiện được nếu không có controller.

 Việc mất kết nối với Zone Director cũng ảnh hưởng đến các chức năng quản lý encryption key, xác thực RADIUS, phát hiện Rogue AP và các chức năng WLAN khác có sự tham gia của controller.

Các AP được thiết kế để làm việc với mode local breakout (Dữ liệu người dùng không tunnel về controller mà đi ra thẳng tại AP) sẽ thực hiện việc chuyển đổi frame tại AP. Các cấu hình cho các chức năng về L3/L4 Access Control Lists và client isolation được lưu tại AP vì vậy các chức năng này vẫn sẽ tiếp tục làm việc với các client đã kết nối. Chức năng L2 Access Control (MAC Address based Access Control) được thực hiện trên Zone Director khi client thực hiện associate vào hệ thống, vì vậy chức năng này cũng sẽ không hoạt động nếu không có controller.

2.2. Dự phòng và quy mô

Nền tảng Zone Director chỉ hỗ trợ dự phòng 1+1 Active/Standby (được gọi là Smart Redundancy) và không hỗ trợ khả năng tạo cluster để tang quy mô (dung lượng) của hệ thống. Việc này gây ra những khó khăn trong việc triển khai một mạng WLAN với quy mô lớn hơn 1000 AP. Zone Director cos thể chạy với mô hình dự phòng N+1 khi sử dụng tính năng Primary and Secondary Zone Director failover, tuy nhiên không hỗ trợ stateful failover (sateful failover – chuyển đổi không làm gián đoạn dịch vụ)

2.3. Authentication / Association

Hạn chế chính của Zone Director AP là tất cả các request của 802.11 Authentication và Association phải đi qua controller.

Zone Director cũng đóng vai trò là RADIUS Client cho tất cả các bản tin authentication và accounting, đồng thời cũng đóng vài trò là một 802.1X authenticator trong 802.1x framework. Zone Director chịu trách nhiệm cho việc quản lý encryption key như là tạo và phân phối Master Session Key (MSK), Pairwise Master Key (PMK), các key tạm khác. Các key này được dùng để mã hóa việc gửi thông tin qua giao diện vô tuyến của AP.

Zone Director cũng chịu trách nhiệm trong việc tích hợp các kiểu xác thực khác bao gồm LDAP / Active Directory, Captive Portal Access, Guest Access Services, Zero-IT client provisioning, Dynamic Pre-Shared Keys và Hotspot Access…

Việc bắt buộc tất cả các giao dịch  802.11 authentications / associations phải đi qua Zone Director dẫn đến một số khó khăn khi thiết kế một mạng WLAN quy mô lớn, bao gồm:

  • 11 Authentication/Association request latency – Trễ xác thực 802.11
  • 1X Authentication latency / packet loss – Trễ/mất gói trong xác thực 802.1X
  • WPA / WPA2 4-Way handshake
  • AP roaming delays – Trễ trong roaming
  • Khả năng đáp ứng trong triển khai theo mô hình phân tán

802.11 Authentication/Association latency:

 Một số thiết bị có giới hạn về độ trễ giữa các gói tin gửi đi và nhận về trong quá trình xác thực. Một ví dụ là một số máy quét barcode sẽ không kết nối được mạng WLAN nếu không nhận được gói tin trả lời trong vòng 100ms trong quá trình xác thực. Các kỹ sư Ruckus đã thực hiện một thử nghiệm năm 2013 và thấy rằng hầu hết các thiết bị không bị ảnh hưởng với độ trễ là vài tram mili giấy. Độ trễ lớn nhất giữa AP và controller đã được thử nghiệm là >400ms (Gửi từ Sunnyvale tới South Africa / Beijing) và hầu như không ảnh hưởng tới việc kết nối của các thiết bị. Tuy nhiên, độ trễ tối đa được khuyến nghị sẽ là 150ms bởi vì chúng ta không thể chắc chắn hết về các thiết bị đầu cuối.

Từ version ZoneFlex 9.7, một tính năng mới đã được giới thiệu là Autonomous WLAN cho phép các Ap có thể trực tiếp trả lời các request authentication của association của client

802.1X Authentication with latency/packet loss:

Bên cạnh các bản tin xác thực 802.11, các bản tin EAPOL được gửi giữa Supplicant (client device) và Authenticator (Zone Director) cũng sẽ gặp vấn đề khi được truyền qua kết nối WAN có đã trễ cao và dễ mất gói. Nên nhớ rằng, LWAPP tunnels sử dụng UDP, các kỹ sư Ruckus đã thử nghiệm và thấy rằng các client sẽ khó xác thực 802.1x thanh công nếu  việc trao đổi các EAPOL key được thực hiện qua kết nối có đỗ trễ cao do bị mất thứ tự các frame và tăng số lượng bản tin EAPOL replay.

WPA / WPA2: 4-Way Handshake

WPA/WPA2 4-Way handshake được thực hiện bởi Client STA và Zone Director để thiết lập các khóa Pairwise Transient Key (PTK) và GroupWise Transient Keys (GTK) được sử dụng cho việc mã hóa dữ liệu được gửi qua giao diện vô tuyến. Sau khi Zone Director đã thiết lập được PTK (dùng để mã hóa lưu lượng unicast của client) và GTK (được gửi đến client để mã hóa lưu lượng multicast), nó thông báo cho AP giá trị của các key để AP có thể thực hiện mã hóa dữ liệu được gửi qua giao diện vô tuyến. Key Caching được lưu trữ tập trung tại  Zone Director và về nguyên tắc AP không cần phải biết đến giá trị của PMK hay bất cứ một Transient Keys nào.

 Từ phiên bản Zone Flex version 9.7, Ruckus Wireless đã đưa vào một tính năng mới gọi là “Autonomous WLAN” cho phép một WLAN sử dụng phương pháp xác thực “Open authentication” với tùy chọn mã hóa WPA/WPA2-Personal trong đó AP sẽ đẩm nhiệm việc sinh PTK từ PMK và lưu trữ PMK trên AP.

AP Roaming Delays:

 Một trong những yếu tố cần quan tâm khi thiết kế một mạng WLAN là độ trễ roaming khi di chuyển giữa các AP. Mỗi khi client re-associate với một AP mới, re-association request phải được chuyển tới Zone Director để phê duyệt. Nếu mã hóa được sử dụng thì sẽ phải thực hiện lại quá trình 4-way handshake giữa Client STA và Zone Director. Việc này có thể sẽ dẫn đến thời gian trễ đáng kể nếu controller đặt xa các thiết bị đầu cuối. Ngay cả khi kỹ thuật fast roaming như PMK caching được sử dụng, thời gian roaming cũng có thể quá dài đối với một số ứng dụng nhạy cảm trễ.

Trong một thử nghiệm, khi độ trễ từ Zone Director đến AP là 50ms, cũng sẽ mất tới >200ms để thực hiện việc chuyển vùng AP. Thời gian này chưa kể thời gian trao đổi các bản tin RADIUS giữa Zone Director và Authentication Server (AS).

Khả năng đáp ứng trong triển khai theo mô hình phân tán

Với các doanh nghiệp/tổ chức lớn với nhiều văn phòng/chi nhánh nằm tại các địa điểm khác nhau, trụ sở chính sẽ có một hạ tầng CNTT bao gồm các dịch Active Directory, LDAP, RADIUS, DHCP, DNS và một số máy chủ. Các văn phòng nhỏ/chi nhánh sẽ kết nối về trụ sở chính qua các kết nối WAN thường có tốc độ thấp và độ trễ cao. Trong một số trường hợp các chi nhánh có thể kết nối về trụ sở chính thông qua kết nối VPN trên môi trường internet. Với môi trường như vậy, về nguyên tắc chúng ta có thể đặt Zone Director controller tại trụ sở chính và các AP tại tất cả các trụ sở/chi nhánh sẽ kết nối về. Tuy nhiên, khi đó mọi association và AAA authentication/authorization request sẽ buộc phải tập trung về controller. Tất nhiên, mô hình này vẫn có thể hoạt động nhưng với các ứng dụng yêu cầu thời gian roaming nhỏ như là dịch vụ Vo-WiFi (yêu cầu thời gian roaming nhỏ hơn 50ms) thì yêu cầu về độ trễ của kết nối WAN giữa các trụ sở phải rất nhỏ (ví dụ với Vo-WiFi nêu trên thì độ trễ không vượt quá 12.5ms), điều này khó khả thi với các kết nối WAN hay Internet.

2.4. Layer 3 Networks:

Từ version ZoneFlex 9.4 trở lên, Ruckus không thực hiện Layer 2 LWAPP tunnels mà thực hiện L3 LWAPP tunnels giúp hỗ trợ việc đặt Zone Director và AP ở các subnet khác nhau.

2.5. Triển khai với NAT:

Tất cả các bản tin LWAPP đều xuất phát từ Access Point và gửi đến controller, vì vậy AP hoàn toàn có thể được triển khai phía sau NAT mà không gặp bất kỳ vấn đề gì. Từ version ZoneFlex 9.2 trở lên, Zone Director cũng hỗ trợ việc triển khai sau NAT, lúc đó AP sẽ được trỏ về địa chỉ public của Zone Director và tất nhiên là phải thực hiện forward một số cổng cần thiết của Zone Director ra ngoài địa chỉ public này. Tương tự vậy, chức năng Smart Redundancy cũng có thể hoạt động nếu Zone Director được đặt sau NAT.

2.6. Chuyển tiếp dữ liệu tập trung

Kiến trúc Split MAC của Zone Director cho phép dữ liệu được chuyển tiếp tập trung nhờ LWAPP tunnel (qua cổng UDP 12222). Tương tự như CAPWAP, LWAPP không hỗ trợ việc tách rời lưu lượng điều khiển và dữ liệu. Cả LWAPP control và LWAPP data tunnel đều kết nối về cùng một interface của Zone Director. Đây không thực sự là vấn đề đối với hầu hết các môi trường triển khai cho doanh nghiệp.

Tuy nhiên, đối với các nhà cung cấp dịch vụ viễn thông thì đây lại là một vấn đề lớn. Hầu hết các nhà cung cấp dịch vụ viễn thông lớn đều muốn tách rời mạng điều khiển và mạng dữ liệu của người dùng.

This is not always the case with service providers though.  Most large operators and service providers actually prefer to keep network control and subscriber data separate and forward them to parts of the network optimized for dealing with the specific traffic types.

Một vấn đề nghiêm trọng nữa là khi mà luồng điều khiển và luồng dữ liệu được truyền chung với nhau, nếu luồng điều khiển gặp vấn đề cũng sẽ làm gián đoạn luồng dữ liệu của người dùng.

Và rắc rối cuối cùng là Zone Director sẽ phải thực hiện một lượng lớn các xử lý MAC layer khi mà dữ liệu người dùng được forward tập trung về. Chính vì vậy, trong kiến trúc Split MAC về nguyên tắc một controller tối đa chỉ quản lý được vài nghìn AP.

Kết Luận:

Kiến trúc Split MAC của Zone Director có một số hạn chế vì vậy cần được cân nhắc khi triển khai các mạng WLAN dựa trên Zone Director. Việc thực thi các tác vụ của 802.11 và toàn bộ việc xác thực, quản lý key được thực hiện trên controller có thể dẫn đến việc tăng thời gian chuyển vùng AP làm việc triển khai theo mô hình phân tán gặp nhiều khó khăn. Vì vậy, việc đặt Zone Director tại chỗ ở mỗi địa điểm triển khai nên được xem xét, nhưng điều này cũng làm tăng chi phí triển khai và quản lý.

3. KIẾN TRÚC SMARTZONE MAC

Nền tảng SmartZone bắt đầu được phát triển từ đầu năm 2011 và không dựa trên kiến trúc Split MAC vốn đã được chấp nhận rộng rãi trong việc thiết kế các mạng WLAN doanh nghiệp. Nền tảng SmartZone đã triển khai một kiến trúc Local MAC tùy biến với việc tách rồi luồng điều khiển và luồng dữ liệu và sử dụng các giao thức lightweight phù hợp nhất cho mỗi nhiệm vụ. Hầu hết các công việc quan trọng của giao thức 802.11 (802.11 Client State Machine) và các chức năng khác được thực hiện tại AP. Bảng dưới đây mô tả rõ việc phân chia các chức năng giữa AP và SmartZone:

Một số chức năng khác được thực hiện trên SmartZone và trên AP được thể hiện ở bảng sau:

3.1. Khả năng phục hồi (khả năng hoạt động khi bị lỗi)

Như chúng ta thấy ở trong bảng trên, nền tảng SmartZone có khả năng phục hồi rất tốt với việc controller bị lỗi. Tất cả các chức WLAN cơ bản và một vài chức năng khác đều được thực hiện tại AP. Việc mất kết nối tới controller sẽ hầu như không ảnh hưởng để hoạt động bình thường của mạng WLAN.

Một số chức năng khác như Social Media Login hoặc Guest access có thể cần sử dụng CSDL người dùng được lưu trên SmartZone để xác thực người dùng có thể bị ảnh hưởng khi mất kết nối với controller. Tuy nhiên, các AP sẽ lưu trạng thái của người dùng đã kết nối với hệ thống và đảm bảo kết nối người dùng không bị ảnh hưởng.

Việc xác thực captive portal qua AP tới các CSDL bên ngoài sẽ không bị ảnh hưởng bởi kết nối tới controller.

Chức năng WiSPR Hotspot cần phải có sự hỗ trợ của SmartZone trong việc HTTP/HTTPS redirect, xử lý client proxy, tích hợp với Landing portal và xác thực RADIUS. Chức năng walled garden (một dạng whitelist trong xác thực hotspot) được thực hiện trên AP qua cơ chế DNS cache, cho phép lưu lượng người dùng đi ra internet trực tiếp từ AP mà không phải đi qua controller.

3.2. Dự phòng và quy mô:

Nền tảng SmartZone hỗ trợ dự phòng cluster N+1 active/active, cho phép tối đa lên tới 4 node trên một cluster. Các AP sẽ tự động san đều ra các node trong cluster (theo thứ tự ngẫu nhiên) để đảm bảo không có node nào bị quá tải.

Tất cả các thông tin về client được chia sẻ và đồng bộ giữa các node. Tất các cả thông tin về cấu hình và các bản ghi cố định khác được phân chia và sao lưu trên các CSDL của cluster để đảm bảo rằng nếu 1 node bất kỳ bị lỗi sẽ không ảnh hưởng đến dịch vụ.

Một controller SmartZone có thể hỗ trợ lên tới 10 000 AP và một cluster (4 node) có thể hỗ trợ lên tới 30 000 AP. SmartZone cũng hỗ trợ việc dự phòng giữa các cluster. Khi một toàn bộ cluster bị lỗi thì có thể chuyển đổi dự phòng sang một cluster khác. Cấu hình giữa 2 cluster phải được đồng bộ (thủ công hoặc đình kỳ).

3.3. 802.11 Association

Trong kiến trúc SmartZone, các thông tin để thực hiện các công việc trong giao thức 802.11 được lưu tại AP. Tất cả các nhiệm vụ về 802.11 authentication & association đều được đảm nhiệm trực tiếp bởi AP và kết quả sẽ được gửi về SmartZone (theo thời gian thực) để lưu trữ trong events logs. Vì vậy sẽ gặp phải các vấn đề về độ trễ giữa Smartzone và AP trong việc thực hiện 802.11 authentication và association.

Trong trường hợp sử dụng phương thức xác thực captive portal, AP sẽ cho phép người dùng associate và đồng thời kiểm tra trang thái của người dùng trên SmartZone. Nếu trạng thái của người dùng là “Authorized” thì AP sẽ không chuyển tiếp người dùng ra captive portal mà cho phép lưu lượng người dùng đi qua ngay lập tức (trong trường hợp kết nối Internet là cho phép ra Internet)

Trong trường hợp sử dụng WPA2-Personal, Pre-Shared Key cũng sẽ được lưu tại từng AP. Tương tự, danh sách L2 Access Control được dùng cho việc hạn chế truy cập theo MAC cũng sẽ được lưu tại AP.

Kiến trúc Local MAC của nền tảng SmartZone đã hạn chế được rất nhiều các vấn đề mà kiến trúc Split MAC gặp phải, bao gồm:

  • 11 Authentication/Association request latency – Trễ xác thực 802.11
  • 1X Authentication latency / packet loss – Trễ/mất gói trong xác thực 802.1X
  • WPA / WPA2 4-Way handshake
  • AP roaming delays – Trễ trong roaming
  • Khả năng đáp ứng trong triển khai theo mô hình phân tán

Quản lý 802.1X Authentication & Encryption Key

AP đóng vai trò như là RADIUS client trong việc gửi tất cả các bản tin RADIUS Authentication và Accounting. Tuy nhiên, cũng có lựa chọn cho phép SmartZone đóng vai trò như là một Radius Proxy.

AP đóng cũng đóng vai trò là 802.1X Authenticator trong 802.1X framework và chịu tránh nhiệm trong việc quản lý tất cả các encryption key, sinh MSK, PMK và các key tạm khác sử dụng trong quá trình mã hóa giao diện vô tuyến. Khi PMK được sinh ra, nó sẽ được lưu tại AP (PMK-caching) để làm tăng trải nghiệm người dùng trong quá trình 802.1x roaming. PMK cũng được gửi từ AP tới SmartZone để lưu trữ phục vụ chức năng Opportunistic PMK Caching. Nếu người dùng chuyển vùng sang một AP mới và cung cấp PMK-ID trong quá trình re-association, AP sẽ tìm kiểm PMK-ID này trên SmartZone để không phải thực hiện lại quá trình xác thực 802.1X đầy đủ. Quá trình WPA-4 way handshake được thực hiện hoàn toàn giữa client và AP loại bỏ hoàn toàn các vấn đề về độ trễ giữa AP và controller.

Tuy nhiên, vẫn có thể xảy ra một số vấn đề liên quan đến độ trễ cao của kết nối giữa SmartZone và AP. Độ trễ trong quá trình tìm kiếm PMK của AP trên SmartZone  và có thể gây ra độ trễ không chấp nhận được trong quá trình roaming. Tuy nhiên, ảnh hưởng này là không nhiều bởi vì quá trình tìm kiếm được thực hiện ngay sau quá trình association, sau đó tất cả các tác vụ khác sẽ được thực hiện trực tiếp giữa AP và Client.

Khả năng đáp ứng trong triển khai theo mô hình phân tán:

Nền tảng SmartZone cho phép các chi nhánh triển khai các AP tích hợp thẳng vào hạ tầng CNTT tại chỗ (Active Directory, LDAP, RADIUS, DHCP, DNS, Firewalls etc.).  Điều này có nghĩa là một SmartZone controller có thể quản lý được nhiều site mà không bắt buộc các authentication request hay dữ liệu người dùng phải kết nối về SmartZone. Đương nhiên là chúng ta vẫn có thể dùng SmartZone như là một proxy nếu muốn.

3.4. Layer 3 Networks:

Các AP chạy với nền tảng SmartZone sử dụng giao thức điều khiển riêng (dựa trên SSH) để kết nối với SmartZone cho phép tất cả lưu lượng điều khiển có thể vận chuyển qua Layer 3.

3.5. Khả năng triển khai với NAT

Tất cả các bản tin trao đổi đều được xuất phát từ AP và gửi tới SmartZone, vì vậy các AP làm việc trong nền tảng SmartZone có thể triển khai được sau NAT mà không gặp trở ngại gì. Các controller trong nền tảng SmartZone bao gồm virtual SmartZone (vSZ-E, vSZ-H) and SmartZone 100/300 đều hỗ trợ khả năng triển khai sau NAT. Trong trường hợp chạy cluster, thì phải sử dụng các địa chỉ IP public riêng biệt cho từng node.

3.6. Chuyển tiếp dữ liệu tập trung

Nền tảng SmartZone giao thức điều khiển riêng (dựa trên SSH) và giao thức dựa trên GRE cho đường dữ liệu và hai đường này được tách riêng. Nền tảng SmartZone cho phép chuyển tiếp dữ liệu tập trung tới SmartZone Controller (dạng Appliance) hoặc về Data Plane (dạng ảo hóa) thông qua giao thức RuckusGRE

RuckusGRE

RuckusGRE là phiên bản tùy biến của L2oGRE (còn được gọi là Ethernet over GRE hoặc SoftGRE) bằng cách thêm vào một header lớp Transport vào gói IP. Việc thêm vào một UDP header cho phép AP thiết lập một GRE tunnel ngay cả khi nó được đặt đằng sau một NAT router. GRE tiêu chuẩn không có UPD/TCP header này.

 RuckusGRE sử dụng TLS certificate cho việc xác thực và có tùy chọn mã hóa AES 128 bit.

Xử lý riêng biệt – Differentiated Handling

SmartZone tách biệt control và data plane vì vậy cho phép xử lý riêng biệt lưu lượng điều khiển và lưu lượng người dùng. Data plane được thiết kế để nhận cấu hình từ control plane nhưng vẫn tách biệt được việc xử lý dữ liệu của người dùng.

Các controller dạng appliance như SmartZone 100/300 đều hỗ trợ data plane trên thiết bị cứng cho phép lưu lượng có thể được tunnel về cùng một thiết bị phần cứng.

Data Plane trên SmartZone 100 có thể sử dụng địa chỉ IP và subnet riêng hoặc sử dụng cùng địa chỉ IP với control plane. Còn SmartZone 300 thì yêu cầu mỗi thanh phần (data plane và control plane) cần có địa chỉ IP riêng của nó.

Virtual SmartZone Data Plane (vSZ-D) là dạng ảo hóa của DataPlane và được sử dụng cùng với dạng ảo hóa của SmartZone controller. Với phiên bản hiện tại, mỗi virtual SmartZone có thể quản lý được tối đa 10 vSZ-D và một cluster có thể quản lý lên tới 40 vSZ-D.

Triển khai Data Plane với NAT

Các controller trong nền tảng SmartZone đều hỗ trợ việc đặt data plane phía sau NAT. kết nối điều khiển giữa vSZ-D và SmartZone cũng hỗ trợ việc đặt sau NAT. Tuy nhiên, mỗi vSZ-D sẽ cần địa chỉ IP public riêng cho nó.

Yêu cầu về độ trễ:

Độ trễ được khuyến nghị giữa vSZ-D và vSZ control plane là <150ms. Đối với các controller dạng appliance (SmartZone 100/300) thì không có yêu cầu này vì dataplane và control plane nằm trên cùng một thiết bị phần cứng.

Xử lý các frame 802.11:

AP vẫn sẽ đảm nhiệm toàn bộ việc chuyển đổi từ 802.11 frame sang 802.3 frame trước khi chúng được đóng gói GRE header điều này giúp giảm tải cho và tăng hiệu năng cho DataPlane.

Kết Luận

Nền tảng SmartZone được thiết kế dựa trên kiến trúc Local MAC cho phép đơn giản hóa việc triển khai các mạng WLAN trên nhiều địa điểm địa lý khác nhau và tăng cường trải nghiệm người dùng mà không cần phải trang bị mỗi nơi một controller. Đây là một yếu tố cốt lõi cho phép triển khai các mô hình kinh doanh dạng cloud, managed service…

Kiến trúc SmartZone cũng cho thấy khả năng xử lý riêng biệt dữ liệu điều khiển và dữ liệu người dùng. Khả năng vSZ-D có thể được đặt trong một subnet riêng cho phép phân cách lưu lượng điều khiển và lưu lượng người dùng trong các mạng của nhà cung cấp dịch vụ. Khả năng vSZ-D có thể đặt được ở các vị trí địa lý khác nhau làm cho việc chuyển tiếp dữ liệu người dùng trở nên linh hoạt hơn.

Kiến thức cơ bản về SAN – Phần 1: Lưu trữ & Quản lý Thông tin

Chào mọi người,


Hôm nay chúng ta sẽ có một cái nhìn tổng quan về Quản lý và Lưu trữ Thông tin (ISM) và biết về  các thành phần của hệ thống lưu trữ thông minh.

Giới thiệu cơ bản

Thông tin ngày càng quan trọng trong cuộc sống hàng ngày của chúng ta. Chúng ta đã trở thành những người phụ thuộc vào thông tin của thế kỷ XXI, sống trong một thế giới theo lệnh, theo yêu cầu có nghĩa là chúng ta cần thông tin khi nào và ở đâu. Chúng ta truy cập Internet mỗi ngày để thực hiện tìm kiếm, tham gia vào mạng xã hội, gửi và nhận e-mail, chia sẻ hình ảnh và video cũng như điểm số của các ứng dụng khác. Tại đây chúng ta có thể tìm hiểu về những điều cơ bản của Thông tin, Sự phát triển của công nghệ Lưu trữ và Kiến trúc và các yếu tố cốt lõi của nó.

Dữ liệu là tập hợp các dữ kiện thô mà từ đó có thể rút ra kết luận. Các bức thư viết tay, một cuốn sách in, một bức ảnh gia đình, một bộ phim trên băng video, bản sao giấy tờ thế chấp được in và ký hợp lệ, sổ cái của ngân hàng và sổ tiết kiệm của chủ tài khoản đều là những ví dụ về dữ liệu.

Ngày nay, dữ liệu tương tự có thể được chuyển đổi thành các dạng tiện lợi hơn như tin nhắn e-mail, sách điện tử, hình ảnh được ánh xạ bit, hoặc phim kỹ thuật số. Dữ liệu này có thể được tạo bằng máy tính và được lưu trữ dưới dạng chuỗi 0s và 1s.

Các loại dữ liệu. Dữ liệu có hai loại.

Dữ liệu có cấu trúc:

Dữ liệu có cấu trúc được tổ chức thành các hàng và cột theo một định dạng được xác định chặt chẽ.

Dữ liệu không có cấu trúc:

Dữ liệu không có cấu trúc nếu các phần tử của nó không thể được lưu trữ trong các hàng và cột, và do đó rất khó để truy vấn và truy xuất bởi các ứng dụng kinh doanh. 

Ví dụ: Địa chỉ liên hệ của khách hàng có thể được lưu trữ dưới nhiều hình thức khác nhau như ghi chú dán, tin nhắn e-mail, danh thiếp hoặc thậm chí các tệp định dạng kỹ thuật số như .doc, .txt,và .pdf. Do tính chất phi cấu trúc của nó, rất khó để truy xuất bằng ứng dụng quản lý quan hệ khách hàng.

Thông tin

Dữ liệu, dù có cấu trúc hay không có cấu trúc, không đáp ứng bất kỳ mục đích nào cho cá nhân hoặc doanh nghiệp trừ khi nó được trình bày dưới dạng có ý nghĩa. Thông tin là trí tuệ và kiến ​​thức thu được từ dữ liệu.

Cơ sở hạ tầng Trung tâm Dữ liệu

Các tổ chức duy trì các trung tâm dữ liệu để cung cấp khả năng xử lý dữ liệu tập trung trong toàn doanh nghiệp. Trung tâm dữ liệu lưu trữ và quản lý một lượng lớn dữ liệu quan trọng. Cơ sở hạ tầng của trung tâm dữ liệu bao gồm máy tính, hệ thống lưu trữ, thiết bị mạng, dự phòng nguồn điện chuyên dụng và kiểm soát môi trường (chẳng hạn như điều hòa không khí và ngăn chặn hỏa hoạn)

Yếu tố cốt lõi

Năm yếu tố cốt lõi cần thiết cho chức năng cơ bản của trung tâm dữ liệu:

Ứng dụng: Ứng dụng là một chương trình máy tính cung cấp logic cho các hoạt động tính toán. Các ứng dụng, chẳng hạn như hệ thống xử lý đơn hàng, có thể được xếp lớp trên cơ sở dữ liệu, từ đó sử dụng các dịch vụ của hệ điều hành để thực hiện các thao tác đọc / ghi vào thiết bị lưu trữ.

Cơ sở dữ liệu: Thông thường hơn, hệ quản trị cơ sở dữ liệu (DBMS) cung cấp một cách có cấu trúc để lưu trữ dữ liệu trong các bảng được tổ chức hợp lý có liên quan với nhau. DBMS tối ưu hóa việc lưu trữ và truy xuất dữ liệu.

Máy chủ và hệ điều hành: Một nền tảng máy tính chạy các ứng dụng và cơ sở dữ liệu.

Mạng: Đường dẫn dữ liệu tạo điều kiện giao tiếp giữa máy khách và máy chủ hoặc giữa máy chủ và bộ lưu trữ .

Thiết bị lưu trữ: Một thiết bị lưu trữ dữ liệu liên tục cho những lần sử dụng tiếp theo.

Yêu cầu chính đối với các phần tử của trung tâm dữ liệu

Tính khả dụng: Tất cả các phần tử của trung tâm dữ liệu phải được thiết kế để đảm bảo khả năng truy cập. Việc người dùng không thể truy cập dữ liệu có thể có tác động tiêu cực đáng kể đến doanh nghiệp.

Bảo mật: Các chính sách, thủ tục và sự tích hợp thích hợp của các yếu tố cốt lõi của trung tâm dữ liệu sẽ ngăn chặn truy cập trái phép vào thông tin phải được thiết lập. Ngoài các biện pháp bảo mật để truy cập máy khách, các cơ chế cụ thể phải cho phép máy chủ chỉ truy cập vào các tài nguyên được phân bổ của chúng trên các mảng lưu trữ.

Khả năng mở rộng: Các hoạt động của trung tâm dữ liệu phải có thể phân bổ khả năng xử lý bổ sung hoặc lưu trữ theo yêu cầu mà không làm gián đoạn hoạt động kinh doanh. Tăng trưởng kinh doanh thường đòi hỏi phải triển khai thêm máy chủ, ứng dụng mới và cơ sở dữ liệu bổ sung. Giải pháp lưu trữ sẽ có thể phát triển cùng với doanh nghiệp.

Hiệu suất: Tất cả các yếu tố cốt lõi của trung tâm dữ liệu phải có thể cung cấp hiệu suất tối ưu và phục vụ tất cả các yêu cầu xử lý ở tốc độ cao. Cơ sở hạ tầng phải có thể hỗ trợ các yêu cầu về hiệu suất.

Tính toàn vẹn của dữ liệu: Tính toàn vẹn của dữ liệu đề cập đến các cơ chế như mã sửa lỗi hoặc bit chẵn lẻ đảm bảo rằng dữ liệu được ghi vào đĩa chính xác như khi nó được nhận. Bất kỳ sự thay đổi nào về dữ liệu trong quá trình truy xuất đều có nghĩa là bị hỏng, có thể ảnh hưởng đến hoạt động của tổ chức.

Dung lượng: Hoạt động của trung tâm dữ liệu yêu cầu đủ nguồn lực để lưu trữ và xử lý một lượng lớn dữ liệu một cách hiệu quả. Khi các yêu cầu về dung lượng tăng lên, trung tâm dữ liệu phải có khả năng cung cấp thêm dung lượng mà không làm gián đoạn tính khả dụng hoặc ít nhất là với sự gián đoạn tối thiểu. Năng lực có thể được quản lý bằng cách phân bổ lại các nguồn lực hiện có, thay vì bằng cách bổ sung các nguồn lực mới.

Khả năng quản lý: Một trung tâm dữ liệu phải thực hiện tất cả các hoạt động và hoạt động theo cách hiệu quả nhất.  Khả năng quản lý có thể đạt được thông qua tự động hóa và giảm sự can thiệp của con người (thủ công) vào các công việc chung.

Vòng đời thông tin 

Vòng đời thông tin là “ sự thay đổi giá trị của thông tin ” theo thời gian. Khi dữ liệu được tạo lần đầu tiên, nó thường có giá trị cao nhất và được sử dụng thường xuyên. Khi dữ liệu cũ đi, nó được truy cập ít thường xuyên hơn và có ít giá trị hơn đối với tổ chức. Hiểu được vòng đời thông tin giúp triển khai cơ sở hạ tầng lưu trữ thích hợp, theo giá trị thay đổi của thông tin.

HP 3PAR CLI command list

showalert        - show status of system alerts
showauthparam    - show authentication parameters
showbattery      - show battery status information
showblock        - show block mapping info for vvs, lds, pds
showcage         - show disk cage information
showcim          - show the CIM server information
showclienv       - show CLI environment parameters
showcpg          - show Common Provisioning Groups (CPGs)
showdate         - show date and time on all system nodes
showdomain       - show domains in the system
showdomainset    - show sets of domains in the system
showeeprom       - show node eeprom information
showeventlog     - show event logs
showfirmwaredb   - show current database of firmware levels
showhost         - show host and host path information
showhostset      - show sets of hosts in the system
showinventory    - show hardware inventory
showiscsisession - show iscsi sessions
showld           - show logical disks (LDs) in the system
showldch         - show LD to PD chunklet mapping
showldmap        - show LD to VV mapping
showlicense      - show installed license key
shownet          - show network configuration and status
shownode         - show node and its component information
shownodeenv      - show node environmental status (voltages,temperatures)
showpatch        - show what patches have been applied to the system
showpd           - show physical disks (PDs) in the system
showpdata        - show preserved data status
showpdch         - show status of selected chunklets of physical disks
showpdvv         - show PD to VV mapping
showport         - show Fibre Channel and iSCSI ports in the system
showportarp      - show ARP table for ports
showportdev      - show detailed information about devices on a Fibre Channel port
showportisns     - show iSNS host information for ports
showportlesb     - show Link Error Status Block information about devices on Fibre Channel port                         
showrcopy        - show remote copy configuration information
showrctransport  - show information about end-to-end transport for remote copy                         
showrsv          - show information about reservation and registration of VLUNs connected on a Fibre Channel port
showsched        - show scheduled tasks in the system
showsnmppw       - shows SNMP access passwords
showsnmpmgr      - show SNMP trap managers
showspace        - show estimated free space
showspare        - show information about spare and relocated chunklets
showsshkey       - show ssh public keys authorized by the current user
showsys          - show system information (system name, serial number etc.)
showsysmgr       - show system manager startup state
showtarget       - show unrecognized targets
showtask         - show information about tasks
showtemplate     - show templates
showtoc          - show system Table of Contents (TOC) summary
showtocgen       - show system Table of Contents (TOC) generation number
showuser         - show user accounts and SSH keys
showuseracl      - show user access control list
showuserconn     - show user connections
showversion      - show software versions
showvlun         - show virtual LUNs (VLUNs) in the system
showvv           - show virtual volumes (VVs) in the system
showvvmap        - show VV to LD mapping
showvvpd         - show VV distribution across PDs
showvvset        - show sets of VVs in the system
checkhealth        - perform checks to determine overall state of the system
checkpassword     - display authentication and authorization details
checkport         - perform loopback test on fc ports
checkpd           - perform surface scan or diagnostics on physical disks
checkld           - perform validity checks of data on logical disks
checkvv           - perform validity checks of virtual volume administrative information.

Hướng dẫn về tốc độ khung hình trong camera giám sát (Frame rate in CCTV)

Đây là bài viết hướng dẫn chuyên sâu về tốc độ khung hình trong camrea giám sát. Đầu tiên, bạn cần phải biết tốc độ của vật thể, thông thường là con người.

Tốc độ của con người

Người di chuyển càng nhanh, bạn càng có nhiều cơ hội bỏ lỡ hành động, Bạn biết “tốc độ” của Frame rate là 1 khung hình / giây (1 fps), 10 khung hình / giây (10 fps), 25 khung hình/ giây (25 fps)… nhưng bạn cần tốc độ bao nhiêu khung hình để ghi hình tin cậy nhất.

Đây là cách mọi người di chuyển:

Đối với một người đi bộ, tốc độ bình thường thì thường là ~4 feet/s (khoảng 1,2 mét / giây) . Đây là video ghi lại người đi bộ bình thường 6 mét trong khoảng 5 giây:

Đối với một người đang chạy, chúng ta có video di chuyển 6 mét trong khoảng 1,25 giây, tức là anh ấy di chuyển với ~5 mét trong 1 giây:

Ví du: Nếu bạn chỉ có 1 khung hình/ giây (1 fps), một người có thể di chuyển từ 1,2 mét tới 4.8 mét trong khoảng thời gian đó. Vì thế chúng ta cần lưu ý điều này khi đánh giá lựa chọn tốc độ khung hình.

Trong hướng dẫn này, tôi xin đề cập đến:

  • Tốc độ mọi người di chuyển ra sao và làm thế nào để so sánh với tốc độ khung hình.
  • Đi bộ: Bạn có những rủi ro nào khi bắt hình một người đang đi bộ ở tốc độ 1, 10 và 30 khung hình / giây.
  • Chạy: Bạn đã nắm bắt được ai đang chạy ở tốc độ 1, 10 và 30 khung hình / giây.
  • Xoay đầu (ngó nghiêng): Bạn nhận mặt mũi rõ ràng của một người như thế nào ở 1, 10 và 30 khung hình / giây.
  • Chơi bài: Bạn không nắm bắt được thông tin gì về bài chơi ở mức 1, 10 và 30 khung hình / giây.
  • Tốc độ màn trập so với tốc độ khung hình: Cả hai có sự liên quan như thế nào?
  • Tỷ lệ băng thông so với khung: băng thông tăng với tăng tốc độ khung hình như thế nào?
  • Tỷ lệ khung hình trung bình được sử dụng: Trung bình trong camera giám sát là bao nhiêu?

Ví dụ đi bộ.

Khi người mẫu đi xuyên qua góc nhìn camera, chúng ta xem anh ấy chuyển từ khung này tới khung khác như thế nào. Trong luồng video 30 fps và 10 fps, anh ấy không hoàn thành một bước đi đầy đủ. Tuy nhiên, trong ví dụ 1fps, anh ta đã tiến tới ~1,2 mét giữa các khung hình, và phù hợp với tốc độ đi bộ của chúng ta đo được ~1,2 mét / giây.

Ví dụ khi chạy.

Khi người mẫu chạy qua góc nhìn camera, luồng 30 fps vẫn bắt kịp anh ta, trong khi ở luồng 10 khung hình / giây, anh ấy đã đi ~0,3 mét giữa các khung. Trong ví dụ 1 fps, chỉ có một khung của đối tượng bị bắt, với góc nhìn của camera giữa các khung, chỉ với chân sau của người mẫu có thể nhìn thấy trong khung thứ hai.

Chụp khuôn mặt

Cố gắng để có được một khuôn mặt rõ ràng có thể khó khăn khi mọi người di chuyển bởi vì họ tự nhiên xoay đầu của họ thường xuyên. Trong video này, chúng ta có người mẫu vừa đi bộ ở hành lang vừa  lắc đầu với tốc độ khung hình khác nhau.
Hãy xem:

Chú ý, ở tốc độ 1 khung hình / giây, chỉ có một cú đánh đầu rõ ràng là bị bắt, nhưng ở tốc độ 10 khung hình / giây, bạn sẽ có nhiều hơn thế. Cuối cùng, ở tốc độ 30 khung hình / giây, bạn có thể nhận được một hoặc hai lần, nhưng không cải thiện nhiều.

Chơi bài

Trong bài kiểm tra này, chủ đề của chúng ta là xử lý một loạt các lá bài từ Át (ace) đến năm với máy ảnh được đặt thành tốc độ màn trập  (shutter) mặc định (1/30).

Trong các ví dụ 30 và 10 fps, chúng ta có thể thấy mỗi lá khi nó được lấy ra từ phía trên bộ bài và đặt trên bàn. Tuy nhiên, trong ví dụ 1 fps, chúng ta chỉ thấy các thẻ xuất hiện trên bàn, không phải là chuyển động của người chơi, vì tốc độ khung hình quá thấp.

Tốc độ màn trập (Shutter) so với tốc độ khung hình (Frame rate)

Tốc độ khung hình không làm mờ hình ảnh. Đây là một quan niệm sai lầm. Điều khiển tốc độ màn trập tự động của camera.

Xử lý thẻ Át thông qua 5 lần nữa, chúng tôi tăng tốc độ màn trập tối thiểu của camera lên 1/4000 giây. Hình ảnh dưới đây so sánh hình ảnh mờ trong tay người chơi và lá bài, với 2 lá bài dễ dàng hơn nhiều trong ví dụ tốc độ màn trập nhanh.

1 / 4000s tốc độ màn trập hoàn toàn loại bỏ tất cả các dấu vết của mờ nhòa hình ảnh. 1/1000 và 1/2000 tốc độ màn trập lần thứ hai làm giảm đáng kể độ mờ, nhưng vẫn có thể thấy được xung quanh tay người chơi và các cạnh của lá bài khi xem khung ghi theo từng khung.
Nếu bạn bị mờ, bạn có vấn đề cấu hình tốc độ màn trập, chứ không phải tốc độ khung hình.

Tốc độ màn trập (Shutter) chậm và Tốc độ khung hình (Frame Rate)

Mặt khác, đôi khi người dùng muốn hoặc nhà sản xuất camera mặc định màn trập tối đa của họ với tốc độ chậm hơn tốc độ khung hình (ví dụ, màn trập 1/4 cho máy ảnh 1/30 giây). Không chỉ gây ra sự mờ của các đối tượng di chuyển , bạn sẽ mất khung hình.
Bài học chính: Tỷ lệ khung hình mỗi giây không bao giờ cao hơn số lần phơi sáng trên mỗi giây (tốc độ màn trập – Shutter). Nếu bạn có màn trập 1 / 4s, màn trập / phơi sáng chỉ mở và đóng 4 lần / giây (tức là 1 / 4s + 1 / 4s + 1 / 4s + 1 / 4s = 1s). Vì điều này chỉ xảy ra 4 lần, bạn chỉ có thể có 4 khung trong giây đó.
Một số nhà sản xuất làm giả khung hình với màn trập chậm, chỉ cần sao chép cùng một khung hình nhiều lần. Ví dụ: nếu bạn có màn trập 1/15, bạn chỉ có thể có 15 lần chụp, và do đó, 15 khung hình. Để làm cho nó có vẻ như bạn có 30 khung hình, mỗi khung có thể được gửi hai lần liên tiếp.
Hãy cẩn thận với màn trập chậm. Ngoài việc mờ, bạn có thể bị mất khung hoặc bộ nhớ bị rác.

Tỷ lệ băng thông so với khung hình

Tỷ lệ khung ảnh hưởng đến băng thông, nhưng đối với các chuẩn nén hiện đại, như H.264, nó ít tỷ lệ thuận hơn. Vì vậy, nếu bạn tăng tốc độ khung hình lên 10x, băng thông tăng có thể sẽ thấp hơn nhiều, thường chỉ có từ 3 đến 5 lần băng thông. Đây là điều chúng tôi thấy thường xuyên bị nhầm lẫn trong ngành CCTV.
Lý do của việc này là nén liên khung, làm giảm nhu cầu băng thông cho các phần của cảnh mà vẫn giữ nguyên trên các khung hình
Minh hoạ thêm điểm này, chúng tôi đã đo 30, 10 và 1 fps để chứng minh sự thay đổi tốc độ bit trong một thiết lập kiểm soát trong phòng thí nghiệm của chúng tôi. Bitrate trung bình như sau:

  • 1 fps là 0.179 Mb / s
  • 10 khung hình / giây, với 10x khung hình, tiêu thụ băng thông 4x nhiều hơn 1 khung hình / giây (0.693 Mb / s)
  • 30 khung hình / giây, với 3x khung hình, tiêu thụ gấp đôi băng thông 10 khung hình / giây và với 30x khung, 7x băng thông 1fps (1.299 Mb / s)

Các phép đo này được thực hiện với 1 I frame trên giây, thiết lập phổ biến nhất trong camera giám sát chuyên nghiệp

Tỷ lệ khung trung bình được sử dụng

Tỷ lệ khung hình ngành công nghiệp trung bình là ~ 10 khung hình / giây, phản ánh mức độ này cung cấp đủ khung để nắm bắt hầu hết các hành động một cách chi tiết đồng thời giảm thiểu chi phí lưu trữ.

Như được hiển thị trong phần trước, đi từ 10fps đến 30fps có thể tăng gấp đôi chi phí lưu trữ nhưng chỉ cải thiện được ít chi tiết.

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