[Xorp-users] OSPF point-to-multipoint issue

Tue Jun 22 06:14:51 PDT 2010

After some tcpdump analysis between Quagga and Xorp, I think I see our issue.  Quagga - like Cisco - allows you to configure OSPF point-to-multipoint interfaces *without* having to specify neighbors statically in the configuration.  When I tried this on Xorp, the OSPF neighbors never came up.  I specifically needed to configure the neighbors under the OSPF point-to-multipoint interface.

When OSPF then starts sending its HELLO packets, Cisco and Quagga both send to AllSPFRouters (224.0.0.5) with a TTL of 1.  This ensures that all OSPF routers on a segment get the HELLO and adjacencies are formed between all routers without letting multihop neighbors establish adjacencies (TTL 1).  Xorp sends the HELLO packets to the configured neighbors' IP address, *not* the 224.0.0.5 multicast address.

During link failure, in both cases (Xorp and Quagga/Cisco), the adjacencies across the failed link are lost as expected.  Host routes are added (Xorp and Quagga) to the linux/kernel routing table to 'route around' the failures.

During link re-establish, in Quagga/Cisco, the multicast packets to 224.0.0.5 are again heard over the re-established link and the SPF routers at both ends re-establish their adjacency.  Once their adjacency is up again and OSPF converges, the host route in the linux/kernel routing table is removed.

During link re-establish in Xorp, the Xorp routers continue to send directed HELLO packets to their established neighbors but do not send them to all configured neighbors.  In other words, once the neighbor is lost, it seems Xorp stops sending the directed HELLO packets to this neighbor.  Once the link to the neighbor is back up, Xorp is still not sending the HELLO packets so the adjacency is never reestablished.  This leaves us in the DOWN state and the host routes still in the linux/kernel routing table.

    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459

-----Original Message-----
From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Vincent, Michael - 0665 - MITLL
Sent: Monday, June 21, 2010 7:37 AM
To: Ben Greear
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

> If it was OSPF, then I guess the code should be changed
> to remove the route, perhaps when it starts receiving
> broadcast pkts from the peer again?

That sounds right.

To 'resolve' the issue, we exit xorpsh and at the linux command line, issue:

for i in `route -n | grep 255.255.255.255 | awk '{print $1}'`; do route del ${i}; done

This removes all the host routes that OSPF added.  There are no host routes (mask of 255.255.255.255) in the linux kernel routing table by default.  The host routes that are added are related to those routes in Xorp OSPF configuration.

> Can you confirm that the problem happens on rejoin of the
> networks and not on link 1-3 failure?  I had asked for
> 'show neighbor' on link failure, and if that was your second
> set of dumps, then the problem appears to already exist before you
> ever get to the rejoin phase.

As the link fails, the host routes are added and OSPF peers drop.  This behavior is expected.  When we bring the link back up, OSPF does not re-establish adjacencies (your previous statement regarding "remove route [...] when it starts receiving broadcast pkts from the peer [...]") and thus the host route is not removed.  With the host route not removed, the 'neighbor' looks multiple hops away and thus not adjacent so no OSPF peering.  That's the catch-22 we eluded to earlier.

The 'show' outputs are from 1) steady state, 2) after the link is failed, 3) after the link is re-established.  Note 2) and 3) outputs are very similar as OSPF goes into the expected fail state during/after link failure.  We don't expect the results from 3) as after link recovery, we would expect the OSPF 'show' output to be similar to 1) steady state.

    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459

-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 4:36 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 12:42 PM, Vincent, Michael - 0665 - MITLL wrote:
>> So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
>> If so, that seems wrong, but maybe I just don't understand point to multi-point OSPF configs...
>
> Agreed.  Hence our dilemma.

So, if you remove a route on 3 (pointing towards 1 via router 5), it works?

What added the route to begin with..OSPF?

If it was OSPF, then I guess the code should be changed
to remove the route, perhaps when it starts receiving
broadcast pkts from the peer again?

Can you confirm that the problem happens on rejoin of the
networks and not on link 1-3 failure?  I had asked for
'show neighbor' on link failure, and if that was your second
set of dumps, then the problem appears to already exist before you
ever get to the rejoin phase.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
Xorp-users mailing list
Xorp-users at xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users