Anonymous said: Hello, VyOS is a fantastic project and is getting even more attention now that was forked from Vyatta. My question is if you are planning to introduce Intel DPDK to it. As you may know, it was added to Brocade's Vyatta vRouter and improved packet forward significantly allowing a single CPU core to handle 10Gbit traffic easily. On mail discussions one of the only concerns I see around VyOS is about how able it is to handle DDOS attacks for example and with this technology will certainly be.

DPDK is just a set of libraries for forwarding plane application development, so “introducing DPDK” actually means “writing a new forwarding plane”. What Vyatta really introduced is a pretty elaborate application based on DPDK that took substantial effort to develop (plans to develop it were first announced in 2012, you do the math ;)

So the real question is whether we are going to develop analogous application. The answer is “not yet”. If someone else makes it, we sure can look into joining the development and integrating it into VyOS, but I’m not aware of any projects that would do exactly that.

The other problem, especially with respect to DDoS, is that the only part that can be accelerated is simple L3 forwarding and stateless filtering. If a packet is subject to any intelligent processing, it hits the slow path and we are back to the topic of general CPU performance. Moreover, in systems that rely on hardware acceleration, lots of fast path and smart path intercommunication issues may occur (CEF = Customer Enragement Feature ;). Also, if intelligent processing is not needed, which is common for core routers in 3-tier networks, a fast but dumb L3 switch can be a better option in terms of performance and port density to cost ratio.

All in all, acceleration is a big and complex topics. Everyone who is interested is invited to join the discussion, but it’s unlikely VyOS will be able to provide it any soon.

Anonymous said: New port knocking using TCP SYN SQN, aka TCP stealth, that's up as a draft IETF and a demo 3.16 kernel patch called Knock over at GNUnet

Sorry for late reply. The reason we use 3.13 is that overlayfs is not yet available for newer kernels (at least it was not at the time helium was feature frozen). If that patch is easily backportable, we sure can integrate it.

VyOS 1.1.0-beta1 is available for download

VyOS 1.1.0-beta1 is now available for download from Image naming is the same to release images.

1.1.0-beta1 should be stable enough for non-critical aplications, but it’s not ready for production and needs your testing. Please install it on your test VMs, load configs from production systems, try out new features, test mercilessly and tell us about any problems you find.

You can read release notes preview at You also can find the list of fixed bugs there.

In a nutshell: we removed the dependency on the kernel version of UnionFS, upgraded the kernel to 3.13, fixed a number of bugs and added several new features. The config backend now uses unionfs-fuse, the livecd union mount uses overlayfs.

New features are:

  • 802.3ad QinQ VLAN stacking
  • Unmanaged L2TPv3
  • Event handler
  • IGMP proxy (pulled from EdgeOS).
  • Dummy interfaces (same functionality to multiple loopbacks).

Also there are two new filters, “| commands” that converts the output of a conf mode “show” command to set commands, and “| strip-private” that removes private information from the config.

You can find links to the documentation drafts for these features at the release notes page as well.

What’s next

If everything goes well and 1.1.0 displays good stability, next release cycle will be shorter and it will be dedicated to adding features we can add to existing codebase.

If not, we will polish 1.1.0 first, and then start working on new features.

At the same time I’m already working on the new backend and new system architecture that will solve the long standing problems of the current VC/VyOS such as lack of programmer-friendly config access API. Everyone is invited to join this work!


I’d like to say thanks to everyone who participated in 1.1.0 development and made this possible: Kim Hagen, Yuyua Kusakabe, Hiroyuki Sato, Toni Cunyat , hydrajump, Alex Harpin, Ewald van Geffen, Trick van Staveren, Jeff Leung, Paweł Pierścionek, Florian Fuessl, Ivan Malyarchuk, Abdelouahed Haitoute, Ryan Riske, Stig Thormodsrud and An-Cheng Huang from Ubiquiti Networks, Paul Gear, neutralrockets, ftoyama (hope I didn’t forget anyone).

New mirror in the US

New mirror in the US (Maine): Thanks to the University of Maine and Ray Soucy!

Maintenance complete,, and were moved to the new server and should work as expected now. If you experience any problems, please let us know.

Maintenance notification:,, at 17:00 UTC

What and how long,, and will be unavailable for up to 3 hours.


Jul 09th, 17:00-20:00 UTC


Finishing the migration to new infrastructure.


At 17:00 UTC websites will be put in maintenance mode to maintain data consistency. You will not be able to post new content and may be unable to access existing content.

After that we will move the data to the new server, check installation, and switch DNS records, and website operations will be restored.

TTL for the records is set to 15 minutes now, if you experience problems with it, try flushing your DNS cache.

Build scripts use development repos by default now

We’ve made a change in the ISO build scripts so they use the development repos,, as package source by default. The development repos are automatically populated by the CI server, so you always get the most recent packages.

This change only affects helium branch, hydrogen stays untouched. We will modify “—with-release-build” behaviour to use the release repos later, since helium doesn’t have a release version yet, that’s not a problem.

Note that release and development repos use different GPG keys, so when you build a development ISO, you will be asked whether you trust the key, same with installing release packages on development builds and vice versa. This is to prevent accidental installation of unstable development packages on production systems.

New nightly builds location and CI server

Thanks to Kim Hagen, we now have a continuous integration server (Jenkins-based):

You can track build status there if you want.

Nightly builds are now stored at

Survey report

The survey is now closed and it’s time to summarize the results. The overall picture didn’t change much from the first days, so I think these data is pretty representative.

Read More