It's worth adding the no-default-route to the dhcp-options and adding a line like

I found a new and exciting way to break it though. And maybe what we were talking about in Slack will be able to correct some of this.

Looks good to me now

Definitely seems to me a op-mode command to trigger a container rebuild would be appropriate.

For example,

To wit, I already had this working with multiple networks (I had named them podman0/1/2/3/4/etc), but I wanted to simplify the initial PR here.

In T3766#100640, @Viacheslav wrote:

Network re-creates every time after reboot and gets configuration from "container network" section.
https://github.com/vyos/vyatta-cfg/blob/242f5685159f615ff79312041d3dde2063e5579a/scripts/init/vyos-router#L273-L277
So there is podman decide how to name this network.

In a different case, it tried to create a network which already been created.

PR975

Fixed by PR966

Duplicate of T3499

It appears things are in such a state where that network doesn't actually exist:

To add to this, it looks like I'm not going to be able to get rid of that without rebooting:

Sorry. Yep. Can confirm, problem fixed.

Just to add to the knowledge surrounding this issue...

@c-po It was thought that possibly the nftables migration was doing something funny here because of the potential overlaps.

The check on DH length is backwards.

@dmbaturin It should. It was vyos-hostsd and some of the rewrite to python that caused the issue initially.

This PR should fix this for now.

Duplicate of https://phabricator.vyos.net/T2465

Honestly it's not anything I've ever used. But from asking around some people still use it (not specifically in VyOS, just in general)

This PR should correct it. Fortunately it appears that that this node was the only place this existed.

That’s how it is now and it doesn’t work.

This is a problem again.

PR should correct this

I think I know what's happening here.

This PR should correct the issue.

It should. This should really be a non-breaking change as it's a fallback for something else that already exists in /etc/hosts.

This also has a measurable impact on CPU. You can tell exactly when I applied the nsswitch.conf fix.

To add to this, this link pointed me at the correct solution:

Go for it. Just to confirm, this did work on the rolling from the 8th of this month, so it was something that got gobbled up in the rewrite.

Then I believe the best course of action is to restore that error condition, but have it reference the “alias” config then.

To add, maybe it's just the content of the error message that's misleading here if there other ways to do it. Or maybe the problem is that there are multiple ways to accomplish this

I guess there's two ways to approach it. This is the correct way: