Bill Sommerfeld wrote:
> 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).
>
Then you deserve what you get. :-/
> 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".
>
We don't "control" this fully... customers can configure BIOS on systems
they bought from vendors like Dell, however they please.
What we can say is, configuration in modes other than a simple set are
unsupported on Solaris.
> IMHO, both we and our customers will be happier if we strongly recommend
> that customers run this feature in lower-complexity configurations.
>
Strongly agree. I think that the cases where customers are most likely
to want to have higher complexity configurations are also the cases
where the system has a separate service processor. AMT is Intel's
"low-end" solution, for simpler systems with only one or two NICs in a
very simple configuration.
I do want to point out that the failure mode for most of these
interoperability issues is loss of access to AMT facilities. This will
not cause the system to panic, corrupt data, or do other bad things.
What it will do is make it harder to use the remote console facility,
remote disk support (I had forgotten about that!), etc.
> 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 think that I addressed that by noting that LMS needs to bind to those
ports to hold them from accidental allocation to other host software.
> 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..
>
Yes. This is why LMS *must* bind to those ports. A failure to bind to
those ports indicates something else is bound, and that should be
syslog'ed with a big warning.
LMS should start early... early enough to preclude other software from
getting in and binding to the port by accident.
An alternative, but less desirable (IMO) approach is to do the
filtering/rule in the kernel. I don't like that at all, though.
-- Garrett
