Learn › BMC & Server Management › Operations

Network Config

Audit a BMC's own network identity: its address, MAC, VLAN, and how the management plane is actually wired. Read it from inside and outside with interactive diagrams, then fence a real Dell BMC onto management VLAN 207.

It is 07:40 at the DC-EAST facility in Ashburn, Virginia. The network team ran their quarterly switch audit on Row 7 overnight, and one port came back flagged. The BMC of the Dell PowerEdge R750xs in Bay 14 is alive on the deployment bridge, untagged.

The Row 7 standard is strict: every BMC lives fenced on management VLAN 207, with a pinned identity in the 10.20.7.0/24 range. The rack-and-stack crew cabled this one, energized the rack, and walked away. Nobody filed its network paperwork.

Work order DC-EAST-WO-1007 is on your tablet: audit the BMC's network identity end to end, file the evidence, and tag the fence before tonight's cutover window.

This is a Practice Zone. The diagrams below react to you: click the boxes, flip the switches. The real machine comes at the end, under Ready to practice.

A BMC's network identity is four configured numbers riding one factory fact:

One more word before the diagram. IPMI numbers its network interfaces as channels. Channel 1 is the LAN channel on this box: the front door every remote audit walks through.

{ "height": 380, "caption": "The path an audit query rides. Click any hop.", "nodes": [ { "id": "you", "label": "You (NOC)", "kind": "admin", "x": 0, "y": 110, "detail": "Your workstation dc-east-ws01. Every audit in this work order starts here, over the management network." }, { "id": "rowsw", "label": "Row 7 mgmt switch", "kind": "net", "x": 230, "y": 110, "detail": "The switch port report that flagged this work order lives here. The switch sees the BMC port's MAC address and whether its frames carry a VLAN tag." }, { "id": "bmcport", "label": "BMC port", "kind": "nic", "x": 460, "y": 110, "detail": "The dedicated RJ45 on the back of the server. The MAC D4:AE:52:B1:23:45 is burned into this port at the factory, the one part of the identity nobody configures." }, { "id": "chan1", "label": "LAN channel 1", "kind": "net", "x": 690, "y": 110, "detail": "IPMI numbers its interfaces as channels. Channel 1 is the LAN channel that remote audits read. Channel 2 does not exist on this box, and asking for it errors." }, { "id": "bmc", "label": "BMC config store", "kind": "bmc", "x": 920, "y": 110, "detail": "Where the configured identity lives: IP source, address, mask, gateway, and VLAN ID are all records in here." }, { "id": "host", "label": "Host OS", "kind": "host", "x": 920, "y": 300, "detail": "Sees none of this. The management identity exists, and answers, even when this box is powered off." } ], "edges": [ { "from": "you", "to": "rowsw", "label": "ipmitool / ssh", "kind": "mgmt" }, { "from": "rowsw", "to": "bmcport", "kind": "mgmt" }, { "from": "bmcport", "to": "chan1", "label": "frames enter", "kind": "mgmt" }, { "from": "chan1", "to": "bmc", "kind": "mgmt" }, { "from": "bmc", "to": "host", "label": "manages", "kind": "plain" } ] }

Trace the lane. The identity you are auditing lives in the BMC's config store, but every hop has its own view of it: the switch sees the MAC and the tag, the port owns the MAC, channel 1 carries the query, and the store holds the four numbers. A proper audit compares those views against each other.

Those four numbers have to come from somewhere, and there are two answers. They behave very differently at 2 a.m.

DHCP means the BMC rents its address. A DHCP server offers a lease, the BMC takes it, and the lease must be renewed while the server stays alive. Static means the identity is pinned in the BMC's own config store: no lease, no renewal, no dependency.

Flip the source and watch what the BMC stops depending on.

{ "height": 360, "caption": "On DHCP, the reachability of your emergency door depends on one extra box staying alive.", "nodes": [ { "id": "you", "label": "You (NOC)", "kind": "admin", "x": 0, "y": 190 }, { "id": "dhcp", "label": "DHCP server", "kind": "net", "x": 260, "y": 30, "detail": "Leases are rented. They expire, and this server must be alive to renew them. Every DHCP client's reachability depends on this one box." }, { "id": "msw", "label": "Mgmt switch", "kind": "net", "x": 260, "y": 190, "detail": "Row 7's management switch. It forwards frames either way; who hands out the address is decided elsewhere." }, { "id": "bmcport", "label": "BMC port", "kind": "nic", "x": 520, "y": 190, "detail": "The same dedicated port in both modes. The wire does not change, only where the identity comes from." }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 760, "y": 190, "detail": "IP Source Static means the identity is pinned in the config store and survives any outage that leaves standby power on." }, { "id": "host", "label": "Host OS", "kind": "host", "x": 980, "y": 300 } ], "edges": [ { "from": "you", "to": "msw", "kind": "mgmt" }, { "from": "dhcp", "to": "msw", "label": "lease offers", "kind": "mgmt" }, { "from": "msw", "to": "bmcport", "kind": "mgmt" }, { "from": "bmcport", "to": "bmc", "kind": "mgmt" }, { "from": "bmc", "to": "host", "kind": "plain" } ], "toggle": { "label": "IP source:", "on": "Static (pinned)", "off": "DHCP (leased)", "dimOn": ["dhcp", "e:dhcp-msw"], "dimOff": [] } }

This is why the Row 7 standard says pinned. The BMC is the door you use when everything else is broken, so its address must not depend on another machine being healthy.

Time to audit. You know the first move from first contact: SSH lands you on the BMC's own Dell shell. The address is in $BMC_IP, credentials ADMIN / ADMIN:

sshpass -p ADMIN ssh -o StrictHostKeyChecking=no admin@$BMC_IP

Once you are standing at the /admin1-> prompt, the firmware's own record of its network identity is one word away: netconfig.

prompt: /admin1-> answer: netconfig output: BMC Network Configuration ============================================================

IP Source: Static IP Address: 10.20.7.14 Subnet Mask: 255.255.255.0 Default Gateway: 10.20.7.1 VLAN ID: none MAC Address: D4:AE:52:B1:23:45 hint: You are already inside the BMC shell. The command is one word: netconfig

Read it line by line, against the Row 7 standard. IP Source Static: pinned, good. IP 10.20.7.14 inside 10.20.7.0/24: correct subnet. Gateway 10.20.7.1: the row gateway, good. MAC D4:AE:52:B1:23:45: the factory fingerprint the switch report also saw.

And there it is. VLAN ID: none. The switch audit was right: this BMC is sitting on the wire untagged.

Nobody opens an SSH session into four thousand BMCs one at a time. The fleet way is IPMI from your workstation: one command, no interactive shell, and it works the same against any vendor. Ask channel 1 for its full LAN parameter table:

ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN lan print 1

prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN lan print 1 output: Set in Progress : Set Complete Auth Type Support : NONE MD2 MD5 PASSWORD Auth Type Enable : Callback : NONE MD2 MD5 PASSWORD : User : NONE MD2 MD5 PASSWORD : Operator : NONE MD2 MD5 PASSWORD : Admin : NONE MD2 MD5 PASSWORD : OEM : IP Address Source : Static Address IP Address : 10.20.7.14 Subnet Mask : 255.255.255.0 MAC Address : d4:ae:52:b1:23:45 SNMP Community String : public IP Header : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00 Default Gateway IP : 10.20.7.1 Default Gateway MAC : 00:00:00:00:00:00 Backup Gateway IP : 0.0.0.0 Backup Gateway MAC : 00:00:00:00:00:00 802.1q VLAN ID : Disabled 802.1q VLAN Priority : 0 RMCP+ Cipher Suites : 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 Cipher Suite Priv Max : aaaaaaaaaaaaaaa : X=Cipher Suite Unused : c=CALLBACK : u=USER : o=OPERATOR : a=ADMIN : O=OEM Bad Password Threshold : Not Available hint: Same remote IPMI form as always, and the subcommand is: lan print 1

Same identity, second witness. IP Address Source says Static Address, the four numbers match netconfig exactly, and the MAC is the same fingerprint, just printed lowercase. The RMCP+ Cipher Suites line even shows why -C 3 works here: suite 3 is on the menu.

And the defect shows up again, from a completely independent plane: 802.1q VLAN ID: Disabled.

One question left on the audit sheet: what is channel 1 physically riding? Ask the channel itself:

ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN channel info 1

prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN channel info 1 output: Channel 0x1 info: Channel Medium Type : 802.3 LAN Channel Protocol Type : IPMB-1.0 Session Support : multi-session Active Session Count : 1 Protocol Vendor ID : 7154 Volatile(active) Settings Alerting : enabled Per-message Auth : enabled User Level Auth : enabled Access Mode : always available Non-Volatile Settings Alerting : enabled Per-message Auth : enabled User Level Auth : enabled Access Mode : always available hint: Same flags as the audit, but now you want info about channel 1

Channel Medium Type: 802.3 LAN. That is real ethernet, the dedicated port from the diagram, not a serial line or a sideband. Multi-session with an Active Session Count of 1: the one session is you, right now.

The BMC in this lab is a standards-faithful emulator: it speaks real IPMI, and every command here is verbatim what you would run on hardware. One honest difference: changing its LAN parameters changes what it reports, not how the lab network is wired, so it stays reachable at $BMC_IP no matter what you set. And your write lands in the IPMI plane only: lan print will show it, while the Dell shell's netconfig keeps reading its own record, so verify from the plane you changed. A real iDRAC applies the change live, to the wire and to every readout at once, and a wrong address or VLAN cuts off your own session. Crash cart time.

So what does 802.1q VLAN ID: Disabled actually expose? The deployment bridge is flat: provisioning jobs, imaging traffic, and every half-configured box the crew patches in can all knock on this BMC's port. None of that traffic has any business seeing a management controller.

VLAN 207 is Row 7's fence. Flip the tag and watch who loses sight of the BMC.

{ "height": 420, "caption": "The fence is not a cable change. It is a tag the BMC starts stamping on its own frames.", "nodes": [ { "id": "you", "label": "You (NOC)", "kind": "admin", "x": 0, "y": 170 }, { "id": "neighbor", "label": "Other deploy traffic", "kind": "host", "x": 0, "y": 360, "detail": "Provisioning jobs, imaging traffic, anything else on the flat bridge. None of it has any business seeing a BMC." }, { "id": "flat", "label": "Deployment bridge (untagged)", "kind": "net", "x": 300, "y": 280, "detail": "The flat network the rack-and-stack crew left this BMC on. Anything patched into it can reach the BMC's port." }, { "id": "v207", "label": "Mgmt VLAN 207", "kind": "net", "x": 300, "y": 60, "detail": "The Row 7 standard fence. Only tagged members of VLAN 207 can see this lane." }, { "id": "bmcport", "label": "BMC port", "kind": "nic", "x": 620, "y": 170 }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 860, "y": 170 } ], "edges": [ { "from": "you", "to": "flat", "label": "flat access", "kind": "inband" }, { "from": "you", "to": "v207", "label": "tagged 207", "kind": "mgmt" }, { "from": "flat", "to": "bmcport", "kind": "inband" }, { "from": "v207", "to": "bmcport", "kind": "mgmt" }, { "from": "neighbor", "to": "flat", "kind": "plain" }, { "from": "bmcport", "to": "bmc", "kind": "mgmt" } ], "toggle": { "label": "802.1q VLAN ID:", "on": "207 (fenced)", "off": "Disabled (flat wire)", "dimOn": ["flat", "neighbor", "e:you-flat", "e:flat-bmcport", "e:neighbor-flat"], "dimOff": ["v207", "e:you-v207", "e:v207-bmcport"] } }

The fix is one write to the config store. The lan set family edits the same parameters lan print reads:

ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN lan set 1 vlan id 207

Its siblings, which you should recognize on sight even though this work order only needs the VLAN:

Two production rules before you touch anything. First, file the before picture: capture the audit output to a file before you change a single parameter. Second, on real hardware this exact command can saw off the branch you are sitting on. Tag the BMC into a VLAN your workstation cannot reach, and your session dies with no way back except a crash cart or the front-panel LCD. Always know your out-of-band way into the out-of-band plane before you write.

The before and after files are not busywork. They are the change record the network team signs off on when the work order closes, and the first thing anyone pulls when something breaks next week.

Time to do it for real. On the machine you are about to open, close out Work Order DC-EAST-WO-1007. The BMC address is preset in $BMC_IP, credentials ADMIN / ADMIN.

Six objectives stand between this BMC and the Row 7 standard:

1. Raise the BMC shell. Get inside and pull the firmware's own network record. 2. Audit from outside. Read the same identity from your workstation over IPMI, the fleet way. 3. Interrogate the wiring. Establish what channel 1's wire actually is. 4. File the before picture. The evidence goes to ~/network-before.txt. 5. Tag the fence. Put this BMC on Row 7's management VLAN, 207. 6. The challenge. Put proof the fence is live on file in ~/network-after.txt. No structure given.

Here is the deal: the workspace shows no commands. It hands you one objective at a time, and you recall the move. That recall is the whole point; it is how this morning's reading becomes your skill.

Stuck is normal. Hit Request a signal on any objective for a nudge, or ask Daemon. It knows exactly which task you are on and will nudge, not spoil.

Your workstation dc-east-ws01 is booting in the bay below, with the Dell BMC beside it on the lab bridge. $BMC_IP and the ADMIN / ADMIN credentials are already set for you. The cutover window opens tonight. Launch the machine and close WO-1007 before it does.

Practice Network Config in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.