Skip to content

On-Premise mfusion Installation

This page covers installing and turning up on-premise / private mfusion — where you host and manage the mfusion server yourself, on your own appliance or VM.

Info

If you use RansNet's cloud-hosted mfusion, this page does not apply — the cloud gateway is provisioned and managed by RansNet, and devices register to it automatically (see Device Bootstrapping). Skip this page entirely and go straight to Device Bootstrapping for your managed devices. This page is only for deployments running their own mfusion instance.

Private mfusion runs on mfusion, HSG, and mlog appliances. Once installed, it acts as the central monitoring and orchestration server for every RansNet device you onboard to it — see mfusion Overview for what it provides.

Step 1 — Bootstrap Network Connectivity

Before enabling the mfusion service, the appliance itself needs working network connectivity — an IP address, and routing so that it's reachable from every device it will manage, and reachable by administrators who need to access its dashboard.

Follow the standard Device Bootstrapping process to configure the appliance's interfaces and routing, exactly as you would for any other RansNet device.

Note

This is the one case where bootstrapping isn't about a device reaching mfusion — it's about configuring this appliance's own connectivity, since it's about to become the mfusion server that other devices call home to.

Step 2 — Enable the mfusion Service

Once the appliance has network connectivity, enable the mfusion monitoring and orchestration service itself:

mfusion server
 start

Other options available under mfusion server:

(config-mFusion-server)#
  !              Comments
  data-lifetime  Commands to maintain historical data (default 365 days)
  data-reset     reset database to default.
  description    Add description for this configuration.
  do             To run exec commands in config mode
  end            Return back to enable model
  exit           Exit from sub configuration mode
  no             Negate a command or set its defaults
  start          Start monitoring service after changes.
  stop           Stop monitoring service.
  track          Track remote host or route presence to auto start/stop the monitoring service.
Command Description
data-lifetime How long historical monitoring data is retained before it's purged. Defaults to 365 days.
data-reset Resets the database back to its default state.
description A free-text label for this configuration.
start / stop Starts or stops the monitoring service. Run start last, after any other options above are configured.
track Ties the monitoring service's running state to a tracked host or route, for a standalone unit. Don't use it on a redundant pair: there, System Sync starts and stops the service with the unit's role (see Step 4).

Verify the Service Is Running

show mfusion server

Monitoring service:     running
Mail service:           running
Database Access:        YES

Step 3 — Access the Dashboard

Browse to the appliance's management IP over HTTPS, for example:

https://10.10.10.1

Log in with the default administrator credentials, then change the password immediately — see Device Hardening for changing default credentials and other first-login security steps.

Step 4 (Optional) — Redundant mfusion and Data Sync with VRRP

If you need mfusion redundancy — a second unit that takes over automatically if the first fails — pair VRRP with System Sync. VRRP provides a shared Virtual IP (VIP) that always points at whichever unit is currently active; System Sync keeps the second unit's database and files continuously replicated so it's ready to take over.

Configure VRRP between the two units first (see VRRP — Localized HA for the full field reference and CLI). Once the VIP is up on the active unit, it appears as a directly-connected /32 route in that unit's routing table:

DC1-VM56# show ip vrrp
VRRP_ID Priority        Status          Interface       Interface IP    VRRP_VIP
-------------------------------------------------------------------------------------------------
9       120             running         eth0            10.65.31.56/24  10.65.31.197/32
DC1-VM56#

DC1-VM56# show ip route connected
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

C>* 2.1.2.1/32 is directly connected, lo, 03:31:21
C>* 3.3.3.3/32 is directly connected, lo, 03:31:21
C>* 10.1.168.1/32 is directly connected, lo, 03:31:21
C>* 10.1.172.0/22 is directly connected, vxlan1, 03:31:20
C>* 10.2.168.1/32 is directly connected, wg2, 03:31:19
C>* 10.2.172.0/22 is directly connected, vxlan2, 03:31:20
C>* 10.17.1.0/30 is directly connected, wbond5, 03:31:05
C>* 10.65.31.0/24 is directly connected, eth0, 03:31:22
C>* 10.65.31.197/32 is directly connected, eth0, 03:06:48
C>* 10.69.69.0/30 is directly connected, tun10, 03:31:20

10.65.31.197/32 — the VIP — only shows as a connected route on the unit that currently holds it. This is exactly the mechanism System Sync uses to determine which unit is primary: configure track route against the VIP under mfusion sync — the only tracking the pair needs. System Sync then switches the database role and the services that belong on the primary (monitoring server, RADIUS server, log server) together.

!
mfusion mysql-server
 start
!
mfusion sync
 remote-ip 10.65.31.53 mac 00-50-56-9b-43-fa
 local-ip 10.65.31.56
 track route 10.65.31.197/32 30 log
 enable
!
security radius-server
 start
!
security log-server
 start
!
mfusion server
 start
!

Configure the second unit the same way, with remote-ip and local-ip swapped.

Key points:

  • Only mfusion sync tracks the VIP (10.65.31.197/32). When this unit holds the VIP, track route passes, this unit becomes System Sync's primary (read/write database), and System Sync starts the monitoring server, RADIUS server and log server. When the VIP moves to the other unit, track route fails here: System Sync stops those services, then demotes this unit to secondary (read-only).
  • mfusion server, security radius-server and security log-server are configured with a plain start on both units, without their own track. On the secondary, their start is held by System Sync until the unit is promoted — see System Sync — Services by Role.
  • This avoids ever running two monitoring engines, or two RADIUS servers writing accounting records, against diverging databases — only the unit that holds the VIP (and is therefore reachable at the address devices call home to) runs them. The secondary keeps logging locally.
  • See System Sync — CLI Configuration for the full mfusion sync reference, and System Sync — Determining System Role for why track route (rather than track icmp/track tcp) is required against a shared VIP.

Upgrading from the earlier setup

Earlier releases also needed track route under mfusion server. With System Sync handling the services, remove it on both units so only one tracker decides:

mfusion server
 no track route 10.65.31.197/32 30 log
!
  • Device Bootstrapping — configuring network connectivity on any RansNet appliance, including this one
  • VRRP — shared Virtual IP redundancy between two units
  • System Sync — database and file replication, and primary/secondary role determination
  • Device Hardening — changing default credentials and other first-login security steps
  • Administration — ongoing mfusion configuration once the service is running (SMTP, backup, audit logs, and more)