Hi Shivani,
I had a question regarding the nature of the BGP peering sessions of the RRCs. Is there any place I can find accurate information about the way the different RRCs maintain their peering sessions; as in how many of the sessions are multi-hop BGP sessions and how many are direct link sessions etc? I was wondering about this since, there has been a paper (see below) published in 2002 that said that most of the RRCs peering sessions were multi-hop eBGP sessions and as a result the BGP data collected here cannnot be an accurate refelction of what goes on the actual Internet/backbone routers.
The above is an inaccurate summary of our paper. In the paper, we specifically mentioned that we used RRC00's data and all the BGP sessions at RRC00 used multi-hop peering. So what we concluded is that data from multi-hop peerings should be carefully sanitized to remove those BGP updates associated with the instability of the monitoring session (in this case, it was the session instability caused by the worm attack). Lan
"Observation and Analysis of BGP Behavior under Stress", Proceedings of the Second ACM SIGCOMM Internet Measurement Workshop (IMW '02), pp. 183-195, Nov. 2002 Any inputs that I can get regarding this will be very helpful.
Shivani.
In the paper, we specifically mentioned that we used RRC00's data and all the BGP sessions at RRC00 used multi-hop peering. So what we concluded is that data from multi-hop peerings should be carefully sanitized to remove those BGP updates associated with the instability of the monitoring session (in this case, it was the session instability caused by the worm attack).
almost. the session resets were exacerbated by what turn out to be mild effects worm attack. but the root cause seemed to be multi-hop ebgp sessions running on a partiuCular vendor's fragile tcp stack designed for point-to-point bgp peering, not trans- and inter-continental. so if you looked at a session cross-eyed, it reset. the upshot of this was that route-views and ris got the message and deployed physically at many critical peering venues, so they could peer directly as opposed to multi-hop. this has much improved the data. thanks route-views and ris. randy
participants (2)
-
lanwang@memphis.edu
-
Randy Bush