Assignment of roaming Collectors
Overview
When a device is roaming, the changes to its network connection usually trigger a change of its IP address and Active Directory Site. If your rules to assign Collectors to a particular Engine depend on these properties of the device, a roaming device may switch to a another Engine every time that it connects to a different network.
Avoiding the switching of devices from one Engine to another has the following advantages:
Improvement of data organization, because a device always sends data to the same Engine.
Economy of licenses, because devices do not consume additional licenses on other Engines.
To avoid repeated switching between Engines of roaming devices, set a reassignment delay (stickiness) value, so that a device can switch from its assigned Engine only after the delay has elapsed.
Roaming devices that connect to a VPN may also have suffer from assignment issues if two different locations reuse the same VPN subnetwork. In the last part of this article, we consider the VPN case in detail.
Configuring the Collector stickiness
To set the stickiness in number of days:
Log in to the CLI of the primary appliance.
Optional: Verify the current stickiness with the command below. If no value was previously set, the command returns an error message because the key does not exist, which implies default stickiness:
nxconsul kv get config/nxassignment/standardType in the following command, where N is the delay in number of days that must elapse before the system considers that a device is roaming:
nxconsul kv put config/nxassignment/standard \nxassignment.stickiness.number-of-days=N
Stickiness special values:
The default stickiness value is 10 days.
A stickiness value of 0 days triggers a change of Engine on every network reconnection, according to the assignment rules.
Determining when a device is roaming
A device may change from assigned Engine because:
The properties (name, IP address, AD site or Collector tag) of the device change and a different assignment rule applies.
An administrator activates a different set of assignment rules.
The system considers that a device is roaming in the first case only, that is, when the properties of the device change. Therefore, the stickiness value is enforced only when a device is roaming and not when modifying the assignment rules.
Note however that devices that are regarded as roaming devices are not necessarily moving from one network to another. For instance, modifying the name of a device in a way that triggers a switch of assigned Engine as a result also makes the device to be treated as a roaming device.
See whether a particular device is considered to be roaming (in the broad sense of the word defined above) from the Collectors page of the Portal.
Entity assignment of roaming devices
When rule-based assignment is based on the IP address of devices, sticky roaming devices usually get the empty entity (-) assigned.
The reason is that a sticky roaming device that switches networks gets a different IP address, but keeps pointing to the same Engine. If this new IP address does match any of the IP rules in the original Engine, which is usually the case when networks are partitioned to differentiate entities, the device is assigned to the default empty entity.
In general, to determine the entity that holds a roaming device, the properties of the device are matched against the rules of the Engine that is receiving its traffic.
Roaming devices on Virtual Private Networks
In some scenarios, two different locations in a corporate network may reserve the same subnet addresses for VPN access. For instance, let us imagine a set of assignment rules that try to map a single VPN subnet address to two different entities or Engines:
Engine | Entity | Field1 | Pattern1 |
France | Paris | ip | 192.168.10.0/24 |
Switzerland | Nyon | ip | 192.168.10.0/24 |
As the VPN subnet is the same for both locations, when exclusively using the IP address as condition in the rules to assign Collectors, devices will always be assigned to the Engine in France, because the first rule takes precedence over the second.
To solve this issue, add a second rule based on a different field other than IP address to disambiguate. Of course, this solution requires that you can identify devices by that other field:
Engine | Entity | Field1 | Pattern1 | Field2 | Pattern2 |
France | Paris | ip | 192.168.10.0/24 | name | FR-* |
Switzerland | Nyon | ip | 192.168.10.0/24 | name | CH-* |
Alternatively, if no other field can help distinguish your devices, use the stickiness value to keep devices on the VPN assigned to the same Engine. This solution works if roaming devices are usually connected to the office network and they only move to VPN access from time to time, where the period on the VPN is lower than the delay specified as stickiness. In this way, they will never switch the Engine, although you will never see them in the entity assigned to the VPN either.
RELATED TASK
Last updated