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).
[cid:image001.png@01DC0140.533F62F0] 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 (#26232): https://lists.fd.io/g/vpp-dev/message/26232 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] -=-=-=-=-=-=-=-=-=-=-=-
