[Xorp-hackers] OSPFv2 P2P Links

Atanu Ghosh atanu at ICSI.Berkeley.EDU
Thu Sep 13 15:18:28 PDT 2007


Hi,

A slightly modified fix is now in cvs.

Revision  Changes                             Path
1.282     +7 -3;  commitid: 39d46e9b4737ea6;  xorp/ospf/peer.cc

  Atanu.

>>>>> "Erlend" == Erlend Knutsen <Erlend.Knutsen at applica.no> writes:

    Erlend> Hi all, Added: "_peer.update_router_links()" to the end of
    Erlend> the method "Neighbour<A>::tear_down_state()"

    Erlend> This seem to do the work for p2p!!  The p2p link is now
    Erlend> correclty deleted from the LSA update, while the stub is
    Erlend> kept.  When the neighbour comes up again the p2p links
    Erlend> appear again in the LSA update.

    Erlend> However we have only tested this once, with 3 routers and 1
    Erlend> router at the edge going down/up.

    Erlend> Thanks Atanu!

    Erlend> Erlend



    Erlend> -----Original Message----- From: atanu at icir.org on behalf of
    Erlend> Atanu Ghosh Sent: on 29-aug-07 04:29 To: Erlend Knutsen Cc:
    Erlend> Bharadwaj Kalahasti; xorp-hackers at icir.org Subject: Re:
    Erlend> [Xorp-hackers] OSPFv2 P2P Links
 
    Erlend> Hi,

    Erlend> Adding a call to "update_router_links()" at the end of the
    Erlend> method "Neighbour<A>::tear_down_state()", should solve your
    Erlend> problem, let me know.

    Erlend>       Atanu.

>>>>> "Erlend" == Erlend Knutsen <Erlend.Knutsen at applica.no> writes:

    Erlend> Kalahasti, I probably will be able to test the code.  I run
    Erlend> 3 instances of OSPF over 3 vmware machines (debian Etch over
    Erlend> windows VMWare player).  I may also be able to extend the
    Erlend> configuration with more machines and different topologies.
    Erlend> However, I have never testet NBMA and P2MP before, but I
    Erlend> guess I only need to make some small adjustments in the
    Erlend> config.boot file.

    Erlend> Regards, Erlend
    Erlend> _________________________________________________________________

    Erlend> Fra: Bharadwaj Kalahasti [mailto:b_kalahasti at yahoo.com]
    Erlend> Sendt: ti 28-aug-07 19:50 Til: Bharadwaj Kalahasti;
    Erlend> xorp-hackers at icir.org; Erlend Knutsen Emne: Re: OSPFv2 P2P
    Erlend> Links

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


    >>>>>>>>>>>>>>
    Erlend> Thank you! This pretty much helped clearing up how OSPF p2p
    Erlend> is supposed to work.  To answer your question: XORP only
    Erlend> seem to support p2p when configurig the neighbours
    Erlend> statically, so YES! XORP supports static Neighbours.  When
    Erlend> running OSPF p2p over Ethernet the Router LSA (catched from
    Erlend> tcpdump) reports a p2p link and a stub link to the Ethernet
    Erlend> subnet between the routers. I can managed to multicast an
    Erlend> LSA update as a result of the Hello inactivity timer for the
    Erlend> p2p link. However the p2p link that went down is still
    Erlend> reported. I am looking further into the code now to try to
    Erlend> ensure that the "downed" p2p link is removed before a new
    Erlend> LSA is sent.  Regards, Erlend --- Bharadwaj Kalahasti
    Erlend> <b_kalahasti at yahoo.com> wrote:
    >>> Erlend, Generally speaking, one set of implementations for
    >>> non-broadcast
    Erlend> neighbors such
    >>> as those of P2MP, P2P and NBMA seems to be to configure the
    >>> neighbors
    Erlend> as 'STATIC'
    >>> neighbors.  For P2P Neighbors, the Hellos are multicast. The
    >>> Intf state for
    Erlend> the OSPF
    >>> interface should be P2P after the IP interface comes up. And the
    >>> Nbr state
    Erlend> should finally
    >>> be Full on the local end assuming that the Router ID of the
    >>> neighbor is
    Erlend> seen by the
    >>> local router.
    >>> 
    >>> These are the steps that should happen: -- So assuming that your
    >>> neighbor has gone Down at the remote end
    Erlend> for the reasons
    >>> - Admin down, Link transmission failure but Link is still Up
    >>> etc, then
    Erlend> this should
    >>> cause Inactivity Timer to be fired on the local end.  -- Expiry
    >>> of this timer should cause a new Router LSA to be
    Erlend> generated and
    >>> area-flooded but without the Neighbor's Router ID in its
    >>> Neighbor
    Erlend> list (since it
    >>> failed to have bi-directional communication).  -- Since the new
    >>> Router-LSA would be different in its LS Header from
    Erlend> the previous
    >>> one for the same local router's Router ID, that should cause its
    Erlend> installation on
    >>> all of the area's routers and kick off a new SPF run once the
    Erlend> installation of the
    >>> Router-LSA in the LSDB is done.  -- The SPF run should take care
    >>> of deleting the P2P host route in
    Erlend> the Routing
    >>> Table.
    >>> 
    >>> 
    >>> I think the implementation of a P2P Nbr is upto interpretation.
    Erlend> The catch here
    >>> is that a static configuration of the Nbr would mean that the
    >>> Hello
    Erlend> packet can always
    >>> have the Neighbor router listed in it indicating bi-directional
    Erlend> communication and
    >>> full adjacency though the link may actually be down (if knowing
    >>> the
    Erlend> existence of a
    >>> Neighbor implies including it in the sent Hello). The other way
    >>> to
    Erlend> interpret the
    >>> RFC is that configuration is good enough to know its existence
    >>> but its
    Erlend> 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
    Erlend> 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
    Erlend> 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
    Erlend> 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
    Erlend> MaxAge).
    >>> 
    >>> 
    >>> 
    >>> I have tested this in a very simple scenario with 3 routers
    >>> R1-R2-R3
    Erlend> 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
    Erlend> each
    >>> other.
    >>> 
    >>> However, when the same routers run with Broadcast links the
    >>> routes
    Erlend> are
    >>>  correctly removed when one of the other routers goes down.
    >>> 
    >>> 
    >>> 
    >>> I can see from the source code and debug output that the
    >>> difference
    Erlend> 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
    Erlend> 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
    Erlend> state,
    >>>  but to me, it does not seem sane that the links to/via a router
    >>> that
    Erlend> 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
    Erlend> in
    >>> this.
    >>> 
    >>> 
    >>> 
    >>> I can send debug logs and config setup if necessary.
    >>> 
    >>> Thanks in advance!
    >>> 
    >>> 
    >>> 
    >>> Regards,
    >>> 
    >>> Erlend
    >>> 
    >>> 
    >>> 
    >>> 
    Erlend> ______________________________________________________________________
    Erlend> ______________
    >>> Luggage? GPS? Comic books?  Check out fitting gifts for grads at
    >>> Yahoo! Search
    >>> 
    Erlend> http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
    >>>

    Erlend> ______________________________________________________________________
    Erlend> ______________ Yahoo! oneSearch: Finally, mobile search that
    Erlend> gives answers, not web links.
    Erlend> http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
    Erlend> _______________________________________________ Xorp-hackers
    Erlend> mailing list Xorp-hackers at icir.org
    Erlend> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



More information about the Xorp-hackers mailing list