- User Since
- Mar 30 2016, 7:20 PM (112 w, 3 d)
Mon, May 14
I think option 2 is the best, but keep in mind the VRRP version is 3, and it support both IPv4 and IPv6.
Mar 12 2018
@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.
Mar 8 2018
The showstopper for me to upgrade to 1.2 with current aproach is the configuration statement (in keepalived configuration)
Feb 27 2018
Jan 16 2018
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
Dec 22 2017
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.
Dec 18 2017
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.
Dec 11 2017
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?
Dec 1 2017
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?
Nov 30 2017
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.
Nov 29 2017
/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 ;-)
Nov 28 2017
But if you run:
Nov 27 2017
Using hello-source-address does not help either...
The 32 bit buils 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.
Nov 7 2017
I have upgraded my "parallel" universe. It look like redistribute static does not work.
Oct 27 2017
Optimize a routers defaults should be targeted to the usecase of a router and not for some special use gets my vote.
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.
Oct 26 2017
I'm upgrading my vmware cluster with vyos routers and are doing some tests. My production environment is running on 1.1.7.
Aug 3 2017
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.
May 26 2017
Is there any progress on this? Is there any design documents in progress?
Dec 20 2016
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.
Aug 11 2016
vyos@r1-80001# run sh ver