VrrpV3 does not support non-VIP configuration

[sundengpan1234]

Describe the bug
VrrpV3 does not support non-VIP configuration

To Reproduce
Ipv6 unicast cannot be started without VIP Keepalived, but ipv4 unicast can be started without VIP Keepalived.

Expected behavior
A clear and concise description of what you expected to happen.

Keepalived version
keepalived -v
Keepalived v2.2.4 (08/30,2021), git commit v2.1.5-642-g33ed3e1

Copyright(C) 2001-2021 Alexandre Cassen, acassen@gmail.com

Built with kernel headers for Linux 3.10.0
Running on Linux 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017
Distro: CentOS Linux 7 (Core)

configure options: --prefix=/home/chenxu/code/third/keepalived/binary/centos PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig

Config options: LVS VRRP VRRP_AUTH VRRP_VMAC OLD_CHKSUM_COMPAT INIT=systemd

System options: VSYSLOG LIBNL3 RTA_ENCAP RTA_EXPIRES FRA_TUN_ID RTAX_CC_ALGO RTAX_QUICKACK IFA_FLAGS IPTABLES NET_LINUX_IF_H_COLLISION NET_LINUX_IF_ETHER_H_COLLISION LIBIPVS_NETLINK IFLA_LINK_NETNSID GLOB_BRACE GLOB_ALTDIRFUNC INET6_ADDR_GEN_MODE SO_MARK
Output of keepalived -v

**Distro (please complete the following information):**
 - Name: [e.g. Fedora, Ubuntu]
 - Version: [e.g. 29]
 - Architecture: [e.g. x86_64]

**Details of any containerisation or hosted service (e.g. AWS)**
If keepalived is being run in a container or on a hosted service, provide full details

**Configuration file:**
vim /etc/keepalived/keepalived.conf 
      1 vrrp_script trackTool0 {
      2 script "/bin/appex/ha/trackTool.sh arping eth1 111.192.41.1 0"
      3 interval 2
      4 rise 1
      5 fall 3
      6 timeout 2
      7 weight -20
      8 }
      9 vrrp_script trackTool1 {
     10 script "/bin/appex/ha/trackTool.sh arping eth0 192.168.63.211 10008"
     11 interval 2
     12 rise 1
     13 fall 3
     14 timeout 2
     15 weight -20
     16 }
     17 
     18 
     19 vrrp_instance LW_CPE_HB1 {
     20 state BACKUP
     21 
     22 virtual_router_id 51
     23 unicast_src_ip 2022:3:2:1::10
     24 unicast_peer {
     25 2022:3:1:1::10
     26 }
     27 priority 200
     28 advert_int 1
     29 
     30 interface eth1
     31 dont_track_primary
     32 preempt_delay 0
     33 
     34 track_interface {
     35 eth1 weight -55
     36 }
     37 track_script {
     38 trackTool0
     39 trackTool1
     40 }
     41 
     42 virtual_ipaddress {
     43 }
     44 notify /bin/appex/ha/notify
     45 }
A full copy of the configuration file, obfuscated if necessary to protect passwords and IP addresses

Notify and track scripts

If any notify or track scripts are in use, please provide copies of them

System Log entries
Apr 9 17:02:31 cpe Keepalived_vrrp[2890]: (LW_CPE_HB1) No VIP specified; at least one is required
Full keepalived system log entries from when keepalived started

**Did keepalived coredump?**

If so, can you please provide a stacktrace from the coredump, using gdb.

**Additional context**
code: keepalived/vrrp/vrrp.c
......
if (list_empty(&vrrp->vip)) {
		if (vrrp->version == VRRP_VERSION_3 || vrrp->family == AF_INET6 || vrrp->strict_mode) {
			report_config_error(CONFIG_GENERAL_ERROR, "(%s) No VIP specified; at least one is required", vrrp->iname);
			return false;  /*I don't think VRRP_VERSION_3  should return false, Because this can be consistent with VRRPV2*/
		}

		report_config_error(CONFIG_WARNING, "(%s) No VIP specified; at least one is sensible", vrrp->iname);
	}
......

[pqarmitage]

It's not related to the issue, but there is something wrong with the way you have built keepalived -
Keepalived v2.2.4 (08/30,2021), git commit v2.1.5-642-g33ed3e1
This is saying it is keepalived version 2.2.4, but it is built from git commit 33ed3e1, 642 commits after v2.1.5. 642 commits after v2.1.5 is actually 18 commits after v2.2.4, and so it should say git commit v2.2.4-18-g33ed3e1. However we don't seem to have a commit 33ed3e1, so this is all very confusing.

Now back to this issue.

The current version of the code you quoted above is:

        if (list_empty(&vrrp->vip)) {
                if (vrrp->version == VRRP_VERSION_3 || vrrp->strict_mode) {
                        report_config_error(CONFIG_GENERAL_ERROR, "(%s) No VIP specified; at least one is required"
                                                                , vrrp->iname);
                        return false;
                }
                report_config_error(CONFIG_GENERAL_ERROR, "(%s) No VIP specified; at least one is sensible", vrrp->iname);
        }

The check || vrrp->family == AF_INET6 was redundant, since IPv6 is only supported with VRRPv3.

From RFC5798 (the VRRPv3 RFC):

5.2.5 Count IPvX Addr

   This is the number of either IPv4 addresses or IPv6 addresses
   contained in this VRRP advertisement.  The minimum value is 1.

and this is why a VIP has to be specified.

Is there a problem if you specify some (unused) link local address as a VIP (with IPv6 the first VIP has to be link local anyway)?

If you still feel that it should be possible to specify no VIPs, could you please explain why you need to do so, and give a full description of the use case.