# What does “shared mode” really mean on a ninth-generation and later Dell server DRAC?

We have a number of Dell PowerEdge servers, ninth generation and later.

As an enhancement over previous generations of Dell PowerEdge servers, shared NIC mode enables connection to the BMC through either LOM, not just one.

We were a bit worried about that, because on several of our servers LOM1 is attached to a dedicated management network and LOM2 is attached to the LAN, and we don't want the DRAC to be accessible from the LAN.

The puzzling thing is that, experimentally, it doesn't seem to be true. (Details below.) With the DRAC configured in shared mode, the DRAC is only reachable from LOM1, not from LOM2.

Is the article wrong? If not, how do I get the DRAC to respond on LOM2? (Short of using Failover mode which according to the article requires teaming, i.e., both LOMs must be on the same network.)

Most importantly, what, if anything, do I need to do to be certain that none of our DRACs are accessible via LOM2?

Test Procedure

The machine I'm experimenting with is PowerEdge 2970 with a DRAC 5, Hardware Version A00, Firmware Version 1.60 (11.03.03). The BMC Firmware Version is 2.50.

The NIC Selection is set to Shared and the NIC is enabled.

The static IP address is 192.168.241.100 and the subnet mask is 255.255.255.0. There is no gateway on our management network so I have that set to 0.0.0.0. Auto negotiation is on. None of the other settings are configured.

With the management network connected to LOM1 (and the LAN connected to LOM2) I can both ping the DRAC and log into the DRAC web interface from a production machine with access to the management network. (IP address 192.168.241.102/255.255.255.0.) I cannot ping the DRAC from a machine on the LAN (mis)configured to use 192.168.241.29/255.255.255.0, even after clearing the ARP cache.

With the management network connected to LOM2 (and the LAN connected to LOM1) I can neither ping the DRAC from the management network machine or connect to it via the web interface. Clearing the ARP cache had no effect. I can ping the DRAC and access the web interface from the machine on the LAN.

In both cases the operating system on the 2970 has full network connectivity on both the LAN and the management network (once the network interfaces are appropriately configured).

I also tried using WinDump to look for arp replies on both the management network and the LAN. In both cases, I saw arp replies from the DRAC only on the network that LOM1 was plugged into.

• From the LAN use arping to see if the DRAC is really non-accessible or just hidden by the netmask used for the LAN. – Brian Jan 19 '16 at 4:10
• @Brian: done. Arp replies were only visible on the network connected to LOM1. – Harry Johnston Jan 20 '16 at 1:11

Assuming that each LOM is connected to a different network (as you stated) and assuming that each of your networks uses a different network address, that would explain why you can only connect to the DRAC via one LOM/network and not the other.

For example, if you assigned the DRAC an ip address of 192.168.1.254/24 then you'll only be able to access it when you're connecting to it from a host on the 192.168.1.0/24 network. Now, if the other network is 10.0.0.0/8 (for example) then naturally you won't be able to connect to the DRAC at ip address 192.168.1.254 from a host on the 10.0.0.0/8 network.

Put another way, I can connect any network device to my physical network (Layer 2) but it doesn't have logical connectivity (Layer 3) unless I assign it an ip address in the correct Layer 3 network. In your case, the DRAC has physical connectivity (Layer 2) to both networks but it has logical connectivity (Layer 3) only in the network in which it's ip address is assigned.

So, make sure that you assign the DRAC a static ip address in the management network.

Edit based on our continued conversation and your testing:

Have a look at the info at this link and specifically how it describes shared mode operation:

Shared — Select this option to share the network interface with the host operating system. The remote access device network interface is fully functional when the host operating system is configured for NIC teaming. The remote access device receives data through NIC 1 and NIC 2, but transmits data only through NIC 1. If NIC 1 fails, the remote access device will not be accessible.

• I'm a little lost on how you were testing. Were you trying to access the DRAC interface via it's configured ip address? If, for instance, your testing host had an ip address of 192.168.1.253/24 and the DRAC had an ip address of 192.168.1.254/24 then you should have been able to connect regardless of which network you were connected to so long as both the testing host and the DRAC were connected to the same physical network. The actual ip addressing scheme in use on each network is irrelevant in this case. – joeqwerty Jan 19 '16 at 6:15
• If I have a physical network and I configure all of the hosts on that network to use an ip address in the 192.168.1.0/24 range I could still connect two devices to that network and configure them with an ip address in the 10.0.0.0/8 range and those two devices would be able to communicate with each other, regardless of the ip address range used by any other devices on that network. They wouldn't be able to communicate with any device with an address in the 192.168.1.0/24 range and vice versa but they'd be able to communicate between themselves. – joeqwerty Jan 19 '16 at 6:18
• To clarify, you disconnected LOM 1 and connected LOM 2 to the network that LOM 1 had been connected to? – joeqwerty Jan 19 '16 at 6:28
• Oh wait, I just thought of something. Each LOM should have a unique MAC address. So the ARP cache on the testing host would have the ip address of the DRAC associated with the MAC address of LOM 1. You wouldn't have been able to connect to the DRAC via LOM 2 until the ARP cache on the testing host flushed the LOM 1 MAC address and the testing host issued a new ARP for the DRAC ip address (resulting in getting the MAC address of LOM 2). How long did you wait while testing with LOM 2? – joeqwerty Jan 19 '16 at 6:31
• OK. I'll look for your update tomorrow. Thanks for giving me something interesting to think about for the evening. – joeqwerty Jan 19 '16 at 6:58