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
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
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
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
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?
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
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
7 matches
Mail list logo
