PowerFlex: Standardizing Data VLAN Tagging After PFxM Upgrade and OS Conversion

During the OS conversion from CentOS to SLES, it was identified that any node originally built under PowerFlex Manager (PFxM) 3.x using v1 networking—where Data1 and Data2 networks were untagged and connected to access VLAN switchports—did not transition cleanly to the PFxM 4.x networking model. These legacy nodes continued to rely on untagged interfaces for data networks, while newer nodes added under PFxM 4.x were deployed with interfaces using VLAN-tagging for Data networks.

During conversion, PFxM 4.x updated the Data network interfaces on these legacy nodes to VLAN-tagged SLES interfaces, but the associated switch ports remained configured as access ports. This condition caused the node in conversion to be isolated from the data networks, which prevented completion of the conversion process.

This procedure provides a clear, repeatable, field-ready method to standardize all nodes—especially those originally built under 3.x v1 networking—to the PFxM 4.x VLAN-tagged design to ensure consistent and reliable Data network operation.

• PowerFlex cluster originally deployed under PFxM 3.x with untagged Data1/Data2 networks (access VLANs).
• The cluster later upgraded to PFxM 4.x, which expects VLAN-tagged Data networks.
• Additional nodes added under PFxM 4.x with VLAN-tagged Data networks on trunk switchports.
• OS conversion from CentOS to SLES did not preserve untagged config on nodes while still using access VLAN switch ports.

The cluster contains a mix of nodes using untagged Data networks and nodes using VLAN-tagged Data networks. When nodes deployed with interfaces not using VLAN tags were upgraded, the interface setting was converted to use VLAN tags. The switch port interface configuration was not converted from access-mode to trunk mode. This created an incorrect mapping of data VLANS between the node interface and switch port. This caused isolation from Data networks for the affected nodes. The environment now needs a controlled, node-by-node remediation to standardize VLAN behavior.

The OS conversion process updates host NIC tagging but does not update or validate switchport mode, leading to a mismatch between host VLAN configurations and switch VLAN expectations.

Perform the following steps for each affected node. Only remediate one node at a time to maintain cluster redundancy and avoid unnecessary rebuilds.

Prechecks

• Verify that the cluster is healthy (no rebuilds in progress, all SDSs online).
• Identify nodes that still use untagged Data networks (for example: IPs configured directly on p2p2/em2 without.VLAN suffix)
• Record the node’s Data1 IP address and Data2 IP address.
• Back up the host network configuration files (for example: /etc/sysconfig/network scripts/ifcfg-*).
• Capture current switchport configuration for the node’s Data1 and Data2 ports for rollback if needed.
• Confirm the VLAN IDs used for Data1 and Data2 (for example: Data1 = 152, Data2 = 160)

Network and Host Changes:

Place the node in maintenance mode

Use PowerFlex Manager to place the node into maintenance mode.

Confirm that the SDS on this node is in maintenance and that no rebuild operations have started.

Update switch ports from access to trunk.

On the switch, update the Data1 and Data2 ports for this node.

Convert Data1 and Data2 switch ports from access mode to trunk mode.

• Ensure Data VLANs (for example, 152 and 160) are included in the trunk allowed VLAN list.
• Ensure that the correct switch port is identified (for example node interface p2p2 connects to switch port Ethernet 1/1)
• Verify that MTU is set to 9216 (or environment standard) on the switch.
• Enable spanning-tree edge trunk, bpduguard, and guard root as per design.

Example for data 1(before):

 Show running-config interface Ethernet 1/1
    switchport
    switchport access vlan 152
    spanning-tree port type edge
    mtu 9216

Example for data1 (after):

 Show running-config interface Ethernet 1/1
    switchport
    switchport mode trunk
    switchport trunk allowed vlan 152
    spanning-tree port type edge trunk
    spanning-tree bpduguard enable
    spanning-tree guard root
    mtu 9216

Sample execution script to change switch port settings.

configuration terminal
 interface ethernet 1/1
    switchport mode trunk
    switchport trunk allowed vlan 152
    no switchport access vlan 152
    spanning-tree port type edge trunk
    spanning-tree bpduguard enable
    spanning-tree guard root
    end
copy running-config startup-config

Update host OS network configuration

• Backup current network files.cd /etc/sysconfig/network-scripts/
• Edit and rename network interface files.
• Restart networking.
• Validate data network paths.

• Log in to the first SDS node
• Review interface that is being used:
• Display current interfaces and IP address:

ip address

• Review static routes and record them.
• Change to the network file directory:

cd /etc/sysconfig/network-scripts/

Review current network files:

ls -ltr

Backup current network file

cp /etc/sysconfig/network-scripts/ifcfg-<devicename>  /etc/sysconfig/network-scripts/ifcfg-<devicename>.bak

Rename current network file.

mv /etc/sysconfig/network-scripts/ifcfg-<devicename> /etc/sysconfig/network-scripts/ifcfg-<devicename>.<vlan>

Example:

mv /etc/sysconfig/network-scripts/ifcfg-em2 /etc/sysconfig/network-scripts/ifcfg-em2.152

Edit network file.

vi /etc/sysconfig/network-scripts/ifcfg-<devicename>.vlan

Example:

vi /etc/sysconfig/network-scripts/ifcfg-em2.152

Update device name with <dot>vlan id and insert VLAN=yes

DEVICE=em2.152

VLAN=yes

Quit and save the file.

:wq!

Repeat for other data network

Restart networking and validate

Restart the network service on the host or perform a controlled reboot.

Static routes configuration

Perform ssh to the SDS node.

Run the following command:

ip route

Ensure that no routes reference untagged interfaces (e.g., em2, p2p2). All routes must reference VLAN-tagged equivalents.

Example 

default via 172.18.133.1 dev bond0.1352

172.18.133.0/24 dev bond0.1352 proto kernel scope link src 172.18.133.100

192.168.152.0/21 dev p2p2.152 proto kernel scope link src 192.168.152.100

192.168.160.0/21 dev em2.160 proto kernel scope link src 192.168.160.100

Network Validations

Verify that the VLAN interfaces (for example, p2p2.152 and em2.160) are up.

Example

 ip address

From the host, ping a known peer or on each VLAN using interface-sourced pings.

Example

ping -I p2p2.152 <peer>

Optional: Test a jumbo-frame MTU using ping with a large payload.

Example

ping -I p2p2.152 -s 8972 -M do <peer>

Exit maintenance mode

 In PowerFlex Manager, verify SDS and device health on the node.

 Exit maintenance mode for the node.

 Monitor for alerts, SDS restarts, or link flaps for several minutes.

Repeat for remaining nodes

Repeat for each remaining node that still uses untagged Data networks until the entire cluster is standardized to VLAN-tagged Data interfaces consistent with the PFxM 4.x design.

Validation Test Plan (Summary)

• MTU Validation: Confirm VLAN interfaces use MTU 9000, and jumbo ping tests succeed to peers on Data1 and Data2.
• SDS Validation: Confirm that SDS is connected, no restarts occur, and device paths are aligned.
• Network Connectivity: Verify east-west connectivity to multiple peers on both Data VLANs (ping from p2p2.152 and em2.160).
• Failover: Temporarily disable Data1 and Data2 interfaces one at a time to confirm SDS remains online using the remaining path and redundancy is restored after reenabling.
• SCR/PFxM: Run SCR and PowerFlex Manager health checks to confirm there are no VLAN/MTU/network-related errors.

Affected Platforms/Versions

- PowerFlex 3.6.x/3.7.x / 3.8.x nodes originally deployed with access-mode VLANs
- PowerFlex 4.x PFMP conversions to SLES
- Dell R640/R740 servers
- Cisco Nexus switches, Dell OS10-based switches

Fixed In Version

4.6.2.1