[c-nsp] FWSM HA secondary reload & long downtime

[Ramcharan, Vijay A]

Not that I'm helping any... 

We've always enabled monitoring on every interface whether the FWSM was
running single or multi mode and I've always taken it for granted that
it was configured that way. 

The FWSM 3.2 config guide says "In multiple context mode, you must
configure interface monitoring from within each context." 
Also that if an interface is shared between contexts you can monitor
that interface in just one context. That doesn't say a whole lot
obviously as you already know. 

Normally if you configure interface monitoring the unit runs a series of
tests (link, activity, arp, broadcast) to determine whether an interface
has failed and what should be done according to the failover policy. 

If all interfaces within a context are not monitored then I wonder, what
is the behavior of a unit booting up? Does that newly booted up context
with no monitored interface go active for some time and mess with
traffic coming/going to/from it for some period of time? Obviously the
"correct" behavior would be to "see" the peer as active and go into
standby. 

I know that for active/standby all contexts on a unit are either active
or standby but obviously something else is going on. 

What does "show monitor" on a context with no monitored interfaces look
like? 
 
Vijay Ramcharan 
  
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: March 12, 2009 16:22
To: ayourtch at cisco.com
Cc: cisco-nsp
Subject: Re: [c-nsp] FWSM HA secondary reload & long downtime

On Wed, 2009-03-11 at 19:14 +0100, Andrew Yourtchenko wrote:
> On Wed, 11 Mar 2009, Peter Rathlev wrote:
> > This of course points to something else being the problem, not the
> > FWSM.
> 
> *bling* too strong of an assumption :).

Ironically that was a very precise observation. ;-) I've looked much
more thoroughly at the logs now, and finally I discovered what would've
taken only few moments to see had I just opened my eyes.

It turns out that more than one context had problems. I think I was
tired when I looked at the configuration differences. Specifically all
contexts with no "monitor-interface"-configuration were affected. Every
context with at least one "monitor-interface" had no problems.

I seem to remember that we stopped using "monitor-interface" in the
individual contexts a year or so back, thinking that when failover is
always system wide anyway, and since all the relevant VLANs share the
same underlying (redundant) path, we could just as well only monitor one
interface in the admin context. By chance a couple of other contexts had
some monitors that weren't removed back then.

It is of course a joy to have figured this out, but I can't seem to find
anything much on what "monitor-interface" in a multiple context setup
actually does or doesn't do.

Should every context have one monitor-interface? Should all interfaces
be monitored or just one per context?

Regards,
Peter


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

______________________________________________________________________
This e-mail has been scanned by Verizon Managed Email Content Service,
using Skeptic(tm) technology powered by MessageLabs. For more
information on Verizon Managed Email Content Service, visit
http://www.verizonbusiness.com.
______________________________________________________________________