On Wed, 2007-10-17 at 09:06 -0700, Garrett D'Amore wrote:
> There is a private method by which the firmware decides whether the host
> OS is alive and healthy. If so, then the host does this work. If not,
> then the firmware takes over.
That doesn't help if the rest of the network thinks that the way to get
to the shared IP is via a NIC that AMT isn't aware of (for instance, you
could be running OSPF multipathing and may have inadvertantly injected a
host route for the management interface into the OSPF cloud).
Taking this up a level, the boundaries of "what works" and "what doesn't
work" with shared ip seem to be fuzzy. we can make the boundaries
simple (don't share unless you're only using one ethernet port), or we
can add hacks (having the host stack forward stuff to the AMT) which
increase the complexity of the boundary between "what works" and "what
doesn't work".
IMHO, both we and our customers will be happier if we strongly recommend
that customers run this feature in lower-complexity configurations.
Just because you *can* in some cases share an ethernet port and/or IP
address with this management processor doesn't mean you *should*.
BTW, there's another gotcha to watch out for that I haven't seen
mentioned yet:
If the management processor is picking off traffic for a particular
port, what happens when the host picks the same port for its own use
(for instance as the local port of an outgoing connection)? if we're
going to recommend using the shared ip mode we need some way to
persistently fence off that port from local use.
I've seen stray ipsec port-level policy rules cause some very
hard-to-diagnose problems when an application other than the expected
one latches on to the port..
- Bill
