[Users] Solved: network manager is the culprit (was: OVZ 7 network issues...)

[jjs - mainphrame]

Curious side note -

Replacing firewalld with ufw allows traffic to be forwarded by the
container. I gather that firewalld was designed for a workstation or a
laptop, not a multi-homed server. That, and the version of firewalld on
RHEL 7 is rather old.

In any case, all of the "direct" firewalld rules that should have done the
trick haven't done so.

I'm curious to see if the newer version of firewalld that comes with RHEL 9
will be any more cooperative on this front.

Jake

On Mon, Dec 26, 2022 at 12:36 PM jjs - mainphrame <jjs at mainphrame.com>
wrote:

> Greetings -
>
> It's 2022, I have a new set of openvz servers, and once again, disabling
> NetworkManager was the key to solving a nagging, intermittent network
> problem.
>
> I recently added interfaces to the openvz servers to connect them to other
> networks, and while everything seemed to work initially, the bridges kept
> going down mysteriously.
>
> I tried removing and rebuilding the bridges, the networks, the virtual
> interfaces, seeing the bridge come up, and then syslog showing
> NetworkManager was taking the bridge down for vague and inscrutable
> reasons, I disabled NetworkManager, and voila. No more bridge problems.
>
> It seems to me that NetworkManager doesn't add any value for a server,
> only additional failure modes. Perhaps it's a solution in search of a
> problem, as they say?
>
> Jake
>
> On Thu, Dec 31, 2015 at 1:15 PM jjs - mainphrame <jjs at mainphrame.com>
> wrote:
>
>> Greetings -
>>
>> It's been 2 weeks of flawless network connectivity to all containers
>> after completely removing network manager, even after attempts to induce
>> the sort of failure that were seen when network manager was running,.
>>
>> At this point, it's clear that network manager was the problem, and the
>> old saw is confirmed: "simple is safe".
>>
>> Happy new year to all who were following this question.
>>
>> Joe
>>
>>
>>
>>
>>
>> On Mon, Dec 14, 2015 at 9:51 AM, Konstantin Bukharov <bkb at virtuozzo.com>
>> wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> From symptoms, it looks like ARP cache expiration issue.
>>>
>>> Please check ARP cache settings on your network equipment.
>>>
>>>
>>>
>>> We haven’t seen such massive reports.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> *From:* users-bounces at openvz.org [mailto:users-bounces at openvz.org] *On
>>> Behalf Of *jjs - mainphrame
>>> *Sent:* Saturday, December 12, 2015 6:18
>>> *To:* users at openvz.org
>>> *Subject:* [Users] OVZ 7 network issues (vz host stops answering arp
>>> requests)
>>>
>>>
>>>
>>> Greetings,
>>>
>>>
>>>
>>> I've been running some servers in OVZ 7 containers for some months now,
>>> and I'm happy with reliability and performance, with the exception of an
>>> occasional loss of ct network connectivity.
>>>
>>> From time to time, I'll get a xymon alert that all containers are
>>> unreachable. The cts are all using host routing. What I see, when I examine
>>> any affected ct, is this:
>>>
>>>
>>>
>>>
>>>
>>> The container no longer responds to ping, even from the local lan.
>>>
>>> The vz host and container can connect to each other
>>>
>>> The container can not reach anything beyond the host.
>>>
>>>
>>>
>>> When I enter the container and ping another box, the pings are received,
>>> but the box can not return the pings as the arp request goes unanswered.
>>> For some reason the vz host forgets about the cts, and it's always all of
>>> them. This is 2 Centos 7 boxes, running OVZ 7 beta and OVZ 7 factory
>>>
>>>
>>>
>>> Doing a vzctl restart on each affected ct restores connectivity. Has
>>> anyone else seen this issue?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20221231/fbb5b627/attachment.html>