Hi Naveen,
The trace file appears to show two VRRP advertisements which were received.
There does not seem to be any indication that those packets ever reached
the vrrp4-input node. For both packets the trace shows this at the end:
00:21:49:755122: error-drop
rx:loop0
00:21:49:755122: drop
ip4-local: ip4 source lookup miss
The error counter for ip4 source lookup miss also appears to be increasing
in the output of 'show err'.
Does the backup have an IP address in the same subnet with 10.4.4.3
configured on loop0? Your original diagram showed addresses in that subnet
configured on the loop0 interface on both VRs, but you mentioned that the
configuration has changed.
It is pretty hard for me to guess what's happening here without having the
full configuration available. Can you give me a full set of commands I
could run in vppctl to exactly replicate the configuration of both VRs? I
don't just mean the settings related to VRRP, but all interface
configuration, bridge domain, etc
Thanks,
-Matt
On Fri, Aug 14, 2020 at 8:10 PM Naveen Joy (najoy) wrote:
> Hi Matthew,
>
>
>
> Thanks! I have attached packet captures to this email. I have captured a
> few more packets as the uplink was quite chatty.
>
> The VRRP speakers are on Vlan 110.
>
> The second file has the untruncated show err output run a few times.
>
> Also, apologies for not clarifying the IP address change. During
> troubleshooting, I had switched the backup and master VRs – still seeing
> the same behavior.
>
> The IP address of the master i.e. 10.4.4.3 shown below is correct
> (Attached: updated diagram).
>
>
>
> Regards,
>
> Naveen
>
>
>
> *From: * on behalf of "Matthew Smith via lists.fd.io"
>
> *Reply-To: *"mgsm...@netgate.com"
> *Date: *Friday, August 14, 2020 at 2:47 PM
> *To: *"Naveen Joy (najoy)"
> *Cc: *"vpp-dev@lists.fd.io"
> *Subject: *Re: [vpp-dev] VRRP issue
>
>
>
>
>
> Hi Naveen,
>
>
>
> See replies inline below...
>
>
>
> On Fri, Aug 14, 2020 at 12:53 PM Naveen Joy (najoy)
> wrote:
>
> Thanks, Matthew. I am seeing the same behavior with the default
> advertisement interval of 1s.
>
> Tcpdump on a linux tap interface plugged into the same BD as the backup VR
> shows VRRP advertisements arriving at the configured rate of 1s (100cs),
>
> So, there is no packet loss of advertisements or delays in sending
> advertisements by the master VR.
>
>
>
> 10:37:19.991540 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:20.991619 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:21.991783 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:22.991792 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:23.991926 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:24.991976 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:25.992057 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:26.992131 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:27.992257 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:28.992311 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:29.992402 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:30.992513 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:31.992586 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
>
>
>
>
>
>
> Ok, its good to know that the packets are all arriving on the backup.
>
>
>
> The diagram attached to the first message in this thread said that the
> master has address 10.4.4.1 and the backup has 10.4.4.3. Is that diagram
> still accurate? The packets in the capture have a source address of
> 10.4.4.3, which is the address that is supposed to be configured on the
> backup according to the diagram. If the diagram is still accurate, it seems
> like those packets should be dropped by the backup as 'spoofed' packets
> since their source address is configured locally on the backup.
>
>
>
> If the diagram is not accurate and the master VR is truly supposed to be
> advertising with a source address of 10.4.4.3, can you please use vppctl to
> generate a packet capture on the backup VR? You could run something like
> 'vppctl trace add dpdk-input 50; sleep 10; vppctl show trace'. Depending on
> how noisy your network is, that ought to capture a few inbound
> advertisements.
>
>
>
>
>
>
>
> However, it appears that there is a delay in VRRP packet processing at the
> backup VR
