[Xorp-hackers] OSPFv2 P2P Links
Atanu Ghosh
atanu at ICSI.Berkeley.EDU
Tue Aug 28 19:29:47 PDT 2007
Hi,
Adding a call to "update_router_links()" at the end of the method
"Neighbour<A>::tear_down_state()", should solve your problem, let me know.
Atanu.
>>>>> "Erlend" == Erlend Knutsen <Erlend.Knutsen at applica.no> writes:
Erlend> Kalahasti,
Erlend> I probably will be able to test the code.
Erlend> I run 3 instances of OSPF over 3 vmware machines (debian Etch
Erlend> over windows VMWare player).
Erlend> I may also be able to extend the configuration with more machines and
Erlend> different topologies.
Erlend> However, I have never testet NBMA and P2MP before,
Erlend> but I guess I only need to make some small adjustments in the
Erlend> config.boot file.
Erlend> Regards,
Erlend> Erlend
Erlend> _________________________________________________________________
Erlend> Fra: Bharadwaj Kalahasti [mailto:b_kalahasti at yahoo.com]
Erlend> Sendt: ti 28-aug-07 19:50
Erlend> Til: Bharadwaj Kalahasti; xorp-hackers at icir.org; Erlend Knutsen
Erlend> Emne: Re: OSPFv2 P2P Links
Erlend> Erlend,
Erlend> You are right. The stub link should remain in the Router-LSA while
Erlend> the Type 1 link
Erlend> should be removed due to non-adjacency with the neighbor.
Erlend> I know of how the changes need to be done. May be you can review
Erlend> them.
Erlend> If I make the same changes for NBMA and P2MP, would you be able to
Erlend> test them for
Erlend> me? I have a single Ubuntu linux loaded DELL PC that does not help
Erlend> much but for a
Erlend> single router instance.
Erlend> Thanks,
Erlend> Kalahasti
>>>>>>>>>>>>>
Erlend> Thank you! This pretty much helped clearing up how OSPF p2p is
Erlend> supposed to work.
Erlend> To answer your question: XORP only seem to support p2p when configurig
Erlend> the
Erlend> neighbours statically, so YES! XORP supports static Neighbours.
Erlend> When running OSPF p2p over Ethernet the Router LSA (catched from
Erlend> tcpdump) reports a
Erlend> p2p link and a stub link to the Ethernet subnet between the routers. I
Erlend> can managed
Erlend> to multicast an LSA update as a result of the Hello inactivity timer
Erlend> for the p2p
Erlend> link. However the p2p link that went down is still reported. I am
Erlend> looking further
Erlend> into the code now to try to ensure that the "downed" p2p link is
Erlend> removed before a
Erlend> new LSA is sent.
Erlend> Regards,
Erlend> Erlend
Erlend> --- Bharadwaj Kalahasti <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> ______________
Erlend> Yahoo! oneSearch: Finally, mobile search
Erlend> that gives answers, not web links.
Erlend> http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
Erlend> _______________________________________________
Erlend> Xorp-hackers mailing list
Erlend> Xorp-hackers at icir.org
Erlend> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
More information about the Xorp-hackers
mailing list