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:

@UnicronNL thank you so much, worked like a charm

you should download it (wget) an do a sudo dpkg -i of the package.
you can do a dpkg -l to check which snmp packages are installed.
this is the location of the 1.7 packages.
http://dev.packages.vyos.net/tmp/khagen/snmp/

@UnicronNL can you please tell me how to install this patch without breaking anything? thank you!

@syncer Yes, the package is for 1.1.7

can someone tell me how to properly apply this patch? thank you!

@UnicronNL will this package work for 1.1.7 ?

Dropped that idea, closing

Hello, @mickvav removed you.
It's wasn't demand or something like that, I just though that you may know that better

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.

Does openfastpath really work? Have you tried it? It all looks great, and if it works reliably, we indeed should integrate it.

Would the http://www.opendataplane.org/ and http://www.openfastpath.org/index.php/service/technicaloverview/ not work better in VyOS?
Use this to create a fastpath interface and the linux OS can just that.

Should be fixed in that same commit if I'm not mistaken as T186 here

Should be fixed in that same commit if I'm not mistaken as T186 here

@oliveriandrea what happens when you use double-quotes for vyos-config and single-quotes for the statement within? Can you also test out the other possible combinations; eg. "--with-escaping-the \"inner quotes\""; this is just for reference (I agree with @syncer recommendations for now). I would be especially interested in if they are treated differently by the tab-completion feature as IIRC it generates somewhat broken suggestions (vyos@vyos #delete openvpn-opt<tab> .. ).

So, I don't see an issue - don't use double quotes
you perfectly fine to specify several openvpn-option statements

no, here we have "double (double quotes)"

@hexes can you provide config and show support outputs
so @EwaldvanGeffen can take a look

It works perfectly without double quotes

openvpn vtun0 {
        local-port 443
        mode server
        openvpn-option "--push redirect-gateway def1"
        protocol tcp-passive
        server {
            name-server 8.8.8.8
            push-route 0.0.0.0/0
            subnet 192.168.255.0/24
        }

@dmbaturin lets push workaround to 1.1.8

Hi @syncer. I'll say... Why not :-)
Is there a way you could contact me directly ?

There is already a commit about this bug:

hey @thomas.courbon, thanks for sharing this,
just wondering if you have interest in join to development,
I guess we can setup with @dmbaturin test and build environments for you
Thanks!

I don't have a platform to test right now but I think the issue is in

Hi thanks for the links.

@thomas.courbon I think we fixed a similar bug before, but it seems the fix wasn't quite complete...

More explanation about the bug.

@mickvav @EwaldvanGeffen can fix this?

@dmbaturin @EwaldvanGeffen @UnicronNL
can we maybe automate this to produce workaround?

HCL - Hardware Compatibility List
But not generic one, more like focused on VyOS (not only booting but actually working well)
There is no defined form how it should look like,
I like your variant of the page!
Good start!

Thanks for your comment. I did some refactor. It is now a table with a link to details.
http://wiki.vyos.net/wiki/Network_appliances

What you are telling is completely true.
Idea is maybe not only focus on appliances but rather build some HCL

We should include fix in 1.1.8

It would be useful, as its used in ISP networks for QOS, specifically in NZ for GPON where 802.1P is tagged by the client router connected to an ONT to access CIR bandwidth allocation for things like VoIP.

Anyone working on this? The changes to BGP are important, but the OSPFv3 changes are critical.

It seems that we need VyOS HCL(Hardware Compatibility List)
For those who looking for certain numbers in performance
Once we will see(or even participate) in some open source DPDK implementation (forwarding or any other in scope of interest) we can start talking about future of it in VyOS

Agree with @rps completely
something like that can appear ocassionally
but we need to set priorities correct

I'll make a move here and suggest that until FOSS projects to implement DPDK support see more maturity that VyOS doesn't go down the rabbit hole of that for now; I think a side project, maybe "HP-VyOS" (for High-Performance VyOS) take on trying to build a version of VyOS that can leverage experimental code like DPDK or VPP.

@mickvav i recall that @dmbaturin had pretty similar experience with vpp

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:

VPP might be a better starting point than "DPDK".

I agree that DPDK would be a game changer for VyOS. It would nullify the Brocade 5600 vRouter and would make VyOS the absolute go to routing software for high PPS networks. I'm already seeing an increase in interest around the BSDRP router project which is using netmap (BSD's version of DPDK in simple terms). The point being that, as more and more networks move towards 10Gbit / 100Gbit networking, VyOS is going to lag behind anyone else who implements DPDK or netmap routing first.

@mickvav I think you're misunderstanding the benefit of DPDK. It's essentially fastpath for Intel-based platforms and if implimented correctly can be the difference between 10 Gbps and 100 Gbps on the same hardware. Obviously being able to scale VyOS to that level would be game-changing. It's important, just likely not in scope for VyOS at this time ...

@mickvav Well, the entire point of VyOS is to simplify routing configuration on a Linux platform / kernel. All the things vyos does can be done with manually tinkering of configuration files, etc. So yes, implementing DPDK will allow for simplified troubleshooting and configuration.

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?

@rps Yes, when I refer to DPDK support I mean full support for routing, NAT, firewall, etc. I understand this would be a huge undertaking which is why I suggested some kind of bounty or possible sponsorship from several companies willing to pitch in and help.

@mickvav I think when people ask "does it support DPDK" it's because they've read that using DPDK will allow forwarding and possible filtering and NATing of traffic at 10 Gbps+ rates. VyOS offering some DPDK stuff and saying "mission accomplished" would leave a bad taste in people's mouths the same way CloudRouter is claiming DPDK support when it's only for bridged traffic.

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 :)

@rps
i guess you can put this as answer and we can mark it as solved

"DPDK support" involved a lot of low-level contributions to a lot of different projects. Essentially you need to re-implement major parts of Linux on a case-by-case basis which is outside of the scope for VyOS right now.

Agree, we can do some slides for that purpose
i mean that people can add reporters and own companies as needed

Maybe really generic one should not reference specific companies, not sure.

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)?

Anything local should hardly be considered high priority, but the first one is remote. We definitely should include the fix in the 1.1.8

In T142#2451, @whiskeyalpharomeo wrote:

Opinion: Yes, 1.1.8.

Opinion: Yes, 1.1.8.

@dmbaturin is this good reason for 1.1.8 ?

@whiskeyalpharomeo you can do that already with the existing CLI.

Absent full vrf or vrf-lite behavior, there is a means of achieving a subset of this behavior using only iptables.

It would be nice if this was available in the next release. Happy to receive any feedback if I need to improve the patch.

@dmbaturin can you check
https://github.com/giandvd/vyos-dev-vm
can we put this maybe under contrib or etc like with management library