- Test - lists.nanog.org

RE: Hey, anyone who wanna help improve the net stability?
by Paul Ferguson 05 Sep '96

05 Sep '96

[cc: list mercifully trimmed] Jim, Regadless of whether the address space is IPv4 or IPv6 (or IPv8 or whatever nonsense), the same problem would exist with this number of prefixes. This is *not* an issue of 'which address space is hosed', but rather, how to put into place practical allocation and aggregation strategies to keep the total number of prefixes to a minimum. It would appear that while you seem overly anxious to say 'I told you so', you've completely ignored the technical discussions on why the problem exists in the first place, and why the allocation and aggregation methodologies need vast improvement than history has shown us. This is completely orthogonal to 'other address spaces'. - paul At 05:15 PM 9/5/96 -0500, Jim Fleming wrote: > >Is now when we say..."we told you so..."....??? > >You are seeing the great allocation policies and procedures at work... > >fortunately, there will be other address spaces and the IPv4 space >can be wrapped up as one TWD... >

1 0

Re: customers and web servers and level one naps
by schnell＠gsd.sprint.com 05 Sep '96

05 Sep '96

Is the gentleman who originally posed the question talking about the NAPs awarded by NSF solicication NSF93-52 (of which there are only three), or in the generic sense (all network access points, including the PAIX). If you research the solicitation I don't believe you'll find suggestions of supporting non-NSP connections or host-based apps other than the RA. Steve At 11:07 9.5.96, bmanning(a)ISI.EDU wrote: >> >> What are the positions of Ameritech, sprint, pac bell and MFS on two >> issues? >> >> First having someone at a NAP who is there as a customer of one of the >> National service providers... and who may or may not engage in cost free >> peering with any of the other NSPs or even with other isps? >> >> Second: allowing such a customer, or an NSP, to attach web services >> directly to the FDDI ring at the NAP. >> >> PAIX is doing this. As far as I know the other major interchange provider >> are not. I am wondering why. >> > > Is PAIX a "major" exchange Gordon? > > >-- >--bill ******************************************************************************** Phone: 1.816.854.2113 Fax: 1.816.854.2201 Sprint Pager: 1.888.366.7890, PIN 398.6644 Text Page via Internet: 3986644(a)pagenet.net ********************************************************************************

1 0

wait a minute here
by Paul A Vixie 05 Sep '96

05 Sep '96

Someone just wrote me and said: > I would be happy to remove a lot of out /24's if the NIC would allocate a > larger than /32 to renumber into. The NIC does not thing this is as > important. According to what I know of InterNIC's policies, they will be glad to trade aggregated address space for unaggregated space, _in_roughly_equal_parts_, and assuming that you have efficiently used your old space. It's not that InterNIC doesn't consider this important -- rather than they are not in the routing business and the routability of addresses is not one of the criteria they can look at when making allocations. So don't put it to them in terms of routability, just SWIP your suballocat- ions and write a nice polite letter showing how some parts of the world will be better off and no part of the world will be worse off if prefixes X and Y are returned to the pool in exchange for prefix Z (of size ~X + ~Y). If you do _that_ and are told to go pound sand, I'd like to hear about it. But I know people who have successfully done what I'm suggesting so I really do not expect you to fail.

3 3

Hey, anyone who wanna help improve the net stability?
by Peter Lothberg 05 Sep '96

05 Sep '96

Hey all! We are approaching 40K routes, and this seems to make IBGP in networks with rich external connectivity pretty unhappy. Without pointing fingers, there are some 9K prefixes that could be removed by proper aggregation/reconfiguration. ICM-Stockholm-2#sh ip bgp summ BGP table version is 526856, main routing table version 526856 39321 network entries (300167/309954 paths) using 13491704 bytes of memory I suggest that everyon go look at what they can do, as we are all loosers with the currect situation. --Peter

10 12

Re: :)
by Sean Doran 05 Sep '96

05 Sep '96

John Curran writes in reply to Enke Chen: | >Sorry, it was a joke (read ":-)") in replying to the original | >question "what kind link it is". Doing OC12 between routers | >is still a dream today ... | | Mea culpe... I mistook it for "marketing announcement" | (i.e. tied to reality only in theory... ;-) Oh, tish and tosh. Think of it as an opportunity to announce the OC24c connections between Sprintlink and BBN Planet. Sean.

2 1

Re: Hey, anyone who wanna help improve the net stability?
by Erik-Jan Bos 05 Sep '96

05 Sep '96

Geoff, > You were plotting the size of the routing table at very tight > intervals (1 hour or so as I recall) - are these graphs online > somewhere? Every hour on the hour I take a sample. The latest and greatest graph can be found at (sorry, no gif or jpeg available currently): ftp://ftp.nic.surfnet.nl/surfnet/net-management/ip/nets.ps Please note the flat-line at the end of the graph: Due to a reconfig of the router I take the samples from during my holidays I am missing some data points :-(. But the last sample points that are in there are well above 40000. __ Erik-Jan.

1 0

Re: Hey, anyone who wanna help improve the net stability?
by Peter Kline 05 Sep '96

05 Sep '96

Now that net99 is assimilated (with the exception of one city), AGIS will begin cleaning up its announcements, as well as implementing access-list 112 inbound. We'll publish the dates and details soon. Peter At 02:51 PM 9/5/96 DST, you wrote: > > >Hey all! > >We are approaching 40K routes, and this seems to make IBGP in networks >with rich external connectivity pretty unhappy. > >Without pointing fingers, there are some 9K prefixes that could be >removed by proper aggregation/reconfiguration. > >ICM-Stockholm-2#sh ip bgp summ >BGP table version is 526856, main routing table version 526856 >39321 network entries (300167/309954 paths) using 13491704 bytes of memory > > >I suggest that everyon go look at what they can do, as we are all >loosers with the currect situation. > >--Peter > > _____________________________________________________________________ Peter Kline | 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.

1 0

Re: Hey, anyone who wanna help improve the net stability?
by Paul Ferguson 05 Sep '96

05 Sep '96

At 03:04 PM 9/5/96 -0400, Gordon Cook wrote: >Then apparently I have misunderstood what the swamp was/is. I thought it >was just an unaggregated area and didn't understand why. Is there text >somewhere that explains very clearly the swamp and the policies attached >there to? > Gordon, The Swamp is 192/8. The unnaggregated /24 allocations in The Swamp is called The Toxic Waste Dump [TWD]. Also see: http://www.isi.edu/div7/pier/whose_routes - paul

1 0

Re: customers and web servers and level one naps
by matthew＠scruz.net 05 Sep '96

05 Sep '96

From: Avi Freedman <freedman(a)netaxs.com> ... > I'd like to know the answer to this (re: PAIX. No other exchange that I > know of gives IPs for use by non-routers that aren't RA machines). ... But that doesn't stop people from attaching hosts into the NAP infrastructure. I pointed this out on the mae-west list a few weeks ago. There are quite a few providers at mae-west who plug the NetEdge at their end into a FDDI ring which has multiple IP subnets on it, one of them the NAP addresses, and another for their local boxes. Since the NetEdge is a filtering bridge, it seems like it would isolate the traffic, but it DOESN'T STOP BROADCAST TRAFFIC. So you get lots of CDP packets, rwhod packets, RIP packets, internal ARP requests, and who knows what else floating around the entire exchange point. All you need to do is send a single ping to 255.255.255.255 via your NAP interface to see just how widespread this has become. Discussion on the mae-west list basically came down to "no, this shouldn't be how people build their networks" but I don't see any changes: (note that some stuff might be missed because not every ping reply gets back) Stuff in other address spaces: Reply to request 0 from scl-ca-gw3.netcom.net (163.179.51.16), 44 ms Reply to request 0 from scl-ca-gw13.netcom.net (163.179.51.14), 304 ms Reply to request 0 from nntp.mainstreet.net (205.137.63.53), 56 ms Reply to request 0 from sc01-gw1.mainstreet.net (207.5.0.2), 52 ms Reply to request 0 from scl-ca-gw7.netcom.net (163.179.51.7), 48 ms Reply to request 0 from scl-ca-gw2.netcom.net (163.179.51.3), 48 ms Reply to request 0 from scl-ca-gw6.netcom.net (163.179.51.6), 48 ms Reply to request 0 from scl-ca-gw4.netcom.net (163.179.51.4), 48 ms Reply to request 0 from scl-ca-gw12.netcom.net (163.179.51.13), 48 ms Reply to request 0 from sc01-gw2.mainstreet.net (207.5.0.4), 48 ms Reply to request 0 from scl-ca-gw10.netcom.net (163.179.51.10), 48 ms Reply to request 0 from news8.agis.net (205.137.63.52), 48 ms Reply to request 0 from scl-ca-gw9.netcom.net (163.179.51.9), 44 ms Reply to request 0 from scl-ca-gw8.netcom.net (163.179.51.8), 44 ms Reply to request 0 from scl-ca-gw5.netcom.net (163.179.51.5), 44 ms Reply to request 0 from scl-ca-gw1.netcom.net (163.179.51.15), 44 ms Reply to request 0 from news4.agis.net (205.137.63.51), 44 ms Equipment that can't reply properly to broadcasts: Reply to request 0 from 255.255.255.255, 4 ms Reply to request 0 from 255.255.255.255, 1 ms Reply to request 0 from 255.255.255.255, 72 ms Reply to request 0 from 255.255.255.255, 4 ms -matthew kaufman matthew(a)scruz.net

2 1

Re: :)
by John Curran 05 Sep '96

05 Sep '96

At 9:32 9/5/96, Enke Chen wrote: >Sorry, it was a joke (read ":-)") in replying to the original >question "what kind link it is". Doing OC12 between routers >is still a dream today ... Mea culpe... I mistook it for "marketing announcement" (i.e. tied to reality only in theory... ;-) /John

2 1