This is the follow-up of last Friday's incident, by RIPE NCC.
In my opinion, RIPE NCC did a good job in this incident. They identified and stopped the problem within 30 minutes!
The problem would be easier to be identified if it caused disconnection on direct peers immediately. However, in this incident, only some and indirect BGP routers kept reseting peers. If they did not deploy Remote Route Collector (RRC) to monitor BGP at remote Internet Exchanges (IX) sites, I believe it would cost us much more time to know this is not day-to-day general BGP incident.
The report itself provides us so many information to be dug further. I need more time to digest!
[Original Post]
RIPE NCC and Duke University BGP Experiment — RIPE Labs
---
Wednesday, September 1, 2010
Incident details of last Friday, by RIPE NCC
Do you like this post? You really should consider Subscribing by Email!
Tweet
Subscribe to:
Post Comments (Atom)
Popular Posts
-
CCNA Exploration 4.0, Semester 4, "Dual Stack IPv6 and IPv4 configuration " Packet Tracer 5.0 practice file (CNA-04-006). ... -
I created this practice to test the Packet Tracer 5.3 features of BGP. -
We hear a lot of directions when we are talking about Data Center technologies: Northbound, Southbound, and even Eastbound/Westbound. What d... -
Fire-like Kapok blossoms in Taipei City, Taiwan To show the reserved VLAN numbers on both IOS and NX-OS, the common command is: sho... -
One working switch port on my Cisco Catalyst 2950 suddenly went down by itself! Of course, my phone rang when I was having dinner, and the...
No comments:
Post a Comment
Tip: you can also anonymously comment here.