[Olsr-dev] broadcast packet filtering

[Hannes Gredler]

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
|