Re: [patch 4/10] s390: network driver.

[Hasso Tepper <hasso@estpak.ee>]

jamal wrote:
> Dont post networking related patches on other lists. I havent seen said
> patch, but it seems someone is complaining about some behavior changing?

For some strange reason I didn't find the beginning of thread either from 
archive, the first post seems to be  
http://oss.sgi.com/projects/netdev/archive/2004-11/msg01015.html.

I'm trying to summarize. The approach - one raw socket to send/receive 
messages no matter how many interfaces are used - worked for Quagga/Zebra 
routing software daemons till now. If some of these interfaces was 
operationally down, socket wasn't blocked even if the queue was full. In 
fact "man sendmsg" has still text:

ENOBUFS
	The output queue for a network interface was full.  This  gener-
	ally  indicates  that the interface has stopped sending, but may
	be caused by transient congestion.   (Normally,  this  does  not
	occur  in Linux. Packets are just silently dropped when a device
	queue overflows.)

Seems that it's no longer true. Seems that kernel is now trying as hard as 
possible not to loose any data - data is queued and if the queue will be 
full, all related sockets will be blocked to notify application. So, one 
socket approach don't work any more for Quagga/Zebra. No problem, we can 
take the "one socket per interface" approach. And we already have link 
detection implemented to notify daemons.

But there will be still potential problem - sending the "interface down" 
message from kernel to the zebra daemon and then to the routing protocol 
daemon takes time. And during this time daemon can send packets which will 
sit in queue and may cause many problems if sent to the network later (if 
link comes up again). Think about statelss routing protocols like rip(ng), 
ipv6 router advertisements etc. They may carry the info that's no longer 
true causing routing loops etc.

And to clarify a little bit: no - the Quagga/Zebra didn't work with previous 
approach perfectly. I fact with link detection and socket per interface it 
will be better than ever no matter what's the kernel behaviour. We just 
want to make sure that solution will be bulletproof.

So, problem - how can we make sure that no potentially dangerous aged 
(routing) info will be in the network?


-- 
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator