Thank you very much for getting back to me in this matter! As for my scenario: in the long run I need to be able to let a single BIRD process run as many as 10000 OSPF protocol instances, each of which communicating locally over an individual TUN/TAP device. In the end, a single Linux system therefore has to be able to support 10000 TUN/TAP devices. As for your ideas and suggestions to check: Having tap1 and tap2 on one system, I'm able to ping tap2 via tap1. Running OSPF in NBMA mode resulted in no messages received by the tap devices at all. I updated my stackoverflow question and included also a strace()-extract of BIRD. In it you see the setup of a socket for a tap device and the inclusion of the file-descriptor for this socket into the set of descriptors observed by the selcet() system call. But unfortunately select() never notices any data ready to be read by this socket file-descriptor. With the additional information about my scenario and the results of your ideas and suggestions, I kindly ask you to take another look at the updated question on stackoverflow. I'm thankful for all the time you or somebody else will invest into supporting me in this matter! Best, Cyrill 2014/1/15 Ondrej Zajicek <santiago@crfreenet.org>

On Mon, Jan 13, 2014 at 02:01:48PM +0100, Cyrill Gössi wrote:

...

Hi

I'm trying to let BIRD communicate over virtual network devices created by the Linux TUN/TAP module.

As it seems the tap devices receive the messages from BIRD. However, BIRD does not seem to receive the messages sent to it over the tap device.

I described the scenario and the issues I run into in more detail on stackoverflow.

I am not sure if i understand your scenario, but if you run both TUN/TAP endpoints on one machine, i would be surprised if OS network code wouldn't be confused by that. If not, you should try ping and try to run OSPF in NBMA mode (which will use just unicasts).

...

If somebody has some experience with running BIRD over TUN/TAP devices,

Generally, it works over OpenVPN tunnels, which use TUN/TAP devices, but in that cases both endpoints are on different machines.

-- Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlLVz2YACgkQw1GB2RHercOUBACgiI8lV1yRxeTp5tCaMVNvZ9hf 8TkAnjppe/ei6PnHmEiiJ3Fhp6PAEN+Z =FDol -----END PGP SIGNATURE-----