Hide Forgot
Description of problem: vrrp_instance ingress include both IPv4 and IPv6 as unicast peers in case of dual stack deployment: /etc/keepalived/keepalived.conf ... vrrp_instance ocp-edge-cluster-0_INGRESS { state BACKUP interface br-ex virtual_router_id 110 priority 20 advert_int 1 unicast_src_ip 192.168.123.127 unicast_peer { 192.168.123.113 fd2e:6f44:5dd8::7e fd2e:6f44:5dd8::6d 192.168.123.67 fd2e:6f44:5dd8::87 192.168.123.83 fd2e:6f44:5dd8::3e 192.168.123.79 fd2e:6f44:5dd8::5f 192.168.123.100 fd2e:6f44:5dd8::44 } ... Version-Release number of selected component (if applicable): oc version Client Version: 4.7.0-0.nightly-2021-08-29-003324 Server Version: 4.7.0-0.nightly-2021-08-29-003324 Kubernetes Version: v1.20.0+9689d22 How reproducible: Deploy dual stack cluster enter to one of the node view /etc/keepalived/keepalived.conf Steps to Reproduce: Deploy dual stack cluster enter to one of the node view /etc/keepalived/keepalived.conf Actual results: ... vrrp_instance ocp-edge-cluster-0_INGRESS { state BACKUP interface br-ex virtual_router_id 110 priority 20 advert_int 1 unicast_src_ip 192.168.123.127 unicast_peer { 192.168.123.113 fd2e:6f44:5dd8::7e fd2e:6f44:5dd8::6d 192.168.123.67 fd2e:6f44:5dd8::87 192.168.123.83 fd2e:6f44:5dd8::3e 192.168.123.79 fd2e:6f44:5dd8::5f 192.168.123.100 fd2e:6f44:5dd8::44 } ... Expected results: ... vrrp_instance ocp-edge-cluster-0_INGRESS { state BACKUP interface br-ex virtual_router_id 110 priority 20 advert_int 1 unicast_src_ip 192.168.123.127 unicast_peer { 192.168.123.113 192.168.123.67 192.168.123.83 192.168.123.79 192.168.123.100 } ... Additional info:
What breaks as a result of this? Is the VIP not working correctly in some way? I have a vague memory of keepalived complaining when the peer list includes addresses in a different family from the VIP, but if so that should be included in the report. As it stands there's nothing to indicate that this behavior is problematic.
Hi @bnemec It's seem like this cause to this bug https://bugzilla.redhat.com/show_bug.cgi?id=1988102 to appear. Why we should create 2 connection to peer? one IPv4 and other IPv6 that transfer the same data?
Why do you think this configuration is related to that bug? https://bugzilla.redhat.com/show_bug.cgi?id=1988102 is not specific to dual stack, so I don't see any way the behavior described in this bug would have anything to do with it. In my testing, this does not cause any functional issues in a dual stack cluster. I've run a deployment and the only problem I can see is some warning messages in the keepalived logs, but the VIPs work as expected anyway and the cluster deploys and is fully functional. I agree this would be nice to fix, but as far as I can tell it's a purely cosmetic issue.
@bnemec You're right, https://bugzilla.redhat.com/show_bug.cgi?id=2003655 is the reason for the original bug
Why did you leave a needinfo on me?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056