[rbridge] Back to ND/ARP optimization

Arien Vijn arien.vijn at ams-ix.net
Mon May 7 07:22:40 PDT 2007


Hello Radia,

On May 6, 2007, at 12:10 AM, Radia Perlman wrote:

> Actually, I'm not sure that's the conclusion that Arien was making  
> (that ARP/ND
> optimization is not worth it), especially with the comment "peak  
> rates much higher".
>
> So Arien...was that actually your conclusion?

Eh... I just posted an observation that differed from the theory :)

> I think that ARP/ND optimization could be added in the future as an  
> option, or
> even that an implementation can do something about it without  
> having the spec
> saying anything about it. Which would argue for not needing it in  
> the spec now.

I agree. Please see my reply on one of your other postings on this list.

> But just want to verify what Arien's conclusion is from the data  
> presented...

My conclusion would be that you should consider that most queries are  
futile. Because in my observations, successful queries are not the  
bulk of the traffic. Hence I think that there is not much gain in  
optimising those. To me it seems hard to optimise unsuccessful  
queries. Throttling seems the only feasible way.

To give a bit more insight:

	1/ Futile ARP/ND queries are mostly due to scanners. Scanners try  
all addresses in one subnet, causing routers to query over and over  
again.

	2/ Another cause is more specific for the peering LAN I presented.  
Many operators just do not remove BGP sessions for peers that have  
left. Routers will continue to query for the lost peer.

	3/ Some systems do perform far more queries than others. As  
illustration you may want to have a quick look at this presentation  
and note some remarkable differences between vendors:

http://www.ams-ix.net/~arien/TM24-AV-ARP-V01.pdf

	4/ The peak rates I mentioned are due to the fact that the ARP  
mitigation kicks in after a while. Without mitigation, we would see a  
constant high query rate. The first version of this system was  
actually created when we saw that routers could not handle the  
increased query rate during a renumbering action.

Considering the above, I also come to the conclusion that all of this  
is a matter for end hosts (routers mostly).

Kind regards, Arien


--
Arien Vijn
Amsterdam Internet Exchange
http://www.ams-ix.net





More information about the rbridge mailing list