[Xorp-hackers] OSPFv2 P2P Links

Tue Aug 28 10:50:37 PDT 2007

Erlend,
  You are right. The stub link should remain in the Router-LSA while the Type 1 link
should be removed due to non-adjacency with the neighbor.
  I know of how the changes need to be done. May be you can review them. 
  If I make the same changes for NBMA and P2MP, would you be able to test them for
me? I have a single Ubuntu linux loaded DELL PC that does not help much but for a
single router instance.
Thanks,
Kalahasti

>>>>>>>>>>>>
Thank you! This pretty much helped clearing up how OSPF p2p is supposed to work.
To answer your question: XORP only seem to support p2p when configurig the
neighbours statically, so YES! XORP supports static Neighbours.

When running OSPF p2p over Ethernet the Router LSA (catched from tcpdump) reports a
p2p link and a stub link to the Ethernet subnet between the routers. I can managed
to multicast an LSA update as a result of the Hello inactivity timer for the p2p
link. However the p2p link that went down is still reported. I am looking further
into the code now to try to ensure that the "downed" p2p link is removed before a
new LSA is sent.

Regards,
Erlend
--- Bharadwaj Kalahasti <b_kalahasti at yahoo.com> wrote:

> Erlend,
>   Generally speaking, one set of implementations for non-broadcast neighbors such
> as
> those of P2MP, P2P and NBMA seems to be to configure the neighbors as 'STATIC'
> neighbors. 
>   For P2P Neighbors, the Hellos are multicast. The Intf state for the OSPF
> interface
>  should be P2P after the IP interface comes up. And the Nbr state should finally
> be
> Full on the local end assuming that the Router ID of the neighbor is seen by the
> local router. 
> 
>   These are the steps that should happen:
> -- So assuming that your neighbor has gone Down at the remote end for the reasons
> - 
> Admin down, Link transmission failure but Link is still Up etc, then this should
> cause Inactivity Timer to be fired on the local end. 
> -- Expiry of this timer should cause a new Router LSA to be generated and
> area-flooded but without the Neighbor's Router ID in its Neighbor list (since it
> failed to have bi-directional communication). 
> -- Since the new Router-LSA would be different in its LS Header from the previous
> one for the same local router's Router ID, that should cause its installation on
> all
> of the area's routers and kick off a new SPF run once the installation of the
> Router-LSA in the LSDB is done. 
> -- The SPF run should take care of deleting the P2P host route in the Routing
> Table.
> 
>   
>   I think the implementation of a P2P Nbr is upto interpretation. The catch here
> is
> that a static configuration of the Nbr would mean that the Hello packet can always
> have the Neighbor router listed in it indicating bi-directional communication and
> full adjacency though the link may actually be down (if knowing the existence of a
> Neighbor implies including it in the sent Hello). The other way to interpret the
> RFC
> is that configuration is good enough to know its existence but its inclusion in
> the
> Hello is subject to event occurence on the link. 
> 
>   I do not know the OSPFv2 code in XORP but if Static neighbors are not supported
> yet, then may be it is a good idea to support it. 
> 
> Regards,
> Kalahasti
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> 
> Hi all,
> 
>  
> 
> It seems like XORP OSPFv2 does not fully manage to update the routing
> table
> 
> when a neighbor connected through a p2p link goes down, e.g. when an
> xorp 
> 
> OSPFv2 neighbour is stopped. The neighbour state is set correctly to
> down,
> 
> but the routes advertised by/through the neighbour are not removed from
> the 
> 
> rest of the network. The LS DB is identical before and after the
> neighbour 
> 
> has been stopped (only the age field differs, but is not set to MaxAge).
> 
>  
> 
> I have tested this in a very simple scenario with 3 routers R1-R2-R3 up
> and
> 
> running with p2p links configured over Ethernet. I have for example
> stopped
> 
> ospf on R2 and then observed that R1 and R3 still have routes to each
> other.
> 
> However, when the same routers run with Broadcast links the routes are 
> 
> correctly removed when one of the other routers goes down.
> 
>  
> 
> I can see from the source code and debug output that the difference in 
> 
> handling of the InactivityTimer Event (i.e. Hello timeout) between
> Broadcast
> 
> and p2p links seems to start in the method:
> Neighbour<A>::tear_down_state;
> 
> This method does not do any work for p2p (_peer.adjacency_change
> 
> only works for DR or BDR). I therefore simply tried to add the call:
> 
> _peer.get_area_router()->refresh_router_lsa()
> 
> to the end Neighbour<A>::tear_down_state. This causes a total recompute
> 
> of the routing but the routes from/via the router that has been shut
> down are
> 
> not removed.
> 
>  
> 
> It may be that p2p links should have some kind of special static state, 
> 
> but to me, it does not seem sane that the links to/via a router that has
> 
> gone down are not removed. The RFC 2178 is somewhat diffuse when
> 
> it comes to p2p and Hello timeout. (It may seem somewhat strange
> 
> to run p2p over Ethernet but this is a requirement.)
> 
>  
> 
> Anyway I hope someone can give me some hints on how to work further in
> this.
> 
>  
> 
> I can send debug logs and config setup if necessary.
> 
> Thanks in advance! 
> 
>  
> 
> Regards,
> 
> Erlend
> 
> 
>      
>
____________________________________________________________________________________
> Luggage? GPS? Comic books? 
> Check out fitting gifts for grads at Yahoo! Search
> http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
> 

____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC