I am currently attempting to configure an IPv6 BGP session on a Vultr VM. The issue is that Vultr does not offer a static IPv6 gateway; instead, they rely on Router Advertisement (RA). Consequently, I am unable to specify any static IPv6 routes.
Unfortunately, I am unable to initiate the IPv6 BGP session, as FRR refuses to establish an eBGP session through the system’s default route.
Is there a method to force FRR to establish an eBGP session using the kernel’s default route?
I had a VM setup with them a couple years or so ago, I did not except any RAs from them. I belive i used a static interface route for it. set protocols static route6 <peer>/128 interface <wan port>. They may require multihop aswell. Its been awhile so i dont remember all the details.
They don’t give me a Ipv6 gateway. Therefore I can’t setup a static route.
You dont need one, it is an interface route.
Tried that too, but when I define a interface route, the destination becomes unreachable, for whatever reason.
vyos@vyos# ping 2001:19f0:ffff::1
PING 2001:19f0:ffff::1(2001:19f0:ffff::1) 56 data bytes
64 bytes from 2001:19f0:ffff::1: icmp_seq=1 ttl=64 time=0.155 ms
64 bytes from 2001:19f0:ffff::1: icmp_seq=2 ttl=64 time=0.196 ms
^C
--- 2001:19f0:ffff::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1036ms
rtt min/avg/max/mdev = 0.155/0.175/0.196/0.020 ms
[edit]
vyos@vyos# set protocols static route6 2001:19f0:ffff::1/128 interface eth0
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# ping 2001:19f0:ffff::1
PING 2001:19f0:ffff::1(2001:19f0:ffff::1) 56 data bytes
From 2001:19f0:7001:0000:0000:0000:febe:4db3 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:19f0:7001:0000:0000:0000:febe:4db3 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:19f0:7001:0000:0000:0000:febe:4db3 icmp_seq=3 Destination unreachable: Address unreachable
^C
--- 2001:19f0:ffff::1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4115ms
Il see if i can get it to work, I gotta wait for their support to re add bgp to my account since its been inactive for so long.
Thanks for your time and effort 
I’ve pocked around a bit more but unfortunately didn’t found a solution so far.
However, when I define a static route to the gateway I get via the RA, everything works fine and the bgp session comes up.
vyos@vyos# set protocols static route6 2001:19f0:ffff::1/128 next-hop fe80::fc00:4ff:febe:4db3 interface eth0
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# ping 2001:19f0:ffff::1
PING 2001:19f0:ffff::1(2001:19f0:ffff::1) 56 data bytes
64 bytes from 2001:19f0:ffff::1: icmp_seq=1 ttl=64 time=0.171 ms
64 bytes from 2001:19f0:ffff::1: icmp_seq=2 ttl=64 time=0.182 ms
But this isn’t a viable solution as the gateway can change at any time 
I am running bgp6 on vultr with the following config, no static routes necessary:
interfaces {
ethernet eth0 {
duplex auto
ipv6 {
address {
autoconf
}
}
...
protocols {
bgp {
neighbor 2001:19f0:ffff::1 {
address-family {
ipv6-unicast {
}
}
capability {
dynamic
}
ebgp-multihop 2
password ****************
remote-as xx
update-source <vultr instance global addr>
}
and
$ sh ipv6 route
K>* ::/0 [0/1024] via fe80::xxx, eth0, 04w0d19h
...
FRR appears to be happy to use the default route received from the RA.
There may be something that changed at some point, I recall being able to do the same as use a year or two ago, But with a fresh build im running into the same issue as OP. What version of VyOS are you using and what version of FRR does it have?.
It seems the solution is to enable “ipv6 nht resolve-via-default”, however it seems there is no option to do this via the VyOS cli currently. I created ⚓ T6001 Add option to enable resolve-via-default to get this feature added. Il try and see if i can get that done this week.
That router is running 1.4-RC1
Hello, this is FRRouting (version 9.0.2).
as I mentioned on task , that option was add as default behavior , although , it’s supported newest version (unfortunately, it’s an issues detected by our main developers) for that reason is not updated :