-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting, given that TTNet sits atop this ranking: https://nssg.trendmicro.com/nrs/reports/rank.php?page=1 I wonder if this is somehow related? ;-) - - ferg - -- Sue Joiner <smj@merit.edu> wrote: Forwarding for Mohit Lad and Jonathan Park. -sue Sue Joiner Merit Network - -------- Original Message -------- Subject: Unstable BGP Peerings? Date: Sun, 13 Jan 2008 17:49:44 +0000 From: ParkJonathan <j13park@hotmail.com> To: <nanog@merit.edu> CC: <smj@merit.edu>, <mohit@cs.ucla.edu> During our recent study on BGP routing instability, we found cases where lots of routes changed from one subpath to another subpath, repeating this kind of behavior over a few months . We do not know the cause of this repeated instability, but suspect the BGP peering between routers in two AS was unstable or had some problems and this caused routing changes seen by many observation points. Specifically, the peerings in question are 174 (Cogent) and 9121 (TTNet) 3257 (Tiscali) and 9121 (TTNet) 9304 (Hutchison) and 15412 (Flag Telecom) 1273 (Cable&Wireless) 4651 (Thai Gateway) 6762 (Seabone) and 7473 (Singapore Telecom) For details of events and timings, please find a short summary on the link below. http://irl.cs.ucla.edu/pca/active-links.html We would really appreciate if somebody from the ISPs involved in this activity (or anybody who might know what happened) would contact us and throw some light on the reasons for this behavior. Thanks Mohit Lad, Jonathan Park UCLA -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHiqUVq1pz9mNUZTMRAkVEAJ0Y4u5AYr/CiG65e3e+Y88HCQJGjQCg723O P17FTAUFOw3Ms1KQW6v2+44= =013x -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
On Jan 13, 2008 6:56 PM, Paul Ferguson <fergdawg@netzero.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Interesting, given that TTNet sits atop this ranking:
https://nssg.trendmicro.com/nrs/reports/rank.php?page=1
I wonder if this is somehow related? ;-)
probably not... but only based on as much a guess on my part as paul's I suspect, a little more below.
- -- Sue Joiner <smj@merit.edu> wrote:
Forwarding for Mohit Lad and Jonathan Park.
-sue
Sue Joiner Merit Network
- -------- Original Message -------- Subject: Unstable BGP Peerings? Date: Sun, 13 Jan 2008 17:49:44 +0000 From: ParkJonathan <j13park@hotmail.com> To: <nanog@merit.edu> CC: <smj@merit.edu>, <mohit@cs.ucla.edu>
During our recent study on BGP routing instability, we found cases where lots of routes changed from one subpath to another subpath, repeating this kind of behavior over a few months . We do not know the cause of this repeated instability, but suspect the BGP peering between routers in two AS was unstable or had some problems and this caused routing changes seen by many observation points.
It seems, to me, that from the data you have on the website perhaps this is just oscillation in best-path decision or internal traffic engineering decisions exposed to the outside world? Perhaps (taking the first picture example) 9121 decides partway through a day or month that they want to use cogent more (ratio levelling or cost reasons) so they draw traffic via 174, then after some metric is met (cost or ratio) they spread the load across their other transit links? This could easily account for the changes you are showing, right? In point of fact the next few examples also seem to reflect the same behaviour... I suppose this could even be automated with one of those fancy-dan InterNap route-optimizer boxes, right? I'd be curious to know if this makes sense to: 1) other folks on-list, 2) the researchers. -Chris
Specifically, the peerings in question are
174 (Cogent) and 9121 (TTNet) 3257 (Tiscali) and 9121 (TTNet) 9304 (Hutchison) and 15412 (Flag Telecom) 1273 (Cable&Wireless) 4651 (Thai Gateway) 6762 (Seabone) and 7473 (Singapore Telecom)
For details of events and timings, please find a short summary on the link below. http://irl.cs.ucla.edu/pca/active-links.html
We would really appreciate if somebody from the ISPs involved in this activity (or anybody who might know what happened) would contact us and throw some light on the reasons for this behavior.
Thanks
Mohit Lad, Jonathan Park UCLA
-----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017)
wj8DBQFHiqUVq1pz9mNUZTMRAkVEAJ0Y4u5AYr/CiG65e3e+Y88HCQJGjQCg723O P17FTAUFOw3Ms1KQW6v2+44= =013x -----END PGP SIGNATURE-----
-- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
participants (2)
-
Christopher Morrow
-
Paul Ferguson