- NANOG - lists.nanog.org

Re: E.E. Times?
by Nick Hilliard 13 Jan '97

13 Jan '97

> Has anyone heard of E.E. Times that did a piece on the Internet and blamed > Cisco routers for all the bottlenecks? They quote www.ra.net/statistics and > www.academ.com/nanog as well as Craig Lebowitz and Fred Baker. I have a > locally translated copy but I would be interested in seeing the original. > > It's on their web site if you wanna dig for it. A very sad article... The URL is http://www.techweb.com/se/directlink.cgi?EET19970106S0051. The first paragraph really sets the tone for the rest of the article: : A report by a federally funded networking research group here suggests : that severe Internet congestion might be linked to "routing instability," : wherein heavy traffic emanating from routers bogs down the public network. : The researchers further claim to have turned up evidence that Internet : autonomous systems supplied by the dominant maker of routers, Cisco : Systems Inc., have inherent router flaws that may exacerbate the problem. The comment at the end is pretty good, too: : Cisco routers might have IP-compatibility problems These people ought to stick to roads and bridges. Nick

4 3

RE: withdrawal propagation (was E.E. Times?)
by ccotton＠ttl.pactel.com 13 Jan '97

13 Jan '97

>>> OK, I've read the article, and it's not very good. The author doesn't >>> understand the terminology. ... or the basic technology. Listen to CNET radio's interview with the author (http://www.news.com/Radio/index.html, Monday 1/6/97 edition) about 19+ minutes into the recording. Chase

1 0

Re: withdrawal propagation (was E.E. Times?)
by William Allen Simpson 13 Jan '97

13 Jan '97

> From: randy(a)psg.com (Randy Bush) > > "William Allen Simpson" <wsimpson(a)greendragon.com> > > An implementation that propagates _extra_ withdrawals shouldn't _hide_ > > behind "standards compliant". In fact, I don't think _is_ either > > "valid" or "standards compliant". There is no standard that says "send > > extra BGP withdrawals for routes that you are not currently announcing". > > It was just a bug in the implementation. > > Nice to know you understand the cause well enough to assign blame. Mind > telling us all what it is? > Looking carefully at what I wrote, I do not see anything about "cause", only the validity (and standards compliance) of an implementation that displays this "effect". Obviously, I made the assumption that these effects were the results of an implementation, rather than a fabrication or a figment of Craig's imagination. Such a buggy implementation would receive "blame", and a fix would be expected. Perhaps there is some disagreement as to the existence of the phenomenon? Randy, do you disagree that there are routers: - sending more BGP withdrawals than announcements? - sending BGP withdrawals for routes that they have not announced? - passing along withdrawals from other routers' announcements seen on other interfaces, even though those routes are not announced by this router? That was my understanding of the effect, and Craig's use of the word "extra". If I am in error, please publically correct my understanding in detail, giving all the facts upon which you rely. Also, please give a reference (section and paragraph) where these phenomenon are specified as "valid" in one of our "standards". Thank you. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

withdrawal propagation (was E.E. Times?)
by William Allen Simpson 13 Jan '97

13 Jan '97

> From: Craig Labovitz <labovit(a)merit.edu> > * there are an awful lot of withdraw/announcements out there > * we don't know were they are comming from, and no, it is not Cisco's fault > * some valid, and standards-compliant vendor implementation decisions are > contributing a small fraction of extra withdraws (yes, Cisco is one of > these vendors, but there are probably others) You know, Craig, sometimes you are just too nice. If "we don't know were they are comming from" [sic], you don't know whether it is or is not Cisco's fault. Why bend over backwards to give such public deference? An implementation that propagates _extra_ withdrawals shouldn't _hide_ behind "standards compliant". In fact, I don't think _is_ either "valid" or "standards compliant". There is no standard that says "send extra BGP withdrawals for routes that you are not currently announcing". It was just a bug in the implementation. We _know_ (based on your research and Cisco's admission) that Cisco's have/had this bug. Therefore, it is at least Cisco's "fault". We don't _know_ (no research, no admissions) that anybody else has this problem; so the value of "probably" is more like "possibly". In any case, it "probably" doesn't matter if anybody else has the problem, since Cisco controls 85+% of the backbone market. > * there are differing opinions on how much of a problem all of this extra > withdraws pose for Internet There are always differing opinions about the Internet. Heck, there are differing opinions about whether the Internet is even useful. We are not looking at or talking about opinions, we are looking at operational facts. And the facts indicate that the duplicate withdrawals comprise a large fraction of the BGP traffic, which in turn comprises a large fraction of the backbone router CPU usage. > * even though it is not clear there was/is a significant problem, vendors > (Cisco) have created fixes to limit some of the extraneous routing > information Have these fixes been universally deployed yet? What release? And how did that affect the withdrawals seen in the overall backbone? > * a recently noticed 30-second periodicity to updates tends to suggest a > systematic problem in the infrastructure. What you mean is a systematic problem in the routing code, or maybe even in the BGP specification. Occam's Razor. The "infrastructure" is something else entirely. The number of wires in the routing mesh are not likely to have any effect on the periodicity of the traffic sent over them. > This 30 second periodicity > occurs with both widthraws and announcements (and seems independent of > the extra withdraw problem). Yes, so why are we talking about it in the same breath (paragraph)? Wouldn't it be better to acknowledge it as a separate issue? And how is the research on the source of the problem progressing? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

RE: E.E. Times?
by Chris A. Icide 13 Jan '97

13 Jan '97

Actually, I have to admit, the following was my favorite line, considering the copyright at the end of the article.... Quotes from the article follow: CMP Media's Prinz said his operation uses "Bay Networks' routers, and we have no issues with them. In fact, they don't have such a thing as a withdraw announcement." "Copyright (r) 1997 CMP Media Inc." <------ quote, and not a copyright on this mail. Chris A. Icide Nap.Net

2 1

Re: tcg and cerf.net?
by Scott Bradner 13 Jan '97

13 Jan '97

Comm Week 23/12/96 said that Teleport Communications Group closed a deal to buy CERFnet

2 1

E.E. Times?
by Hank Nussbacher 13 Jan '97

13 Jan '97

Has anyone heard of E.E. Times that did a piece on the Internet and blamed Cisco routers for all the bottlenecks? They quote www.ra.net/statistics and www.academ.com/nanog as well as Craig Lebowitz and Fred Baker. I have a locally translated copy but I would be interested in seeing the original. Thanks, Hank

2 1

Filtering rules
by Hank Nussbacher 12 Jan '97

12 Jan '97

Sprint has publicized its filtering rules in the past. Can anyone who has a filtering rule similiar to Sprint's post it here (as well as Sprint's current rule (I have their 6/96 rules)). Thanks, Hank

4 3

Internic registries
by jordy 12 Jan '97

12 Jan '97

-----BEGIN PGP SIGNED MESSAGE----- I was doing some maintanace on some of my domains a few days back and decided to update my Internic contact information. Low and behold I found that the company field in the whois query was wrong. I did a whois on a few other internic handles I know and it looks as if they are wrong as well. I thought at first that maybe someone changed my Internic contact registration (which is why I'm sending my PGP key to them right now), but the last update time is months ago, and I'm sure I would have noticed it before now. So did Internic's whois server break? Or did their registery get corrupt? - -- Jordan Mendelson : www.wserv.com/~jordy Web Services, Inc. : www.wserv.com -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMtfN2hA7rx9toVxZAQFz+AP8Cy2WMeemqq7utDt2OIFWEI/ZLSs+VlRI JZsRGPQjHcrz2yHSXeWvg24SKBRlgy2O7OTRMclZaEAmsOTfA4fIAoR5cT5uXcyK Oo7fz0Xwt+sXvGrc4SFjiJyHMBAc71ohakhFVDafqyWipjb+04HCV7VN5zk7TgKV xsVnGzgx+SA= =tuPj -----END PGP SIGNATURE-----

8 7

Re: Internic registries
by William Sommers 12 Jan '97

12 Jan '97

On Sat, 11 Jan 1997 20:23:37 -0500 (EST) Mark Kosters wrote: > I see this and have noticed in the change logs that the whois dumper > program was recently updated. I've backed out the change and the old > info will return by 6:00AM or so tomorrow. > > (Ingres database looks ok but obviously whois is not). > > Thanks, > Mark Were I InterNIC management, I'd be wondering why it took an employee perusing an off-topic thread in this list to have the problem brought to somebody's attention. I reported it to action(a)internic.net yesterday morning, at which time it had already been going on for at least a day. Then again, since I've long been convinced my mail to InterNIC is just plain blackholed anyway (based on a response rate of exactly 0% to date), I don't know why I thought that one would have been treated any differently. (Sorry, couldn't resist.) :-) William Sommers San Francisco Online Televolve, Inc. sommers(a)sfo.com

1 0