OSPF routers (with BIRD on debian) recognize each other as neighbors but can't ping each other

Question

I've created a "line" topology using virtual box - creating 4 machines and making a separate link between each using internal networks - R1 (eth0, 10.0.1.1) <-> (eth0, 10.0.2.1) R2 (eth2, 10.0.2.2) <-> (eth0, 10.0.3.1) R3 (eth2, 10.0.3.2) <-> (eth0, 10.0.4.1) R4. I've enabled packet forwarding for ipv4 using:

sudo sysctl net.ipv4.ip_forward=1

the OSPF configuration for R2 and R3 in /etc/bird.conf looks like this:

protocol ospf MyOSPF {
    tick 2;
    rfc1583compat yes;
    area 0.0.0.0 {
        stub no;
        interface "eth2" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
        interface "eth0" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
    };
}

when I enter birdc and type

ospf  show topology

and

ospf show neighbors

it seems that all the routers see the correct topology, recognize the adjacent routers as neighbors and calculate the costs correctly. However it's not possible to ping R3 from R2, unless the interface is manually specified (ping -I eth2 10.0.3.1). This is not the case with R1 and R2, where eth0 is used on both ends.

Here is what /etc/network/interfaces looks on R2:

allow-hotplug eth0
iface eth0 inet static
address 10.0.2.1

auto eth1 #this is the bridged adapter used to ssh to the vm from the host
iface eth1 inet dhcp 

allow-hotplug eth2
iface eth2 inet static
address 10.0.2.2

I'm a bit confused whether the problem is in the configuration of the interfaces or that of the routing protocol.

Here is the output of

ip link

and

ip route

for each machine

Answer 1

I figured it out! There are several reasons the setup was not working - first of all, the addresses were not set right. The interface should be assigned the following (for example) addresses to make things work:

R1 (eth0, 10.0.1.1) <-> (eth0, 10.0.1.2) R2 (eth2, 10.0.2.1) <-> (eth0, 10.0.2.2) R3 (eth2, 10.0.3.1) <-> (eth0, 10.0.3.2) R4

in order for both interfaces facing each other on each two adjacent routers to be on the same broadcast domain (/24 subnet). The netmask on each interface should be set to 255.255.255.0.

As for OSPF configuration in BIRD, the "networks" block had to be added to the area in order to designate what kind of information the routers are supposed to exchange (in particular, which networks the routers are talking about). In that case since we have a /24 (255.255.255.0) network on each end we can use a /16 network (255.255.0.0) in the networks statement to exchange information between the two adjacent /24 networks (10.0.1 and 10.0.2 for example). So at the end it looks like this:

protocol ospf MyOSPF {
    tick 2;
    rfc1583compat yes;
    area 0.0.0.0 {
        networks {
            10.0.0.0/16;
        };
        stub no;
        interface "eth2" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
        interface "eth0" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
    };
}

from bird ospf confiiguration manual networks {set} - Definition of area IP ranges. This is used in summary LSA origination. Hidden networks are not propagated into other areas.

Answer 2

Your routers can see each other via OSPF because OSPF uses multicast out the whatever interface to discover neighbors. That means you don't actually need working routing tables to see neighbors so long as the two routers are on the same multicast domain.

So looking at your screencaps -- all your router interfaces are either in 10.0.0.0/8 or 192.168.0.0/24. Your routers are going to see that and assume that they're in the same broadcast domain, so instead of sending the packet out eth0 or eth2 or whatever they're just going to send the traffic out random interfaces.

You should use small direct attached subnets for router to router communication and not have these giant /8 subnets which will just make things confusing.

It is a common situation to have a router with lots of different overlapping routing tables that are actually different real networks.

For bird specifically: http://bird.network.cz/?get_doc&f=bird-2.html

Lastly, you need to make sure that bird knows about the OS routes and is setting routes on the OS. Ah, this may be the source of your trouble -- from the FAQ:

BIRD does not import some routers from kernel

First, learn option of kernel protocol must be active.

Second, 'device' routes related to interface addresses/prefixes added automatically by OS/kernel are never imported. You could add them using direct protocol.

Third, for some obscure and historic reasons BIRD 1.3.x (or older) does not import even some manually added device/host routes (i.e. ones without gateway). There are two ways to fix this. Either add these routes to the kernel routing table with static protocol source (e.g. '@ip route add 10.20.30.0/24 dev eth0 proto static@' ), or recompile BIRD with attached patch (see the bottom of the page) to fix this issue.