The workaround using /config/scripts/vyatta-postconfig-bootup.script works nice. It is probably more user friendly if it is configurable in cli.

set firewall name IN-ETH0 rule 70 helper ftp

Is a good approach i think. When all are going to use encrypted ftp the helper can't be used, but for now I have some customers who don't want to find their passive ports. So I must get the helper going ...

Working with only static and OSPF + static route.

Looks like this is working now on my two routers using this feature - good work!

This bug is in effect also without using dynamic routing.

I have upgraded this router to :

@rps I think this is a bug, because this behavior is not by design - it just to happen ;-) . You may call i a design bug.

If you need config samples for testing I'm happy to provide it. Or tell me when to retest.

For the VRRP group running IPv6 you need 'vrrp_version 3' at least in the keepalived config.

I think option 2 is the best, but keep in mind the VRRP version is 3, and it support both IPv4 and IPv6.

@rps RA and VRRPv3 is quite a complex "thing". And it's easy to make something which don't work. If you have more than one VRRP group running on a network segment, only one of the groups should do RA. The most difficult case to solve may be if you run two routers with two groups on the same interface to do some kind of load balancing and also want to do RA. This may require configuration of RA on the VRRP group. But if you don't run VRRP you must configure RA directly on the interface.

The showstopper for me to upgrade to 1.2 with current aproach is the configuration statement (in keepalived configuration)

With prefix delegation you have a static prefix on your inside, but the "wan" interface on the router is using DHCP.

Without routing you probably can't get it to work. Are your addresses managed from Comcast using prefix delegation?

@beamerblvd have you added routes for your vif 100,200 and 900 in your "COMCAST BUSINESS IP GATEWAY"?

Perhaps you could make a drawing of what you try to get working? With proper interface naming etc. eth0 - wan, eth1 - dmz, eth2 - lan or whatever you are using. It makes it easier to understand what you try to do. And for the interfaces why do you want to use the /60?

Maybe this is relevant? https://phabricator.vyos.net/T421

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

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

Does anyone have any ideas how to get VRRPv3 in 1.2?
If we could conclude on the approach we could go further by describing cli commands, make out how the upgrade should be done, create documentation and so on.

But should it be configurable using cli?
Should there be a warning when adding a interface and no buffer is available?
Should there be some smartness created for avoiding the "no buffer" event?

Anyone having any ideas to how to solve this problem?

We are hit by bugs in the OSPF of Quagga which are not fixed in newer versions, but are fixed in FRR. Most of my stuff is working. Getting up to date on Quagga is probably also quite some job, and from the testing perspective it's just the same. Everything must be tested... From the design and documentation perspective we need to put down some more work if we are using FRR.

@dmbaturin is there a (estimated/proposed) releasedate on 1.2.0?

Using two debian VM i have played around with this today.
I have been using debian 9.2 and keepalived v1.3.2

@mdsmds If you have a mixed environment running with VRRP, just comment out the offending line in the 32Bit router and you are good.

It looks like this https://github.com/vyos/vyatta-vrrp/commit/dfbc742a6454388aa6a2523541a170c01fc42533#diff-7a3c3afc4665f422017c25f832c9c28b

/opt/vyatta/sbin/vyatta-keepalived.pl in the 32-bit build writes the native_ipv6 line to the configuration.

For some reason the 32 bit build add native_ipv6 to the configuration in /etc/keepalived/keepalived.conf

Are we going for FRR in 1.2, or are we going to keep Quagga?
I'm just wondering what I should test ;-)

But if you run:

Using hello-source-address does not help either...

The 32 bit build is using IPv6 VRRP address and 64 bit build is using IPv4 VRRP address

With limited people in the project I think the "core" features for a router should be of priority. A lot of things is nice to have, but we need to have a good router.
IPv6 with VRRP, connection tracking, updated routing engine, IPv6 PD is stuff we need and requires a lot of design, implementation, testing and documentation.

This is a drawing of my current lab environment.

I have upgraded my "parallel" universe. It look like redistribute static does not work.

Optimize a routers defaults should be targeted to the usecase of a router and not for some special use.
If you want to use a vyos as a VPN concentrator - well then configure if for this case. If the defaults are not optimized for general purpose, then you must tweak it for the "main usecase" as a router.

I'm upgrading my vmware cluster with vyos routers and are doing some tests. My production environment is running on 1.1.7.

I'm using pptp and also IPSEC VPN in combination with VRRP. It works for me, but you must restart the service when a router becomes VRRP master. And you need to create a VRRP sync-group so all interfaces are master on one router. I'm using preempt false to avoid the service to be moved (and restarted) more than necessary.

Is there any progress on this? Is there any design documents in progress?

I could participate in a meeting next week, this week is "getting ready for Christmas" week ;-)

I like to participate in the testing. But I think we need to break down the point in a bit more specific tests. We should also have requirements which state what is pass / fail. And we should probably create specific test descriptions ant test cases which could be automated.

vyos@r1-80001# run sh ver

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