From owner-freebsd-questions Thu Sep 26 15:10:59 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17829 for questions-outgoing; Thu, 26 Sep 1996 15:10:59 -0700 (PDT) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA17784 for ; Thu, 26 Sep 1996 15:10:54 -0700 (PDT) Received: from fluffy.aros.net (fluffy.aros.net [205.164.111.2]) by mailhub.aros.net (8.7.6/Unknown) with ESMTP id QAA21753; Thu, 26 Sep 1996 16:10:52 -0600 (MDT) Received: from fluffy.aros.net (localhost [127.0.0.1]) by fluffy.aros.net (8.7.6/8.6.12) with ESMTP id QAA17214; Thu, 26 Sep 1996 16:10:51 -0600 (MDT) Message-Id: <199609262210.QAA17214@fluffy.aros.net> To: eischen@vigrid.com (Daniel Eischen) cc: freebsd-questions@freebsd.org Subject: Re: Sprints response to to wcarchive connectivity problems In-reply-to: Your message of "Thu, 26 Sep 1996 14:21:48 EDT." <9609261821.AB24484@pcnet1.pcnet.com> Date: Thu, 26 Sep 1996 16:10:50 -0600 From: Dave Andersen Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sprint is quite correct. CRL's netblocks are flapping and getting dampened by the routers. The problem is not local to Sprint - MCI routers are reporting the flapping as well, but are not dampening them out as aggressively as Sprint's are. I'll try to remember to copy some of the flap stats over here the next time it's having problems. CRL would be well advised to correct the problems with their router. -Dave Andersen > Here is Sprints response (in my ISPs words). While this may be the cause > of recent problems (last week or so), is it representative of most of > the other Sprint connectivity problems? > > "cdrom.com's provider, crl.com, is connected to the internet via a > non-approved poor router. The router is hosing causing flapping problems. > This is also due to the fact that crl does not properly peer. In other > words, crl and therefore crl's customer is not holding up to acceptable use > policies. The destination is deliberately blocked when the router flaps so > as to prevent flapping throughout the network."