Re: [vpp-dev] VRRP master gratuitous ARP request with physical MAC address
Hi Ajesh, Thanks for the explanation. When you have "accept mode" enabled on a VR and that VR enters the master state, the virtual IP addresses get added on the interface. From your description, it seems like the ARP/neighbor resolution code is using the newly added IP address as the sender protocol address in ARP requests rather than other addresses which were already configured on the interface. I'll have to look into how that could be fixed. Some possible workarounds for the time being: - Don't enable accept mode on the VR. If VRRP does not add the virtual IP address to the interface, it will not be used in ARP requests. - Create a static entry in the neighbor table for the gateway. -Matt On Fri, Feb 25, 2022 at 5:08 AM wrote: > Hi Matt, > > Thanks for the reply. > We are(i am working with Mechthild) using an Ericsson R6K > router(bridge/bvi on the router). > > The VPP VRRP master indeed sends GARP at start up with the right VRRP MAC > address, so are the VRRP periodic advertisements using the correct virtual > MAC. > However, when it has to resolve the GW address it sends out ARP requests > using the VIP and with the sender MAC as the physical interface MAC, > > like in this packet Mechthild has shown (172.17.1.3 is the VIP and .126 is > the GW ) > > 22:33:52.620143 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > (0x8100), length 46: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4 > (len 4), Request who-has 172.17.1.126 tell 172.17.1.3, length 28 > > Frame 8: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) > Ethernet II, Src: Dell_1f:47:60 (78:ac:44:1f:47:60), Dst: Broadcast > (ff:ff:ff:ff:ff:ff) > 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 101 > Address Resolution Protocol (request) > Hardware type: Ethernet (1) > Protocol type: IPv4 (0x0800) > Hardware size: 6 > Protocol size: 4 > Opcode: request (1) > Sender MAC address: Dell_1f:47:60 (78:ac:44:1f:47:60) << > Sender IP address: 172.17.1.3 > Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) > Target IP address: 172.17.1.126 > > This causes the R6K to update the ARP/bridge table. > > The RFC states that, > >When a VRRP router restarts or boots, it SHOULD NOT send any ARP >messages using its physical MAC address for the IPv4 address it owns; >it should only send ARP messages that include virtual MAC addresses. > > > However it is not mentioning about regular operation - but logically it > should still work the same way, or? > > Thanks and best regards, > Ajesh > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20918): https://lists.fd.io/g/vpp-dev/message/20918 Mute This Topic: https://lists.fd.io/mt/89367259/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VRRP master gratuitous ARP request with physical MAC address
Hi Matt, Thanks for the reply. We are(i am working with Mechthild) using an Ericsson R6K router(bridge/bvi on the router). The VPP VRRP master indeed sends GARP at start up with the right VRRP MAC address, so are the VRRP periodic advertisements using the correct virtual MAC. However, when it has to resolve the GW address it sends out ARP requests using the VIP and with the sender MAC as the physical interface MAC, like in this packet Mechthild has shown (172.17.1.3 is the VIP and .126 is the GW ) 22:33:52.620143 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.126 tell 172.17.1.3, length 28 Frame 8: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) Ethernet II, Src: Dell_1f:47:60 (78:ac:44:1f:47:60), Dst: Broadcast (ff:ff:ff:ff:ff:ff) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 101 Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: Dell_1f:47:60 (78:ac:44:1f:47:60) << Sender IP address: 172.17.1.3 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 172.17.1.126 This causes the R6K to update the ARP/bridge table. The RFC states that, When a VRRP router restarts or boots, it SHOULD NOT send any ARP messages using its physical MAC address for the IPv4 address it owns; it should only send ARP messages that include virtual MAC addresses. However it is not mentioning about regular operation - but logically it should still work the same way, or? Thanks and best regards, Ajesh -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20914): https://lists.fd.io/g/vpp-dev/message/20914 Mute This Topic: https://lists.fd.io/mt/89367259/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VRRP master gratuitous ARP request with physical MAC address
Hi Mechthild, See comments below... On Thu, Feb 24, 2022 at 9:30 AM Mechthild Buescher via lists.fd.io wrote: > Hi all, > > > > We have another problem/question related to VRRP. When the router connect > to the setup has disabled MAC learning, the ARP table on the router doesn’t > have the virtual MAC for the VIP but the physical MAC of the interface on > the VRRP master. > > > > Tracing showed that GARP is sent from VIP with physical MAC of the > interface: > > 22:33:52.620143 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > (0x8100), length 46: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4 > (len 4), Request who-has 172.17.1.126 tell 172.17.1.3, length 28 > > 22:33:52.620145 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > (0x8100), length 46: vlan 102, p 0, ethertype ARP, Ethernet (len 6), IPv4 > (len 4), Request who-has 172.17.2.126 tell 172.17.2.3, length 28 > > 22:33:58.461327 78:ac:44:1f:47:60 > 00:25:90:5f:67:45, ethertype 802.1Q > (0x8100), length 60: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4 > (len 4), Reply 172.17.1.3 is-at 00:00:5e:00:01:e7, length 42 > > 22:33:59.485321 78:ac:44:1f:47:60 > 00:25:90:5f:67:45, ethertype 802.1Q > (0x8100), length 60: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4 > (len 4), Reply 172.17.1.3 is-at 00:00:5e:00:01:e7, length 42 > > > These packets are standard ARP replies & requests, not gratuitous ARP requests. The "who-has" (target protocol address) and "tell" (source protocol address) IP addresses would be the same if it was a gratuitous ARP request. E.g. - 12:12:42.064324 00:08:a2:0b:0d:27 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 198.51.100.5 (Broadcast) tell 198.51.100.5, length 46 > This seems to be wrong. If I read the standard correctly ( > https://datatracker.ietf.org/doc/html/rfc3768, ch. 8.2), it should use > the virtual router MAC address for GARP requests. > > > The RFC you cite (3768) is for VRRPv2. The VRRP plugin only implements support for VRRPv3, which is specified in RFC 5798. Regardless, both of those RFCs say: "When configuring an interface, Virtual Router Master routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IPv4 address on that interface". The gratuitous ARP packet sent by VPP's VRRP plugin does contain the VR virtual MAC address in the ARP sender hardware address field. It does not use the VR virtual MAC address as the source MAC address in the ethernet header of the ARP request packet though, it uses the MAC address of the hardware interface. RFC 5798 does not say anything about which source MAC address (hardware vs virtual) should be used on a gratuitous ARP request. The only mention I found related to ARP source MAC addresses is in section 8.1.2 ( https://datatracker.ietf.org/doc/html/rfc5798#section-8.1.2) which says that ARP replies to requests for the VR virtual IP addresses should use the hardware MAC address rather than the virtual MAC address - "Note that the source address of the Ethernet frame of this ARP response is the physical MAC address of the physical router". If your router is populating it's ARP table using the source MAC address of a gratuitous ARP packet rather than using the sender protocol address from the packet payload, that seems like incorrect behavior. What type of router is it? Thanks, -Matt > MASTER conifg: > # vppctl show vrrp vr > > [0] sw_if_index 26 VR ID 231 IPv4 > >state Master flags: preempt no accept yes unicast no > >priority: configured 200 adjusted 200 > >timers: adv interval 100 master adv 100 skew 21 master down 321 > >virtual MAC 00:00:5e:00:01:e7 > >addresses 172.17.1.3 > >peer addresses > >tracked interfaces > > > > VPP version (includes https://gerrit.fd.io/r/c/vpp/+/34815 ): > # vppctl show version verbose > > Version: v21.06.0-2~g4ffc97bad > > Compiled by: suse > > Compile host: SUSE > > Compile date: 2022-02-21T13:42:14 > > Compile location: /root/vpp-21.06-release/vpp > > Compiler: GCC 7.5.0 > > Current PID: 6528 > > > > Is this a bug in VPP or is there a configuration parameter which I > overlooked? > > > > Thanks for your help, > > > > BR/Mechthild > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20911): https://lists.fd.io/g/vpp-dev/message/20911 Mute This Topic: https://lists.fd.io/mt/89367259/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
