IPv6 SLAAC broken on Redundant VPC VR due missing Prefix Information Option in radvd.conf

[jeanvetorello]

problem

Description

IPv6 SLAAC does not work for guest VMs connected to a Redundant VPC network because the Virtual Router (VR) generates an incomplete radvd.conf.

The VR sends Router Advertisements (RA), but does not include the Prefix Information Option (PIO). As a result, guest VMs never generate a global IPv6 address through SLAAC.

This issue only happens on Redundant VR deployments.

Normal (non-redundant) VRs work correctly.

Expected behavior

The VR should generate a radvd.conf containing:

prefix /64
{
AdvOnLink on;
AdvAutonomous on;
};

Guest VMs should receive:

Router Advertisement
Prefix Information Option (PIO)
Global IPv6 address via SLAAC

Actual behavior

The generated /etc/radvd.conf on the Redundant VR does NOT contain the prefix block.

Example broken config:

interface eth2
{
AdvSendAdvert on;
MinRtrAdvInterval 5;
MaxRtrAdvInterval 15;

RDNSS 2001:4860:4860::8888
{
    AdvRDNSSLifetime 30;
};

RDNSS 2001:4860:4860::8844
{
    AdvRDNSSLifetime 30;
};

};

As a result:

Router Advertisements are sent
DNS information is sent
BUT Prefix Information Option is missing
SLAAC fails
Guest VMs only get fe80:: link-local addresses

Working comparison (non-redundant VR)

A non-redundant VR correctly generates:

interface eth2
{
AdvSendAdvert on;

prefix 2601:c201:1a00:c358::/64
{
    AdvOnLink on;
    AdvAutonomous on;
};

RDNSS 2001:4860:4860::8888
{
    AdvRDNSSLifetime 30;
};

};

In this case:

Prefix Information Option is present
SLAAC works correctly
Guest VMs receive global IPv6 addresses

Additional observations

On the broken redundant VR, cloud.log shows a different orchestration flow:

systemctl stop radvd
systemctl disable radvd
systemctl enable radvd
systemctl start radvd

While the working non-redundant VR only performs:

systemctl restart radvd

This may indicate a bug specific to:

Redundant VR orchestration
IPv6 VPC synchronization
radvd.conf rendering logic

Workaround

Manually adding the following block to /etc/radvd.conf immediately fixes SLAAC:

prefix 2601:c201:1a00:c358::/64
{
AdvOnLink on;
AdvAutonomous on;
};

After restarting radvd:

systemctl restart radvd

Guest VMs immediately receive global IPv6 addresses.

versions

Environment
Apache CloudStack 4.21.0.0
VPC network
Redundant VR enabled
Debian SystemVM template
IPv6 enabled guest network
SLAAC configuration
No DHCPv6

The steps to reproduce the bug

Reproduction steps
Deploy a VPC network with IPv6 enabled
Enable Redundant VR
Deploy a guest VM
Verify /etc/radvd.conf inside the VR
Observe that no prefix block is generated

Capture RA packets:

tcpdump -vv -ni icmp6
Observe that Router Advertisements do not contain Prefix Information Option
Guest VM never receives global IPv6 through SLAAC
...

What to do about it?

Possible root cause

The VR appears to correctly receive:

IPv6 address
IPv6 CIDR
IPv6 ACL rules

But the prefix section is not rendered into radvd.conf.

This may be related to:

Redundant VR logic
IPv6 metadata rendering
VPC synchronization flow
Incorrect prefix selection during HA orchestration

[weizhouapache]

@jeanvetorello
is the setting the same in both Primary VR and Backup VR ?

has you tested isolated network with redundant VRs ? do they have the same issue ?

[jeanvetorello]

yes on both VR.

I tested removing the condition on systemvm/debian/opt/cloud/bin/cs/CsVpcGuestNetwork.py

if entry['router_guest_ip6'] == entry['router_guest_ip6_gateway']:

After rebuilding/regenerating the VR configuration, the generated radvd.conf correctly included:

prefix 2601:c201:1a00:9c45::1/64
{
AdvOnLink on;
AdvAutonomous on;
};

[weizhouapache]

yes on both VR.

I tested removing the condition on systemvm/debian/opt/cloud/bin/cs/CsVpcGuestNetwork.py

if entry['router_guest_ip6'] == entry['router_guest_ip6_gateway']:

After rebuilding/regenerating the VR configuration, the generated radvd.conf correctly included:

prefix 2601:c201:1a00:9c45::1/64
{
AdvOnLink on;
AdvAutonomous on;
};

Great

Will you create a pull request against 4.20 or 4.22 branch ?