> I can see situations in the future where people's lives could be
> dependent on networks working properly, or at least endangered if a
> network fails.
Actually it's not the future. My father's design bureau was making
hardware, since 70s (including network stuff) for running industrial
process
This report has been generated at Fri Dec 25 21:11:26 2009 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
BGP Update Report
Interval: 17-Dec-09 -to- 24-Dec-09 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS984249612 3.7%3100.8 -- LDCC-AS Lotte Data
Communication Company
2 - AS6389
On Dec 25, 2009, at 5:44 AM, Vadim Antonov wrote:
> The pre-planned emergency checklists may be a good idea for network
> operators. Try obvious (when you're calm, that's it) actions first, if
> they fail to help, try to limit damage. Only then go file the ticket and
> talk to people who can in
Shops where engineering and operations function separately can suffer from
reduced efficiencies. A recent example comes to mind. Vendor X was onsite
turning up some equipment, including a small VPN concentrator for remote
access. It was a new model of VPN concentrator that the installers hadn't
I expect the ARIN and RIPE folks may be influential and as such, it could be a
good idea for them to attend.
Mike
From: Jon Lewis [mailto:jle...@lewis.org]
Sent: Thu 12/24/2009 3:13 PM
To: O'Reirdan, Michael
Cc: J.D. Falk; nanog@nanog.org
Subject: Re: Article
> What I'm getting at is that after following this thread for a while,
> I'm not convinced any amount of process-borrowing is going to solve
> problems better, faster, or even avoid them in the first place. At
> best, our craft is 1/3rd as "old" (if that's somehow I measure of
> maturity) as flight
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to bgp-st...@lists.apnic.net
For historical data, please see http://thyme.apnic.net.
If you have any comments please contact Philip Smith .
Routing
On Thu, 24 Dec 2009, Scott Howard wrote:
His actions were then "subject to the consensus of those on the conference
bridge" (ie, ATC) who could have denied his actions if they believed they
would have made the situation worse (ie, if what they were proposing would
have had them on a collision co
On Thu, Dec 24, 2009 at 01:09:26PM -0500, Randy Bush wrote:
> > I _do_ create action plans and _do_ quarterback each step and _do_
> > slap down any attempt to deviate.
>
> imagine a network engineering culture where the concept of 'attempt to
> deviate' just does not occur.
Whimsical deviations
On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov wrote:
> The ISP industry has a long way to go until it reaches the same level of
> sophistication in handling problems as aviation has.
It seems that there's a logical fallacy floating around somewhere
(networks have parts and are complicated, airp
On Fri, 25 Dec 2009, Vadim Antonov wrote:
The ISP industry has a long way to go until it reaches the same level of
sophistication in handling problems as aviation has.
Well, to counter this one might talk about the medical business (doctors)
which hasn't been able to embrace the checklists at
Just clearing a small point about pilots (I'm a pilot) - the
pilot-in-command has ultimate responsibility for his a/c and can ignore
whatever ATC tells him to do if he considers that to be contrary to the
safety of his flight (he may be asked to explain his actions later,
though). Now, usually ign
I think any network engineer who sees a major problem is going to have a
"Houston, we have a problem" moment. And actually, he was telling the
ATC what he was going to need to do, he wasn't getting permission so
much as telling them what he was doing so traffic could be cleared out
of his way. Fir
14 matches
Mail list logo
