souyofnewerth opened a new issue, #14463:
URL: https://github.com/apache/cloudstack/issues/14463
### problem
On 4.23.0.0 (KVM, BridgeVifDriver), when an isolated network or VPC virtual
router gets a public IP
from a VLAN different from its source NAT VLAN, the new public NIC is
defined/hot-plugged with
<link state='down'/>. Inside the router the interface shows "ethX DOWN <ip>"
and ARP to the gateway
of that range is INCOMPLETE, so the IP does not work (static NAT VM cannot
use it; when it was the
old source NAT IP after a source NAT change, all port forwards on it stopped
working and clients
got "Network is unreachable").
Observed in three situations on the same isolated network:
- after "Make source NAT" moved the source NAT to the second-VLAN IP (router
recreated): the NIC of
the old source NAT IP (untagged, cloudbr0) was down
- Enable Static NAT for a second-VLAN IP: the hot-plugged NIC (brbond0-2119)
was down
- Disable + Enable Static NAT again: the NIC was re-plugged and again down
listRouters only shows the source-NAT public NIC for that router; the extra
public NIC is not listed.
BridgeVifDriver sets intf.setLinkStateUp(nic.isEnabled()) (new in 4.23; not
present in 4.22.1.1),
so it looks like these extra public NICs reach the agent with enabled=false.
Workaround: on the host, virsh domif-setlink <router> <vnet> up (then arping
-U from the router).
### versions
CloudStack 4.23.0.0, KVM (Ubuntu 24.04 and 26.04 hosts, Linux bridge, LACP
bond), advanced zone,
isolated network (DefaultIsolatedNetworkOfferingWithSourceNatService).
4.22.1.1 code does not set the
link state from nic.isEnabled().
### The steps to reproduce the bug
1. Advanced zone with two public IP ranges: untagged 192.0.2.40-59 and
vlan://2119 203.0.113.114/26.
2. Isolated network with source NAT 192.0.2.43 and a running VM.
3. Acquire 203.0.113.114 for the network and Enable Static NAT to the VM.
4. On the router's host: virsh domiflist r-N-VM; virsh domif-getlink r-N-VM
<vnet on brbond0-2119>
-> "down". Inside the router: ip -br addr -> ethX DOWN 203.0.113.114/26.
### What to do about it?
Public NICs of virtual routers (and other system VMs) should be plugged with
link up, or the
management server should send enabled=true for them. Possibly the
NicProfile/NicTO for additional
public NICs created in IpAssoc / router (re)deploy does not carry the nic's
enabled flag.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
