- NANOG - lists.nanog.org

re: AGIS Route Flaps Interrupting its Peering?
by Ed Kern 05 Jul '96

05 Jul '96

> > 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. I agree.. > > 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 sure... 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).. Ed

1 0

re: AGIS Route Flaps Interrupting its Peering?
by Sean Doran 05 Jul '96

05 Jul '96

| 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. Let me reiterate the point that propagating third-party next-hops in the absence of guaranteed fate-sharing is EVIL, or at least very very risky. My opinion is probably at one pole of the spectrum of ideas about NAPs and MAEs, however it's essentially this: do not propagate other people's next-hops at all to your NAP/MAE peers, either using next-hop-self (or the equivalent) or announcing only those prefixes for which you have yourself as a next-hop. Moreover, one should be very cagey about accepting third-party next-hops from one's peers, and either refuse routes with such next-hops, or (with permission only), rewrite the next-hops in question, unless there is a very good reason to do otherwise. On that point, and with respect to "neighbor foo next-hop-self" at an exchange-point, one has to remember that one will be doing multiple hops across the same medium, which is an inefficient way of making use of both one's (or maybe everyone's, depending on the particular fabric) exchange-point bandwidth, and also one's router capacity. One may, given careful thinking, decide to accept and/or propagate third-party next-hops, if this is an issue. However, this should not be the default behaviour at any exchange-point, because the AGIS/DIGEX disconnectivity is a well-known and formerly oft-seen problem. Finally, there is wording in some bilaterals floating out there with respect to third-party transit at exchange points, which may push towards one pole or the other of opinions on third-party next-hops on non-fate-shared (and often *weird*) LISes. On another front, *weird* MAE and NAP setups have caused so much trouble that I sometimes wonder when the next time I get to say "I told you so" about multi-fabric-bridging-from-hell will be, and how bad it will hurt. Sean.

2 1

re: AGIS Route Flaps Interrupting its Peering?
by Ed Kern 05 Jul '96

05 Jul '96

Depends on which report your talking about...there were two... one that was digex internal and the one gordon sent around... The digex internal one did have a number of flaws and many conclusions that were plain false. The one gordon sent around about having things unreachable inside agis...well thats true...at the time we were having lots of problems with unstable prefixes from agis....as it turns out this may have been a netedge problem with the agis side...(no fault of agis at all) While agis keeps saying that we never contacted them about this problem thats true...We dont get proactive with other providers that have flapping problems..(and that at the time was all that our noc thought it was) Technical problem now fixed...things are back to relative abnormal. Any problems with that Kent? Ed PS. Is it just me or does gordon remind you of fire marshal bill...."Hey letme show ya something" POOF - ---------- Forwarded message ---------- Date: Thu, 4 Jul 1996 14:30:32 -0400 (EDT) From: Mark Kent <mark(a)agisgate.agis.net> To: agislist(a)interstice.com, inet-access(a)earth.com, nanog(a)merit.edu Subject: re: AGIS Route Flaps Interrupting its Peering? Regarding an internal Digex report of AGIS instability, Gordon Cook asks of an inappropriate audience: >> does anyone know what happened? 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. However, I'm sure that Kern didn't think that he would have to share his findings with nanog, inet-access, and agislist... - -mark ------- end -------

1 0

Re: Internet access and telco usage patterns
by Eric Woodward 05 Jul '96

05 Jul '96

At 05:36 PM 7/4/96 -0700, Michael Dillon wrote: >> > Has anybody looked at the practicality of installing modem pools in each >> > telco switch location to grab the dialup user's traffic at the IP level >> > and then route it to their ISP of choice for authentication and further >> > routing. In other words, an ISP wouldn't buy phone lines, modems and >> > terminal servers, they would buy IP access ports. > >I now find that BC-Tel is offering this service in parts of British >Columbia. BC-Tel is half owned by GTE. Michael, Also of possible interest here is that Westel, another telco in British Columbia started offering this service early 3rd quarter of last year (with Livingston Portmasters, ISP managed RADIUS authentication, and its own Internet connection) which pressured to BCTel to offer a similar service. Eric Woodward. ejw(a)wedirect.ca.

1 0

Internet access and telco usage patterns
by Michael Dillon 05 Jul '96

05 Jul '96

There is an interesting column in PC Mag http://www.pcmag.com/issues/1513/pcmg0017.htm regarding "Will the Internet Crash" but Machrone understands the technology better than to do a chicken little imitation. Anyway, he has an anecdote about what PC Mag's BBS did to telco usage patterns with about 100 dialup lines in use nationally. I know that Bell Canada in the toronto area of Canada and BC Tel in Vancouver have also run into problems caused by Internet dialup usage patterns that lead BC-Tel to drop selling Centrex to ISP's and Bell Canada to attempt putting ISP's into a higher tariff category. I suppose other telcos are running into similar capacity problems. Anyway, since some of the core providers in North America are telcos (Sprint, MCI) and since all the other ones work rather closely with the telcos for obvious reasons, I have a question. Has anybody looked at the practicality of installing modem pools in each telco switch location to grab the dialup user's traffic at the IP level and then route it to their ISP of choice for authentication and further routing. In other words, an ISP wouldn't buy phone lines, modems and terminal servers, they would buy IP access ports. I have heard of something like this (I think) going on in Britain where Demon Internet services has Energis providing their dialin lines via something called the Virtual POP in which Demon has no equipment located outside their NOC and has the ability to switch capacity from location to location as load patterns change. Of course, this is probably not working at the IP level but simply dealing with routing of digitized switched audio calls. Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com

4 4

re: AGIS Route Flaps Interrupting its Peering?
by Mark Kent 04 Jul '96

04 Jul '96

Regarding an internal Digex report of AGIS instability, Gordon Cook asks of an inappropriate audience: >> does anyone know what happened? 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. However, I'm sure that Kern didn't think that he would have to share his findings with nanog, inet-access, and agislist... -mark

2 1

AGIS Route Flaps Interrupting its Peering?
by Gordon Cook 04 Jul '96

04 Jul '96

I received the following this evening: From: help(a)digex.net (DIGEX Help Desk - System Status) Newsgroups: digex.status Subject: System Status Message 1149 (6:25 PM, Wed Jul 3 1996) [...] o We have also received reports of a lack of connectivity to certain web sites. The reason for these connectivity problems is that routers controlled by Apex Global Information Services (AGIS) are attempting to exchange routing data with DIGEX routers too often, and our routers have stopped listening to their routers. Other major Internet Service Providers are also experiencing these effects. DIGEX has no control over this situation, and therefore, we have no ETR. Connectivity will resume as soon as the AGIS routers stop flooding DIGEX routers with route updates. does anyone know what happened? ********************************************************************** The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200 (609) 882-2572 phone and fax Corporate $350 Internet: cook(a)cookreport.com Corporate Site Lic. $650 http://pobox.com/cook/ for new report: "Tracking Internet Infrastructure" ***********************************************************************

1 0

Re: hostname anecdotes
by salo＠msc.edu 03 Jul '96

03 Jul '96

> From: Alan Hannan <alan(a)gi.net> > Subject: hostname anecdotes > To: nanog(a)merit.edu > Date: Tue, 2 Jul 1996 21:51:32 -0500 (CDT) > > I'm not certain that the hostname anecdotes are terribly relevant > to the operation of north american networks. > > Perhaps the discussion could be more well suited in big internet? It might be useful for NANOG to discuss what involvement NANOG and ISPs ought to have with these schemes. o Should, for example, NANOG agree that ISPs ought not provide secondary name service for this sort of activity? o Should NANOG agree that some sorts of domain name speculation are good grounds to terminate a customer? o Should NANOG decide that some other organization ought to address these issues? (What ever happen to FARNET?) - ISOC? - IETF? - The courts? - The Internic? o Should NANOG stick to purely technical issues? -tjs

1 0

hostname anecdotes
by Alan Hannan 03 Jul '96

03 Jul '96

I'm not certain that the hostname anecdotes are terribly relevant to the operation of north american networks. Perhaps the discussion could be more well suited in big internet? -alan

1 0

RE: Hostname Scam
by Regis Donovan 02 Jul '96

02 Jul '96

edfang(a)visi.net sez, wrt the visit.<state>.com "enforcement": >> I just can't wait to here of a suit about visit.netscape.com being an infringing trade/service mark netscape is a state? ut oh. i'd better start reading the papers again... "but your honor! the host was only CNAME'd to visit!" --regis

1 0