MitchDrage commented on code in PR #14240:
URL: https://github.com/apache/cloudstack/pull/14240#discussion_r4161689208
##########
plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java:
##########
@@ -458,6 +458,14 @@ public boolean isExistingBridge(String bridgeName) {
@Override
public void deleteBr(NicTO nic) {
+ if (Networks.BroadcastDomainType.getSchemeValue(nic.getBroadcastUri())
== Networks.BroadcastDomainType.Vxlan) {
+ // VXLAN bridges are named after the VNI alone, so no physical
interface lookup is needed
+ String vxlanId =
Networks.BroadcastDomainType.getValue(nic.getBroadcastUri());
+ if (vxlanId != null) {
+ deleteVnetBr(generateVxnetBrName(null, vxlanId), true);
Review Comment:
Good catch. I had a bit of a look and a test. You're right - the route del
runs against a non-existent device.
It looks like the multicast route has always been left behind on VXLAN
bridge teardown.
Since the pif can't be derived from the bridge name for VXLAN, and most of
the unplug paths (VM stop included) don't carry the NIC's traffic label, I
think the best option is to read the interface from the `vxlan<vni>` device
before calling the script.
The alternative would be to derive it in modifyvxlan.sh, but that is often
customised to suit individual deployments so I think that would be problematic.
Thoughts?
--
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]
