[Xorp-hackers] OSPFv2 P2P Links

Tue Aug 28 11:02:08 PDT 2007

Kalahasti , Erlend,

Feel free to submit patches.

Adam

On 8/28/07, Bharadwaj Kalahasti <b_kalahasti at yahoo.com> wrote:
> 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
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>