On Thu, 12 Mar 2009, Peter Rathlev wrote:
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.
if all the interfaces go over the exact same path, there is probably not
an entirely huge benefit of it.
Should every context have one monitor-interface? Should all interfaces
be monitored or just one per context?
From the practical perspective, if the "magic trick" of having at least
one monitored interface per context solves it - business needs first,
let's put it in. But otherwise it should not be needed. Would be very cool
if you have some cycles to try this in the lab - if this is reproducible,
I think we should treat it as a bug if not already. I'm on PTO the next
two weeks, after that open the SR# and shoot me unicast.
cheers,
andrew
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
