Hi,
On Wed, Nov 10, 2010 at 03:01:21PM -0700, John Neiberger wrote:
I'm just curious to hear your thoughts on OIR on this platform. Is
this something that you prefer to avoid? Do you have any OIR-related
horror stories you'd like to share?
On 6500/7600 (and 7200), we *never* had any issues.
:- John == John Neiberger jneiber...@gmail.com writes:
I ran into a problem with an OIR last night on a 7609. I normally
don't like to do them. I usually prefer to power the router down
first, replace/add the card and then power it back up. It caused all
sorts of fun when it
On Thu, 11 Nov 2010, Gert Doering wrote:
On 6500/7600 (and 7200), we *never* had any issues.
We've had a few mishaps. Field engineers don't know exactly how to insert
the card properly so the bus stalls for a prolonged period of time
(remember that *every* time you insert or remove a blade
On 11/11/2010 04:44, Richard A Steenbergen wrote:
5 minutes? What boxes are YOU rebooting? :)
mmm, actually yeah, last reboot took 7m30s before link up - and that was
layer 2 only, not layer 3.
Once upon a time, a sup720 would reboot in less than 4 minutes, sigh.
Nick
To: John Neiberger
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] OIR on 7600s: Pretty much evil?
Hi,
On Wed, Nov 10, 2010 at 03:01:21PM -0700, John Neiberger wrote:
I'm just curious to hear your thoughts on OIR on this platform. Is
this something that you prefer to avoid? Do you have any
I'll second Gert - I've personally performed close to 100 OIRs on a
variety of 6500 chassis, and never had it cause a problem.
There was a previous thread almost exactly like this, BTW - if you
feel like searching the archive. It was half-filled with OIR always
fails, I call it Online Insert and
What's the time length on the bus stall? Working on re working lots of
timers, hadn't thought of this. Something to add to the tests.
--chip
On Thu, Nov 11, 2010 at 9:55 AM, Geoffrey Pendery ge...@pendery.net wrote:
I'll second Gert - I've personally performed close to 100 OIRs on a
variety
On Thu, 11 Nov 2010, chip wrote:
What's the time length on the bus stall? Working on re working lots of
timers, hadn't thought of this. Something to add to the tests.
The bus is stalled all the time during the insertion. There is a few
millimeters of insertion length where the bus is
On Thu, Nov 11, 2010 at 8:16 AM, chip chip.g...@gmail.com wrote:
What's the time length on the bus stall? Working on re working lots of
timers, hadn't thought of this. Something to add to the tests.
--chip
In our case, I powered the card down, replaced it, then powered it
back up via the
It's not deterministic as it starts when first longest pin touches backplane
and ends when shortest pin connects. As a practical matter assume 100ms on the
low side and reboot on the high side. :)
Most protocol timers will be long enough that the low side is not a concern
exceptions being BFD
Mikael Abrahamsson wrote:
The bus is stalled all the time during the insertion. There is a few
millimeters of insertion length where the bus is stalled. If you're
rapid and firm in the insertion, you get a few tens of milliseconds of
stall. If you do it wrong and the car gets stuck in that
On Thu, Nov 11, 2010 at 10:58 AM, Kevin Loch kl...@kl.net wrote:
Mikael Abrahamsson wrote:
The bus is stalled all the time during the insertion. There is a few
millimeters of insertion length where the bus is stalled. If you're rapid
and firm in the insertion, you get a few tens of
Yes the LC bus is isolated but in async mode the BFD packet must still be sent
to the RP CPU and all BFD packets are generated from the RP CPU. 6500/7600 do
not support distributed BFD like CRS and GSR where LC CPU handles BFD.
I assume that you were considering scenario where BFD in echo mode
I think the issue is more complicated then just does it work or not. It is
dependent on how you have your 6500/7600 deployed.
Some form of bus-stalls will occur with any OIR. They may be minor, they may
not and that comes down to how long it takes for the shared bus to re-stabilize
because
: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Geoffrey Pendery
Sent: Thursday, November 11, 2010 6:56 AM
To: John Neiberger
Cc: Gert Doering; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] OIR on 7600s: Pretty much evil?
I'll second Gert - I've personally
On 10/11/2010 22:01, John Neiberger wrote:
I ran into a problem with an OIR last night on a 7609. I normally
don't like to do them. I usually prefer to power the router down
first, replace/add the card and then power it back up. It caused all
sorts of fun when it failed the initial startup and
It's true. Bad things can happen. Primary one is buss stall. They are
not supposed to happen anymore but there are bugIDs out there that
prove they do. During buss stall we can't do forwarding lookups to PFC
(pretty sure DFC lookups still work). Even worse is that during buss
stall
On Wed, Nov 10, 2010 at 5:28 PM, Benjamin Lovell belov...@cisco.com wrote:
It's true. Bad things can happen. Primary one is buss stall. They are not
supposed to happen anymore but there are bugIDs out there that prove they
do. During buss stall we can't do forwarding lookups to PFC(pretty sure
Good ole' On Insert: Reload. Yeah the bus stalls are priceless, you're
best bet is to plan like you're taking down the router, and if it works, hey
you just saved some downtime, and are done early. That being said, at least
the actual crashes aren't terribly common, so you can do low risk stuff
On Wed, Nov 10, 2010 at 11:26:36PM +, Nick Hilliard wrote:
So yeah. Annoying, but there you go. Usually you'll get away with
it, but if your application is unforgiving of a 5 minute reboot during
production hours, then you may want to consider a maintenance window.
5 minutes? What
20 matches
Mail list logo
