[Olsr-dev] broadcast packet filtering
Tue May 6 14:30:36 CEST 2008
isn't it fair to say that the encaspulation of the data-plane
traffic is done within the same process that runs the
On Tue, May 06, 2008 at 02:09:51PM +0200, Erik Tromp wrote:
| > its not bashing. - i was just expressing common insights in
| > router design that any scheme that mixes up forwarding-plane
| > with control-plane have an inherent risk of destabilizing the
| > control-plane of the system.
| Your assumption is wrong, and thus all that follows - "Ex falsus
| quod libet" :-) . Bmf does not mix up the forwarding plane
| with the control plane. Bmf uses encapsulation, which is a modern-day
| technology. Bmf does this in order to:
| 1. prevent multiple copies of the same IP packet from being received
| by the application software
| 2. prevent the need for putting network interfaces into promiscuous
| mode, as is done in other MPR-based flooding/forwarding mechanisms.
| For more information, read the README_BMF.txt file, especially
| paragraph 5.
| Bmf *does* perform the forwarding in user-space. In Linux-based
| systems, it would be nicer (i.e. more elegant and maybe better
| performing) to have the forwarding done in kernel-space. However,
| current linux-kernels do not offer an implementation that filters
| out the forwarding of recently seen packets. Maybe a kernel
| module can be written for iptables to implement this, but that would
| introduce the dependency on an external software component, which is
| not my preference.
| Another option is to guarantee that each packet gets forwarded to
| a downstream node by at most one upstream node. This is the assumed
| way of working in current Linux-kernel multicast forwarding
| implemenations. This requires building of a forwarding tree, which
| reduces redundancy to zero (each branch in the tree is a single point
| of failure), and is not consistent with the MPR-based redundant
| mechanism used in OLSR.
| > not vague opinions, more experience of building and
| > supporting routers for 10+ years :-).
| Same for me ;)
| Thanks for the URLs!
More information about the Olsr-dev