Starting from Saturday 11 july, the measured amplitudes of the 6 MHz and 56 MHz lines became noisy for an unknown reason. The 2 signals became noisy at the same time so we suspected a problem with the LNFS box that generates the two lines, while the 22MHz, generated on a different synthesizer (LNFS_2) doesn't show the same problem. 
In order to test this hypothesis, on July 15 at 9:00 UTC, the two LNFS boxes were exchanged, and the rms on the measured signal amplitude returned to normal. The rms of the 22MHz signal amplitude remained unchanged, and did not increase after the intervention.
At this point, we don't know exactly what causes the signals to become noisy. A similar phenomenon has been already observed in the past, when the problem was associated to a temperature problem in the INJ IER. The temperature in IER rose by a few degrees and became more unstable since last month. This might be an explaination for the problem even if there is not a direct correlation observed at the moment.
The two LNFS boxes may be exchanged again in the future or swapped with one spare.
The swap of the two LNFS done on July 15th has been done without exchanging the eth address of the devices. As a consequence, while restarting the automation, it was trying to communicate with the old address, thus inverting the {6, 8, 56 }MHz signals with the {22, 81}MHz. We stucked at the Fmoderr state of the INJ node, untill we swapped the ethernet cables of the two LNFS (to be noted: it seems there is the possibility to swap the ports directly into the configuration file of the LNFS server.
Because of this, we found a peculiar corner case of the FmodErr loop: after the exchange of address, the LNFS_FREQ_3 was not anymore setted on 56MHz (was instead the old 81). The check of the Fmod, however, is based on a 56MHz demodulated channel, that gave 0 correction to the loop. Eventually, no change (both MC_Z or LNFS) has been requested, and the 8Mhz frequency has not been changed (and so the 6 and 56, which are automatically updated once the 8 changes).
As a result, this morning we didn't have any modulation at 56MHz. The problem has been solved applied a reset of the 8MHz.
The Fmod loop will be updated consequently.