Babel, neither any other dynamic protocols currently in RipEX2, does not involve RSS/MSE reading so you cannot say that if RSS drops under e.g., -90 dBm, switch the routing path. On the other hand, if the link is unstable and unreliable, hello packets will be lost from time to time and Metric will be increased which might eventually end up in using some alternative route.
As already mentioned within examples, consider Hello intervals together with SCADA protocol requirements. Using 4 RipEX2 units, these were measured values on the RF channel (just several examples):
Hello interval: 5 seconds, Multiplier: 2, ~ 1 pps, 792 bps
Path switching usually within several tens of seconds, up to 2 minutes
Hello interval: 15 seconds, Multiplier: 4, ~ 0.3 pps, 224 bps
Hello interval: 20 seconds, Multiplier: 3, ~ 0.2 pps, 168 bps
Path switching usually 1-3 minutes
Hello interval: 30 seconds, Multiplier: 4, ~ 0.1 pps, 102 bps
Path switching between approx. 30 seconds and 5 minutes
It might be beneficial to statically define those packets should primarily go over repeater “A” and only if this link fails, use repeater “B”, or even direct link. Babel (and OSPF/BGP) work in background and logic is based on metrics and particular algorithms. It is not possible to manually define it this way as with RipEX Backup paths. Only the received cost can be set to higher or lower values, but per unit/interface, not per neighboring IP. E.g., one repeater can have Rx cost set to 100, whereas second one 200. This can prioritize the first one.
It is also possible that while topology changes, the metric can change up and down for multiple paths. It can switch to turned off path again, because even other metrics are being increased. Eventually, the path over turned off repeater gets a metric of 65535 and then disappears completely.
For any other advanced setup, contact our technical support support@racom.eu.