On Sat, 1 Mar 2014 18:42:11 -0800 "Paul B. Henson" <hen...@acm.org> wrote: > 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.
I see the problem of /32 route. But it doesn't occur on my environment (OpenBSD 5.5-beta/amd64).. % ospfctl show fib | grep 128 * 56 10.128.120.0/24 127.0.0.1 * 56 10.128.120.213/32 10.0.0.1 % And do you know why the ospfd doesn't use "the whole /24"? > 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? Even if tun(4) is used, packets are processed in-kernel. --yasuoka
