Log message "vrrp packet too short" every second

General questions
1

Hi,
I have configured VRRP on the inside of to routers, the failover function of the VRRP is working as expected. But the log file on both routers gets filled up by this:

vyos@ir2:~$ sh log 10
Aug 15 13:05:26 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:27 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:28 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:29 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:30 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:31 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:32 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:33 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:34 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:05:35 Keepalived_vrrp[3391]: (10) vrrp packet too short, length 56 and expect 64

vyos@ir3:~$ sh log 10
Aug 15 13:04:16 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:17 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:18 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:19 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:20 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:21 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:23 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:24 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:25 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64
Aug 15 13:04:26 Keepalived_vrrp[40309]: (10) vrrp packet too short, length 56 and expect 64

Obviously something is wrong with my config, but I can’t find out what. With or without version 3 makes no difference. Here is my VRRP-related config:

vyos@ir2:~$ sh conf | strip-private
high-availability {
    vrrp {
        global-parameters {
            version 3
        }
        group 10 {
            address xxx.xxx.137.1/26 {
            }
            interface eth1.2
            priority 200
            vrid 10
        }
        group 20 {
            address xxxx:xxxx::1/64 {
            }
            interface eth1.2
            priority 200
            vrid 20
        }
    }
}
interfaces {
    ...
    ethernet eth1 {
        description "Data sw3 Eth1/23"
        hw-id xx:xx:xx:xx:xx:d1
        vif 2 {
            address xxx.xxx.137.22/26
            address xxxx:xxxx::12/64
        }

vyos@ir3:~$ sh conf | strip-private
high-availability {
    vrrp {
        global-parameters {
            version 3
        }
        group 10 {
            address xxx.xxx.137.1/26 {
            }
            interface eth0.2
            priority 110
            vrid 10
        }
        group 20 {
            address xxxx:xxxx::1/64 {
            }
            interface eth0.2
            priority 110
            vrid 20
        }
    }
}
interfaces {
    ...
    ethernet eth0 {
        hw-id xx:xx:xx:xx:xx:f7
        offload {
            gro
            gso
            sg
            tso
        }
        vif 2 {
            address xxxx:xxxx::13/64
            address xxx.xxx.137.23/26
        }

ir2: VyOS 1.5-rolling-202405140019
ir3: VyOS 1.5-rolling-202406170021

The routers are connected with a Cisco Nexus switch.

What does the log message really mean?

2

Try removing all offloading options and see if any of them had an effect on this?

The common recommendation regarding that error is that you have mismatching VRRP version like one is using v2 and the other is using v3 (or no version set so both are used) and that could confuse VRRP resulting in this error.

But in your case you seem to be using version 3 for both routers so it shouldnt be that.

How are the routers connected to each other, through that cisco nexus switch?

If so how is the config for that cisco nexus switch regarding tagged or untagged vlan etc?

Im thinking if you for example have tagged vlan 2 on one cisco interface but untagged on the other then the router connected to that interface will have vlan2 packets arrive without a tag (which is 4 bytes large).

3

Thank you for your reply.

delete interfaces ethernet eth0 offload

on ir3, still same log messages.

I also tried changing vrrp version to v2, also deleting version-command on both routers, still same log messages, so I keep it at v3.

They are connected to the same switch, vlan is tagged on both ports (other vlans replaced by x and y):

vlan 2
  name asdf
!
interface Ethernet1/2
  description ir3 LAN (srv9, eth0 in vyos)
  switchport mode trunk
  switchport trunk allowed vlan 2,x,y
  no shutdown
!
...
interface Ethernet1/23
  description ir2 LAN (eth1 in vyos)
  switchport mode trunk
  switchport trunk allowed vlan 2,x
  no shutdown
!

I also tried disabling group 20 (IPv6) on both routers, still same log messages.

4

Do you perhaps have other VRRP devices connected to that cisco switch which is “leaking” to your VyOS boxes?

Im thinking since you got vlan 2,x,y on ir3 but only 2,x only ir2 interfaces on that cisco?

If still nothing found next is to do some tcpump on these interfaces and if possible paste that in this thread.

You can do tcpdump directly in VyOS (I prefer to do that in bash mode).

1 Like
5

There we have something. xxx.xxx.137.2 and xxx.xxx.137.3 are two pfSense firewalls with CARP configured, on the same vlan as the VyOS VRRP (vlan 2).

Is it possible to use the excluded-address to ignore VRRP packets from those two addresses?

vyos@ir3:~$ monitor traffic interface eth0.2 | strip-private | grep VRRP
18:56:42.625137 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 9, prio 0, authtype none, intvl 1s, length 36
18:56:42.766732 IP xxx.xxx.137.22 > xxx.xxx.0.18: VRRPv3, Advertisement, vrid 10, prio 200, intvl 100cs, length 12
18:56:42.821442 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 7, prio 0, authtype none, intvl 1s, length 36
18:56:42.821442 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 16, prio 0, authtype none, intvl 1s, length 36
18:56:42.821485 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 6, prio 0, authtype none, intvl 1s, length 36
18:56:42.821485 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 15, prio 0, authtype none, intvl 1s, length 36
18:56:42.821485 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 10, prio 0, authtype none, intvl 1s, length 36
18:56:42.821485 IP xxx.xxx.137.2 > xxx.xxx.0.18: VRRPv2, Advertisement, vrid 5, prio 0, authtype none, intvl 1s, length 36
6

I would probably resolve this by using version 3 and enable unicast instead of multicast mode and by that define the unicast IPv4 address of your peer.

Its not uncommon to have 2 (or sometimes more) VRRP groups on the same layer2 network.

For example if you got like R1/R2 ↔ SW1/SW2 ↔ R3/R4 where R1/R2 is one group and R3/R4 is another group.

Verify that they use unique VRRP group ID’s (one for the R1/R2 combo and another for the R3/R45 combo) and configure a unique VRRP authentication (password) for each group aswell and you should be safe.

You could go the extra mile of adding a ACL to only allow VRRP from the designated partner but that is usually not needed when you do the above.

Edit: I can see in your post that you got two sources for VRID=10 where one is VRRPv3 and the other is VRRPv2 so there is your explanation of why the VRRP daemon of VyOS process both and discard one due to wrong size (due to wrong version).

So fix is to cleanup which VRRP group id’s you use and put authentication on each VRRP group id.

2 Likes
7

Wow great, thank you. Changing the vrid from 10 to something else on the VyOS routers stopped the log message. I would never have thought about that CARP on other devices could mess with the VRRP in VyOS. I also added authentication password to the VyOS boxes, the pfSense already had passwords on the CARP configuration.

8

Regarding passwords make sure that each group use its own.

The passwords are not foolproof as in dont expect them to be any security enhancement feature - see it more as a way (such as VRID) to make it less likely to screw things up.

As in your case if the VyOS VRRP process wouldnt have triggered that the length is incorrect then it would without password joined the group of your opnsense boxes and that would have been fun when one of them failover (since you by accident had the same VRID on both groups).

9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

10

@Apachez @Pike wow interesting!

Thanks for sharing this VRRP/CARP weirdness

1 Like