Stable enough for production use?

General questions
1

Hey folks,

I’ve been following VyOS for quite some time now, mostly watching from the shadows, waiting with anticipation and excitement as the project grew. 1.2.5 seems, from the outside, to be mature. Is 1.2.5 stable enough to run in a production scenario, or should I hold off for the Equuleus branch?

2

I would say it’s very stable. I am currently running 1.2.3 in production and I have no issues.
There are a few bugs. But if you follow the vyos phabricator tasks, and if you’re unaffected by those; I can say it’s safe to run VyOS in production :slight_smile:

3

Hi jscarle!

Thanks for showing an interest in the VyOS project!
For the time being the current production grade release of VyOS is 1.2.5(crux) and is used by many in production. So i would say it will be safe to use this in production

1.3(equuleus) is by now our development branch and is fine to use in systems where issues are more accepted. i would say home network, labs etc. To be more safe when using 1.3 create a “lab” router and test all your configuration prior for installing the “real” system.
Equuleus will go into feature-freeze in short time and i would think that the stability of the release will increase when that happens., but i think it will be some time until 1.3 is as stable as 1.2 :slight_smile:

1 Like
4

I’ve seen quite a few posts about performance issues because of the Python backend which concerns me. I would like to deploy VyOS in our datacenter to replace our edge routers, but in order to do that, I need to be sure that its stable enough for the task.

In particular, there are four atypical configurations which I use that could be problematic for VyOS.

  1. A several thousand IP address network-group which is used to drop traffic from banned IP addresses.
  2. Several hundred source NAT rules and several hundred destination NAT rules.
  3. A full /24 defined for VRRP.
  4. Deployment on a Windows Server 2016 Hyper-V Failover Cluster.
5

We are using Vyatta/Vyos for about 8 years in a business critical environment. Basic usage, nothing fancy: Routing, NAT, VPN, Firewalling, dns doctoring, VRRP. This should be some indication whether it is production ready or not. :grinning:

1 Like
6

I can answer this, but not the others. I’m using Vyos at home and I am using this script to update every 3 hours a blacklist table. There is no performance impact on Vyos at all.

Please note that the list itself isn’t maintained within the Vyos cli. Only the address-group is created (see the Nets4-Blacklist below, but then it’s populated “outside” Vyos using the ipset command. That said, it works extremely well.

firewall {
    all-ping enable
    broadcast-ping disable
    config-trap disable
    group {
        network-group Allowed-XXX {
            network x.y.0.105/32
            network x.y.0.121/32
            network x.y.0.109/32
            network x.y.0.120/32
            network x.y.10.10/32
            network x.y.10.11/32
        }
        network-group Nets4-BlackList {
            description "Blacklisted IPv4 Sources"
        }

Also for what it’s worth, I suspect Vyos will be able to handle your NAT requires with no issues, the Linux iptables performance is excellent.

7

@tjh

Hey there. Quick question on setting the blacklist group up. There is a step in there for a post-config.d directory located script, present in EdgeOS but not Vyos. What did you do for that step along with placing the iprange package in a location that gets installed on image upgrades?

8

@phillipmcmahon To get the blacklist applied on bootup I just edited

vyos-postconfig-bootup.script

and put in it

sleep 30 && /config/scripts/updBlackList.sh

I put the sleep in just to make sure everything’s settled, I don’t know if it’s required.

For iprange all I did was install the package from the Debian 8 repo (I’m using 1.2.x)
I realise this will be lost on image upgrade. However it’s not required, it’s just a nice-to-have.
I’ve put in a Phabriactor task asking for this to be added to the default install, it’s ~8k or something and is a useful script to have installed on a router.

9

Thanks for the reply. I will add that to my setup now I know how the post config section works. Appreciated.

Still don’t get why there is a loadBlackList.sh and an updBlackList.sh on github, when the first is an older version of the second.

Be good to be able to add packages as part of the image upgrade in general, not just iprange.

I am hoping wireguard can be separated out and provided as an update packed for VyOS. Some good work has been done recently for EdgeOS with it back in the official packages available.

10

I don’t understand the point of the loadBlackList either, I didn’t install it myself.

What’s wrong with Wireguard as it stands in the 1.2.5 at the moment? The real heavy-lifting of wireguard is done in kernel space, not userspace.

11

Maybe more a specific 1.2.5 issue. It does not support multiple key pairs. On my rolling config I have 2 listening WG interfaces and another WG interface paired to a mullvad peer. Works great.

“Down-grading” to 1.2.5 as I have to use the same keypair then this breaks the on-bound tunnel to mullvad from establishing.

No real issues as I can run rolling just fine but would have been nice to have this work also on the LTS image.

12

@tjh

Solved my issue. Nothing wrong with wg on 1.2.5, in the process of downgrading from rolling to 1.2.5 a whole number of things breaks in the config.boot file.

Seems the entries for my routes got mangled. Once added back all is working fine.

1 Like