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: [email protected] [mailto:[email protected]] On Behalf Of Peter Rathlev Sent: March 12, 2009 16:22 To: [email protected] 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 [email protected] 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. ______________________________________________________________________ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
