On Sat, Mar 01, 2014 at 07:41:10PM +0900, YASUOKA Masahiko wrote:
> I could repeat the problem. ospfd seems not to be able to use routes
> set by npppd. The problem seems to be come from pppx(4)'s behavior of
> its link state.
>
> Using tun(4) instead of pppx(4) avoid the problem.
If I switch npppd to use tun, after startup (before any clients even
connect) ospfd shows three routes:
# ospfctl show fib | grep 120
* 56 10.128.120.0/24 127.0.0.1
4 10.128.120.1/32 10.128.120.1
* 56 10.128.120.1/32 127.0.0.1
Kind of odd ones though, routing the whole /24 to localhost? After a
client connects, it adds another /32 to it:
# ospfctl show fib | grep 120
* 56 10.128.120.0/24 127.0.0.1
4 10.128.120.1/32 10.128.120.1
* 56 10.128.120.1/32 127.0.0.1
56 10.128.120.12/32 10.128.120.1
And after the client disconnects, it goes away:
# ospfctl show fib | grep 120
* 56 10.128.120.0/24 127.0.0.1
4 10.128.120.1/32 10.128.120.1
* 56 10.128.120.1/32 127.0.0.1
However, it's still not advertised by ospfd to other routers, so the
client still can't communicate with the network beyond the openbsd
router terminating the vpn connection.
So while tun seems to avoid the pppx problem of dangling routes, it
still doesn't solve the issue of ospfd not advertising them <sigh>.
pppx is more efficient than tun, right? It keeps packets in the kernel
rather than bouncing them through userspace?
No ospfd experts that would like to chime in :)? The vpn /32 routes
don't seem to be marked as either valid or connected...
Thanks...
