AGIS Route Flaps Interrupting its Peering?
Rebecca L. Nitzan
nitzan at es.net
Fri Jul 5 19:09:44 UTC 1996
Peter et al:
We too have had nothing but trouble with the netedge boxes
(to mae-east and mae-west). They are particularly insidious
when they are "kind of working". A couple years ago, when traffic
loads were lower, they seemed to perform well. Does anyone know if
MFS has plans to address this problem?
Rebecca L. Nitzan Lawrence Berkeley National Lab
Network Engineering Services Group 1 Cyclotron Rd, 50A/3101 MS 50C
ESnet - Energy Sciences Network Berkeley, CA. 94720
phone: 510-486-6468 fax: 510-486-4300 nitzan at es.net
>Here's some background:
>AGIS's router is not colocated at the MAE parking garage, but is in fact
>colocated at WorldCom in downtown Washington DC. Our bits get from there to
>the MAE via a DS3, and that DS3 is terminated at each end with a device
>called a NetEdge, which does the FDDI to DS3 ATM conversion.
>These NetEdges seem to have three different possible operating states:
>completely working (which doesn't happen often enough); broken (often, right
>out of the box); and kind of working (which happens all too often). This
>third operating state results in some very interesting, possibly misleading,
>and sometimes damaging behavior. It looks quite similar to the kind of
>behavior you get when you change the MAC layer device but keep the same ip
>address at either of the MAE's: ARP caches get inconsistent, and BGP
>sessions with other routers flop around, leading to routes getting flap
>dampened by those running the appropriate code.
>Here's what happened:
>AGIS's connection to MAE-East experienced one of these kind-of-working
>problems which resulted in the erratic behavior above. Digex customers
>wishing to reach AGIS customers called the Digex NOC, and the posting which
>started this all was made to the Digex internal news group. Similarly, AGIS
>customers had problems, and we worked with MFS to get the problem resolved
>(they must have a warehouse full of swapped-out NetEdges at this point).
>In the interval, a short-on-facts bozo spit into the wind and got us and
>Digex wet. I'm in private correspondence with Ed Kern to postmortem the
>At 10:25 AM 7/5/96 -0400, Ed Kern wrote:
>>> 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.
>>Went into this in the last message...Digex will try and be more
>>proactive with pointing out Agis flapping prefixes in the future.
>>> 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.
>>> > 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.
>>What I was referring to was the internal circulation here...which I was
>>under the impression got to external customers....now im not so
>>The internal report was flawed because it relied to much on source
>>routes and came to some bad conclusions on the internal state of agis.
>>> My key point is that nothing of interest happened. This was a
>>> non-issue until the misinformation was blasted around the Internet
>>> technical universe.
>>I would argue that the external message that got sent around was
>>misinformation...It was correct information from what the people
>>could see at the time it was released...(lots of dampened prefixes and
>>a down peer)..
>Peter Kline Senior Network Engineer| 313-730-5151
>AGIS - Internet Backbone Services | _Lucem Diffundo_
>Post-Traumatic Success Disorder+ |
>You can pretend to care, but you can't pretend to be there.
More information about the NANOG