[Xorp-hackers] OSPFv2 p2p links
Erlend Knutsen
Erlend.Knutsen at applica.no
Mon Aug 27 10:34:46 PDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070827/395f84c4/attachment.html
More information about the Xorp-hackers
mailing list