14.8.0 Multiple boosters

[Pierre-Nicolas]

We have identified an issue happening for setups with multiple boosters ; this issue is linked to NATs, the internal notification system, and how it is configured on boosters.

Boosters are currently incorrectly configured to have the same server_name while NATs expects each booster to have a unique server_name.

FileWave 14.9.0 fixes the configuration, but in the meantime you can fix it by changing the following booster setting:

In

/usr/local/etc/filewave/nats

or

C:\ProgramData\FileWave\FWBooster\nats

remove in booster.conf files any line with

server_name: "FileWave NATS Booster"

and restart boosters.

Sorry for the inconvenience.

[HCCSC John H]

Does this apply if you have a DNS 'round robin' type of record for your FW Boosters-where you have one internal DNS record for all of your boosters for load balancing? For external we have one DNS to internal IP NAT

[Josh Levitsky]

43 minutes ago, HCCSC John H said:

Does this apply if you have a DNS 'round robin' type of record for your FW Boosters-where you have one internal DNS record for all of your boosters for load balancing? For external we have one DNS to internal IP NAT

My understanding is that this change is so that the boosters don't all present themselves to the server or other boosters as "FileWave NATS Booster" so it would apply. 

[Pierre-Nicolas]

The issue is limited to the notification system - all boosters are connected to the server (for notification, boosters are not chained, they all go directly to the server).

Notifications are used for various internal needs : it is used when you upgrade boosters from FileWave admin, or it can be used when you remove a client from FileWave - this invalidates the client certificate used by the device, and a notification is sent to all boosters to tell them to update their CRL (Certificate Revocation List), to ensure a removed device can't connect to boosters.

The issue is that the server requires notification peers to have a unique name, and it closes any connection with the same name when a new one occurs. So as all our boosters have the same name, the notification system is constantly dealing with "same" booster reconnecting.

This has a negative impact on features using notifications on boosters (as mentioned, booster upgrade mechanism may be degraded), but also has an impact on server performance as it has to recycle resources constantly for each re-connection.

To reiterate, it limited to the notification system, not on how you name your boosters and how you set them up for fileset delivery.