BQN Docs

How to Update the Software

‍

Updates within the same major release

To update within the same major release (e.g. from R4.7.1 to R4.8.3), only the bqn package needs to be updated (e.g. bqn-R4.8.3.bpkg). The update consists of two steps: first it is installed and then it is activated. The activation involves a traffic interruption of some seconds, so it is advised to carry it out at times of low throughput.

The installation is performed in Administration->Software, clicking on the ⁝ menu icon and selecting Install… A file selector pops up to choose the package, that it is transferred to the BQN server and installed.

The activation is done in Administration->Software clicking on the ↶ arrow icon of the package to activate (highlighted in red in the picture below).

This operation forces you to log back into the BQN after a few seconds, during which time, the traffic flow is interrupted.

‍

Updates across major releases

Contact support@bequant.com for detailed instructions before performing an upgrade to a new major release.

‍

To migrate to a new major release (e.g. from R3 to R4), the platform packages will need updates (bqnos, kernel, bqnkernel, linux and gui), in addition to the bqn package. Platform packages require a reboot to be activated. The process is the following:

1.       Install new bqnos, wait for one minute and reboot

2.      Install kernel and bqnkernel (together in in this order), wait for one minute and reboot

3.      Install linux, wait for one minute and reboot

4.      Install gui and reboot

5.      Install bqn and reload

 The server must be placed out of the traffic path, as server reboots will involve service losses.

Finally, the old configuration may require migration to the new release.  As a minimum, you will have to remove deprecated commands accessing the BQN server via SSH and running the commands:

 
bqnadm@bqn# configure
bqnadm@bqn(config)# clear config undefined
bqnadm@bqn(config)# commit
%WARN: Verify configuration after deleting undefined commands
bqnadm@bqn(config)# end
bqnadm@bqn# exit

‍

How to Generate a Diagnostic

When requested by Bequant support, a diagnostic file can be generated in Administration->Diagnostic.

The file will be placed in the download folder of the browser being used.

‍

How to Back up the Configuration

You can save the server configuration to a local file in Administration->Backup->Save.

To load a previously saved backup, go to Administration->Backup->Load.

There are three options:

• Load a backup from another server. The purpose of this option is to bring a common configuration to a number of servers, with the same policies and API clients. When this option is used, only those generic sections of the configuration are loaded. Server specific parts (management interface configuration, data wires, licenses and API BQN own IP address) are left untouched.
• Restore a backup from this server. This option is used to recover a previous state of this server configuration. In this option, the configuration is completely replaced by the backup one, so it is important that the configuration comes from this very server, otherwise the server may be left unreachable.
• Merge a configuration file with this server configuration. This option is useful to carry only some configuration sections, for example a set of policy rules. In this option, the whole configuration in the file is added to the current configuration. Only generic configuration sections and of them, only the ones strictly needed should be included in the merge file,in order  to avoid conflicts. For example, a configuration can have only one management default gateway, so merging a file containing a default gateway will replace the old one.

Select the load option and press SELECT FILE. Select the file to load and press Open.  A dialogue will inform of the operation outcome (if OK or if an error is found). If there is an error, no modification is done to the server configuration (load operation is atomic).

‍

Monitoring with SNMP

The BQN supports the following SNMP v2c alarms (traps):

• Cpu: excessive server CPU load.
• Memory-dpdk: excessive memory usage in DPDK packet processing.
• Memory-pool: excessive memory usage in BQN general memory pool.
• Disk: file system full or almost full.
• Process: some mandatory processes down.
• Traffic-uplink: no traffic in the uplink direction.
• Traffic-downlink: no traffic in the downlink direction.
• Traffic-low: low traffic (uplink and downlink directions combined).
• Traffic-inverted: uplink throughput higher than downlink throughput (possibly because some wires are inverted, with access port connected to the Internet and vice versa).
• Wire: no wires configured or some wires down.
• ‍License-available: no license defined or license invalid.
• License-expiration: license has expired.
• License-usage: server throughput is above the license capacity.
• Time: no NTP server configured or not reachable.
• ‍Bqnmgr: BQN remote management system not reachable.

These alarms are related to the dashboard shown in BQN homepage. See the Troubleshooting section for more information.

To configure the SNMP agent, go to Administration->SNMP:

The BQN SNMP also exports some system statistics. To get the BQN MIB files, click here.

‍

Traffic Captures

The BQN can be used to get traffic captures in pcap format from any of its network interfaces Those captures can be used to troubleshoot issues in the BQN server, but also somewhere else in the network, as direct traffic captures are many times difficult to obtain in other network nodes.

Traffic captures are indicated with a magnifying glass icon next to the interface name. It is available in the following pages:

• ‍Status->Interfaces->Link State
• ‍Status->Interfaces->Data Wires

Clicking in the icon displays a dialogue with the capture options:

The filter field accepts the format of tcpdump filters. If is optional, and if empty, all traffic will be captured. Some filter examples:

• Traffic involving an IP address: host 10.0.0.23
• TCP traffic involving an IP address and port: tcp and host 10.0.0.23 and port 443
• UDP traffic involving an IP subset to a specific Internet address: udp and net 10.0.0.0/24 and host 8.8.8.8

If the network has VLANs and/or PPPoE, the corresponding toggle switch must be set for the filter to work. In the previous screenshot, the network has VLANs.

Maximum capture file size (up to a maximum of 500MB). The capture will stop when this size is reached.

Capture timeout (600 seconds maximum). The capture will stop when this time elapses. It can also be stopped before that pressing the CANCEL button,

The capture is limited by a maximum size and timeout(whatever happens first). The reason is to protect the system, because traffic captures has a performance impact.

To reduce the performance impact on the system, use the smallest size and duration meeting your needs.

Once the capture is complete, a pcap file will be generated in the browser download folder. The file can be inspected using a traffic tools supporting the pcap format, for example wireshark.

‍

Logs

In order to help in the debugging of complex issues, the GUI displays two types of logs:

• OS log messages. Go to Administration->Logs->System.
• Kernel log messages (output of dmesg command). Go to Administration->Log->Kernel.

It is possible to request more log lines and to export the log entries to a local file.

‍

System Users

The BQN system has two types of users:

• Administrators: with unrestricted access to the node functionality, including configuration changes and software installation. By default, a user named bqnadm is created with administration profile.
• Operators:  with access only to data visualization. By default, a user named bqnop is created with operator profile.

An administrator can create, delete or modify system users in Administration->Users.

‍

‍

Software Bypass

It is possible to make some traffic to go through the BQN transparently, without being processed by BQN. Such traffic will be captured in one of the network interfaces and relayed transparently to its peer interface in the same wire. That way, the BQN software will have no impact on such traffic.

The kind of traffic that can be configured to be bypassed are:

• IP traffic v4
• IP traffic v6
• Traffic with some specific VLAN tags.
• Traffic without a VLAN tag (i.e. untagged).
• Some IPv4 and/or IPv6 addresses or address ranges.

‍

To bypass some traffic, go to Configuration->Optimization Settings and enable the corresponding toggle.

For VLANs and IP ranges, type in the value, press + to add it and apply the settings.

Take into account that bypassed traffic will not benefit from BQN features: it will not be optimized, no metrics will be recorded and no policies applied.

‍

Secure Setup

‍

Session Timeout

A configurable timeout will disconnect a GUI session after a time of inactivity.

To enable the inactivity timeout, go to Administration->General Settings and set the value in seconds in GUI inactivity timeout and press Apply.

The inactivity timeout will be applied to new sessions.

‍

Strong User Passwords

By default, when setting a user password, any value is valid. It is possible to strengthen the system security by forcing some minimum complexity to user passwords. To do so, go to Administration->General Settings and set the to On the switch Strict password and login security.

‍

When the strict password switch is set to On, the following minimum password complexity is enforced (and password change rejected if not met):

• Length of at least 8 characters.
• At least one lowercase letter.
• At least one uppercase letter.
• At least one digit.
• At least one special character.
• The username cannot be part of the password, either straight or in reverse form. For example, if user is bqnadm, passwords Bqnadm6? and Mdanqb6? are rejected.

In addition, the password must pass pam_cracklib simplicity test. This test rejects poor passwords such as:

• Dictionary words
• Palindromes. E.g. Af16-61fA
• Same consecutive characters. E.g. …aaa…
• Too long monotonic sequence. E.g. …123… or …abc…
• Less than five differences with the old password.

Also, the account is blocked for five minutes after five consecutive failed login attempts. Root is excluded from this policy to avoid denial of service attacks.

‍

Management Interface Firewall

To set up the management interface firewall, which will only apply to the management interface (not to the interfaces configured in wires) select on the lateral menu Configuration->Interfaces->ManagementFirewall. This will show the IP address ranges allowed to access the management interface. By default, no IP address ranges are configured, and all are allowed.

To add an allowed IP address range, click the  menu icon and press on Add IP Address Range…. Once one IP address range is allowed, the firewall is enabled, and all incoming connections from IP addresses not part of the configured IP address ranges will be blocked. It is therefore important to include an IP address range that covers the IP address from which we are accessing the GUI and also the subnet of the management IP address (the GUI will include them in the suggested list). Other IPs that interact with the management interface, such as RADIUS/REST clients, a billing system and the NTP server, should also be included.

To disable the firewall, remove all entries pressing the delete icon next to each entry, and once all entries are deleted, click once the Apply button. It is important not to press Apply before all entries have been deleted, because a premature Apply would keep the firewall active and it may prevent you from accessing the server, if the entry covering your IP is not present.

‍

Hide Per-subscriber Service Information to Operators

It is possible to configure the system so users with operator profile do not see the following information:

• In Subscriber dashboard, the DPI service details.
• In Subscriber dashboard, in the active flow table, the DOMAIN column.
• In Statistics->DPI ServiceAnalysis->Hourly Volume Per Service, the IP/Subscriber ID filter.
• In Statistics->DPI Service Analysis->Total Volume Per Service, the IP/Subscriber ID filter.

To disable access to that information, go as administration to Administration->General Settings and disable the switch DPI per subscriber for operator profiles.

‍

Audit log

The system keeps an audit log with a register of the most relevant actions performed in the system. The files are in /opt/bqn/var/audit and readable only by the root user.

The current audit file is called audit and old audit files will be compressed with gzip and named with the Unix epoch time of rotation (e.g. audit-1688636727.gz). Old files are kept for 182 days.

Each file row is an audit entry with the following fields:

• Time: Date and time of the event, in format YYYY-mm-ddTHH:MM:SS+UTC-Offset.
• Type: Type of action: access, config, software, system, users.
• Author: Name of the system user performing the action, in the cases where it is available.
• Description: Action description.

Some of the registered actions are:

• Access to the system.
• Users created/deleted.
• User password modifications.
• Configuration changes.
• Software updates.
• System reboot or shutdown.
• Time local/zone changes.

‍

Sending system logs to a syslog server

It is possible to configure the BQN to send its system logs to an external syslog server. The syslog server must support BSD syslog protocol (IETF RFC 3164) or syslog protocol (IETF RFC 5454).

To do the setup, log as root via SSH and follow these steps:

‍

Create the following directory, so the changes are persistent:

mkdir -p/bqn/root/etc/rsyslog.d/

Copy the original configuration file into that directory:

cp /etc/rsyslog.d/remote.conf /bqn/root/etc/rsyslog.d/

Edit the configuration file:

vim /bqn/root/etc/rsyslog.d/remote.conf

If  the BSD syslog protocol is used (IETF RFC 3164), add this line to the configuration file:

*.* action(type="omfwd" target="server-ip" port="server-port" protocol="tcp")

Replace server-IP by the syslog server IP address and server-port by its port (e.g. 514).

‍

If the format needed is syslog protocol (IETF RFC 5454):

*.* action(type="omfwd" target="server-ip" port="server-port" protocol="tcp"  template="RSYSLOG_SyslogProtocol23Format")

Reboot the system:

reboot

And that’s it, the BQN system logs in /var/log/messages should be sent to the syslog server.

‍

If later on, you do changes to the configuration file, you need to restart the rsyslog service for the changes to be applied:

systemctl restart rsyslog.service

Check that the service is OK by requesting its status:

bqn:~ # systemctl status rsyslog.service
rsyslog.service - System Logging Service
   Loaded: loaded (/bqn/img/linux/usr/lib/systemd/system/rsyslog.service; enabled)
   Active: active (running) since Thu 2023-10-05 10:37:17 CEST; 1 months 10 days ago
 Main PID: 6992 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           `-6992 /usr/sbin/rsyslogd -n
. . .

‍

Configuration using TLS

To encrypt the communication with the syslog server, the BQN needs the package linux-R3.0.13-20231130 or later. Transfer the server certification authority certificate to the BQN server rsyslog directory:

scp ca.pem root@bqn:/bqn/root/etc/rsyslog.d

Edit the configuration file:

vim /bqn/root/etc/rsyslog.d/remote.conf

Add the following lines before the . action line (chosen port is normally 6514, review it in action line):

$DefaultNetstreamDriverCAFile /bqn/root/etc/rsyslog.d/ca.pem
$DefaultNetstreamDriver gtls # use gtls netstream driver
$ActionSendStreamDriverMode 1 # require TLS for the connection
$ActionSendStreamDriverAuthMode anon # server is NOT authenticated

To apply the changes, restart the rsyslog service:

systemctl restart rsyslog.service

‍