Hi Inder, Here are some answers to your questions...
Is this an expected behavior when using the same VR ID across different > interfaces and FIB tables? It's not an intended behavior. I would expect things to work with your setup , but I have never tried using VRs with the same VR ID on subinterfaces of the same physical interface which are attached to different FIB tables. I have tested many times with subinterfaces using the same VR ID on the same physical interface with both subinterfaces using the default FIB table and that has worked. > Could this be a known issue or limitation in VPP 24.02? It's not a known issue. So if you're asking if it might possibly be fixed in a newer release than 24.02, I don't know. If it was caused as a side effect of some bug unrelated to VRRP, maybe it works in a newer version. But the issue has not been specifically addressed since 24.02 because you're the first person to report it that I know of. Are there any recommended best practices for handling VRRP instances across > multiple FIB tables? There are no documented best practices. One suggestion I can make is to try using a different VR ID on one of the VRs and see if the behavior changes. > Please let us know if additional logs, configuration snippets, or packet > captures would help in analyzing the issue further. > Yes, all of that stuff would help :) If you send the commands you are using to configure VPP, a packet capture of one of the ping packets being dropped and output of 'vppctl show hardware-interfaces', that might help me make a better guess on what's causing the issue. Thanks, -Matt On Thu, Feb 26, 2026 at 8:53 AM Inder via lists.fd.io <inderpalpatheja= [email protected]> wrote: > Hi Team, > > Dear VPP Community, > > We are currently using *VPP version 24.02* and have encountered an issue > related to VRRP configuration. We would appreciate your guidance on this > behavior. > Setup Details > > - > > Two VMs configured in an active/backup redundancy model. > - > > A VRRP instance (VR ID 101) is configured on interface eth0.1. > - > > eth0.1 is associated with *FIB table 1*. > - > > Both VMs participate in this VRRP instance, with one acting as *Master* > and the other as *Backup*. > - > > In this setup, the Backup VM is able to successfully ping the VRRP VIP. > > Issue Observed > > When we configure a second VRRP instance with the *same VR ID (101)* on a > different interface (eth0.2), where: > > - > > eth0.2 belongs to a separate FIB table (FIB table 2), > > we observe the following behavior: > > - > > The Backup VM is no longer able to ping the VRRP VIP of the first VRRP > instance. > - > > This functionality was working correctly prior to configuring the > second VRRP instance. > > Additional Observation > > - > > After restarting the VPP service, the ping to the first VRRP VIP from > the Backup VM starts working again. > - > > We understand that using the same VR ID results in the same Virtual > MAC address. > - > > However, we are unsure why restarting VPP restores correct behavior. > > Query > > 1. > > Is this an expected behavior when using the same VR ID across > different interfaces and FIB tables? > 2. > > Could this be a known issue or limitation in VPP 24.02? > 3. > > Are there any recommended best practices for handling VRRP instances > across multiple FIB tables? > > Please let us know if additional logs, configuration snippets, or packet > captures would help in analyzing the issue further. > > Thank you in advance for your support. > > regards > Inder > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26853): https://lists.fd.io/g/vpp-dev/message/26853 Mute This Topic: https://lists.fd.io/mt/118013037/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
