Recent changes in routing or IPv6 related parts?

[Alexander Leidinger]

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?

Bye,
Alexander.

[Chris H]

Post by Alexander Leidinger
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.

--Chris

Post by Alexander Leidinger
Bye,
Alexander.
--

[Alexander Leidinger]

On Tue, 22 May 2018 10:12:22 +0200 "Alexander Leidinger"

Post by Alexander Leidinger
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.
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.

[Alexander Leidinger]

Post by Alexander Leidinger

Post by Chris H
Hello, Alexander.
I'm not sure if this landed in -CURRENT. I only know it landed in 11.
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.

It doesn't look like this is causing the issues I see. I have added
some printfs in the silent-discard parts and nothing in printed when
the workaround-script detects the issue.

Bye,
Alexander.