[Olsr-dev] broadcast packet filtering

[Joe Gio]

Hannes/Eric/All

I have done some experiments with an igmp router (modified igmp proxy) 
on the wired and tun interfaces along with an interface inspired by the 
quagga plugin. Olsr uses HNA messages to distribute multicast 
subscriptions on the wireless side. I plan to add the same api to pimd 
at some point but not sure if this is
going to do it all since the problem that I still have is that as Eric 
stated there is no way to retransmit (flood the packets based on mpr 
status) and check for dups in the kernel (so far).
This is where you take the big CPU hit. The gateworks board runnning 54M 
b/sin 802.11g mode we are using tops the CPU at 100% at about 13mbps 
when user space handles the packets, while it can handle much when using 
pure kernel forwarding.

Also note that olsr does receive its own broadcast packets too, but 
since each socket has its own socket buffers the olsr packets do get in.

A problem may exist with olsr processing during high traffic load so I 
have set the main olsr thread priority to real time, while leaving the
bmf thread at normal priority also added a mutex between olsr and bmf.

I'm also currently working on some "tc" rules that would give preference 
to olsr port 698 packets. I have been looking at the
qos-scripts distributed along with openwrt kamikaze but any help would 
be appreciated.


Eric
I think that there may be a problem/oversight with bmf and the duplicate 
check.
If I originate a packet from the wired side and the packet contents does 
not change (which is not unreasonable) then
this will be considered to be a duplicate at some point. I think that 
originating bmf should forward these along with a sequence number 
possibly in the unused field of the bmf header.

JoeGio

Hannes Gredler wrote:
> On Tue, May 06, 2008 at 10:16:52AM +0200, Erik Tromp wrote:
> | Hannes,
> | 
> | IMHO your comment is bashing. Please support your insinuations
> | ("destabilizing") with examples or with proof. And mention exactly the
> | circumstances and conditions so we have a base for improvement.
>
> erik,
>
> 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.
>
> see http://www.itu.int/ITU-T/ngn/fgngn/docs/FGNGN-004-June04.doc
>
> another (failed) example is to piggyback the first packet of a
> mcast stream as the payload of PIM register messages.
>
> router vendors have abandoned this mix of planes long
> time ago (app. 10 years).
>
> more worse, the lack of seperation, prevents running olsrd on a
> router system with dedicated hardware processing (the keyword here
> is "dedicated" i.e. could be a dual-core CPU where one CPU is dedicated
> to forwarding and the other CPU is dedicated to control-plane)
>
> | Of course any over-feeding of packets into any forwarding system may lead to
> | queues becoming full and overflowing. Totally nothing new here. Try to route
> | 1000000 IP packets per second through a 50 MHz CPU and its queues will
> | overflow.
>
> well dropping data traffic on the forwarding-plane is a reasonable action,
> and at least it does not destabilize the network as it has no impact on others.
>
> if you handle both forwarding and control-plane in the _same_ component then
> an overload of one function ill impacts the other function.
> now there is full fate-sharing and this is the element that is not desirable.
>
> | Destabilization is the result of wrong handling priorities. Not from loose
> | statements based on vague opinions.
>
> not vague opinions, more experience of building and supporting routers
> for 10+ years :-).
>
> see also
>
> http://en.wikipedia.org/wiki/Control_Plane
> http://en.wikipedia.org/wiki/Forwarding_Plane
>
> see here some standardization efforts of building a control-plane to
> forwarding-plane protocol.
>
> ftp://ftp.rfc-editor.org/in-notes/rfc3746.txt
>
> HTH,
>
> /hannes
>
> | 
> | 
> | -----Oorspronkelijk bericht-----
> | Van: (spam-protected)
> | [mailto:(spam-protected)] Namens Hannes Gredler
> | Verzonden: dinsdag 6 mei 2008 7:59
> | Aan: Joe Gio
> | CC: olsr-dev
> | Onderwerp: Re: [Olsr-dev] broadcast packet filtering
> | 
> | hi joe,
> | 
> | IMO the basic idea of the bmf plugin (piggyback dataplane traffic on top of
> | control-plane traffic) is way broken, and for the reasons you have been
> | giving (as per your example below), it may even become destabilizing.
> | 
> | i have been mulling with henning over the ideas to program real multicast
> | forwarding state (/64 (S,G) for IPv4 and /256 (S, G) for
> | IPv6 into the kernel FIB. Every node shall publish the multicast groups it
> | wants to receive via protocol extensions. During the SPF run we could
> | compute the distribution tree and program the kernel FIB, such that
> | forwarding-plane and control-plane stays seperate.
> | 
> | the idea is nothing new, much stuff will be derived from MOSPF
> | 
> | http://www.javvin.com/protocolMOSPF.html
> | 
> | /hannes
> | 
> | On Mon, May 05, 2008 at 02:26:45PM -0400, Joe Gio wrote:
> | | 
> | | It has been noticed that nodes generating high broadcast traffic (bmf 
> | | encap packets for instance) will "loose" some incoming messages even 
> | | though they are clearly visible being received using tcp dump on the 
> | | wireless interface.
> | | 
> | | The problem is that "broadcast " packets sent from the local node are 
> | | looped back to any listening sockets on the same box as is the case in 
> | | bmf, so bmf has to process (discard) its own broadcasts. Since bmf is 
> | | already busy reading packets of the wired interface the wireless 
> | | receive queue starts to get backed quickly so any "real" packets 
> | | received from other nodes get dropped in the socket buff before bmf 
> | | can process. This can be confirmed using the netstat command  "while 
> | | sleep 1; do netstat -a 2<&1 | grep 50698; done"
> | | 
> | | This command filters out the nodes own broadcast packets using ip 
> | | tables on the gateworks armeb board.
> | | 
> | | ADDR=`ifconfig ath0 | grep "inet addr" | awk '{print $2}'`
> | | 
> | | BCAST=`ifconfig ath0 | grep "inet addr" | awk '{print $3}'`
> | | 
> | | ADDR=`echo $ADDR | sed -e s/:/\ /g | awk '{print $2}'`
> | | 
> | | BCAST=`echo $BCAST | sed -e s/:/\ /g | awk '{print $2}'`
> | | 
> | | iptables -I INPUT -p udp --src $ADDR --dst $BCAST -j DROP
> | | 
> | | Joe Gio
> | 
> | --
> | Olsr-dev mailing list
> | (spam-protected)
> | http://lists.olsr.org/mailman/listinfo/olsr-dev
> | 
>
>