Re: [B.A.T.M.A.N.] [PATCHv2 2/2] batman-adv: Snoop DHCPACKs for DAT

[Antonio Quartulli <a@unstable.cc>]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

On Tue, Jul 05, 2016 at 08:01:37PM +0200, Linus Lüssing wrote:
> In a typical mesh network, when a new client connects then it will
> usually first try to grab an IPv4 address via DHCP. Afterwards in
> public mesh networks a client will try to contact the internet over
> the server.
> 
> While the IPv4 address of the DHCP-Server is usually well propagated
> in the DHT, the IPv4 address of a newly joining client is not.
> 
> This can lead to a considerable amount of ARP broadcasts not caught
> by DAT from the servers.
> 
> In a 1000 nodes mesh network (Freifunk Hamburg) we can still see
> 30KBit/s of ARP traffic (equalling about 25% of all layer two
> specific overhead, remaining after some filtering) flooded through
> the mesh. These 30KBit/s are mainly ARP Requests from the
> gateways / DHCP servers.
> 
> Through snooping DHCPACKs we can actually learn about MAC/IP address
> pairs without the need of any flooded ARP messages in advance. This
> allows servers to fill their local DAT cache with according entries
> before any communciation with a client can possibly have taken place.

Linus,

have you tried applying this patch on one of your servers and measure the local
effect? (i.e. if the number of BRD ARP req is reduced or not?)

I think that a DHCP ACK packet should already refresh the local ARP cache (or
not?), thus the need for an ARP request should not be triggered by the newly
joined client. (I might be wrong, but that's why I ask measuring the effect)

Cheers,

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]