How did you go with OFP? I can compi;e and run it on vyos platform but first I tried in on Ubuntu and found it much worse than stock linux perhaps there are some setup that is required for it to function optimally. I also tried vpp and that doubled the pps at 64bytes.

Nightly builds are working again, need to fix web hooks next.

Yes, related. I was just talking to myself really, we get the CI back first, and then we can look into adding vyconf to it.

Our gateway is bad and we should feel bad. When jenkins migration to the new site is complete (we are migrating build hosts too), this should work again.

I get a 502 Bad Gateway too.
Is this related? https://phabricator.vyos.net/T222

Awesome. I don't know if it's just me but I get a 502 Bad Gateway when accessing https://ci.vyos.net/

Thanks! Unit tests pass.

Unit tests pass for me too.

Mentioning: http://pastebin.com/yZLVRfnA
Which is an example of how would WLB work with a custom script.

@EwaldvanGeffen apply this rule on what? a WLB?
the WLB from what I understood required an interface per gateway while PBR allows me to route the traffic towards any of the gateways which can be the next-hop ie 10.0.0.100/24 or 10.0.0.101/24.
This is what I remember from vyatta and I haven't digged into the subject since I have a huge gap ahead as far as I can see.

@elico if you apply a 'source my-lan-clients, destination port-80, proto tcp' rule with gateway your proxy server + the custom testing-target script. If the proxy is up it will be routed towards it. If the target goes down, without any other policies the packet will fall onto PBR and then routing. Isn't that the behaviour you were looking for?

@EwaldvanGeffen WLB has a difference from PBR and what is required a PBR.
The code is not something I was looking for but an example of implementation in the configuration.
Then I will be able to look at the code and understand what might be applied to PBR compared to WLB.

Wan-load-balance. Example is here: https://github.com/vyos/vyatta-wanloadbalance/blob/current/scripts/http_test.pl and implementation https://github.com/vyos/vyatta-wanloadbalance/blob/current/templates/load-balancing/wan/interface-health/node.tag/test/node.tag/type/node.def

@EwaldvanGeffen Can you help with giving an example of implementing this?
Like with a tiny ping that returns a status code?
(I do not know what WLB is...)

@elico it's pretty simple since WLB supports custom tests for gateway/targets. You can simply script it up to that.

@EwaldvanGeffen technically we can simplify it into a form of a script that monitors the service using http or another tcp\udp based and would flag the avaliability of the service.
The marking and forwarding rule can be automativally bypassed if the service is flagged as down.
Anyone interested working with me on this?
It's basically a simple conditional PBR.. and since WCCP is "OK" for tiny routers for beafy machines such VYOS have I believe that it would be a piece of cake to cook this up.

Here is a howto on the openfastpath - https://www.howtoforge.com/tutorial/opendataplane-with-open-fast-path-on-ubuntu/

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.

Looks like it works, and the tests pass.

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

Pluto has changed to charon.

This bug is also present in the last night build

@whiskeyalpharomeo pointed to
https://github.com/jeroennijhof/pam_tacplus
I talked with @dmbaturin and it looks like via PAM we can perform at least something basic.
@dmbaturin can you comment more ?

Yes, waiting a bit does not hurt. We are working on version 3 of the patch to accomodate the missing features

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...

The Quagga has been provided with a patch to support Large BGP Communities. This patch is for Quagga 1.1.0 but should be easy to backport if needed.

Hi, I'm new and found my way here via WAR's blog post.
Big +1 for TACACS+ support.
I manage a bunch of cisco routers and now have half a dozen or so vyos routers in the mix too. I need to grant junior admins rights to these while limiting their ability to break stuff and currently use TACACS+ for this with the cisco routers we manage. I would love to do the same for the growing fleet of vyos virtual routers.

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.

@hmkias I think that some kind of a daemon would be required to "coordinate" between the squid machine to the VYOS.
I had an idea about it in the past but never had the chance to actually implement it with vyatta.
However I have seen that in ZEROSHELL there is a very nice feature which test for proxy IP level availability.
How complex would it be to make a condition to the policy based on a lock file?

Why aren't you all discussing this on the Quagga mailing list? More generally, what is the VyOS project policy about work that belongs in upstream?

Through an early allocation, IANA assigned 30 as the path attribute value for Large BGP Communities.

I m thinking on two approaches to the problem, WCCP or patching Squid. Ultimately the complexity and time decides the way.

@rps I think he needs a more modern version of squid with sslbump support. I wouldn't put any effort in WCCP, it seems fairly legacy to me.

Patch for HTTPs filtering.
I have to remove the existing version and install a new patched version from source.

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

@hmkias Patch Squid for what?

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.

I would start with PBR in the first phase for supporting the external proxy.

In theory, you could have the web filter be a pair of servers using VRRP.

@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".

or do a fallback to another device.

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.