First logging into a normal OS shell probably would help with third party tools (like ZeroTier and JumpCloud that I requested as features).

This did the trick. Just build a fresh ISO:

https://github.com/vyos/vyos-build/commit/e5259ccb17e93e110d1dcdeb98f4dc1b9d1df192
This seems to have done the trick thanks.

@UnicronNL maybe this will fix this issue:

Our nightly builds ships wpasupplicant 2.3-1+deb8u4, according to https://www.debian.org/security/2017/dsa-3999 it's fixed in 2.3-1+deb8u5.

I have not approached any of the Pi Hole team yet, but I do appreciate the realistic feedback.

Hey all,

I'd also greatly prefer unchanged default behavior, but a config option to bring in the new hotness :)

How exactly do you see the two products interact on a single system?
Do you have this request on their ticketing system? Can you link the two?
Does it have to run on a rpi?

Considering JSON's a standard that's quite close to the VyOS syntax, i don't see why maintaining another nonstandard format is needed when JSON is available :)

Comment by @beamerblvd on 2016-01-24:

Hello, is there a way to easy install kernel source/headers for default kernel used by vyos 1.1.x (3.13.11-1-amd64-vyos)?

So it looks like vpp progressing a bit.
https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

Thank you.
It looks like you have this compiled to much newer kernel, 4.4.15 while current kernel in VyOS 1.1.7 is 3.13.11-1-amd64-vyos.
So it looks like i need to compile it by my own, but thanks anyway for sharing this ;)

Here you are -

Ups, seems I was wrong in last comment. I'll collect all the files from .deb and post them here.

Well, I don't have access to development vm, where I did this stuff today (remind me on monday, please), but I do have kernel module (the only file in .deb, actually) compiled against 4.4.15-amd64-vyos kernel.

Hello,
Is there a chance that ipt_NETFLOW will be included in next release (and if yes, where it is planned to release this version?)
@mickvav Can you share your .deb package please? We need ipt_NETFLOW ASAP. Thanks

@sebastianm In VyConf it's going to be fairly easy (ok, possible at least) to implement different input and output formats, so chances are we can add | display json or | display yaml filters if there's demand for it.

Unless there is a specific advantage to changing the behavior of VyOS the existing behavior should be kept. What is the advantage of going having the linux shell be the default? Also, I like the idea of making it configurable.

I'm all about compatibility with existing behaviour. Looking back over just about every network device I've ever operated, and the bits that annoy me the most is when behaviour is changed in a surprising fashion. I know there's a tension with the ability to actually continue to improve the product, but where there's a choice between 'make it unsurprising', or 'make it cooler', from a user perspective, you want the developers to have exhausted every option to do bother before making it surprising.

That is not something that we need to choose between,
we keep both, but for environments where users comes from AD, LDAP, Radius, etc.

Actually I like the fact to have the users SSH pub key inside the config. This makes it super handy to just copy/paste a users config entry arround VyOS instances.

This one is partially related to T312 but not only
we had some discussions with @dmbaturin in past about keys
and came across idea that it will be great to keep keys outside of config

To my mind... I'd rather keep a compatible syntax than a new one, even if there are benefits in terms of uniformity and parsing.

I say don't change it (keep it the same as it's in 1.1.7). I'd consider YAML or JSON (in that order) though. (I am/was lylylyly on IRC).

There was no interest on this, closing as invalid

Merijn is right in my experience. I think root should get unix and the rest the vyos-cli. If you make it a configurable setting within the vyos-cli it would be bestest for everyone.

The specification has been published as IETF standard: https://tools.ietf.org/html/rfc8092

Seems to be OK.

I added a force-gateway option some time ago. Regardless it's somewhat expected on 1.2, it needs testing and review. I meant 1.1.7 in my previous post (yes, confusion).

been using the VyOS 1.2.0-beta1

What version have you been using?

in edgeos each loadbalanced interface has it's ip table set directly at the interface-health section of the loadbalancing config. ex:

I tried doing some basic routing with ofp and it seemed to work but the shipped dpdk version does not compile for my kernel (4.10), so I can't test that.

I have tried this and I could not seem to get any data what-so-ever to go over the open fastpath interface, so I don't think it is a viable solution.

Has anyone tried to do something with the howtoforge: https://www.howtoforge.com/tutorial/opendataplane-with-open-fast-path-on-ubuntu/

for now it is set to fixed speed.
please close if agreed on this.
https://github.com/vyos/vyatta-cfg-system/commit/d582bbaf3ad95566de9b90d1572d60e39936a1a7

In T100#4801, @silverbp wrote:

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

Well, I take vyos-kernel, iptables, build them in packages directory, and put ipt-netflow from here: https://github.com/mickvav/ipt-netflow-code as git submodule in the same packages directory, build it there and get working .deb package containing module, crafted for current vyos kernel. I have no CLI integration for it though I use my own firewall-messing scripts. But in general, you jest have to do modprobe the module with right parameters (where to send collected data) and add somewhere in firewall the rule with "-j NETFLOW" to trigger, which packets to take into account.

@mickvav I recall that you told in some task about IPT usage
can you share how you currently integrate IPT?
@jclendenan and me(and not only) will be interested to see this in 1.2

In T100#4598, @mtz4718 wrote:

Is this en-devour dead? I really want to help but I wonder I'd be much use. If there's any dumb testing or boring tasks let me know.