For anyone that operates a wireless network or a
copper based network:
Official Space Weather Advisory issued by NOAA Space
Environment Center
Boulder, Colorado, USA
SPACE WEATHER ADVISORY BULLETIN #02- 2
2002 July 23 at 12:00 p.m. MDT (2002 July 23 1800 UTC)
( CORRECTED ) MAJOR SUNSPOT
On Tue, 23 Jul 2002, Brad Knowles wrote:
> IMO, there is a serious risk of having DNSBL servers attacked and
> used as a DoS.
A slightly different sort of DOS from what you mean would be what we got a
few days ago. I got a call from our Noc about problems with our
old (but still online) in
At 2:29 AM -0400 2002/07/23, Phil Rosenthal wrote:
> IMHO Even the really large DNSBL's are barely used -- I think
> (much) less than 5% of total human mail recipients are behind
> a mailserver that uses one...
Not true. There are plenty of large sites that use them (e.g.,
AOL), an
The new NANOG traceroute (also known as TrACESroute)
is now available. It fixes the latest "security" compromise
detailed on Bugtraq and on SUSE security focus at
http://online.securityfocus.com/advisories/2740
Ehud Gavron
[EMAIL PROTECTED]
Directory:
ftp://ftp.login.com/pub/software/tracerout
Some long long long time ago I wrote a small tool called snmpstatd. Back
then Sprint management was gracious to allow me to release it as a
public-domain code.
It basically collects usage statistics (in 30-sec "peaks" and 5-min
averages), memory and CPU utilization from routers, by performi
On Tue, Jul 23, 2002 at 11:53:29AM -0400, Ralph Doncaster wrote:
> I'm seeing 2-5% packet loss going through a Cisco 2621 with <10mbps of
> traffic running at ~50% CPU. (packet loss based on ping results)
>
> Pinging another box on the same catalyst 2900 switch gives no packet loss,
> so it see
On Tue, 2002-07-23 at 10:53, Ralph Doncaster wrote:
>
> I'm seeing 2-5% packet loss going through a Cisco 2621 with <10mbps of
> traffic running at ~50% CPU. (packet loss based on ping results)
> ...
If its not the switch or source ethernet segment generally, and it
doesn't appear to be the ro
Does anybody else has BGP problems with Savvis today?
They are usually very proactive on any problems, call me even for 20
second interruptions but today my BGP session has been dead for probably
5-6 hours (and effectively my ability to use Savvis as upstream provider),
I called them 3 hours
On Tue, 23 Jul 2002, Phil Rosenthal wrote:
>
> ---
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Jason Lewis
>
> Isn't ping the first thing to be dropped in favor of other traffic? I
> remember a similar issue and Cisco saying that was the behavior. Don't
> quote me on th
---
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Lewis
Isn't ping the first thing to be dropped in favor of other traffic? I
remember a similar issue and Cisco saying that was the behavior. Don't
quote me on that.
jas
---
Even if it is, that still means that other pa
One common solution is a hash based on the cpe site name or some other
unique key provided by the cpe information (address, ph #, etc).
Changing the hash occasionally provides new passwords, and it is all
easily scripted..
-Original Message-
From: Daniska Tomas [mailto:[EMAIL PROTECTED
> I'm seeing 2-5% packet loss going through a Cisco 2621 with <10mbps of
> traffic running at ~50% CPU. (packet loss based on ping results)
>
Isn't ping the first thing to be dropped in favor of other traffic? I
remember a similar issue and Cisco saying that was the behavior. Don't
quote me
On Tue, 23 Jul 2002, Daniska Tomas wrote:
> i'm wondering how large isps offering managed cpe services manage their
> password databases.
Slovakia, that's an interesting one for NANOG.
Key management is still a hard problem. It would be nice if the NSA
published how they do it, but I suspect
Somebody affected by a Level3 fiber between Boston and New York ?
Thanks
German
It has a lot of similarities to old Audi's. Remember they used to work
fine and then for no reason used to fall in to drive, rev high, and run
over Grandma and the kids! Sounds a bit like their peering.:)
On Tue, 23
Jul 2002, Streiner, Justin wrote:
>
> On Mon, 22 Jul 2002, Alex Rubenste
On Mon, 22 Jul 2002, Alex Rubenstein wrote:
> Yes, it's horrid. I've been peering with PSI for going on three years, and
> it's never been as bad as it is now.
I took advantage of their "free peering" offer back in the day, and ended
up peering with them for about 18 months (06/1999 - 01/2001).
I'm seeing 2-5% packet loss going through a Cisco 2621 with <10mbps of
traffic running at ~50% CPU. (packet loss based on ping results)
Pinging another box on the same catalyst 2900 switch gives no packet loss,
so it seems the 2621 is the source of the packet loss. I need help
figuring out why
On Tue, 23 Jul 2002, Phil Rosenthal wrote:
> I have a small RRD project box that polls 200 interfaces and has it
> takes 1 minute, 5 seconds to run with 60% cpu usage (so obviously it
> can be streamlined if I wanted to work on it). I guess the limit in this
> implementation is 1000 interface
On Tue, Jul 23, 2002 at 09:53:41AM -0400, Matt Zimmerman wrote:
>
> There is a C library, librrd. That is how the other language APIs are
> built. As to efficiency, there is a lot of stringification, which is
> inconvenient and unnatural in C, but this should not be the bottleneck in
> the col
On Tue, Jul 23, 2002 at 02:40:10AM -0400, Richard A Steenbergen wrote:
> While you're at it, eliminate the forking to the rrdtool bin when you're
> adding data. A little thought and profiling goes a long way, this is
> simple number crunching we're talking about, not supercomputer work. The
> pr
On Mon, Jul 22, 2002 at 10:50:03PM -0700, Doug Clements wrote:
> I think the problem with using rrdtool for billing purposes as described
> is that data can (and does) get lost. If your poller is a few cycles late,
> the burstable bandwidth measured goes up when the poller catches up to the
> in
On Tue, Jul 23, 2002 at 08:34:40AM +0200, Alexander Koch wrote:
> Phil,
>
> imagine some four routers dying or not answering queries,
> you will see the poll script give you timeout after timeout
> after timeout and with some 50 to 100 routers and the
> respective interfaces you see mrtg choke b
hi,
i'm wondering how large isps offering managed cpe services manage their
password databases.
let's say radius/tacacs is used for normal cpe user aaa, but there is
some 'backup' local user account created on the cpe for situations when
the radius server is unreachable. for security reasons, t
23 matches
Mail list logo
