Hi José, I implemented the VRRP plugin following RFC 5798. The RFC states at https://datatracker.ietf.org/doc/html/rfc5798#section-8.1.2:
"When a host sends an ARP request for one of the virtual router IPv4 addresses, the Virtual Router Master MUST respond to the ARP request with an ARP response that indicates the virtual MAC address for the virtual router. Note that the source address of the Ethernet frame of this ARP response is the physical MAC address of the physical router." The way your switches should learn how to reach the virtual MAC address is by learning from VRRP advertisements since VRRP advertisements do use the virtual MAC address as the source address on the ethernet frame. By default advertisements are sent once per second. Your screenshot from wireshark only shows some ARP packets, it does not show any VRRP advertisements. Are you able to see any VRRP advertisements when you sniff traffic with wireshark? What source MAC address is displayed? I'm not sure if maybe you are using different terminology than what I am used to, but I would not expect a switch's ARP table (L3-L2 mappings - 'show arp') to necessarily contain any information about the virtual MAC address, I would expect it's MAC address table (L2-physical port mappings - 'show mac-address-table') to have information about which port(s) the virtual MAC address has been seen on. The latter is what would typically be required for devices connected to a switch to forward traffic to the VPP interface where the VR is configured. Can you clarify which of these you are talking about? If the above doesn't help, I might be able to help troubleshoot more if you can tell me what version of VPP you're running, what vendor/model of NICs you are using, and how you are configuring your VRRP VR. Thanks, -Matt Smith On Wed, Jul 30, 2025 at 4:28 AM José Manuel Díaz Rodríguez via lists.fd.io <jmdiaz=jscingenium....@lists.fd.io> wrote: > Hi everyone, > > > > We’ve configured VPP with a bond, several subinterfaces and VRPP on top. > > The Cisco switch participating in the network forwards the ARP replies of > the node acting as VRRP master, but its ARP table remains empty. > > I can only show you a normal ARP request/reply right now. I expect > gratuitous ARP replies to be similar. > > Look at how the virtual MAC addres is in the body of the reply (sender MAC > address, as shown by Wireshark), not the Ethernet header (which carries the > physical MAC address). > > > > > > As VPP doesn’t use the virtual VRRP MAC address in the Ethernet header of > subsequent emitted frames (packets routed by VPP), my colleagues tell me > this won’t ever work with Cisco switches. > > That Cisco switches only learn MAC addresses by seeing them in the source > address field of the Ethernet header of frames (not ARP reply bodies). > > I cannot believe it. It seems so obvious a restriction as to have passed > unnoticed by VRRP plugin implementers. > > VPP is a project originated at Cisco. There must be someone in this list > with authoritative information on this subject. > > I’ve been asked to reimplement VRRP myself. There must be something we are > overlooking. Engineering can’t be so cruel. > > If Cisco switches can learn VRRP MAC addresses as communicated by the VPP > VRRP implementation, please tell me. > If anyone can reproduce the problem on their own VPP installations, that > would be very helpful also. > > At this moment, nobody believes me, and they say its obvious VPP’s VRRP > implementation is wrong. > > Would it be possible (although not recommended) to configure VRRP not to > use the virtual MAC address, but the physical one, in the Sender MAC > address of the ARP reply (normal and gratuitous)? > > We are using VPP 25.02. > > > > Thank you very much. > > Best regards, > > > > José Manuel > > *Información básica sobre protección de datos:* *Responsable del > tratamiento:* JSC Ingenium S.L.U. con CIF B81574089 y domicilio en > C/Condesa Venadito, No. 1, 28027, Madrid con número de teléfono 917030454 y > correo electrónico le...@jscingenium.com. Asimismo, ha designado un > delegado de protección de datos con correo electrónico > d...@grupoingenium.com. | *Finalidad principal:* gestionar la relación > comercial y/o profesional / Prestar el servicio contratado / Atender las > consultas o remitir la información que nos solicita. | *Legitimación:* > ejecución contractual / precontractual (artículo 6.1.b) del RGPD) / Interés > legítimo (artículo 6.1.f) del RGPD). | *Derechos:* puede ejercer los > derechos reconocidos en los artículos 15 a 22 del RGPD, de acceso, > rectificación, supresión, portabilidad, limitación, oposición, así como a > no ser objeto de decisiones basadas únicamente en el tratamiento > automatizado de sus datos, cuando procedan escribiendo a la dirección > C/Condesa Venadito, No. 1, 28027, Madrid o en el correo electrónico > d...@grupoingenium.com. | *Información adicional:* puede consultar la > información adicional y detallada sobre nuestra Política de Privacidad en > http://www.jscingenium.com o escribiendo al correo electrónico > d...@grupoingenium.com. | *Confidencialidad:* si usted no es el > destinatario y recibe este correo electrónico por error, rogamos se ponga > en contacto con nosotros y destruya de inmediato el mail/fax por error > recibido con todos sus documentos adjuntos sin leerlos ni hacer ningún uso > de los datos que en ellos figuren, ateniéndose a las consecuencias que de > un uso indebido de dichos datos puedan derivarse. > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26233): https://lists.fd.io/g/vpp-dev/message/26233 Mute This Topic: https://lists.fd.io/mt/114445686/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
