Advanced Configuration

Converting syslogs to IPFIX

The Flow 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 Flow Replicator (SFR) can be set up to provide a fault tolerant environment in case the Primary Flow Replicator (PFR) 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. The first method, if desired, can be used when replicators are on the same subnet.

Traditional Configuration

How it works

The secondary flow replicator (SFR) actively monitors the state of the primary flow replicator (PFR) and frequently synchronizes its database with the settings from the primary.

When a Flow Replicator is in secondary mode, it will no longer maintain its current configuration and any current configuration is lost. At any time, the SFR 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 PFR.

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

Additionally, the SFR continues to monitor the state of the PFR. When the PFR is reachable, replication on the SFR stops. The SFR synchronizes any updates to the PFR database and begins the process of monitoring the state of the PFR.

Requirements

The following requirements must be met to set up a Fault Tolerant Environment:

  • A Primary and Secondary Flow Replicator
  • Each exporter configured to send data to both the Primary and Secondary Flow 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 flow collectors are receiving the replicated data.

Note

The secondary flow replicator requires a fault tolerance license key. To acquire a fault tolerance license key contact plixer directly.

Configuring a secondary flow replicator

Deploy a second Flow Replicator based on the installation instructions earlier in this guide. The role command is used when setting up a fault tolerant environment. Run the following command on the secondary flow replicator:

  • 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 flow 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.

Turning off Fault Tolerance

At anytime, a secondary Flow Replicator can become an independent Flow Replicator 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 and Secondary 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 primary replicator fails, the packets are instantly picked up by the secondary and forwarded to the collectors configured as part of the replicator profiles.

Once the primary is active again, the primary 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 and Secondary Flow Replicator
  • Each exporter configured to send data to a single virtual IP Address

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 flow collectors are receiving the replicated data.

Configuring High Availability

  1. On the master replicator, run the following commands to add the virtual IP address:
REPLICATOR> system virtualip enable eth0 <virtual_ip_here>
  1. Next, declare the IP address of the master:
REPLICATOR> role set ha master <primary_ip>
  1. Next, execute the following to enable High Availability on the primary:
REPLICATOR> role set ha on 101 <virtual_ip_here> eth0 master
  1. The final step for configuring the master replicator is to edit /etc/plixer.ini and delete the line that starts with “primaryip=”
  1. On the secondary replicator, run the following commands to add the virtual IP address:
REPLICATOR> system virtualip enable eth0 <virtual_ip_here>
  1. Next, declare the IP address of the master:
REPLICATOR> role set ha master <primary_ip>
  1. Lastly, execute the following to enable High Availability on the secondary:
REPLICATOR> role set ha on 100 <virtual_ip_here> eth0 backup

Testing a secondary replicator

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

Turning off Fault Tolerance

To turn off High Availability Fault Tolerance, simply 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.