how are backups implemented?

Ratul Mahajan ratul at cs.washington.edu
Thu Sep 20 23:39:15 UTC 2001



let me repeat my question, this time more clearly. we, at uw, are
analyzing bgp tables for possible errors (misconfigurations). one of the
strange things (question 3 below) we are observing is the following.

a prefix 10.10.0.0/16 (for instance) is announced by AS X. sometimes, some
of its more-specifics (like 10.10.1.0/24, 10.10.56.0/24 ....) would appear
for a short time (for example, 4 hours) and then disappear again.  
furthermore, these more-specifics would have an origin AS Y (Y != X). 

i am curious if this behavior can be caused by some sort of backup
arrangements i don't understand, or some router/administrator mess-up. 
clues?

	thanks,
	-- ratul

On Thu, 20 Sep 2001, Ratul Mahajan wrote:

> 
> 
> [posting this message after having looked for answers elsewhere including
> the archives, but found no satisfactory answers]
> 
> i wanted to ask the operations community about how backups are typically
> implemented. i am more interested in backup implementations, in which a
> failure would expose a different origin AS (this would exclude prepending
> based backups).
> 
> 1. when a network is multihomed, and one of the links fails, would you
> expect a smooth transition (as seen in the bgp tables of a remote AS) from
> one origin AS to another (modulo convergence effects)?
> 
> 2. can a failure (anywhere in the network) ever expose another origin AS
> for some AS's while it stays the same for some?  i guess it can, when the
> network is being persistently announced from both origins, and under
> normal scenario one origin could be hidden from some AS's. would this also
> hold for a routing table as rich as routeviews?
> 
> 3. can a failure ever cause more-specifics with a different (from the
> origin of the less-specific) origin AS to appear (again, as seen from a
> remote AS)? this might depend on how backups are implemented - so what i
> am asking is, is this a common/possible case?
> 
> 
> 	thanks,
> 	-- ratul
> 
> 





More information about the NANOG mailing list