Traffic to VIP not reaching instance

[automagics]

We’re running into an issue on CloudStack 4.20.1 with a setup where we’re using keepalived and a VIP between two KVM instances in a shared guest network.

Both instances have their own NIC with a static IP, and there’s a VIP in the same subnet that’s managed by keepalived. The VIP floats between the two VMs, but it’s not assigned statically to either NIC in CloudStack. It only exists inside the VMs when keepalived assigns it.

When the VIP is active on any of the instances, we can’t connect to it. The security groups that are assigned to the instances allow all traffic (just for testing purposes).

We ran tcpdump on the CloudStack host, and traffic to the VIP does arrive at the host. But inside the VM that currently holds the VIP, there’s nothing. The traffic never gets there.

So our conclusion is: since the VIP isn’t defined in CloudStack itself, it looks like traffic to that IP isn’t forwarded to the instance, even though the IP is active on the interface from inside the VM.

Some extra context:

• Network type: Shared
• VLAN-backed
• Guest traffic type
• CIDR/netmask/gateway are all correctly configured
• The VIP is in the same /24 as the two static IPs
• Hypervisor: KVM

We’re wondering:

• Is this expected behavior?
• Is there a way to make CloudStack forward traffic for IPs that aren’t explicitly assigned to a NIC?
• Or is there another approach recommended for using keepalived/VRRP-style failover with floating IPs?

Thanks in advance!

[DaanHoogland]

@automagics Is the VIP on VMs in an isolated network or in an L2 network (or some other kind)?

[automagics]

The VIP is in a shared guest network (not isolated or pure L2). The guest network uses the DefaultSharedNetworkOfferingWithSGService network offering, with services like DHCP, DNS, and UserData provided by a Virtual Router, and security groups enabled.

Each VM has a static IP assigned in CloudStack. The VIP is not known to CloudStack and is managed by Keepalived inside the VMs.

[alexandremattioli]

@automagics most likely the SG is blocking the traffic. Try it in a shared network (or L2) without SG.

[automagics]

Thank you for the suggestion. I created a new network offering and guest network, and left out the SG. This works like a charm!