The VXLAN RFC states:

What would be a filter that is not working?

Please wait for todays build and test again. Thanks for your support!

IPv6 address in scp://<user>:<passwd>@[IPv6-address]/<dir> looks like not properly escaped. Should be \[IPv6-address\].

@syncer
Use the configurations I provided and observe the packets the router is sending out.
In the nightly build the router is sending out using the IPv6 group address
Up to 1.1.8 the router is sending out using the IPv4 group address
This makes upgrades impossible
Using VRRPv2 with both IPv4 and IPv6 virtual addresses in the same VRRP instance is only possible due to a bug in the 1.2.19 keepalived

On two debian 8 test VM I compiled keepalived 1.3.9 without any errors. It may be a good thing to get this latest version for our new implementation.

@aopdal can you please provide relevant information and not just bunch of already known info?
We need description of problem and how to reproduce it, not comments from captain obvious

The current implementation is working on keepalived 1.2.19 (from 2015.07.07). In 1.2.20 (from 2016-04-02) a lot of bugs are fixed and the possibility to use IPv6 in VRRPv2 is gone.
When implementing IPv6 / VRRPv3 we should probably base the implementation on a newer version of keepalived.

Testing on

Please test latest nightly builds and report back

that is obsolete

@c-po i should get router with v6 and snmp
will ping you once it up

@EwaldvanGeffen can i mark this as solved?

can't reproduce

i think it's solved by now, if not, please reopen

can you add required nodes for this maybe
@UnicronNL please assist

@dmbaturin please review and merge in

i removed serial device in OVA

@dmbaturin @UnicronNL please review and merge in

@dmbaturin can you merge it in

Use "set load-balancing wan sticky-connections inbound".

Use "set load-balancing wan sticky-connections inbound"

@dmbaturin any comments on this?

@c-po can you look into this please

I'll check, meanwhile, could you verify that you still see this issue in the latest build?

@aopdal try latest nightly as we pushed changes related to vrrp

package is now in the vyos repo and used in images

@syncer I am the unofficial maintainer of the Squid-Cache RPM's and DEB packages and doing it for more then 4 years now.
These days network routers are actually Route Servers and only the low cost devices doesn't contains any form of proxy functionality on them.
If you need a simple IP router you don't need it and this is most of the use cases of YVOS to my knowledge.
However we might be able to compromise on something in the middle instead of ditching it or other proxies.
Squid-Cache is good for caching but very old so for filtering there are couple other more efficient solutions and also the nature of the Internet HTTP world have changed so caching is good only for very specific purposes...
So I think that it would be a nice to have but if it's possible to allow the admin configure Squid or another proxy outside of the configuration shell it would be a better solution.
Also if you want to intercept traffic into squid you can just use DNAT rules.

@mickvav What's the status of 1.2.0-x? is there a build node\vm\container I can experiment building nDPI support?

I use squid as a caching proxy to very considerably speed up patching and non-encrypted static web content. I also use the blacklists which are updated every day. While VyOS with Squid and Wifi is a very good integrated router for home and SOHO, I also use it as building bloc for sample firewalls you encounter in corporate environments in several showcases.

Awesome. :) Let me know if you ever need an extra pair of hands on the infrastructure front.

It will be sooner or later ;)

That's true, I would use a TLS mirror with a SHA-256 hash from the master. But I'd also want the master to be TLS.

If you can at least get a strong hash sum of the ISO from the master, that should be sufficient regardless of where the binary is downloaded from. Of course, if the master is compromised, all bets are off.

We should probably put in the mirror documentation that new mirrors must support TLS and existing mirrors are strongly urged to add support for TLS. However, to be clear, wanting a secure source for my downloads, I won't download from a mirror, because there's a lower level of trust. In fact, given a mirror with TLS and a the master source without TLS, I would chose the master source every time.

This begs the question about the mirror mechanism. My mirror supports TLS, but most don't.