Skip to content

Network metric weight regression with additional networks #2867

@smbambling

Description

@smbambling

Description

Seeing some different behavior after upgrading to Lima 1.0. When provisioning a machine with socket_vmnet ( installed from source and owned by root ) the VM has two default gateways ( expected ). However the shared interface lima0 now has a lower metric then the bridged interface which prevents the VM from accesses external resources

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.105.1   0.0.0.0         UG    100    0        0 lima0
0.0.0.0         192.168.5.2     0.0.0.0         UG    200    0        0 eth0
192.168.5.0     0.0.0.0         255.255.255.0   U     200    0        0 eth0
192.168.5.2     0.0.0.0         255.255.255.255 UH    200    0        0 eth0
192.168.105.0   0.0.0.0         255.255.255.0   U     100    0        0 lima0
192.168.105.1   0.0.0.0         255.255.255.255 UH    100    0        0 lima0

On the VM created from Lima 1.0 I was able to remove the route for eth0 and recreate it with a lower metric to allow traffic flow externally.
Creating a VM with Lima 0.23.2 also with socket_vmnet ( installed from source and owned by root ), has both default interfaces with the same metric which allows external traffic

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.5.2     0.0.0.0         UG    100    0        0 eth0
0.0.0.0         192.168.105.1   0.0.0.0         UG    100    0        0 lima0
10.42.0.0       0.0.0.0         255.255.255.0   U     0      0        0 cni0
192.168.5.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0
192.168.5.2     0.0.0.0         255.255.255.255 UH    100    0        0 eth0
192.168.105.0   0.0.0.0         255.255.255.0   U     100    0        0 lima0
192.168.105.1   0.0.0.0         255.255.255.255 UH    100    0        0 lima0

After chatting with Jan Dubois via Slack it was noted this change comes from #2632

This prevents a scenario where VM need to pull container images from a registry that resides outside the shared network, but access to VM within this shared network are still required.

Eg: K3s using metalLB for BGP to connect to BIRD VMs on the shared network still need to pull container images from a source outside the shared network.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions