Advanced configuration

Converting syslogs to IPFIX

The Replicator is capable of converting syslogs into IPFIX. A global configuration setting convertSyslog specifies what UDP port to convert.

REPLICATOR> show setting convertSyslog

+-------------------------------+-------------------------------+----------+
| convertSyslog                 | 514                           | Enabled
|
|  When enabled, syslogs sent to the specified port will be converted to
|  IPFIX and sent to the sender port(s) in the profile.
+-------------------------------+-------------------------------+----------+
Done in 0.168892 secs

By default, this functionality is disabled.

+--------------------------------+-----------------------------------------+
| syslog                         | IN PORT 514 -> OUT PORT 9995
+--------------------------------+-----------------------------------------+

 Policies                     Exporters     ->    Collectors
 (include) 0.0.0.0/0          10.1.1.242          10.1.10.1
                              10.1.1.249          10.1.4.101
                              10.1.1.252          10.1.4.19
                              10.12.1.98          10.1.4.222
                              10.3.1.1            10.1.4.93
                              192.168.21.254
                              24.39.1.172

+--------------------------------+-----------------------------------------+
Done in 0.009376 secs

If convertSyslog is disabled, a syslog received from one of the exporters on port 514 is replicated as a syslog to all the collectors on port 9995.

If convertSyslog is enabled and set to 514, the same syslog received from one of the exporters on port 514 is converted and replicated as IPFIX to all the collectors on port 9995. The syslog will not be replicated as a syslog.

Fault tolerance

A second Replicator can be set up to provide a fault tolerant environment in case the primary Replicator goes offline.

A fault tolerant environment will function with either a virtual or hardware appliance. There are two methods available for fault tolerance environments.

The first method (i.e. traditional method) is used when two Replicators exist on different subnets. The second method (i.e. high availability) can be used when two Replicators are on the same subnet.

Note

If desired, the traditional method can also be used when Replicators are on the same subnet.

Traditional configuration

How it works

The secondary Replicator actively monitors the state of the primary Replicator and frequently synchronizes its database with the settings from the primary.

When a Replicator is in secondary mode, it will no longer maintain its current configuration and any current configuration is lost. At any time, it will not allow any configuration changes. With the exception of the role and show commands, all profile and global configuration must be changed on the primary Replicator.

If the secondary Replicator determines that the primary is offline, it attempts to contact collectors. If the collectors are reachable, the secondary Replicator takes over replication based on the configured profiles in the last known good synchronized database. If the collectors are not reachable, it maintains the secondary status until a collector or the primary Replicator is reachable.

Additionally, the secondary Replicator continues to monitor the state of the primary. When the primary Replicator is reachable, replication on the secondary appliance stops. The secondary Replicator synchronizes any updates made to the primary database and begins the process of monitoring the state of the primary Replicator.

Requirements

The following requirements must be met to set up a fault tolerant environment:

  • A primary and secondary Replicators;
  • Each exporter configured to send data to both the primary and secondary Replicator IP addresses

A primary and secondary server can be a mix of virtual and hardware appliances. Configure the primary with the desired profiles, global configuration settings, and verify the collectors are receiving the replicated data.

Note

The secondary Replicator requires a fault tolerance license key. To acquire a fault tolerance license key contact Plixer directly.

Configuring a secondary Replicator

After deploying a second Replicator, use the role command to set up a fault tolerant environment:

  • role set secondary <primary_Replicator_ip:listener_port> [timeout]

Replace the <primary_Replicator_ip> with the IP address of the primary server and <listener_port> with a port on which the primary is actively listening for packets.

The timeout represents the number of consecutive missed polls before the secondary takes the role as the primary. The default is 2 polls if timeout is not passed in.

REPLICATOR> role set secondary 10.1.4.66:2002 3

Testing a secondary Replicator

Once the Replicator has been successfully set to secondary, the last step is to verify connectivity to the primary.

  • role test secondary
REPLICATOR> role test secondary

The fault tolerant environment is active if the test runs successfully.

Disabling fault tolerance

At anytime, a secondary Replicator can become a stand-alone appliance by issuing the role set primary command.

REPLICATOR> role set primary

High availability

How it works

Packets are sent to a virtual IP address that both the primary/master and secondary/backup Replicator are configured to listen for traffic. The primary and secondary configurations each contain a priority so the Replicators are aware of their role.

When the master Replicator fails, the packets are instantly picked up by the backup and forwarded to the collectors configured as part of the Replicator profiles.

Once the primary is active again, it starts forwarding the packets to the configured collectors. This method can be used to set up redundancy beyond a primary and secondary role.

Requirements

The following requirements must be met to set up a fault tolerant environment:

  • A primary/master and secondary/backup Replicators;
  • Each exporter configured to send data to a single virtual IP address.

Primary and secondary servers can be a mix of virtual and hardware appliances. Configure the primary with the desired profiles, global configuration settings, and verify the collectors are receiving the replicated data.

Configuring high availability

  1. On the primary/master Replicator, run the following commands to add the virtual IP address:
REPLICATOR> system virtualip enable eth0 <virtual_ip_here>
  1. Set the IP address of the master:
REPLICATOR> role set ha master <primary_ip>

Note

When prompted, enter the root user’s password for the primary/master Replicator.

  1. Enable high availability on the primary Replicator:
REPLICATOR> role set ha on 101 <virtual_ip_here> eth0 master
  1. On the secondary Replicator, run the following commands to add the virtual IP address:
REPLICATOR> system virtualip enable eth0 <virtual_ip_here>
  1. Enter the IP address of the master:
REPLICATOR> role set ha master <primary_ip>
  1. Enable high availability on the secondary:
REPLICATOR> role set ha on 100 <virtual_ip_here> eth0 backup

Note

When prompted, enter the admin user’s password for the primary/master Replicator.

Testing a secondary Replicator

  1. Run the following command on both the primary and secondary Replicators:
REPLICATOR> role test ha
  1. Purposely shutdown the master Replicator and ping the virtual IP. If a response is received, high availability has been properly configured.
  2. Restart the master Replicator.

Disabling high availability

To turn off high availability, run the following command on the primary and secondary Replicators.

REPLICATOR> role set ha off
REPLICATOR> system virtualip disable eth0 <virtual_ip_here>

Closed networks with no gateway

This configuration currently requires root access and a reboot of the Replicator.

In the /etc/sysctl.conf file, there is a setting called net.ipv4.all.rp_filter. When this value is set to 1 (i.e. net.ipv4.all.rp_filter = 1), all packets that come into an interface that the host doesn’t have a route are filtered (dropped).

For example: a user has a closed network of 192.168.250.x with no gateway. The packets sent to the Replicator that were not 192.168.0.0/24 are dropped and never replicated to any configured collectors.

The solution is to edit the /etc/sysctl.conf file and change net.ipv4.all.rp_filter = 1 to net.ipv4.all.rp_filter = 0. A reboot is required.