Meet OS/VX

Many of Vyatta/VyOS users are complaining about old runtime it uses - Debian Squeeze which is not supproted well, has a some security flaws, and so on.

So I’ve decided to recreate a bit of my work from the ground to clean all the law restrictions and to be able to release it to Open Source Community.

I’ve called it OS/VX. It’s a port of VyOS to modern Ubuntu 14.04 LTS runtime with some updated software. Sure, it even boots. And even works (at least on my routers) :slight_smile:

OS/VX homepage is at

There you’ll find a link to live CD builds and more.

Some parts of OS/VX aren’t at Github yet just because their code needs some cleanup. They will be there soon, I believe.
And some of specialized modules (primarily for high-speed switching, routing and digital signal processing) can’t be included in open source OS/VX at all because of they’re covered by a lot of NDA’s.

So, enjoy yourself and let’s make the World smarter together! :slight_smile:

Many thanks to Vyatta and VyOS maintainers and developers for the excellent work!

Hello Valentin,
I think that the VyOS project is really fragile in this stage and Vyatta Core have no more a real support from Brocade.
Why, instead creating a new project, don’t you join the VyOS development and merge VyOS + OS/VX?

For example, you could contribute with your expertise to moving out from Debian Squeeze.

I think that, from end user perspective, this splitting scenario (vyatta core, vyos, OS/VX, (others?)) is just confusing and creates the question “which one should I choose?”.

I’m really convinced that, joining efforts togheter, we can let survive the “vyatta core” project and user base :).


I thought about joining VyOS development, but there are two thing that prevented me: the absense of routers hardware it’s running on and the abscence of any guaranties of the project future. I’m not interested in any kind of “virtual routing”. I’m interested in real hardware solutions that will beat Cisco some day :slight_smile:

I have a hardware that can be used in that way. It uses highly customized software (kernel modules, firmwares, libraries, etc) that can’t be released, but can be used as extensions on top of some open source runtime. But that runtime should provide some additional capabilities to support them.

So, in case of joining some open source project I have to support two branches: original open source project that can’t be used by us directly and it’s fork that includes all the necessary open source addons (I think nobody will agree about some code that will do “some dirty things” they will not understand to be included in mainstream).
And nobody gives the guaranties that someday the maintainers will not say “Ok guys, let’s turn that way!” and that way will be always acceptable by me. So, in worst case I’ll have to fork from that project someday anyway. And it will become a problem because someday this two projects simply will stop merging.
I always passed this way with Linux kernel. It’s Open Source :slight_smile:

Forking in the beginning is always easier. If somebody wants - he can backport 14.04 LTS transition from OS/VX to VyOS, it’s not a big problem.

Hello Valentin,
I understand your point of view. I’m wondering if could be possibile for you think about OS/VX as VyOS + modification.
What I mean is this. Suppose OS/VX is 99% the same of VyOS, isolating the differences and forking only the subparts otaining something like OS/VX = VyOS + module replacements + patches.
By this way, we could work to the common parts togheter and, just to not confuse and split the users, maybe you could call your project VyOS Harware Edition (or something similar, just to express the idea).

What do you think about it?

Thank you

I’m in doubt that it will be possible even in near future. This time - yes, OS/VX looks just a VyOS ported to LTS. But I have some plans of what should be included in it (WAN serial line cards support, TDMoE, some open source stuff for our modules - things that are missing now but that are mandatory for any telecom equipment) or what should be completely removed to make it well suited for our tasks. And this plans cannot be discussed or changed just because open source community wants this.

I can’t use software that I can’t fully maintain. Because of nobody gives any guarantees that the project will be alive or that it will not be sold to some commercial company, as it happened to Vyatta CE. And that’s why it has different name and owner.

Look to Ubiquity. They’re using Vyatta inside thier EdgeMax routers, but also they have own independent and fully controllable fork of the project.

But you’re right: this is Open Source and we can do some things together. I think that the best option for VyOS is to re-fork it back from OS/VX now (14.04 has completely different build/live subsystem, Linux kernel, libraries, and so on, so they can’t be just merged via GIT) and start working from this checkpoint.

If you can’t use software you don’t maintain, you should write an OS from scratch. (;

Anyway, I’m not going to talk anyone out of forking or do anything to prevent it, but I don’t think it’s a right thing to do.

The problem is, a substantial part of the old code is already unmaintainable. It’s cheapear to rewrite than to modify. Even worse, the old config backend ran out of room for modification. RBAC? Fat chance. Remote API? Needs over 9000 abstraction layers and still stays a dirty hack. Saner default value handing? Breaks compatibility entirely. Live rollback? Blocked by the default value handling in particular.

The right thing to do is to develop a new backend free of those problems and design the “userland” code properly. This is what Vyatta is already doing, their new code is proprietary though.

New package base and drivers are indeed important, but until we have a system with reasonably future-proof design, we are all insecure.

Yes, it’s a long and hard work, that is why the squeeze-based branch is still maintained and going to be around for a while. But we have to, or else we have no future.

Hello Daniil,
a personal curiosity: dividing vyatta code quality and design from the ability to correctly run on a platform, for what is your knowledge, even if “a mess”, can the actual vyatta/vyos code able to run on debian “wheezy” release?

I mean: could it be possibile divide the system integration from the development? Maybe, if he is interested of course, Valentin could help the VyOS project to upgrade on “wheezy” while the software code is analyzed and re-designed from scratch.

What do you think about?

Greetings, Daniil!

Absolutely, you’re right. But I think this problem is related not only to current backend, but to underlying Linux software it uses. I think it will be very hard to design some “universal” backend without redesigning (and therefore rewriting) large parts of Linux networking software. Mainly because there are many invisible relations between different software in OS. So, the backend should be able to resolve all the conflicts and dependencies.
But one sunny day author of one of the programs we’re using will include “some cool feature” that can break all the work we’ve done. Or upgrade may be needed in case of some security flaws found in current version we’re using. But next version could use different configuration syntax, have different behavior, etc. This underlying software is just like The Ocean :slight_smile:

I like current Vyatta’s backend because it is very generic. Sure, it is quite old, does not support many of modern features, but it can be used with any kind of software (I’m using it to control radio transceivers and ADC/DAC boards, yeah :slight_smile: It’s behavior can be simply modified in case of “ooops, here’s the new feature!”. I think until we’re using underlying Linux software we have to be able to adapt backend very quickly to any external modifications. And the best tools for that are Perl and sh :slight_smile:

I’m in doubt that it’s possible to design some featurerich solid backend+userspace (and system/kernel-space too) with “just for fan” Open Source coding without any significant commercial support. And Vyatta’s fate is a good example.

As for Debian - I don’t use it. Look to Wheezy: they changed init subsystem from sysvinit to systemd just in one minor updade! It happened not in 7.x → 8.x transition, but it happened in 7.4->7.5 update!
In case of VyOS that means that all subsystems that are responsible for daemons operations have to be rewritten. I’m not ready to do that.

I prefer Ubuntu LTS releases just because of they are always frozen in some stable state. And (it’s my IMHO, not a holywar) Ubuntu has more usable solutions (as for Debian’s systemd - I still can’t understand ideas it uses :slight_smile:

I understand. A personal curiosity: how would you valuate the possibility to use as underlying linux part a RHEL/Centos base for the VyOS project?


I’ve never used them. But they are RPM-based, so it will be a really tricky job to port dpkg-based software to them.

As of my vision, Ubuntu LTS is the best candidate, because:

  1. It is stable
  2. It has big community and excellent support
  3. It has very powerful build system that is already used for packages

But basically what would be RPM-based (or dpkg-based) is related only to the underlying linux packages and we would find the equivalent in RHEL/Centos (says: kernel, perl, openssl, dnsmaq, etc.).
The vyos/vyatta part could be packaged accordingly (or using other mechanisms / not packed at all).

@Daniil: what do you think about Ubuntu LTS and RHEL/Centos as VyOS base?


I think it will be very hard to design some “universal” backend without redesigning (and therefore rewriting) large parts of Linux networking software.
It has nothing to do with linux networking software or any other software. That’s entirely in application logic, not in the backend. Anyway, vyatta application code has this problem widely represented as well. Look at e.g. firewall, there is no sane way to just inherit from the base class and define options specific to selected type of firewall (filter/nat, iptables/ebtables etc.).

So, the backend should be able to resolve all the conflicts and dependencies.
Note that the current backend doesn’t have any dependency resolution at all. All it has is hardcoded node priorities with no correctness checking and only priority inversion warnings.

It’s behavior can be simply modified in case of “ooops, here’s the new feature!”
Really? Have you tried to actually modify it? Many problems exist since the early days of VC and still not fixed because changing the fundamental design decision that caused it means totally broken backwards compatibility or even complete rewrite. It didn’t change since like 2011 when jsouthworth made some optimizations.

I’m in doubt that it’s possible to design some featurerich solid backend+userspace (and system/kernel-space too) with “just for fan”
There is no other choice anyway. CStore is dead, even the original authors barely remember how exactly it works now.

Also, note that ubuntu is going to switch to systemd in new releases as well. The fact ubuntu 12 is stable doesn’t make things easier, it causes exact same problem to debian—adding newer packages will be getting more and more painful and move to a newer release will be inevitable at some point. (As of Adriano’s CentOS question: same problem x10, and major releases are even more different from each other).

For those who missed it: This is where old backend problems are described.

GitHub - vyos-legacy/vyconfd: Early prototype of the backend rewrite that went nowhere This is where the new backend development takes place.

Thank you Valentin.
Daniil, what is your opinion about my question, instead?


just to add a question regarding this a few years later. have you or anyone else that you know, attempted to reverse engineer or understand the new design of the brocade vrouter? if you download a demo version is could shed some light into the new direction for the 1.2.x design.

Personally I don’t think that Reverse Engineering is anything useful or advisable to properly design a quality software solution in general and, specifically, any new evolution of VyOS.

Didn’t Brocade move to ZebOS as the routing stack? That’s the same thing Ubiquiti moved to around 1.8.0/1.8.5 as well.