December 1997 - Test - lists.nanog.org

Re: @HOME problems
by Nicholas Bastin 04 Dec '97

04 Dec '97

On Wed, 3 Dec 1997, NANOG sysadmin list wrote: > Is anyone here aware of the source of seemingly random packet loss to and > from home.net? We have a T1 from @home and I've been getting about 75% packet loss on it for the last couple weeks. We've got a ticket in, but nobody seems to know what the heck is going on. Best I can tell is all my traffic gets to MAE-WEST with only 1% - 2% loss, and then starts timing out. Of course, anything within the @home network is just as quick as usual. Nick Bastin System Administrator - World Trade Internet Communications

3 3

Invalid announce for 15/8
by Edvard Tuinder 04 Dec '97

04 Dec '97

Hi, Has anybody outhere any idea as to why AT&T Japan (AS 2915) is announcing the 15/8 network from HP? I'm not getting anywhere near HP this way.. Amsterdam1>sh ip bgp 15.0.16.68 BGP routing table entry for 15.0.0.0/8, version 7637408 Paths: (2 available, best #1) 5583 4000 2915 194.235.74.237 from 194.235.74.237 (194.235.236.21) Origin IGP, localpref 100, valid, external, best Community: 8251:5001 5496 174 71 71 71 195.86.26.2 from 195.86.26.2 (194.165.94.235) Origin IGP, localpref 100, valid, external Shouldn't GIP/GSL (as4000) be filtering this bogus announcement? Thanks, -Ed -- Edvard Tuinder Cistron Internet Services Finger ed(a)cistron.nl for PGP key ``I must fear Evil, for I am but mortal and mortals can only die''

2 2

Re: [nanog] @HOME problems (fwd)
by NANOG sysadmin list 04 Dec '97

04 Dec '97

But the problems originate from home.net, not sprint, apparently ---------- Forwarded message ---------- Date: Thu, 4 Dec 1997 00:12:14 -0500 (EST) From: NANOG sysadmin list <nanog(a)seersucker.millburn.net> To: Stephen Balbach <stephen(a)clark.net> Subject: Re: [nanog] @HOME problems Sprint/Pennsauken, NJ... On Wed, 3 Dec 1997, Stephen Balbach wrote: > > What gateway to the @Home network? > > On Wed, 3 Dec 1997, NANOG sysadmin list wrote: > > > Is anyone here aware of the source of seemingly random packet loss to and > > from home.net? > > > > Thanks > > -=asr > > > > >

1 0

@HOME problems
by NANOG sysadmin list 03 Dec '97

03 Dec '97

Is anyone here aware of the source of seemingly random packet loss to and from home.net? Thanks -=asr

1 0

Horrible Service Agreements
by Forrest W. Christian 03 Dec '97

03 Dec '97

Over the last few months, I've been trying (without success) to find a provider for our second T1 to the net. Basically, all we want is a full-bandwidth T1 w/bgp4, to an upstream I am comortable with the quality of service of, and who can provide this to us (in montana) at a reasonable monthly rate. Finding a suitable provider hasn't been too hard, but the difficulty comes in when it's time to sign a contract. So far, we have accepted a proposal pending contract approval for TWO different potential upstreams. Both quoted a price of around 2500 per month including local loop. However, the contract terms include what I'm terming an anti-spam clause which generally states that if us or any of our clients or their clients decide to "prevent others from enjoying the internet" (paraphrasing) they can terminate us immediately and make us pay for the remainder of the year term. Each (or maybe better said one or more) of the contracts also included other terms which I felt were totally unreasonable. Such as not being able to mention the name of your upstream. Makes it kinda hard to tell potential clients who you are connected to. Another required us to upgrade our equipment based on whatever specifications they felt was necessary at that point. And there were more. Now, I understand the need to be able to terminate spam havens. I also understand the need to require your customers to use compatible and reliable equipment. Let me explain my problem -- Lets assume that customer "a" decides to purchase an account on our system to send out spam. We don't know he's planning to do this, but he does succeed in sending out 10,000 messages before we find out. Under both agreements, we can be immediately terminated without notice and be required to pay for the remaining time on the 12 month agreement. Regardless if we terminate the offending user as soon as we find out or not. Another example. Lets assume that someone in our upstream decided that we MUST have a $250,000 router to connect to their system. If we can't provide such a beast, we are immediately terminated and required to pay for the remaining year term. Both of the potential upstreams have been wholly unwilling to negotiate a contract in good faith to resolve these issues. I know that nanog is probably not the best forum for this, but I figured it might be a good place to start to look for a provider which can: a) Sell us a T1 line, with BGP4, with local loop to NPA NXX 406 443 for about $2500/month, on a year term or less. b) Not have such rediculous contract language. I'd also like to hear what types of contracts are actually signed by providers and if they are actually read before they are signed. You can reply to me directly, instead of on the list, if you'd like. -forrestc(a)imach.com

13 17

caching at windmills (i mean exchange points)
by k claffy 03 Dec '97

03 Dec '97

to: ISP's at mae-west we submit for your valued consideration a proposition http://www.nlanr.net/Caida/maewest.cache.html (first few paragraphs of web page included below) k and dw nlanr/caida (under we-run-commodity-infrastructure supervision from steve feldman (maewest), bill woodcock (zocalo), and david meyer (UO) ) -------------------------------------------------------- web caching as a viable Exchange Point Service proposed business-compatible model of web caching as a service provided at a NAP background NLANR has been operating a national public web caching system for about two years, as part of a research proposal sponsored by the National Science Foundation to architect and deploy prototype Internet information provisioning infrastructure. While the project has been an enormously successful `proof-of-concept' to the Internet community, especially internationally where it was received subjected to far higher and faster accelerating demand than we intended, participation in a cooperative global web caching mesh has for a variety of reasons been slower to catch on in the United States. A significant barrier to the use of caching by ISPs in the United States is the lack of a discernable pricing and business model to support caching as a commericial Internet service, either independently, packaged with a backbone service, or packaged with exchange point connectivity service. NLANR's project has allowed the development and deployment of a strong research code platform, as well as a prototype infrastructure that has recevied international recognition for its operationally pivotal role in the Internet. However, partly because of the tremendous success and resulting expectations of this `prototype' infrastructure, NLANR has not had the budget or cycles to pursue penetration of the U.S. commercial Internet market, partially expecting it to catch on from its own momentum. In 1997, NSF approved a follow-on award to use the by then globally-entrenched NLANR caching infrastructure for extended architectural investigation and experimentation. We maintain a project plan timeline, status reports, and cache status page including information on upgrades, major configuration changes, and outages. More importantly, we are now in a position to move forward with architectural models of caching that are more compatible with commerically-provisioned commodity intrastructure, and in which ISPs themselves will have an incentive to participate. On 1 December 1997, we are deploying a prototype web cache service at MAE-West, specifically designed to demonstrate the viability of a commercial model for providing web caching service. purpose The principal purpose of this peering-point-colocated Squid cache is to provide an easily accessible (no-AUP, low hop-count, low latency) alternative to the current vBNS-hosted root caches. The secondary purpose of this cache is as a demonstration of the feasibility of introducing self-supporting caches into the main stream of the Internet's core. Having a web cache at popular Internet exchange point provides ISPs an opportunity to leverage their presence at this strategic position in the Internet topology. Because the exchange point is a likely component of the paths of many web pages travelling across the Internet, storing web pages on a web cache at this point offers ISPs a potentially significant savings in bandwidth and end user latency by allowing them to retrieve pages there rather than having to go on to the original source.

4 4

Re: The Year of the Backhoe Continues...
by Sean Donelan 03 Dec '97

03 Dec '97

>The relative severity has gone up though for two reasons. First, there >is more fiber than ever in the ground and that which is in the ground >is carrying more traffic than it used to. So a single cut can cause >lots of people problems. Also, because of the increase in internet >use, the visibility of such cuts has gone way up. Doesn't any one else get a chuckle when they hear a *single* cut can cause lots of people problems when referring to the Internet, given the mythological history of the Internet's design goals? Looking over logs for the last few years, the same causes why the application user has problems show up over and over again. Here they are in order.... 1. Congestion 2. Operator/Software error 3. Telcom facility outage (fiber/cable cut or telco 'virtual' service frame/atm/smds/etc failure) 4. Power failure 5. Hardware failure Its difficult to distinguish between operator errors and software errors, since most cases of operator/software failure often involve a failure by both. Also it is sometimes difficult to tell what the true cause of an outage was. It may be more convient to blame the usual suspects, than to admit your own mistakes. I've noticed some 'fiber cuts' have later turned out to be switch or DACS programming errors. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

IBGP problem concerning more specific routes
by Pascal Petit - SYNET 03 Dec '97

03 Dec '97

Here is an amusing BGP problem : Wild Wolrd-----------R1--------------R2------Our Networks There is an IBGP sesion running between R1 and R2. R2 advertises route 194.214.0.0/16 to R1. In our block there is a class C used by one of our customer which is not directly connected to our network. This customer advertises its class C to the Wild World via its own ISP. R1 receives the 194.214.253.0/24 advertisement from the Wild World, it stores it in its routing table; however R2 never takes it into account : its routing table only mentions 194.214.0.0/16 , it doesn't mention the more specific routing entry 194.214.253.0/24. Our Networks cannot get to 194.214.253.0/24. Is it a feature of IBGP ?? Thanks for any help, Pascal ------------------------------------------------------------------------ Pascal Petit SYNET tel: 33 1 4696 0040 74, rue Roque de Fillol fax: 33 1 4696 0041 92800 Puteaux email: ppetit(a)synet.fr FRANCE http://www.synet.fr

2 1

Re: caching at windmills (i mean exchange points)
by Duane Wessels 03 Dec '97

03 Dec '97

Ton Verschuren writes: >I know. Still, for a cache to fill it has to fetch docs and thus act as >a parent. If the NLANR cache acts as a parent for all MW connected >ISP's than *all* misses from those ISP's get routed through the NLANR >cache and for the transatlantic traffic the lines of NLANR's ISP will >fill up. No? In order for the cache to fill, yes some MW customers will need to call the cache a parent. Some could call the cache a sibling. However, it isn't so black-and-white as that. Squid can be configured to measure RTTs to origin servers. Squid's ICP replies will include the RTT estimations, and the child cache can compare these values to its own measurements, or those made by other (parent) caches. Additionally, for the MW cache, we have modified Squid to return an ICP_MISS_NOFETCH reply for requests origin servers which appear to be unreachable (presumably due to incomplete routing info). Upon receiving this reply, the child cache will not forward the request to us. Thus, a child cache can use our MW cache as a parent only for origin servers which are reachable by us, and which our cache is "closer" to. If the child cache is closer, then it will forward the request directly. A potential problem is that the RTT measurement feature is not compiled in by default. It requires building Squid with a macro defined, and installing the ICMP sending/receiving program with root privs. A few more details can be found at http://squid.nlanr.net/Squid/FAQ/FAQ-7.html#ss7.6 Duane W. -- wessels(a)nlanr.net Think Globally, Cache Locally.

2 1

Re: Horrible Service Agreements
by Adrian Chadd 02 Dec '97

02 Dec '97

On Tue, 2 Dec 1997, Vadim Antonov wrote: > Adrian Chadd <adrian(a)ourworld.net> wrote: > > > Erm, say you put your address on a webpage. > > Or post it to USENET. Better yet, write your home telephone, > address and social security number so every bozo can visit you > or steal your credit. [snip] I hope you realise I meant email address here. :-) This isn't relevant to NANOG I agree, so I'll be brief. Then I'll shut up :) Why should I waste my time having to implement anti-spam measures when it isn't fully effective anyway? Not everyone does it, so its not completely worth it. People have a habit of finding holes and back doors in protocols, programs, and I'm pretty sure any system brought in to effectively kill spam would either be so restrictive it becomes a pain in the butt to use, or its just 'broken' and people find a way to spam through it. Makes it all worthless. Although there ARE loophools in legalese, these are generally harder to find, and the penalties involved would deter most people from spamming. So IMHO, its really a question of which one BEST solves the problem QUICKEST. if you can get everyone to fix their mailer agents to do the anti-spam thing, or rush in a new mail protocol, hell.. feel free. I certainly don't have the time on my hands to keep rooting around upgrading mail agents to support new protocols, or anti spam stuff, etc, etc... Adrian (who really shouldn't be posting to email lists as much as he has been lately.. :-)

1 0