Quoting Chris H <bsd-li...@bsdforge.com> (from Tue, 22 May 2018 09:59:04 -0700):

On Tue, 22 May 2018 10:12:22 +0200 "Alexander Leidinger" <alexan...@leidinger.net> said

Hi,

I've updated 2 machines to r333966 and I see a change in the behavior in the network area on one of the systems.

To begin with, the "original" behavior was not OK either, the em NIC fails to "do proper network communication" (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220997). A workaround for me was so far to do an IPv4 ping to the router from time to time, and if it fails do some ifconfig down/up. If the ping doesn't work afterwards, reboot. Most of the time this worked.

Now I see a change in behavior, the scripts kicks in, all is ok for the script afterwards, but internally (inside the machine) I can't reach ipv6 jails. The system is reachable externally (only tested so far is the main host-IP).

The setup is vimage based, several jails (via iocage) on epairs connected via bridge to the NIC. One bridge for IPv6, one for IPv4. rc.conf has prefer IPv4 setting after encountering another issue.

One IPv4 address (/32) for the host where a nginx is running to proxy port 80 and 443 requests on IPv4 to the IPv6 addresses of the jails (IPv6 access is going directly to the jails).

After a reboot, the nginx on the main IPv4 address delivers data from the ipv6 addresses of the jails (rev-proxy setup). After a while this stops working. The workaround-script mentioned above doesn't change this behavior. Restarting nginx doesn't help. A reboot helps.

Has someone an idea of recent changes in a related area which may be able to cause such an issue? Any rev I could try to revert to check if it is related?
Hello, Alexander.
I'm not sure if this landed in -CURRENT. I only know it landed in 11.
But your trouble might be related to pr #224247 :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224247

Hope this helps.

Thanks, I've compiled a kernel which will print a message with the interface name when a packet will be dropped because of this. If I see something which makes it look like it could be related, I will disable it and try again.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Attachment: pgpB4pj6pnxK2.pgp
Description: Digitale PGP-Signatur

Reply via email to