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 — see Redundant mfusion and Data Sync below.

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, and it's what lets mfusion server itself follow the same active/standby state: configure track route against the VIP under both mfusion sync and mfusion server, so both the database role and the monitoring service switch together.

!
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
!
mfusion server
 track route 10.65.31.197/32 30 log
 start
!

Key points:

  • Both mfusion sync and mfusion server track the same 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 the monitoring service starts. When the VIP moves to the other unit, track route fails here, System Sync demotes this unit to secondary (read-only), and the monitoring service stops.
  • This avoids ever running two independent, actively-writing monitoring engines against diverging local databases — only the unit that actually holds the VIP (and is therefore reachable at the address devices call home to) runs the service.
  • 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.
  • 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)