Can you disable this GRE tunnel and make a dump of a moment when a tunnel being established?
Also, send output of:

sudo ip6tables -t raw -L -n -v
sudo ip6tables -t filter -L -n -v
sudo ip6tables -t mangle -L -n -v
sudo ip6tables -t nat -L -n -v

That should be already in there for a few days now.

In T1262#33324, @hagbard wrote:

@fromport does the new pkg solve the issue you are seeing? It did during all my tests.

@fromport does the new pkg solve the issue you are seeing? It did during all my tests.

just tested, still same behaviour.

GRE packet is entering on "LAN" interface (eth3) but is not being forwarded to uplink (eth1, route to ::/0)
Any firewall on eth3 has been removed during testing.

let me check that with latest rolling version.

Will update.

Oh, and one final question: you don't have a static IPv4 address, do you? Just trying to sort out any possibilities.

I haven't made any 'Apply changes' to the modem and unfortunately it still won't forward my IPv6 traffic. You don't happen to have a firewall rule handy for being extremely permissive with IPv6 outgoing traffic, do you?

Ah, interesting. I'll see if I can reproduce the address dhcpv6 problem.

The commit failed and had to be ctrl+C'd. However, delete interfaces ethernet eth1 address dhcpv6; commit; then a second commit making the dhcpv6-pd changes work. So instead of the single step working, it had to be broken into two.

Yeah, I still have a bit of debug output in there. Easy enough to remove.

@jjcordon can you provide the full configuration and test again with a latest rolling version?
In our test with 1.2.0-rolling+201902250337 everything works fine:

routing table:
C>* 2001:XXXX:YYYY:11::/64 is directly connected, eth1, 00:27:06
C>* 2001:XXXX:YYYY:12::/64 is directly connected, eth2, 00:14:28

According to pmacct configuration, this looks good. We need to check code, and if all is correct I propose to merge this into rolling for testing.
Just the one nuance. Currently, VyOS CLI doesn't allow to set a BGP neighbor to the local IP address. If we accept this patch, then it will be good to remove this restriction.

Rebooted the router and configured following your instructions and got assigned an IPv6 address on my LAN interface! I'd never managed to get this far with pfSense (I could only get it to assign me addresses on the external interface) or on EdgeOS (probably over a year ago). Thanks so much!

I'm closing this ticket, because we don't have feedback from author for a long time nor configuration for reproducing this by ourselves.
If someone will meet with this bug with FRRouting-based versions of VyOS, please reopen.

Hello!
Bug confirmed in 1.2.0-rolling+201902250337. Current way of checking values accept only that names, which is returned by cat /etc/iproute2/rt_dsfield (source). Currently with kernel 4.19.20-amd64-vyos this is:

# Differentiated field values
# These include the DSCP and unused bits
0x0	default
# Newer RFC2597 values
0x28	AF11
0x30	AF12
0x38	AF13
0x48	AF21
0x50	AF22
0x58	AF23
0x68	AF31
0x70	AF32
0x78	AF33
0x88	AF41
0x90	AF42
0x98	AF43
# Older values RFC2474
0x20	CS1
0x40	CS2
0x60	CS3
0x80	CS4
0xA0	CS5
0xC0	CS6
0xE0	CS7
# RFC 2598
0xB8	EF

Great! The one I built last night is still available here: http://www.avernus.com/~gadams/vyos-crux.201902250834.dhcpv6pd-amd64.iso

I‘m on Telekom FTTH (Germany) and could test an ISO, too.

Indeed, this is on Comcast Business. At least they're consistent in their oddity, eh?

You wouldn't happen to be on Comcast, would you? The supposed-/56 that's offered when instead it's a /60 is a behavior I'm familiar with on Comcast.

Great! I'll look forward to hearing how it works for you.

In T421#33183, @gadams wrote:

I've learned a lot about building ISO images over the past couple weeks. I have a first version of my change ready; it's in two commits currently:

https://github.com/gsadams/vyos-1x/commit/9dc320b026d29e1c6e290346b8be53a6f5a74a11
and
https://github.com/gsadams/vyatta-cfg-system/commit/5c1900015fe5f0c65810bdbbefa0c61cd118cc6d

and also likely requires the fix I proposed in T1059 (which appears not to have been merged, yet), depending on your particular configuration.

If you'd like to test it, I have built an image from the latest Crux branch plus those three changes, here: http://www.avernus.com/~gadams/vyos-crux.201902250834.dhcpv6pd-amd64.iso

I'm currently running that image, myself. It'd be nice if anyone who wants to get DHCPv6-PD working could give it a try and let me know whether it works for you, what you think of the config syntax, or anything glaring that it's missing. The configuration syntax is basically what I described up above. You'll need to enable the DHCPv6 client on the appropriate interface (the one connected to your ISP, presumably), and specify how you want the delegated prefix farmed out to other interfaces.

One known limitation is that the DHCPv6-PD configuration can currently only be applied to an ethernet interface. That's not because of any technical limitation; it's just that applying it to other interfaces will require copying a bunch of files, so I thought I'd try to get it right in one place, first.

Confirmed in 1.2.0-rolling+201902250337. A hw-id is assigned to only one of interfaces per boot.
If this will not lead to a race condition situation, maybe try to implement the solution from T577#12637 proposed by @rps?

No further complaints - seems to be resolved.

okay - then I kindly close this one.

Confirmed in 1.2.0-rolling+201902250337.
I think we must allow adding overlapped networks/address into the same set, as ipset allows to do this. Maybe situations, where this will be necessary, are rare (for example, resizing network size defined in set), but there is no clear reason to deny such combinations.

Awesome, thx.

We've not had this issue since i applied the patch.

I've learned a lot about building ISO images over the past couple weeks. I have a first version of my change ready; it's in two commits currently:

@hagbard last rolling has no issue.
everything works as expected

@thinkl33t any updates?

In T1148#33158, @dmbaturin wrote:

@danhusan IPv6 should not be affected. Workaround for IPv4:

@oleksandr.ovsiannikov any updates?

binaries (lcdproc, lcdproc-extra-drivers) added to rolling releases.

Added the above snipped to vyos-1x and the latest rolling releases

Unfortunately this is not implemented in ntpqc. The reason it worked for me was my firewall blocking everything else.

It didn’t cure it I’m afraid. It has, however, changed the error message to:

and thanks for the help hagbard ...

So i have test it and ... hmm the Problem is that the grub menu is ripped apart.

Please test with a rolling relase build date newer than 20120220 - Drivers have been replaced with the ones provided by Intel

@syncer

In T1247#32887, @oleksandr.ovsiannikov wrote:

@hagbardIt fixes the issue with WANLOADBALANCE_PRE chain, but we still observe unexpected behavior.
I will write a little bit more letter.

/var/log/messages

Brill, i've applied that patch and will keep an eye on it for a few days to see what happens.

can you edit /usr/libexec/vyos/system/on-dhcp-event.sh

The line giving the error is:

@TriJetScud please see :

I think we have a much fresher strongman,
maybe someone picks it up to rewrite in python

To be fair, the things we're need to make this work is