Re: static IPv6 setup is not working stable
Hi Demi, have done: ndp -s fe80::1%vio0 00:00:5e:00:02:02 which results in a nearly permanent setup: Neighbor Linklayer Address Netif ExpireS Flags 2a03:4000:24:82f:: d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::1 d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::4500 d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::5353 d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::8022 d6:16:7b:a0:ce:63vio0 permanent R l fd91:24d4:fa4c:379d::1 d6:16:7b:a0:ce:64vio1 permanent R l fe80::1%vio0 00:00:5e:00:02:02vio0 23h59m54s S R fe80::22d8:b00:89ee:ff4%vio0 2c:6b:f5:a0:77:c0vio0 23h57m43s S R fe80::22d8:b00:89fa:424c%vio010:0e:7e:26:f1:c0vio0 23h44m43s S R fe80::d416:7bff:fea0:ce63%vio0 d6:16:7b:a0:ce:63vio0 permanent R l fe80::d416:7bff:fea0:ce64%vio1 d6:16:7b:a0:ce:64vio1 permanent R l So the gateway is now “ticking” around the 23h59m. It doesn’t run stable at all. Ping6 from the outside: 16 bytes from 2a03:4000:24:82f::4500, icmp_seq=16 hlim=58 time=680.134 ms 16 bytes from 2a03:4000:24:82f::4500, icmp_seq=17 hlim=58 time=81.254 ms Aug 10 17:12:58.718515 rule 5._2.1/(match) pass in on vio0: 2001:470:7309:8400:8258:5a7c:fe68:afdd > 2a03:4000:24:82f::4500: icmp6: echo request [flowlabel 0xec744] Aug 10 17:12:59.546185 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff00:bca4: [|icmp6] [class 0xc0] Aug 10 17:12:59.547423 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff4a:3f62: [|icmp6] [class 0xc0] Aug 10 17:12:59.550876 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff06:ad8f: [|icmp6] [class 0xc0] Aug 10 17:12:59.554148 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff73:d955: [|icmp6] [class 0xc0] Aug 10 17:12:59.642650 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff00:2: [|icmp6] [class 0xc0] So it works like in the past, that a lot off packages goes lost first, than it works for a time and than it goes off again. Kind regards, Kay-Uwe > The best option I know of is to add a static, permanent NDP entry > with ndp(8) entry before bringing up the interface. This works even > if the peer does not respond to NDP at all. > > Sincerely, > > Demi signature.asc Description: Message signed with OpenPGP using GPGMail
Re: static IPv6 setup is not working stable
On 2020-08-06 09:51, Janne Johansson wrote: > I have a setup where the virtualization (KVM) combined with the networking > does present a IPv6 def-gw as both an fe80:: and > the more normal 2001:a:b:c:d::1/64 and where the 2001-v6 ip works far > better on virtual machines due to redundancy mac sync things on the network > side, and since the ndp list showed the fe80::1 had a VRRP/CARP-lookalike > mac, it could be the same. > > In my case both bsd and linux IPv6-using VMs suffer from ndp "drops" where > it can take seconds for the discovery to figure the mac address out again > after a drop. > > So if you can divine what the "real" v6 ip is of the default-gw, try > setting this hard in the conf or /etc/mygate and retry v6. > > > Den tors 6 aug. 2020 kl 14:46 skrev Matthias Schmidt : > >> Hi, >> >> * kug1977 wrote: >>> >>> Is this something wrong configured on OpenBSD server or is this something >>> the provider has to check on the gateway side? >> >> I also have a VM at the exact same provider (netcup) and face >> the same problem. Since all of my VMs at different providers are >> identical (base install + conf via ansible) and I don't see the issue at >> other providers (IONOS, Hetzner) I suspect it has nothing to do with >> OpenBSD... The best option I know of is to add a static, permanent NDP entry with ndp(8) entry before bringing up the interface. This works even if the peer does not respond to NDP at all. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: static IPv6 setup is not working stable
Just to chime in uselessly, I am having no end of trouble with IPv6 on various machines. I cannot get IPv6 to work either on my PC-ENGINES APU connected to a FRITZ!box or my VPS at tinykvm.com; but for whatever reason things work better (although not completely) at vultr.com. As far as I know the setups are identical, but of course the "upstream" network is different in each case. Luckily I don't really need IPv6 so I just decided to ignore the issues. But that doesn't feel very satisfying. (And my Google-fu must be terrible because I cannot seem to find a single OpenBSD IPv6 tutorial that actually works when I try to go with it.)
Re: static IPv6 setup is not working stable
Dear Janne, traceroute6 -I ipv6.google.com traceroute6 to ipv6.l.google.com (2a00:1450:4001:81b::200e), 64 hops max, 60 byte packets 1 2a03:4000:24::3 (2a03:4000:24::3) 0.384 ms 0.558 ms 0.563 ms 2 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 0.887 ms 0.545 ms 0.421 ms 3 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 4.227 ms 3.486 ms 3.574 ms 4 2001:4860:1:1::6bc (2001:4860:1:1::6bc) 6.794 ms 5.098 ms 3.559 ms 5 2001:4860:0:11df::1 (2001:4860:0:11df::1) 4.243 ms 3.825 ms 3.843 ms 6 2001:4860:0:1::671 (2001:4860:0:1::671) 4.169 ms 3.866 ms 3.856 ms 7 fra15s16-in-x0e.1e100.net (2a00:1450:4001:81b::200e) 3.776 ms 3.889 ms 3.867 ms OpenBSD is learning the default route fe80:1%vio0 by NDP, so even without configure it as gateway will be used. And using somethings next hop is gw is not working either route add -inet6 default 2a03:4000:24::3 add net default: gateway 2a03:4000:24::3: Network is unreachable I have opened a ticket with NETcup … hopefully they will check. -Kay-Uwe > On 06 Aug 2020, at 16:10, Janne Johansson wrote: > > No, I think in my case it is Juniper multichassis LAG (link aggregation > groups) getting confused by identical fe80::x for multiple local v6 > networks, or something to that effect. > > How does the traceroute6's look when it "works"? If you get a "real" v6 > there you might (ab)use that as the gw ip? > >> On 06 Aug 2020, at 16:04, kug1977 wrote: >> >> Unfortuanatly, the Provider netcup doesn’t give out IPv6 gw address >> configuration other than fe80::1, so I cannot check these. But all >> virtualization there is based on KVM, too. So I guess the issue is with KVM? >> signature.asc Description: Message signed with OpenPGP using GPGMail
Re: static IPv6 setup is not working stable
No, I think in my case it is Juniper multichassis LAG (link aggregation groups) getting confused by identical fe80::x for multiple local v6 networks, or something to that effect. How does the traceroute6's look when it "works"? If you get a "real" v6 there you might (ab)use that as the gw ip? Den tors 6 aug. 2020 kl 16:04 skrev kug1977 : > Unfortuanatly, the Provider netcup doesn’t give out IPv6 gw address > configuration other than fe80::1, so I cannot check these. But all > virtualization there is based on KVM, too. So I guess the issue is with KVM? > > > > On 06 Aug 2020, at 15:51, Janne Johansson wrote: > > > > I have a setup where the virtualization (KVM) combined with the > networking does present a IPv6 def-gw as both an fe80:: here> and the more normal 2001:a:b:c:d::1/64 and where the 2001-v6 ip works > far better on virtual machines due to redundancy mac sync things on the > network side, and since the ndp list showed the fe80::1 had a > VRRP/CARP-lookalike mac, it could be the same. > > > > In my case both bsd and linux IPv6-using VMs suffer from ndp "drops" > where it can take seconds for the discovery to figure the mac address out > again after a drop. > > > > So if you can divine what the "real" v6 ip is of the default-gw, try > setting this hard in the conf or /etc/mygate and retry v6. > > > > > > Den tors 6 aug. 2020 kl 14:46 skrev Matthias Schmidt : > > Hi, > > > > * kug1977 wrote: > > > > > > Is this something wrong configured on OpenBSD server or is this > something > > > the provider has to check on the gateway side? > > > > I also have a VM at the exact same provider (netcup) and face > > the same problem. Since all of my VMs at different providers are > > identical (base install + conf via ansible) and I don't see the issue at > > other providers (IONOS, Hetzner) I suspect it has nothing to do with > > OpenBSD... > > > > -- > > May the most significant bit of your life be positive. > > -- May the most significant bit of your life be positive.
Re: static IPv6 setup is not working stable
I have a setup where the virtualization (KVM) combined with the networking does present a IPv6 def-gw as both an fe80:: and the more normal 2001:a:b:c:d::1/64 and where the 2001-v6 ip works far better on virtual machines due to redundancy mac sync things on the network side, and since the ndp list showed the fe80::1 had a VRRP/CARP-lookalike mac, it could be the same. In my case both bsd and linux IPv6-using VMs suffer from ndp "drops" where it can take seconds for the discovery to figure the mac address out again after a drop. So if you can divine what the "real" v6 ip is of the default-gw, try setting this hard in the conf or /etc/mygate and retry v6. Den tors 6 aug. 2020 kl 14:46 skrev Matthias Schmidt : > Hi, > > * kug1977 wrote: > > > > Is this something wrong configured on OpenBSD server or is this something > > the provider has to check on the gateway side? > > I also have a VM at the exact same provider (netcup) and face > the same problem. Since all of my VMs at different providers are > identical (base install + conf via ansible) and I don't see the issue at > other providers (IONOS, Hetzner) I suspect it has nothing to do with > OpenBSD... > -- May the most significant bit of your life be positive.
Re: static IPv6 setup is not working stable
Hi, * kug1977 wrote: > > Is this something wrong configured on OpenBSD server or is this something > the provider has to check on the gateway side? I also have a VM at the exact same provider (netcup) and face the same problem. Since all of my VMs at different providers are identical (base install + conf via ansible) and I don't see the issue at other providers (IONOS, Hetzner) I suspect it has nothing to do with OpenBSD... Cheers Matthias
