confirmed, works just fine of free esxi

I think we can choose how to implement it. We can apply it as a default entry in one of the vyos chains or let the user-decide. The advantage with the latter is that both implementations can co-exist for a while. With the former solution I would remove the old implementation to not confuse the user.

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

@afics thanks, i merged it to this one

Related/duplicate: T33.

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.

These should be gone now.

And some more, on the machine with working config:

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

https://github.com/vyos/vyatta-cfg-system/commit/b66cc78521db17628efa3dd27766527816c170cc

Makes code simpler and easier to read. Makes kernel a bit smaller (leave out floppy module)
Makes booting a little bit faster.

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

@dmbaturin can you take a look and merge this patch ?

I already have a working patch for my own setup, I attached it:

Changing this to wishlist,
@dmbaturin please comment your view of this
Thanks

Hello,
we considering a possibility to add DNS recursor,
however, for now, there is no ETA for that functionality.

@dmbaturin this should be not hard to implement, correct?

About systemd there is another point - if you look into systemd default setup (/lib/systemd/system/serial-getty@.service), 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...]"

For the jessie branch, we are likely staying with systemd, so systemd-related code will have to be added anyway.
Whether to remove the inittab-related code or not, not sure. I don't think we should implement both right away, but if we leave some room for extending it to support other init systems, it should be fine I think.

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.

@mickvav exactly, we looking to provide some support in that direction
@aopdal, I understand your concerns, but also don't find limiting users as something good,
@UnicronNL ported 1.2 to clearfog pro device, NFS server will be a good addition there for example,
we also talked about SIP functionality, all that Network Functions.
It does not about create multi-purpose distro, more like provide ability to build customized images

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.

Why would anybody want to use a router as a "small server"? General Linux distributions have everything you need for a small server.

Looks like it's closed mostly.

@EwaldvanGeffen
i will be happy to have ability add nfs/nettalk/cifs
for that type of home appliances, not sure how we should handle such deviations
I believe we should not be restrictive in this matter

I think its outside our scope. vyos is a network appliance. it provides services to transfer network traffic or services essential to transfer traffic (dns, dhcp). nfs does touch this aspect at all. Neighter would a radius service but that would enable pppoe-server or hostapd,... to move traffic. Nfs is not a requirement for any deamon to move traffic. ergo outside thhe scope.

In T49#768, @mickvav wrote:

In T49#766, @mickvav wrote:

I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need nfs client and I'll double check, whether it's enabled in my branch tomorrow...

In T49#766, @mickvav wrote:

I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need nfs client and I'll double check, whether it's enabled in my branch tomorrow...

I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need mfs client and I'll double check, whether it's enabled in my branch tomorrow...

Could you give an example of an use-case? Because I think this choice was very much by-design.

Where is the updated vyatta-quagga packages ?

It is normal. In the debian way of doing things, debian/control of the kernel package is produced by running "debian/rules debian/control" (sic!), as it's architecture-dependent.

If this will be included, someone has to make deep testing of quagga vrf-related patchset. Looks like it's described here: http://permalink.gmane.org/gmane.network.quagga.devel/11770 but I'm not sure, whether it's included in upstream quagga or not.

@EwaldvanGeffen just wondering what will be the best option in terms of difficulty of implementation

I will look into it. I think it is feasible to add to 1.x, but we have to think about the cli. We have to treat the default VRF in a way, so it doesn't come in the way of users who don't want/need to use VRFs.

Some time ago @dmbaturin told me that it's pretty difficult to implement in 1.x
Just wondering if this should be added only to 2.x

It looks like should not be hard to implement
https://www.kuncar.net/blog/using-vconfig-to-set-vlan-tagged-interface-with-802-1p-cos-priority-bits-set/2014/

I'd certainly be willing to try whatever is necessary and test it out.

https://github.com/vyos/vyatta-quagga/commit/d9823008822c536dcd995a9d3c9ca444b85a66be
https://github.com/vyos/vyatta-quagga/commit/f58e94cb1c452faadb4dd86e347fd1945eee408d
https://github.com/vyos/vyatta-quagga/commit/d0d6f926cd7c842cd1818bacd469e91874ec5605

Just wondering if there are any arm-based devices with several ports and affordable price?

@EwaldvanGeffen advanced ova should work just fine,
it's just like simple ova, but making questions upon deploy
I will test to be sure for 100% and will report back

By duplicate address detection you mean (examples cases):

1. eth0 address 192.168.1.1/24 and eth0 address 192.168.1.1/25
2. as 1) but between eth0 and eth1
3. duplicate IP address on connected segment of interface (you share an IP with another node)
4. as 3) but with all connected-segments
5. as 4) but additionally in connected routes unique

Can you deploy the advanced ova on free products? Because iirc there are some restraints (eg. single node ESXi)?

So we currently preparing with @higebu simple signed ova/ovf
once migration to jessie will be finished, we can then think about advanced version