Hi Daniil,
Thanks for your interest and feedback. We would like to share some more details about our implementation.
1. Fully ported and optimized VyOS for industrial embedded hardware platforms
Yes, we made some modifications to the VyOS build process to support our industrial embedded hardware platforms.
Our current deployment is based on ARM64 platforms, so we customized the build process, including kernel configuration, hardware support, and platform-specific components.
The same approach can also be applied to x86-64 industrial platforms. The main differences are related to hardware drivers and kernel configuration.
We tried to keep our modifications aligned with the existing VyOS architecture as much as possible, rather than maintaining a completely independent fork.
2. Dual 5G modules with Linux native PRP
We believe this capability could be a candidate for integration into upstream VyOS.
Our 5G modules operate in QMI/MBIM mode and can be managed through ModemManager.
The architecture is:
VyOS
|
+---------+---------+
| |
WWAN interface WWAN interface
| |
ModemManager ModemManager
| |
QMI/MBIM QMI/MBIM
| |
5G modem 5G modem
| |
GRETAP GRETAP
| |
+------- PRP -------+
|
Industrial L2 network
The PRP implementation is independent from the modem management layer and operates above the WWAN interfaces.
The implementation is based on the Linux kernel HSR/PRP subsystem, with VyOS CLI integration added for configuration and monitoring.
Some kernel configuration changes are required to enable the Linux native HSR/PRP functionality.
The L2 transport path is provided through GRETAP tunnels over the 5G WWAN interfaces, while PRP operates above these transport paths to provide frame duplication and duplicate discard functionality.
The current implementation includes:
-
Two independent 5G WWAN interfaces using QMI/MBIM mode
-
ModemManager for modem management
-
Linux native HSR/PRP subsystem for Layer 2 redundancy
-
GRETAP tunnels for L2 transport
-
PRP duplicate transmit and discard processing
This architecture enables hitless Layer 2 redundancy during 5G handover events and avoids the service interruption normally caused by cellular mobility events.
We also integrated HSR/PRP interface creation, configuration, and monitoring into the existing VyOS CLI framework.
Example:
admin@CPE# set interfaces hsr
Possible completions:
> hsrN HSR interface name
> prpN PRP interface name
Example configuration:
admin@CPE# set interfaces hsr prp38
Possible completions:
+ address IP address
description Description
disable Administratively disable interface
disable-link-detect Ignore link state changes
interlink Interlink interface
mtu Maximum Transmission Unit (MTU)
protocol Redundancy protocol
slave1 First slave interface
slave2 Second slave interface
supervision Supervision address
version HSR protocol version
vrf VRF instance name
3. L2 TCP MSS adjustment
Regarding the L2 TCP MSS clamping description in our previous message, we would like to clarify one point.
The current implementation does not directly use the nftables netdev hook. Instead, it uses the existing VyOS bridge MSS adjustment functionality, which relies on the underlying Linux networking stack.
The bridge MSS adjustment configuration is:
bridge br338 {
ip {
adjust-mss 1300
}
}
The bridge netfilter option is enabled as required by our forwarding path:
parameter net.bridge.bridge-nf-call-iptables {
value 1
}
We also evaluated the nftables netdev hook approach, and we believe it could be a possible direction for more flexible L2 traffic manipulation in the future.
For transparent L2 forwarding scenarios, a dedicated CLI option could improve usability and make this functionality easier to configure.
4. SoftIRQ performance optimization
For the SoftIRQ optimization under high-frequency industrial control traffic, we have performed several kernel and networking stack optimizations.
The main optimization areas include:
The main challenge was handling the combined workload of:
We would be happy to discuss these optimization methods and provide more details where appropriate.
However, these optimizations are highly hardware-dependent, and the current tuning parameters are mainly validated on our specific industrial hardware platforms.
Additional adjustments may be required for different CPU architectures, NICs, and hardware configurations.
From our experience, a profile-based approach may be more suitable than applying fixed parameters globally.
Thanks again for your feedback.
We are very interested in discussing how these industrial networking capabilities could fit into the VyOS upstream architecture.
We believe VyOS is well positioned to serve as a lightweight software-defined industrial RedBox for private 5G and edge networking scenarios.
Best regards,
Industrial Networking Technical Team
