+1 here as for small ISP.
Needed features (at least):

• choose interface to listen on
• choose directory to serve
• toggle read-only/read-write access

Would-be-great features:

• View connections log
• View current connections

I think it's a bad idea in case of automation scripts, which rely on general linux root shell - e.g. don't need sudo to get root access. So, anyone with this kind of integrations will need to adjust their software, if it would be not possible to make VyOS act like ordinary linux and accept (without pain) things like

ssh root@vyos arping -I eth0 12.34.56.78

We have thing like this in dhcpd's config - there you can state something like "subnet-parameters ... include file".
I was thinkking a little bit on it and came to the following idea - may be we should implement general syntax for stanza like "hey, vyos, I have config file for this service, please use it as is, but I still need the service to be operated on by vyos CLI commands". How do you think, would it be a good option to implement @dmbaturin?

Configuration and output of

dmesg

please.

Can you attach output of

Well, may be 2.0 should be Sodium though...

@c-po I don's think that there is unique-one-ideal way to configure kernel modules in run time - some of them have interfaces as files in /proc or /sys filesystems, some don't and expect some ioctl on some /dev/ device or on some network device. Others, as netfilter, expect whole bunch of binary data to be pushed to kernel after being compiled by their own userspace tool.
As far as I understand, what we can do - is to make some use of sysctl to adjust the parameters that it can access. Thus, more or less generic way is to call sysctl something=somevalue in op mode and to write something=somevalue to file like /etc/sysctl.d/path_to_conf_entry.conf together with calling sysctl something=somevalue in configuration mode. This way we can get more-or-less generic way to describe sysctl's parameters in conf and op mode.

@c-po this thing should work already without T123, if someone can test this code on live hardware - it seems to be ready to merge.

@alainlamar , well done!

Looks like one has to run also something like

There are some issues with compiling keepalived on 32 bit systems recently - http://www.keepalived.org/changelog.html

Well, may be we just have to either:

If you have a lab to try - may be you can just copy

Is there any possibility to test this functionality in some kind of virtualized environment? Or the developer has to own an appliance with lcd screen to check this things?

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.

Just wondering, if it's possible to address this problem by just addint some firewall rule like
iptables -t mangle -j TEE ...
Did anyone did some digging into xtables-addons package to elaborate, whether it's possible to use firewall for this kind of things? I think, it should be much faster to do this things in kernel, than in userspace.

Awesome!

Well, I have to ask everybody to double think about the very decision to drop the support for "install system" option.
The point is - when you do "install image" - you just drop known-working OS image file to some directory, and if you want to update the OS, you just drop another one (am I correct here?).
But, If you've installed some custom .deb's on the host, you should re-install them after the OS image is updated, even if you had to install new image because of one-line security fix.
Isn't it the scenario for which all those people in debian have used package manager for decades? Isn't it better to just update one package in installed system?

Fine!

Fine.

+1 for removal.

Trim is a good point, may be we can but I will emphasize these things here:

1. DO NEVER install vyos or any other linux, intended for running 24x7 on cheap usb flash. I did it. Don't repeat my mistakes.
2. /var/log in tmpfs is generally a very bad idea, as you will have no logs to examine system failures post-mortem.
3. It's a good idea to monitor your ssd's health, and it's a good idea to include smartctl in VyOS default package list, but ssds have different vendor-specific SMART flags for their health indication, so it's up to user to specify the correct ones for his or her equipment.
4. There is a damn dirty and simple solution to address trim issue without any modifications to running image:

tune2fs -o discard /dev/sdXY

but one has to make sure that device supports trim BEFORE doing this :)

Actually merged year ago.

Merged in october.

Pull request - https://github.com/vyos/vyatta-quagga/pull/5
Anybody tested this .debs?

Seems to be OK.

Do you have BIOS or UEFI boot mode in your motherboard setup selected?
To all - there was some reason why I've included grub-pc in my image, but I'not sure that it will help in this case.

@dsummers jool seems to be kernel-level and tayga seems to be userspace-level. The first one should be faster, and I expect package loss in the second one on high packet rate.

Well, I think I can some day do some things on adding this to CLI, if someone points me to known-working config for this feature. Am I right that this IPv4 - IPv6 NAT can not be implemented by iptables/ip6tables stuff? If netfilter already can do it - it's much better to do this things in kernel (as netflow, in my opinion).

It seems to me that it should be linked with removal of in-kernel raid autodetection in recent kernels. We should employ user-space autodetect. Those people at gentoo have something on it here: https://wiki.gentoo.org/wiki/Custom_Initramfs#Software_RAID We should do something similar.

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.

Great, thanks!

@Alexis , I've got my build environment up and running and created .deb's for this issue. Feel free to test.

For me the current defaults is fine for router-like device. But it's a good idea to have this option in user config, e.g.

Well, my vote is "No", because if for small configs it's OK to have just intent-expressed syntax, if you have huge one, e.g. several pages - if you omit prefix before, say, 55, you will have to guess from context, if it is a vlan or preffix list entry, or VRRP group or whatever.

Well, I am not sure I can do this fast, as I am using different approach in flow collection - https://github.com/mickvav/ipt-netflow-code and have no idea on what do do with sflow. If you have someone else to assign this job to - do it.

Well, just to make things clear - nDPI is actually a userspace software, that performs DPI analisis of data flow (from pcap-ed interface in real time or from .pcap file). It's interface to netfilter goes through ndpi-netfilter package, which actually opens kernel-userspace socket to forward some packets throug nDPI in userspace. If I am right in brief, we have two important steps:

1. Make userspace software compile and work.

I thing, this should require almost no vyos-specific coding - just original package should be compiled on vyos vuild system into .deb

2. Make netfilter-related package integrate into vyos iptables configuration.

Here we need to create some package like vyos-ndpi-netfilter, which fetches and compiles ndpi-netfilter, handles vyos configuration templates and creates correctly working .deb with all this stuff.
vyos-ndpi-netfilter.deb should depend on ndpi.deb

How exactly can we help you?

Sent pull request. This thing is really trivial. @Alexis, would be so kind to that resulting package is ok? My building appliance is somewhat disabled right now and I have only a tiny amount of time to do recreate it, so I will be able to test that everything is ok next week only, sorry.

Reviewed the discussion there - I think we have to wait at least couple of weeks until it will be at least a little bit tested there...

Well, than it seems to me that the reasonable starting idea is to start with the following configuration:

1. make tree-like control pane topology on some stupid switch, for example.
2. make "basic" configuration for every device, where only control pane interfaces are up and running
3. make your jenkins or some other automated tool able to upload configuration into all these devices.
4. make full-graph cabling between existing devices with some reasonable background logic

(e.g. "port 1 of any device always goes to hp,
port 2 of any device always goes to srx240
port 3 of any device always goes to ASA
port 4 always goes to Mikrotik)

@syncer , do you have any drawing on network topology, that you are going to implement? If you do and it's not a secret, please share.

@elico, have a look at https://github.com/mickvav/ipt-netflow-code - it's my vyos/debian repackage for ipt-netflow - another iptables target module which I've ported (and use in production) on my own vyos repackage. If you take it's "debian/" folder, put in your repo, than we can fork it and maintain as submodule.

Well, I think, I can try to make this thing work on VyOS, especially if the community is interested.
@elico, it seems to me to be that if you have this thing working with ubuntu you already have some debian folder which produces .deb's on dpkg-buildpackage correctly, or you mean that after just "make && make install" on running system, it installs and works?

The last one seems to be really interesting - it's a kernel module, should be fast and so on.

It's an interesting idea, I've even tried this stuff couple of days ago, but it seems to be under heavy development, although seems to be a motion in right direction - snippets of code in documentation doesn't work, things which they demonstrate in videos are already moved in another modules and so on. So to make these things importable into vyos, they should first be made workable.
Thus, if someone needs this stuff to be integrated into vyos, he has to achive some simple goals:

Ok, @Caesar305, than I'll ask another stupid question - why do you think that if someone will implement FULL linux bridging/routing/firewall stack with DPDK, he will get some significant profit from this decision? May be I miss something, but if all these things are already implemented in kernel, they are just already there, so DPDK seems to be extremely effective if you make it do specific things by throwing away all unneeded things, if you implement everything in userspace application instead of kernel you will benefit only on simplicity of debugging, am I right?

Well, I think this question can't be correctly answered until it is correctly stated. So I suggest waiting @Caesar305 for some clarifications. @rps 's answer implies that "support" means "ALL the routing stack works over dpdk" which seems to be really far now. But another option is the ability to run specific dpdk software on dedicated ports (e.g. traffic generator software for load testing of external equipment or high performance network sniffer) - this task seems to be achievable, if it's requested and donated for :)

Hm, I belive it should be relatively easy to make vyos "forget" about some interfaces, on which you plan to use your separate dpdk-enabled software and to just compile dpdk into main distribution. Is it enough for your needs, @Caesar305 or you need some specific application or you are talking about making all firewall stuff work over dpdk (which sounds like A VERY VERY HUGE task)?

And if you have any other known https destinations with different port numbers - redirect corresponding traffic explicitly.

I can suggest trying to do fork() on before line 139 and exit this forked child later - this should keep parent daemon's memory footprint constant.

Can you push your recent changes to github?

You need "create" section in your templates/policy/route-map/node.tag/rule/node.tag/set/src/node.def to make things survive reboots, I think.

May be you can run tcpdump -nvvv port bootps on your host to catch your client's requests to make sure that clients request hostnames without prefixes?

Hm, as ipt-netflow is actually a firewall target, it looks like it's configuration logic should be slightly different from pmacct's one.
Looks like there should be some service level config tree, specifying module load parameters, like

I had to disable dkms there
https://github.com/mickvav/ipt-netflow-code
And if anyone is interested - I also have xtables-addons compilable against vyos kernel (it has several interesting firewall features - such as geoip and ipmark) - https://github.com/mickvav/xtables-addons

Well, I have ipt-netflow on self-rebuilt vyos kernel, no problems with performance. But I have no vyos-related scripts for interaction with this module.

And some more, on the machine with working config:

Ok, now works, but I've got some strange notices on "show vrrp" :

Why should we remove support for obsolete features, which do not break anything?

I think it leads to incompatibilities with other device's default behavior - cisco, for example, exports/imports everything, if another behavior not stated explicitly, AFAIR.

Would be great - with some make target for this it's possible to arrange nightly builds with these images.

Hm, looks like it has 1gbe port working, am I right?
Do you have your .img creating procedure described or scripted somewhere?

You mean, I can order a board, take sd, put some image onto it and get working vyos on this board?

Well, you was discussing hardware here, and I know that mikrotiks used to be bootable into debian, so I've concluded that you are planing to port vyos on mikrotik's hardware. But clearfrog is also interesting idea.

Is there some place, where you track current work on mikrotik port? May I help it somehow?

Steel need someone with known working quagga MPLS confgiuration to test. @afics ?

Created pull request - https://github.com/vyos/vyatta-cfg-quagga/pull/9 to track changes, related to this ticket.

@dmbaturin @syncer should we keep configuration syntax in sync with brocade?

What is vRouter 5600?

Well, looks like pre-alpha is here:

@afics I think keyword route is unnecessary in your suggested syntax - we have all options right under "set policy" tree. @syncer , @dmbaturin what will you say?

Well, it's somewhat more complicated than expected, but possible. I'll try do it today, but not 100% sure that I'll have enough time...

I think, I can. Need two things - url to docs to check semantics and readyness to test.

Did you run into some trouble with snort? Are there any discussion on this topic somewhere?

About systemd there is another point - if you look into systemd default setup (/lib/systemd/system/[email protected]), you can find that it's default setup is rather clever - it takes advantage from agetty's ability to automatically select console baud rate. But current vyos configuration scheme insists on some fixed baud rate. So, we also have options:

1. (simple) Remove speed option or ignore it. + allows usage of upstream systemd configuration
2. Alter systemd configuration to use fixed speed from config.
3. Modify speed to accept list of possible speeds, e.g.

speed "9600[,38400...]"

Looks like this simple patch is ready for production. Backing idea - quagga has route-map to filter routes, going to be installed from ospf into kernel table, but we had no way to install it in vyos config. This patch creates 'router ospf route-map NAME' vyos configuration command, which maps into 'ip protocol ospf route-map NAME' quagga configuration mode command. The development was discussed under Q26.

Well, I think that anyone, who really needs some specific feature set, nfs server, samba server, whatever, can make and maintain his own fork of vyos-build and it has (almost) no problem to build a speific iso himself.