July 1997 - Test - lists.nanog.org

Re: Sprint Collapsing ASes?
by jprovo＠ma.ultranet.com 07 Jul '97

07 Jul '97

"Robert A. Pickering Jr." <pickerin(a)fuse.net> wrote: >Well, I was on vacation last week, and came back to this note from >the SprintLink NOC. I'm surprised no one else posted this. Perhaps we were all waiting to how well it went; the doom-n-gloomers will undoubtably flame away no matter how smoothly this large change gets executed. >Is there any other information? Are they collapsing all of their >networks to a single ASN? Yes, they're going to reflectors. All the 'visible confederacy' stuff is folding into 1239. Cheers, Joe Afilliation for identification only, etc etc... -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: Flawed logic?
by Larry Vaden 06 Jul '97

06 Jul '97

At 09:58 AM 7/6/97 -0400, Paul Ferguson wrote: > >The 'free lunch' syndrome is one in which, historically, the service >providers in the default-free zone willingly propagated all routing >announcements announced to them without hesitation. Now they have >drawn policy lines where this is not the case, and in some instances, >will no longer entertain peering relationships without economic >incentive. The syndrome is one in which those who are directly or >indirectly affected complain bitterly that they feel they are being >unfairly discriminated against and that such activities are restraining >their ability to run a business. > Paul seems to be saying there is the possibility of a market solution to "the routers will fall over" problem. If you are in a position or know some one who is in a position to discuss this issue further, please email me privately at vaden(a)texoma.net. Thank you, Larry Vaden, founder and CEO Internet Texoma, Inc.

2 1

Re: Sprint AS1800 weirdness?
by Skutch 06 Jul '97

06 Jul '97

I am going to respond to this with four small sentences. #1) There was a fiber cut in Fort Worth. #2) "that dork" isn't a very nice thing to say. #3) At least "that dork" knew the truth. #4) All spam >> /dev/null or null 0, whatever your preference. Kissies, Alex > Sprint has had a bunch of internal routes flapping (and they have > been dampened). The dork on the phone at their noc said that > there was a large fiber cut in ft. worth and that there were 185 > ds3s down. Whatever. > > Bradley Reynolds > breynolds(a)harborcom.net > ber(a)cwru.edu > PGP Fingerprint: 73 17 77 08 8A 72 DB 45 76 28 C5 5A 97 52 26 > PGP Public Key: http://www.harborcom.net/~breynolds/pgp.html > > >

1 0

Re: ? re: Tony Bates' CIDR Report
by Sean M. Doran 06 Jul '97

06 Jul '97

Not that this is really all that NANOG relevant, but if one checks into the archives on the NANOG and RIPE mailing lists, you will find that after lots of discussion, I agreed with Daniel Karrenberg and many others that /19s were eminently reasonable MAXIMUM prefix lengths for globally-visible NLRI. A minimum aggregation boundary leading to no prefixes larger than 18 bits is desirable, and any aggregation that leads to even shorter global prefixes is a big plus for scalability. Consequently, just to repeat myself, /19s for everyone meeting registry requirements is probably just fine. Now let's eliminate globally visible /24s. All of them. ESPECIALLY the historical stuff in the swamp and toxic waste dump. BTW, this probably can serve as notice to people that the step from proxy aggregation of long prefixes to outright lNAT for offenders is not that far in the future... Of course, the plus then is that people at the edges can be as sloppy as they want wrt routing announcements; from the perspective of large chunks of the topology (peers' and suppliers' networks, for example), even rather heavily meshed networks could and will appear to be neatly aggregated into PA address space. Sean. P.S.: Those vendors who are crowing about flow-directed shortcuts for IPv4 would be wise in investing in other flow-directed technologies, such as lNAT, intrusive web caching and redirection, and the like. I am fairly confident that the near future will bring a popular recognition among large transit providers (that is, your initial market) of the Internet as a services-based network with congestion avoidance principally performed at the edges, with unknown spaghetti (odd IP topologies, address and protocol translations and gatewaying, etc.) in the middle. All this nonsense about addressing MUST go away, and an ability to stage migrations to post-IP transport protocol(s) is also very handy. Developing a mindset wherein IP itself is not necessarily end to end, IP addresses may change relative to topology, and may change over time is a really keen way of accomplishing that.

2 1

? re: Tony Bates' CIDR Report
by Larry Vaden 04 Jul '97

04 Jul '97

On another list, we're discussing whether small ISPs should be able to obtain globally routable /19s. A well respected member of the NANOG community has suggested that "routers would fall over" if the /19s were granted. As you know, Tony Bates publishes the weekly CIDR report; therein he makes the following comment: "This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible." Today's data indicates 2,791 router slots are involved in the "Top 30". Could these router slots really be made available as Tony suggests? If not, why not? Thank you for your time and for your responses. If you will, respond to pagans(a)texoma.net also. If you prefer to remain off the record, reply privately with *OFF THE RECORD* in your subject line. Here's today's data as published at <http://www.employees.org/~tbates/cidr-report.html#General_Status>: --- 04Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS174 1148 819 329 28.7% Performance Systems International AS2493 766 460 306 39.9% i*internet AS3602 556 309 247 44.4% Sprint Canada Inc. AS2048 251 120 131 52.2% LANET-1 AS1691 301 172 129 42.9% BCTEL AS6541 186 59 127 68.3% GTE Intelligent Network Services AS3804 248 135 113 45.6% Bell Solutions AS1 1032 922 110 10.7% BBNPLANET AS1967 186 82 104 55.9% Middle East Technical University AS839 125 26 99 79.2% North West Territories Regional N AS701 972 875 97 10.0% Alternet AS7195 121 43 78 64.5% INTERRED AS816 318 248 70 22.0% UUNET Canada (ASN-UUNETCA-AS4) AS2704 256 186 70 27.3% HOOKUP-NET-A AS4293 108 44 64 59.3% IMCI AS549 250 189 61 24.4% ONet Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4648 190 134 56 29.5% NZIX 2 AS3561 942 890 52 5.5% MCI AS6181 53 4 49 92.5% FUSE-NET AS3799 74 26 48 64.9% IDS AS97 175 128 47 26.9% JvNCnet AS813 208 161 47 22.6% UUNET Canada (ASN-UUNETCA-AS1) AS719 565 518 47 8.3% LANLINK autonomous system AS4454 74 27 47 63.5% TNET-AS AS4763 100 56 44 44.0% Telstra New Zealand AS2711 98 57 41 41.8% SUNBELT-AS AS271 98 57 41 41.8% BCnet Backbone AS3749 75 35 40 53.3% TECNET AS225 63 25 38 60.3% VIRGINIA-AS ---- 2791

1 0

Re: Root Servers not updated
by Carl Oppedahl 04 Jul '97

04 Jul '97

At 02:22 PM 07/03/97 -0400, David H. Holtzman wrote: >There's a lot of smoke going around this list and others about the root >servers. The internic generated a corrupt zone file on Tuesday which Bind >did not load and prevented XFERs to the secondaries. We became aware of it >last night and it is currently fixed. New zones will be ready for XFER >within the next hour. > >The issue with requiring a login for retrieving the zone files was designed >to help reduce spamming. We are currently experiencing a huge system load >due to several individuals who are trying to register recently deleted >domain names. The requests are being repeated and fired off every few >milliseconds. One individual has over 50,000 templates in the system as we >speak. We believe that by requiring an identity to download the zone >files we will better protect the community. > >Note that this ftp policy has not yet gone into effect. > >Lastly, it appears irresponsible to fan the flames of "the internic is >trying to get over" via lists like these. How about giving us the benefit >of the doubt? We generally stay silent on these issues, but feel that it >is important to explain what we are doing and why. No, we are not trying >to take over the net. Sorry for the confusion. I didn't see any irresponsible fanning of flames. I saw NSI (rather characteristically, I might add) making what now turns out to be a secret (you call it "silent") plan to change something about how information passes from the A root server to the other root servers, and not sharing it with the Internet community until someone (in this case, Paul Vixie as I recall) noticed that NSI had screwed up and done it wrong. And only after someone outside of NSI noticed the screwup, did someone within NSI bother to acknowledge it. And only then did NSI fix it, as far as I can tell, by the way. If people had "given NSI the benefit of the doubt" as you request, presumably by not posting anything about this screwup, it is anyone's guess how long it would have taken for the screwup to get fixed. I also didn't see any "smoke". What I saw was factual discussions of how the root level servers were out of synch with each other, indeed almost a week out of synch before it got fixed. If it is "important to explain what NSI is doing and why", then why did this explanation not happen *before* NSI made this ill-fated change? Why did this explanation only happen after people outside of NSI discovered the problem and commented upon it?

1 0

Re: ANS?
by Chris Ballard 04 Jul '97

04 Jul '97

We don't appear to be annoucing this net to any of our EBGP peers, as far as I can tell. Can you send me the information that you have, indicating that ANS is announcing this route. cballard > > ... > > > > AS 517 is University of Karlsruhe, Germany. > > > > it is now XLINK (a spin-off from the Univercity of Karlsruhe, Germany), now > belonging to BULL. > > The net 145.225.0.0 is LINDE from Mainz, Germany. I dont know what this > has to do with ANS. The Announcement at MAE-EAST seems to be ok.. > I dont think that this NET should be announced by ANS :-) > > > > Winfried Haug | SEICOM.DE & SCHWABEN.DE | Tel. 07121 9770- 0 > Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. 07121 9770-19 > 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack 07127 989-X > haug(a)schwaben.net| 90*ISDN (64kb/X.75) / 90 * 33.300 | Rack 0711 9675-X > haug(a)seicom.net |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack 07121 709-X > * 2 MBit DE-CIX Connectivity * 2 MBit WIN Connnectivity * 2 MBit UU.NET * > >

1 0

ANS?
by James Sanford 04 Jul '97

04 Jul '97

Anyone know what's going on? Packets to ANS are going to EU.Net, and I wouldn't doubt it if other networks are screwy too. Digex MAE-East Looking Glass shows: BGP routing table entry for 145.225.0.0/16, version 532087 Paths: (3 available, best #2, advertised over IBGP) 701 286 286 517 198.32.186.249 from 198.32.186.249 (137.39.3.58) Origin IGP, metric 0, valid, external Community: 2548:668 286 517 192.41.177.120 from 192.41.177.120 (134.222.86.34) Origin IGP, valid, external, best Community: 2548:668 1800 1755 517 192.41.177.240 from 192.41.177.240 (198.67.131.49) Origin IGP, metric 16, valid, external Community: 2548:668 AS 517 is University of Karlsruhe, Germany. -- James Sanford - jsanford(a)iaxs.net Infinity AccessNET - 612-944-7123

3 3

Re: Root Servers not updated
by George Herbert 03 Jul '97

03 Jul '97

David Holtzman wrote: >There's a lot of smoke going around this list and others about the root >servers. The internic generated a corrupt zone file on Tuesday which Bind >did not load and prevented XFERs to the secondaries. We became aware of it >last night and it is currently fixed. New zones will be ready for XFER >within the next hour. Thank you for the information. >The issue with requiring a login for retrieving the zone files was designed >to help reduce spamming. We are currently experiencing a huge system load >due to several individuals who are trying to register recently deleted >domain names. The requests are being repeated and fired off every few >milliseconds. One individual has over 50,000 templates in the system as we >speak. We believe that by requiring an identity to download the zone >files we will better protect the community. > >Note that this ftp policy has not yet gone into effect. Also thank you for the information... >Lastly, it appears irresponsible to fan the flames of "the internic is >trying to get over" via lists like these. How about giving us the benefit >of the doubt? We generally stay silent on these issues, but feel that it >is important to explain what we are doing and why. No, we are not trying >to take over the net. Sorry for the confusion. I had some long conversations with Chuck Gomes there following the great PR debacle of the InterNIC billing cleanup earlier this year. One of the aspects of this covered the need for more proactive information releases by InterNIC when things go wrong. InterNIC, being a singular and critical resource, is in a particularly touchy situation with regards to the general question of trust on the internet. What with all the policy issues that are also flying, as well as a moderately bad history (some of which was bad PR/info release rather than actual problems), InterNIC suffers from an ongoing problem that large segments of the network operator community fear you. That is, obviously, not a good thing to have. The only solution is that InterNIC has to become actively proactive about informing the community when things go wrong. I don't think it's too much of a stretch to say that at the very least the operators of all the root nameservers should have had the problem report mailed to them on Tuesday, if not made more publically available via the nanog mailing list, etc. Again, I urge InterNIC to understand how important it is that you push this information out to people rather than have us get flustered and come looking for it when things go wrong. -george william herbert gherbert(a)crl.com

1 0

RE: URGENT! Root Servers not updated
by Rodney Joffe 03 Jul '97

03 Jul '97

Slow downn a little... Apparently Mark Kosters is on vacation... so they're trying to track him down to get this cleared up (this info gleaned as a result of trying to deal with Genieweb claiming .com authority :-) Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Jesse Caulfield [SMTP:jesse@netthink.com] > Sent: Thursday, July 03, 1997 10:17 AM > To: Gordon Cook > Cc: nanog(a)merit.edu > Subject: Re: URGENT! Root Servers not updated > > As I understand it (and I really don't so you should stop reading > now...) > the purpose of locking down the zone files (or whatever) is not > necessarily a power grab by NSI, but rather a move to protect the > people > and information who appear in that database (or whatever) from > otherwise > nefarious miscreants. Folks who want the file will simply have to > register > for it. > > I believe information generally wants to be free, but there may be a > good > business, technical and socially acceptable case for asking users of > the > database to identify themselves. > > Also, it's possible NSI got ahead of themselves and locked stuff up > before handing out the keys. What with the move and power grid > failures in > Herndon, anything's possible. > > -- > JMC > > > On Thu, 3 Jul 1997, Gordon Cook wrote: > > has the basic problem that paul vixie complained about been solved? > > > > I called a knowledgable source last night. That person was aware of > the > > change and said that the proper IANA people had been informed in > advance > > and had (he thought) not disagreed. the change he believed was not > for any > > of the reasons that paul feared. > > > On Wed, 2 Jul 1997, Paul A Vixie wrote: > > The message below was one of several that came to me today. > Apparently, > > when NSI changed the FTP access controls recently for the COM, ORG, > EDU, > > and NET zones, they also disallowed zone transfers from the "A" name > > server to most of the other name servers.

2 1