ARP cache stuffing/gratuitous ARP

[Barnes, Peter D.]

Hello Folks,

We’re using SimpleNetDevice/Channel (SND/C) for some large models, and we’ve encountered a scaling issue related to ARP.

In the current implementation ARP sends a broadcast packet to find the link-layer address associated with a network layer (IPv4) address.  With N nodes on the SND/C, that results in N^2 packets early in the simulation.  NeedsArp can be toggled off, but that sends *every* packet in broadcast, which affects the entire simulation.  These issues are even worse when we run ns-3 in parallel (using a DistributedSimpleNetDevice/Channel we are developing).

It occurred to us to try ARP cache stuffing, to pre-populate the cache.  However iIt looks like you can’t do this trivially; the code is spread across ArpL3Protocol::Lookup(), which creates the ArpCache::Entry in WaitReply state, and ArpL3Protocol::Receive(), which populates the entry and puts it in Alive state.  

Q1:  is there any reason *not* to add a method ArpCache::Add(Ipv4Address to, Address destination) to stuff the cache?  Or is there a better way to do this?

Interestingly, ArpL3Protocol::Recieve() discards unsolicited ARP Replies, as poisoning attacks.  Since it also discards requests not to self, It’s not clear that ns-3 handles gratuitous ARP (GARP) at all.  

Q2:  Is not handling GARP a defect?

Finally, ArpCache::Entry’s can be marked Permanent, but that is only used by a test case ATM.

Q3:  Are there any gotchas/subtleties in marking cache entries as permanent?

Thanks,

Peter