On Sun, May 01, 2011 at 01:41:44PM +0200, Benjamin Kiessling wrote:
> Hi,
> 
> > ospfd does not need any of the multicast options. ospfd uses the
> > IP_MULTICAST_IF socket option and bypasses the routing table lookup by
> > doing so. rtadvd and many other daemons do it in a similar way.
> > The multicast_host option is only needed for applications that do not use
> > the special multicast setsockopt()s.
> 
> Thanks for enlightening me.
> 
> > E.g. gre(4) needs the net.inet.gre.allow sysctl to be set to 1.
> 
> The key has been set to one and when I run tcpdump on the interface I see the
> LSAs from the router on the opposite end but the local ospfd doesn't emit any.
> Running:
> 
> ramen:~> ospfctl show interfaces
> Interface   Address            State  HelloTimer Linkstate  Uptime    nc  ac
> vr0         172.22.94.67/27    DOWN   -          active     00:00:00   0   0
> gre0        172.22.94.67/32    P2P    00:00:02   unknown    09:49:30   0   0
> 
> I see what I think I'm supposed to see. Starting ospfd in debug mode doesn't
> reveal any anything of value:
> 
> orig_rtr_lsa: area 0.0.0.0
> orig_rtr_lsa: stub net, interface vr0
> if_fsm: event UP resulted in action START and changing state for interface vr0
> from DOWN to DOWN
> orig_rtr_lsa: area 0.0.0.0
> orig_rtr_lsa: stub net, interface vr0
> orig_rtr_lsa: stub net, interface gre0
> if_fsm: event UP resulted in action START and changing state for interface
> gre0 from DOWN to P2P
> spf_calc: area 0.0.0.0 calculated
> 
> The config looks like this:
> 
> router-id 172.22.94.67 
> fib-update yes 
> 
> auth-type none 
> hello-interval 10
> retransmit-interval 5
> router-dead-time 40
> transmit-delay 1
> 
> # areas
> area 0.0.0.0 {
>         interface gre0 { metric 10 }
>         interface vr0 { passive }
> }
> 
> Any ideas where I could have misconfigured anything?

Are you sure that you're not blocking the ospf or gre packets with pf?
The hello timer is running and so hello packets should be generated and
sent. Since there are no errors from ospf when sending packets I assume
that the problem is in gre(4). Can you ping the remote end of the gre
tunnel?

-- 
:wq Claudio

Reply via email to