On 04.03.2022 00:44, Rob Marshall wrote:
Hi Andrei,
So you think the issue may be that the firewall is not up and running when
the interfaces are brought up? What would be a good way to determine that?
You could start with answering my question about network management you
are using.
Logs for the boot when interfaces were assigned to the wrong zone would
be interesting. If your distribution is using systemd and you have
configured persistent journal, you can use "journalctl -b NN" to
indicate logs from the specific boot. Or simply "journalctl -b" for the
current boot when this problem happens.
Services definition for systemd and network startup service would be
helpful too.
systemctl cat firewalld.service
systemctl cat <your-network-startup>.service
I did notice in the logs that the two interfaces that were missing
have a
bunch of entries about setting the zone of the interface to "public". The
interface that wasn't missing is just set to drop.I'm not sure what that
means.
Rob
On Thu, Mar 3, 2022 at 9:12 AM Andrei Borzenkov <arvidjaar(a)gmail.com> wrote:
> On Thu, Mar 3, 2022 at 5:01 PM Rob Marshall <rob.marshall17(a)gmail.com>
> wrote:
>>
>> Hi,
>>
>> I have an issue where, after a system reboot (Oracle Linux 7),
> communications to the node are not working correctly. If i stop and start
> (often a restart doesn't work) the firewalld service the network will work
> correctly. While things were broken I did a: 'firewall-cmd --list-all' and
> noticed that two of the interfaces were missing. Where can I look to
> determine what may be going wrong when firewalld starts after a reboot?
>>
>
> Sounds like a race between firewalld and your network management
> program. If firewalld is not fully ready when interfaces are
> configured, they are not added to firewalld. Just a guess. Check
> startup order and dependencies.
>
> What network management are you using?
>