Cannot connect two ospf-instances over tun-interface

dawid k tookie009smieci at gmail.com
Thu Apr 5 12:16:17 CEST 2018


Hello,

I got the server to work. The issue was, that I didn't disable iptables
correct. Now two client and the server are exchanging own routes.

I connected to one client another one over a router and the router is
connected to the ospf-network as well.

But somehow I cannot contact the new client from the first client or even
from the server. Iptables are surely disabled now.

My current setting


client3
192.168.30.2 (eth)
|
|
192.168.30.1 (eth)
routerA
192.168.21.5 (eth)
|
|
192.168.21.1 (eth)
client2
10.29.0.8 (tun)
|
|
10.29.0.1 (tun)
Server
10.29.0.1 (tun)
|
|
10.29.0.4 (tun)
client1
192.168.21.17 (eth)


I ran following commands on client1

route -n (routes with metric 12 are set by bird)

Destination       Gateway         Genmask         Flags Metric Ref    Use
Iface
10.29.0.0          0.0.0.0         255.255.252.0   U     0      0        0
tun0
WWWWW        0.0.0.0         255.255.255.252 U     0      0        0 eth1
XXXXXXX        0.0.0.0         255.255.255.255 UH    1024   0        0 eth1
192.168.21.0    10.29.0.8     255.255.255.240 UG    12     0        0 tun0
192.168.21.16  0.0.0.0         255.255.255.240 U     0      0        0 eth0
192.168.30.0    10.29.0.8     255.255.255.240 UG    12     0        0 tun0


traceroute  192.168.21.3
traceroute to 192.168.21.3 (192.168.21.3), 30 hops max, 38 byte packets
 1  10.29.0.8 (10.29.0.8)  101.192 ms  111.038 ms  116.587 ms
 2  192.168.21.3 (192.168.21.3)  102.448 ms  72.160 ms  100.151 ms

traceroute  192.168.30.1
traceroute to 192.168.30.1 (192.168.30.1), 30 hops max, 38 byte packets
 1  server(10.29.0.1)  128.053 ms  128.731 ms  117.244 ms
 2  *^C (no response)


and the server:

route -n (routes with metric 17 are set by bird)

Ziel            Router          Genmask         Flags Metric Ref    Use
Iface
192.168.21.16   10.29.0.4       255.255.255.240 UG    17     0        0 tun0
192.168.21.0    10.29.0.8       255.255.255.240 UG    17     0        0 tun0
192.168.30.0    10.29.0.8       255.255.255.240 UG    17     0        0 tun0
192.168.20.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.29.0.0       0.0.0.0         255.255.252.0   U     0      0        0 tun0
ZZZZZZZZ     0.0.0.0         255.255.0.0     U     1002   0        0 eth0

traceroute  192.168.21.3

traceroute to 192.168.21.3 (192.168.21.3), 30 hops max, 60 byte packets
 1  10.29.0.8 (10.29.0.8)  40.352 ms  96.659 ms  96.643 ms
 2  192.168.21.3 (192.168.21.3)  96.625 ms  96.606 ms  96.586 ms

traceroute  192.168.30.1
no responce

As you can see in route -n, the server has a valid route to 192.168.30.0

Do you have any idea, what I'm missing now? I guess that's the "tricky
party", mentioned by Micheal McConnell.



2018-04-04 13:54 GMT+02:00 dawid k <tookie009smieci at gmail.com>:

>
> 2018-04-04 12:31 GMT+02:00 Ondrej Zajicek <santiago at crfreenet.org>:
>
>> On Wed, Apr 04, 2018 at 11:35:03AM +0200, dawid k wrote:
>> > 2018-04-04 10:59 GMT+02:00 Jan Maria Matejka <jan.matejka at nic.cz>:
>> >
>> > > Hello,
>> > >
>> > > please could you enable 'debug all' for the ospf protocol at server?
>> > > It should tell you whether it receives the packets and what is it
>> doing
>> > > with them.
>> > >
>> >
>> > It is enabled, Here the logs:
>> >
>> >
>> > no received packets, but with tcpdump on server I can see, that all
>> devices
>> > are sending hello messages:
>>
>> Hello
>>
>> That is interesting, It is possible that there is some problem with
>> multicast on OpenVPN, as mentioned by Michael McConnell, but not in the
>> sense
>> of multicast transmit (which works as seen by tcpdump), but multicast
>> delivery
>> to userspace sockets (so BIRD does not get them).
>>
>> One workaround would be to use NBMA interface type in BIRD OSPF. That
>> uses just unicast, so perhaps there would not be this problem. See 'type
>> nbma' OSPF option. Then you have to use 'neighbors' option to specify
>> client IPs on server and at least server IP (marked 'eligible') on clients
>> and set priority to 0 on clients.
>>
>> Thank you for your help, but it is still not working.
>
> I tried the nmba connection between one client and server with following
> settings:
>
> client:
>
>                 interface "tun0" {
>                         cost 10;
>                         type nbma;
>                         strict nonbroadcast yes; #tried with disabled as
> well
>                         stub no;
>                         hello 10;
>                         transmit delay 5;
>                         wait 10;
>                         dead 40;
>                         priority 0;
>                         neighbors {
>                                 10.29.0.1 eligible; #server's IP
>                         };
>                  };
>
> server
>                 interface "tun0" {
>                         cost 10;
>                         type nbma;
>                         strict nonbroadcast yes;
>                         stub no;
>                         hello 10;
>                         transmit delay 5;
>                         wait 10;
>                         dead 40;
>                         neighbors {
>                                 10.26.0.4; # client's IP
>                         };
>                  };
>
> There are no error messages in logs only the info: HELLO packet sent via
> tun0.
> I started  tcpdump -v -s 0  proto ospf -i tun0 now on both client and
> server and there is no traffic at all.
> The routes are set properly and ping is working. I tried ptp as well with
> similar result. Im using iptables, but for the test I deactivated it.
> I have no idea, why tcpdump shows no traffic. I suppose, that there is an
> issue with OpenVPN, what Michael McConnel and others mentioned.
>
>
>
>
>> --
>> Elen sila lumenn' omentielvo
>>
>> Ondrej 'Santiago' Zajicek (email: santiago at 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."
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20180405/345c089a/attachment.html>


More information about the Bird-users mailing list