[Xorp-cvs] XORP cvs commit: xorp/bgp

[Atanu Ghosh]

CVSROOT:	/usr/local/www/data/cvs
Module name:	xorp
Changes by:	atanu@xorpc.icir.org	2005-06-29 00:52:28 UTC

XORP CVS repository


Modified files:
	bgp           route_table_nhlookup.cc 

Log message:
	On a peering if a route existed with a unique nexthop and a
	replacement route arrived with the same unique nexthop, previously a
	de-registration would be sent to the RIB followed by a registration.
	
	Most importantly there was a window during which the nexthop was not
	resolvable. If the decision process performed a lookup on the peer
	during this window the lookup would have to return that the status of
	this nexthop was known as it had been known previously. Unfortunately
	if the decision process decided that this route was the winner it
	would attempt to get the IGP distance from the next hop resolver which
	did not have an answer. This caused an assert in the decision process,
	by the time a route reaches the decision process its status must be
	known.
	
	The current code no longer does the de-registration first. In the case
	that the nexthops are the same in both routes, re-ordering the
	de-registration/registration means there is no longer a window when
	the status of the nexthop is not known. In the case where the nexthops
	are different it is necessary to defer the de-registration until the
	new nexthop has been resolved.
	
	The problem was triggered by configuring four routers in a clique with
	E-BGP peerings. Then introducing a single route and withdrawing that
	route.
	
	Bug found by: Dario Vieira

Revision  Changes                               Path
1.20      +38 -6;  commitid: 746242c1f0cb7ea6;  xorp/bgp/route_table_nhlookup.cc