|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Katrina Network Damage Report
randy, all, On Sun, Sep 11, 2005 at 04:11:50AM +0700, Randy Bush wrote: > Re: From: Todd Underwood <[email protected]> > but, the geolocation stuff is cool. could it have told us, in > an operationally useful/timely manner, that at&t had moved from > new jersey to spain the other day? yes, within about 30s. but randy, you should know better than to think that requires any geolocation. 12/8 didn't move to spain, it moved to bolivia (AS26210). and since '12956 26210' was a novel origination pattern for 12/8 (and the other /8s involved), no geolocation required. simple analysis of bgp updates tells the story. anyone who can process updates from a large peerset and compare those to recent routing history or routing policy can report that as an anomaly. > > 1) the multi-hop issue is bogus, i believe. i'll ignore it > > unless randy chooses to say what he means here. > > maybe use <http://nanog.org/mtg-0210/wang.html>. some siteseer > entries seem a bit mangled, but [0] seems ok. i'm familiar with the presentation, but thanks for citing it. as you know jim cowie, andy ogielski and bj premore did some related work for renesys including http://www.renesys.com/resource_library/renesys-spie2002.pdf and http://www.renesys.com/resource_library/Renesys-NANOG23.pdf (linked from: http://www.nanog.org/mtg-0110/global.html) these are all interesting work regarding whether bgp session resets during large-scale worms are the cause of monitoring artifacts or whether those worms cause instability themselves. there are differences of opinion about the results, but it's all interesting and worth reading. good stuff. but off topic here, i believe. randy: why do you think resets of multi-hop sessions has anything to do with these results reporting individual prefix outages in the Katrina-affected regions? sorry for being slow, but i'm just not seeing any connection. maybe someone smarter than me can spell it out in small words for me. > > 2) yes, indeed. we chose only to comment on changes in the > > routing table as changes in the routing table. inferences > > about unreachability of end interfaces is left entirely to > > the reader > > but reachability is what it's all about. the folk here are > paid to deliver packets. the control plane (routing) is one of > the tools we use to achieve that end. yes, of course. prefixes with no entry in a routing table are not reachable from that device. what i am saying is that we are not implying that the end interface went down or that the point to point link between the end user and their provider went down (although both of these seem likely). we are saying that there was not a routed path from a consensus of our peers to that prefix. so that is definitely unreachable from that consensus of those peers. > Re: From: George William Herbert <[email protected]> > > Looking at the routing tables you see failures. If a prefix > > goes away completely and utterly, and is truly unreachable, > > then anyone trying to see it is going to see an outage. > > not if a covering or more specific tells us how to get packets > to the destination. but perhaps that's what you mean by a > prefix being unreachable and i am being too picky. i think you may be being picky, but i've already admitted that i'm having trouble following your points. :-) we can look in more detail at coverings and more specifics. but the depressing fact of the matter is that there are very few covering prefixes for many of these that are effective (which i define to mean: have the same origination pattern). my claim, and anyone with routeviews/ripe data and a few hundred MB of space can verify this, is that these prefixes are really and truly outaged. not reachable from pretty much anywhere on the Internet. i think that at the higher level, this is probably not as controversial as it seems to be in nanog so far. :-) t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence [email protected] www.renesys.com
|