Unable to find IPv6 address for zone ID: %d, physical network ID: %d, VLAN: %s

[klausheck]

ISSUE TYPE

• Bug Report

COMPONENT NAME

Creation of virtual router with dual-stack IPv4/IPv6 fails.

CLOUDSTACK VERSION

4.17

CONFIGURATION

OS / ENVIRONMENT

Ubuntu 20.04

SUMMARY

When instantiating a Dual-Stack Network, the following error occurs:

Unable to start a VM [3f772370-2cf1-4ce0-96ff-a51f36d376b8] due to [Unable to create a deployment for VM instance {id: "108", name: "i-2-108-VM", uuid: "3f772370-2cf1-4ce0-96ff-a51f36d376b8", type="User"}].

After diving into the issue, it turns out that the actual reason is a failure in creating the virtual router, which can be seen in the management log entry:

ROR [c.c.n.Ipv6ServiceImpl] (Work-Job-Executor-68:ctx-f9e73850 job-1385/job-1386 ctx-12d32990) (logid:c126a9d8) Unable to find IPv6 address for zone ID: 1, physical network ID: 202, VLAN: vlan://99

In table "vlan", however, there is no entry with physical network ID: 202. All entries there have physical_network_id 203.

The table "networks", on the other hand, has an entry for physical_network_id 202. But that entry is the "Guest network" definition.

It seems to me as if the search parameter 202 is simply not correct. What the system wants to find is the /64 IPv6 "IP range" that is defined for the Zone's physical network transporting "Public" traffic type. This is supposed to be used by the virtual router as its IPv6 address within the "Public" network.

In order to test this assumption, I added an entry to table "vlan". It is exactly the same as the one defined for traffic type "Public", only with physical_network_id 202 instead of 203.

With this "test entry", the virtual router is created correctly, as is the vm instance. This pretty much indicates that the assumption was correct.

The bug is: when instantiating a dual-stack network, the Cloudstack Manager searches for the wrong physical_network_id in order to create the virtual router.

With the fake entry, I found a working workaround, but I would highly appreciate a fix.

STEPS TO REPRODUCE

• the configuration steps do exactly follow the "IPv6 Support in Cloudstack" chapter in the "Plugins Guide" for version 4.17.0.0 including "Adding a Public IPv6 Range" to the Zone's Public traffic type and "Adding Guest IPv6 Prefix"
• all prerequisites for IPv6 are fulfilled
• create a network offering DefaultDualStackIsolatedNetworkOfferingWithSourceNatService which is analogous to DefaultIsolatedNetworkOfferingWithSourceNatService plus option IPv4 + IPv6 (Dual Stack)
• create a guest network using the new network offering DefaultDualStackIsolatedNetworkOfferingWithSourceNatService
• create a compute instance in the new Dual-Stack network

EXPECTED RESULTS

As explained above, the virtual router for the dual-stack network should have been created.

ACTUAL RESULTS

The creation of the virtual router simply failed.

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[weizhouapache]

@klausheck Can you check if the IPv6 prefix and public IPv6 cidr (you should have added) on the correct physical network ?

[shwstppr]

@klausheck thanks for reporting the issue. If I understand correctly, you have public and guest traffic handled by different physical networks and the network with id 202 is for the guest traffic? I'll investigate this.

[klausheck]

Traffic type Guest is placed on physical network named "cloudbr2". There, I added the IPv6 prefix XXXX:XXXX:1111:1120::/60. The guest network gets the IPv6 CIDR XXXX:XXXX:1111:1127::/64 and has the physical_network_id 202.

Traffic type Public is placed on physical network named "cloudbr3". There, I added the IP Range: Gateway: XXXX:XXXX:1111:1112::1 CIDR: XXXX:XXXX:1111:1112::/64 VLAN/VNI: vlan://99 (automatically added) physical_network_id in table vlan is 203.

[shwstppr]

@klausheck and what is your public IPv4 range look like?

[klausheck]

Traffic type Guest: vlan://2114 | 10.99.103.0/24

Traffic type Public: Gateway: XXX.XXX.238.225 CIDR: XXX.XXX.238.224/27 VLAN/VNI: vlan://99 Start IP: XXX.XXX.238.237 End IP: XXX.XXX.238.250

Without IPv6 everything works perfectly, so I suppose that everything is correct with the IPv4 configs. I guess there is just a small bug, such that the IPv6 network info is searched for in the wrong physical network. The bug probably has no effect as long as public and guest traffic are handled in the same physical network.

[rohityadavcloud]

Fixed in https://github.com/apache/cloudstack/pull/6588 @klausheck pl test latest snapshot (for ex. daily builds http://download.cloudstack.org/testing/nightly/) and re-open if you've any further issues on this bug, thanks for reporting.