re: AGIS Route Flaps Interrupting its Peering?
So, Mark, you're saying that your routers did not have a problem? If your routers did have a problem, did it affect other providers?
Right. Our routers did not create any problems that we are aware of. There was a minor problem at mae-east that appears to have been caused by the MFS NetEdge. Several IP addresses in 192.41.177.0/24 became unreachable from our router at 192.41.177.145, but not our router at 192.41.177.170. We contacted MFS about the problem and they rebooted the NetEdge in the middle of last night. Things are back to normal. Since ANS seems to be passing our interface address as the next-hop directly to some nets (e.g., Digex and Advantis), the failure as I described above did lead to a loss of connectivity between AGIS and at least Digex and Advantis. Pending the solution of the MFS problem, it would have been possible to work around the issue if the affected nets had routed _through_ their transit provider.
If it did affect other providers, were you available to resolve the problems in a timely manner?
I do not believe that we affected other providers in the manner implied by the [internal] Digex report. We had three bgp sessions down. We could not ping those neighbours. MAE-East transit customers of other networks could have been affected as I described above, if they were not protected by "next-hop-self" from their transit provider. One key point is that we have not received any complaints or reports of any sort concerning any perceived issues at mae-east from any mae-east peers. Digex made no attempt to contact us. We were already working with Advantis on the unreachable issue above, but the first we heard of the "AGIS attacks mae-east" report was when a Digex customer sent us a report similar to that forwarded to all of you by Cook.
] Gordon Cook asks of an inappropriate audience:
I'm not certain it's innapropriate. If someone's trying to play with us, and causing us problems, then I would like to know about it.
An appropriate audience would have been the AGIS noc and the Digex noc. I think the Cook approach was inappropriate because the issue was purely between Digex and AGIS until Cook distributed it to the three widespread mailing lists.
] The Digex report is seriously flawed. Ed Kern of Digex has told us ] that he is looking into how the conclusions in that report were reached.
How is the report flawed?
I see that Ed Kern has already replied indicating that the report was indeed flawed. I don't think that there is anything to be gained by going into further detail.
] However, I'm sure that Kern didn't think that he would have to share ] his findings with nanog, inet-access, and agislist...
Could you share your findings? If there was a problem, I think we'd all prefer an explanation rather than a finger shaking for having interest.
My key point is that nothing of interest happened. This was a non-issue until the misinformation was blasted around the Internet technical universe. -mark
On Fri, 5 Jul 1996, Mark Kent wrote:
An appropriate audience would have been the AGIS noc and the Digex noc.
Wrong! It's an operations issue and it SHOULD be on NANOG or a global outages list if such should some day exist.
Could you share your findings? If there was a problem, I think we'd all prefer an explanation rather than a finger shaking for having interest.
My key point is that nothing of interest happened.
There are hundreds of providers learning how to deal with multihoming and peering. Anything like this is of interest because people need to know how to recognize and solve problems to keep the global network running.
This was a non-issue until the misinformation was blasted around the Internet technical universe.
Yep, no doubt about it. If you create the environment for misinformation to spread then it WILL spread. However, you can fix this. If timely an accurate outage information is available from everybody then misinformation won't spread and where it does manage to propogate it will merely be static. Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael@memra.com
participants (2)
-
Mark Kent
-
Michael Dillon