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.

@EwaldvanGeffen have you given the method I described a try on VyOS? I know it works on EdgeOS and pre- 6.4 releases of Vyatta and honestly haven't tested it on VyOS because it's not something I have a need for... so it very well could work differently/be broken on VyOS, but that would be surprising.

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

Short answer: not really.

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

You can use policy routing to match HTTP and HTTPS traffic and point it at a next-hop that is an external transparent proxy.

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.

@afics this ticket at least have description
i will merge all to one soon

Thanks both.
As suggested, is there a way to check the device is live and then forward traffic or do a fallback to another device.

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.

You would have to forward traffic to your device. Preferably it handles all types of traffic. Otherwise you can forward dport 443 towards a specific IP.

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.

Keep in mind that the specification has not yet been standardised. If you commit to implementing, make sure you only release it as a 'beta' or 'test release'.

Interested in this too. We will be multi-homing soon and requesting an AS number from ARIN. I doubt we will be getting a 2-byte ASN.

Let me know if you require any additional information. I'm happy to help you with interop testing

@dmbaturin what do you think?

@whiskeyalpharomeo maybe in your scope of interest

@dmbaturin is this good reason for 1.1.8 ?

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

Welcome @whiskeyalpharomeo !
No code required(but of course welcomed if any)
After all this project not only about the code!
I like to think that is about giving access to advanced networking to everyone out there!
Since it not like 10 years ago, now technology(hardware) more accessible

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

This is part of a broader AAA activity, such as TACACS+ and/or RADIUS integration for system level administration.

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

I pushed the priority changes I had to do on my T132 branch.

In T128#2209, @UnicronNL wrote:

As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.

As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.

In T128#2194, @dmbaturin wrote:

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

But what's worse, is that making it a commit fail will break the configs of those people who carelessly left a nonexistent interface in their DNS forwarding config, it will fail to load at boot time after upgrade.

As much as I hate generating configs that make no sense, leaving those people with potentially inaccessible systems after they upgrade (DNS loads before SSH AFAIR) is not an acceptable cost of somewhat tidier generated configs.

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

https://github.com/vyos/vyatta-vrrp/commit/86a3e32d367c6936fe424d6aace06ea7262f4300

@dmbaturin is about unsaved changes indication
@jeffbearer system loads last saved config

Can you push your recent changes to github?

Changing the priorities, I managed to make it work and it's loaded fine on reboot.

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.

Ok, so the main issue is that the route-map is only applied to routes installed _after_ it's been setup ... so you have to remove / readd all the static routes which obviously doesn't work when you reboot :(

This is my attempt :

vyos@r1-80001# run sh ver

@higebu seems correct.
It will be a good start

We need this? https://github.com/hiroyuki-sato/vyos-cfg-zabbix-agent