[Xorp-hackers] OSPFv2 P2P Links
Erlend Knutsen
Erlend.Knutsen at applica.no
Wed Aug 29 01:43:50 PDT 2007
Hi all,
Added: "_peer.update_router_links()" to the end of the method
"Neighbour<A>::tear_down_state()"
This seem to do the work for p2p!!
The p2p link is now correclty deleted from the LSA update, while the stub is kept.
When the neighbour comes up again the p2p links appear again in the LSA update.
However we have only tested this once, with 3 routers and 1 router at the edge going down/up.
Thanks Atanu!
Erlend
-----Original Message-----
From: atanu at icir.org on behalf of Atanu Ghosh
Sent: on 29-aug-07 04:29
To: Erlend Knutsen
Cc: Bharadwaj Kalahasti; xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] OSPFv2 P2P Links
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070829/2131d03d/attachment-0001.html
More information about the Xorp-hackers
mailing list