[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