@jhendryUK or @hsahmed can you share a full configuration for reproduction please.

This is still happening with version 999.201801111542

done by @UnicronNL ... ISO built.

@syncer vyos-999.201803161451-amd64.iso is the first version running on Linux 4.14.26!

Thanks!

Thanks for the feedback!

I was actually playing around with this last night (building it via vyos-build myself) when I saw that the 4.14.26 vyos kernel package was up

@myura please test the latest rolling release if your i219 chipset is now detected. Kernel has been upgraded to 4.14.26.

Will be implemented by T583.

These are the pachtes i took from old vyatta, seems like you got them all.
https://github.com/vyos/vyos-kernel/commit/4c8de1009e13a978bacd5066024d194be983ecbd
https://github.com/vyos/vyos-kernel/commit/e8b8c70f0e20666824f33083d7aa76a3f1a1f6f5
https://github.com/vyos/vyos-kernel/commit/fc58d4a339537765585855a9b793b953c7c984f1
https://github.com/vyos/vyos-kernel/commit/e59dab9f2985869cfdbf9b74cb5c8034c218707b

I started working for 1.2: https://github.com/higebu/vyos-1x/tree/cloud-init

A bit more information on this.

The Kernel commit/patch fc58d4a33953776 is used by https://github.com/vyos/vyatta-keepalived/commit/8bd97620 and VyOS 1.2 is using vyos-keepalived which no longer needs this patch.

@syncer please close and reopen if req.

Pretty much agree but don't think we need to worry about supporting a use case that is likely to create other problems until someone actually requests it as a feature.

I agree with @aopdal comments. Regarding the approach on how to handle RAs, probably the most common usecase would be a single VRRP group per interface. For that case, maybe an interface config stating that the interface should only send RAs if the VRRP group on that interface is in Master state could do the trick. As already said, other more complex scenarios (like the one with multiple VRRP groups per interface for load balancing) probably would require state transition scripts (or not relying in RAs).

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

Looking through all changes I come up with the following:

Looking into this I see 47 non merge commits which are not in the mainline Kernel:

It sounds like we can give the upgrade to keepalived 1.3 a try provided we go back to virtual-address support IPv4 only (like in 1.1) and remove the native_ipv6 statement from the configuration script as step 1.

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

I think we should investigate possibility of v3 in 1.2
Will be possible to implement in 1.2 or not that is other story.

Just checking on this. The nightly build for 1.2 has keepalived 1.2.19 and transition support for virtual IPv6 addresses using VRRPv2 appears to be functional at first glance.

@syncer could this be a duplicate of T523?

Well, I added an initial version of the script.

Please make sure to read the guideline: http://blog.vyos.net/vyos-2-dot-0-development-digest-number-5-doing-1-dot-2-x-and-2-dot-0-development-in-parallel
You can use the cron script as an example, too.

Got it.

Implemented and CI build triggered.

@SimonWydooghe please retest on nightly builds

@c-po @UnicronNL have this ever been solved?

For reference this is the standard ruleset I use on our servers for IPv6 (limited to only what is necessary for DHCPv6 and ICMPv6):

P.S. @dmbaturin If you can direct me to some instructions on how you would prefer suggested patches be submitted I can re-work to make it easier on you.

Closing the task then.

I tested with VyOS 999.201803020337.

@dmbaturin I totally agree

@alainlamar @c-po Multi-nodes should indeed be used whenever possible instead of making the user enter comma-separated values and the like.

The issue was the folder change, not the conf file name. The conf file is still squidGuard.conf
Pull request: https://github.com/vyos/vyatta-webproxy/pull/6

Customer could not wait any longer and did did not want to do any more testing. We rolled back to 1.8.1 and IKEv1. We can considered this closed. Thanks for the help and efforts!!!!

fixed this couple of days ago.

@UnicronNL maybe you can advise here

The drivers shipped inside the Linux Kernel do not match the Intel ixgbe driver 100%. There are small feature discrepancys.