Symptoms

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.

Cause

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.

Resolution

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 nodeReview 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.8.0.1

Support Cases