Two things to be aware of when using DRAC on shared ports with aggregation
1. Spanning tree can make the DRAC temporarily unavailable. If you reboot
the server, this will bounce ports on the server side. When the switch sees
a port status change, it may cause spanning tree to go into a learning
state, blocking the port, and so blocking DRAC access. The workaround is to
disable STP on server facing ports, or at least make sure STP is running in
2. Degraded aggregation on the server may cause ports on the switch to be
disabled, blocking DRAC access. Whether this happens or not depends on the
aggregation protocol you use, and the exact switch configuration. An
example of a degraded aggregation is when the server is booted into the
BIOS POST, Lifecycle Controller, etc. You should test this, and adjust your
switch settings accordingly.
> Subject: Re: [Linux-PowerEdge] PowerEdge R210ii, Ubuntu 12.04.1 LTS,
> and iDRAC6/IPMI
> To: <pe...@newton.cx>, <bouti...@ednet.ns.ca>,
> Content-Type: text/plain; charset="utf-8"
> The LOMs are the 2 integrated ports on the motherboard. The NICs are the
> ports on the add-in card. iDRAC can use either LOM1 or LOM2 for network
> access and it uses a unique MAC address that is different than the MACs
> that are used for OS network communication. Therefore no need to configure
> any VLANs.
> OS based teaming has no effect on iDRAC network communication. However,
> switch based teaming like link aggregation (802.3 AD) will have an impact
> since incoming traffic may be routed by the switch to either member of the
> team. If this teaming is between LOMs only, you can configure failover
> between LOMs. In this case, iDRAC will listen on both LOM ports but will
> only respond on the selected LOM. Also if the link fails on the selected
> LOM, then it will switch to the other LOM.
+61 4 05 499 490
Linux-PowerEdge mailing list