- NANOG - lists.nanog.org

c|net: Four Horsemen of Net Apocalypse
by Paul Ferguson 01 Nov '96

01 Nov '96

More FUD: http://www.news.com/News/Item/0,4,4975,00.html - paul

1 0

Re: BBN bitten again?
by Andy Sell 01 Nov '96

01 Nov '96

Gentlemen, DNS is configured but there's currently no machine at the IP address. Andy Sell At 12:13 PM 11/1/96 -0500, Deepak Jain wrote: > >I am seeing the same behavior from the East Coast. > >-Deepak. > >On Fri, 1 Nov 1996, Kent W. England wrote: > >> Folks; >> >> Since early yesterday, much or all of BBN Cambridge has been down. >> Anyone know what is going on? More rodent adventures? Or did that gasoline >> truck I fantasized about really turn over into the parking level? >> >> --Kent >> >> >> TraceRoute noc.bbnplanet.com (199.94.209.25) >> timed out >> 1 292 292 205.163.24.49 nb49.cts.com >> 2 278 -14 205.163.24.33 ctshub-e1.cts.com >> 3 332 54 207.67.240.113 cts-gw-ds3.atmnet.net >> 4 306 -26 206.62.12.49 agis-atmnet.losangeles.agis.net >> 5 293 -13 205.254.168.249 a5-0.1009.santaclara3.agis.net >> 6 288 -5 198.32.136.14 mae-w.bbnplanet.net >> 7 277 -11 4.0.20.17 sanjose1-br2.bbnplanet.net >> 8 295 18 4.0.1.81 sanjose1-br1.bbnplanet.net >> 9 309 14 4.0.1.73 oakland-br2.bbnplanet.net >> 10 319 10 4.0.1.134 denver-br1.bbnplanet.net >> 11 313 -6 4.0.1.134 denver-br1.bbnplanet.net >> 12 323 10 4.0.1.190 denver-br2.bbnplanet.net >> 13 336 13 4.0.1.130 chicago1-br1.bbnplanet.net >> 14 407 71 4.0.1.194 chicago1-br2.bbnplanet.net >> 15 381 -26 4.0.1.126 boston1-br1.bbnplanet.net >> 16 613 232 4.0.1.182 boston1-br2.bbnplanet.net >> 17 1752 1139 4.0.1.158 cambridge1-br2.bbnplanet.net >> 18 * * timed out >> 19 * * timed out >> 20 * * timed out >> 21 * * timed out >> 22 * * timed out >> 23 * * timed out >> 24 * * timed out >> 25 * * timed out >> 26 * * timed out >> 27 * * timed out >> 28 * * timed out >> 29 * * timed out >> 30 * * timed out >> not reached >> >> >

1 0

Word is getting out
by Lon R. Stockton, Jr. 31 Oct '96

31 Oct '96

Thought this news item was interesting, given recent conversations here regarding peering (or lack thereof). ---------- Forwarded message ---------- THERE IS A WAR GOING ON! There are those who have been predicting the Internet would collapse under its new found weight. I predict it is collapsing from greed. Some of you may have noticed that certain sites on the east coast have been unreachable for the last 5 days. It is because of a disagreement between a major backbone carrier and other regional Network Access Providers. The major carrier has removed the regional carrier from their routing tables. TechKnow Times is currently investigating this story and as soon as the story details can be confirmed we will bring a special report. REMEMBER THIS: You read about this first in TechKnow Times.... Thom <Editor(a)TechKnowTimes.Com> ------- End Forwarded Message --------

1 0

Re: Bit-dumping [Was: Re: Peering Policy]
by Andy lague 31 Oct '96

31 Oct '96

Here's a possibility offered for discussion for minimizing the effect of someone pointing default to you at an exchange point. This would not defeat all defaulting but might make the effect less painful. Do not carry a full routing table on your exchange point router. Only carry routes to your customers and to networks with which you peer at that particular exchange point. That way if someone sends you traffic destined for a peer that you do not see at that exchange point, like via private peering on another router or at another exchange point, your exchange point router will not have a route to it. Traffic from a defaulting network destined for one of your local peers could be forwarded to that peer directly without crossing your backbone. Also, it may help in detecting a defaulting network. If a customer of the evil defaulting network traceroutes to a destination that ends on your exchange point router and sends it to your NOC as a problem - their caught. This would work best at exchange points that are less than fully attended. -Andy

2 1

Re: Bit-dumping [Was: Re: Peering Policy]
by Chris A. Icide 31 Oct '96

31 Oct '96

At 09:39 PM 10/30/96 -0800, Andy lague wrote: > >Do not carry a full routing table on your exchange point router. Only carry >routes to your customers and to networks with which you peer at that >particular exchange point. > > Sorry, but I'm about 50 mails behind in this thread, so I may repeat something someone may have suggested, but I'll give it a shot in case someone hasn't said this. Might there be a way Cisco (ahem, the router vendor) could add an IP or MAC based inbound (or outbound) filter on the next hop? If so, I could maintain a filter that matches my peers. This would not prevent my peers from pointing default at me, but would prevent non-peers from doing so. Chris

2 1

Re: Bit-dumping [Was: Re: Peering Policy]
by Tony Li 31 Oct '96

31 Oct '96

Do not carry a full routing table on your exchange point router. Only carry routes to your customers and to networks with which you peer at that particular exchange point. How is this supposed to help if you're providing transit? Tony

1 0

Tennessee Circuit Charges
by Derek Elder 30 Oct '96

30 Oct '96

As I am fairly new to this list, please feel free to flame me at will if this is off-topic, not of interest, or being heavily discussed elsewhere. Are any of you running into instances such as we are in Tennesee where the state it imposing an 'ISP Tax" that we are to pay? They are even claiming that that tax is retroactive to 1994...it also appears that the state legislature is considering a tarrif amendment allowing BellSouth to charge more than $1.00/hour surcharge for data calls. I know that many of you have already or are currently fighting PUC battles and I would appreciate any insight on the subject. I will now take this offline and would appreciate any responses via private email (unless everyone is interested). | Derek Elder | djelder(a)accessus.net

1 0

Re: Peering Policy ( was Re: AGIS/DIGEX )
by Scott Huddle 30 Oct '96

30 Oct '96

Michael Dillon <michael(a)memra.com> writes > > > > > The bookkeeping costs $2000 per month for *BOTH* providers to monitor > > > > > this, collect data, collect bills, etc.... > > > > > > > > Source of data, please? > > > > > > Same source as the other guy's data. I pulled it out of thin air. > > > Actually, I figured $2,000 per month would be an appropriate salary for > > > one clerk to handle this job. > > > > > > And the point was that managing settlements costs money. We know that in > > > the POTS system the costs of usage based billing are at least 50% of the > > > total. > > > > OK, do you have a source for the POTs number? > > Of course not! I have an axe to grind here. I want to see global flat-rate > telephone service for everybody. No per-minute charges, period! Your argument changes from an economic one to a political one. If you want to run for office, there are better forums. If you want to convince people who are building commercial networks, get some facts. -scott

1 0

Re: Bit-dumping [Was: Re: Peering Policy]
by Paul Ferguson 30 Oct '96

30 Oct '96

I think this sounds like a fine idea. - paul At 02:25 PM 10/30/96 -0500, Jon Zeeff wrote: > >Which is why someone at NANOG suggested using the port # (vs. MAC address). > >> > Problem is that if hardware fails or is swapped out, MAC addresses change. > >

1 0

RE: A proposal for reducing routes due to multihoming
by Vadim Antonov 30 Oct '96

30 Oct '96

Alexis Rosen wrote: >Bill Simpson claims that this idea is ~10 years old, but if so perhaps >it's time to air it again.... >It's dead simple, really: Assign address blocks to pairs of providers. >Both providers announce those blocks all the time, and assign addresses >out of those blocks to customers who multihome between those two >providers. That idea also assumes that providers exchange specifics within shared blocks. Otherwise it won't work. Doesn't sound like big savings... And is certainly a hell to manage. I demonstrated some time ago that the lower boundary on the routing table size given today's Internet topology is about 300 routes. That was done by analyzing AS-paths -- i.e. the assumption was that everything can be aggregated down to 1 route per AS. The result generally indicates that 90% of routes can be eliminated by renumbering and aggregation. The rest is simply too few to worry about. --vadim

1 0