Data Domain: Intel E810 Interfaces May Fail to Initialize After Upgrade

One or more network interfaces do not come online correctly after a DD OS upgrade and reboot.
Network connectivity tests such as ping may fail on the affected interfaces.
Interface-specific routing tables and routing rules are missing after the upgrade.
Network communication may not resume until the affected interfaces, and corresponding switch ports are reset.
System logs may contain link parameter configuration errors during interface initialization.
Routing rules are automatically recreated after affected interfaces are manually disabled and re-enabled.

Example
Prior to the upgrade, interface-specific routes and routing rules are present.
For example, output similar to the following may be observed:

Before Upgrade:

GENERATED_ON=Tue Apr 14 05:48:12 CEST 2026
VERSION=DD OS 8.4.0.10-1315721

Net Route Show Gateway Detailed
-------------------------------
IPv4 Default Gateways

gateway IP    source     tables      interface address   owner
-----------   --------   ---------   -----------------   -----
172.31.71.1   vnet0      tvnet0      172.31.71.52/24     none
172.31.72.1   vnet1.21   tvnet1.21   172.31.72.36/24     none
172.31.72.1   vnet2.21   tvnet2.21   172.31.72.38/24     none
10.150.68.1   static     tnet2a      10.150.68.50/24     none
10.150.68.1   static     tnet4a      10.150.68.51/24     none
10.150.68.1   static     tnet6a      10.150.68.52/24     none
10.150.68.1   static     tnet6c      10.150.68.58/24     none
-----------   --------   ---------   -----------------   -----

We see the routing rules are present:

Table: tnet2a
Kernel IP routing table:
default via 10.150.68.1 dev net2a
10.150.68.0/24 dev net2a scope link src 10.150.68.50
Routing rules:
32748: from all oif net2a lookup tnet2a
32749: from 10.150.68.50 lookup tnet2a
Table: tnet4a
Kernel IP routing table:
default via 10.150.68.1 dev net4a
10.150.68.0/24 dev net4a scope link src 10.150.68.51
Routing rules:
32742: from all oif net4a lookup tnet4a
32743: from 10.150.68.51 lookup tnet4a

After Upgrade:

GENERATED_ON=Tue Apr 14 15:21:47 CEST 2026
VERSION=DD OS 8.4.1.22-1389047

The rules are missing:

Table: tnet2a
Kernel IP routing table:
Routing rules:
Table: tnet6a
Kernel IP routing table:
Routing rules:
Table: tnet6c
Kernel IP routing table:
Routing rules:
Table: tnet4a
Kernel IP routing table:
Routing rules:

After the interface was explicitly disabled and enabled, the rules were added back by sms routine:
The rules are added back after CLI was executed (notice how it is still missing for other interfaces net6a and net6c):

Net Route Show Gateway Detailed
-------------------------------
IPv4 Default Gateways

gateway IP    source     tables      interface address   owner
-----------   --------   ---------   -----------------   -----
10.150.68.1   net2a      tnet2a      10.150.68.50/24     none
10.150.68.1   net4a      tnet4a      10.150.68.51/24     none
10.150.68.1   static     tnet6a      10.150.68.52/24     none
10.150.68.1   static     tnet6c      10.150.68.58/24     none
172.31.71.1   vnet0      tvnet0      172.31.71.52/24     none
172.31.72.1   vnet1.21   tvnet1.21   172.31.72.36/24     none
172.31.72.1   vnet2.21   tvnet2.21   172.31.72.38/24     none
-----------   --------   ---------   -----------------   -----

Table: tnet6a
Kernel IP routing table:
Routing rules:
Table: tnet6c
Kernel IP routing table:
Routing rules:
Table: tnet2a
Kernel IP routing table:
default via 10.150.68.1 dev net2a
10.150.68.0/24 dev net2a scope link src 10.150.68.50
Routing rules:
32756: from all oif net2a lookup tnet2a
32757: from 10.150.68.50 lookup tnet2a
Table: tnet4a
Kernel IP routing table:
default via 10.150.68.1 dev net4a
10.150.68.0/24 dev net4a scope link src 10.150.68.51
Routing rules:
32754: from all oif net4a lookup tnet4a
32755: from 10.150.68.51 lookup tnet4a

The missing rules caused the ping to fail.
While checking what caused the rules to be missing, these errors are found in the logs. 

sms: INFO: sms_net_set_iface_job: interface net2a, cmd ENABLE, dhcp no, cur addr 10.150.68.50, new addr 10.150.68.50
sms: INFO: sms_net_set_iface_job: interface net2a, AN 1, duplex 0, speed 0, fec 0
sms: INFO: Invoking side-fx for setting key with prefix config.net
sms: INFO: Invoking side-fx for setting key with prefix config_master
sms: INFO: sms_net_core_config_iface: iface interface net2a, AN 0, duplex 0, speed 0, fec 16
sms: INFO: sms_net_core_config_iface: config interface net2a, AN 1, duplex 0, speed 0, fec 0
sms: INFO: _sms_net_config_iface_link_mode:Configuring link_mode: net2a, autoneg: 1 speed: 0 duplex: 0 fec: 0
sms: NOTICE: deleting lease file for interface net2a
sms: INFO: _sms_net_enable_iface: interface net2a, AN 1, duplex 0, speed 0, fec 0
sms: INFO: _sms_net_enable_iface: config net2a to add 10.150.68.50 and delete no IPv6 addr for self
sms: INFO: dd_plib_net_setup: Change IF net2a for type 2, state: RUNNING
sms: NOTICE: dd_net: plib: _net_set_if(): IP address 10.150.68.50 for net2a set successfully
sms: INFO: dd_net: plib: Took 3 sec to go to running state for net2a
sms: INFO: dd_net: plib: _net_set_params interface net2a: HW settings autoneg 1 speed 0 duplex 0 fec 0
sms: INFO: _set_iface_state(): ifname=net2a, rq_state=4, if_state=0x1043
sms: ERROR: _net_set_params_pe interface net2a: failed to set link parameters, error : 95 (Operation not supported)
sms: ERROR: dd_net: plib: _net_set_if(): _net_set_params() failed for iface net2a, error Operation not supported
sms: ERROR: dd_plib_net netrq: net2a, addr=10.150.68.50, netmask=255.255.255.0, ifstate=RUN, autoneg=1, full_duplex=0, speed=0, ipv6ready=1,
sms: ERROR: Error: <22: *** Failed to set link parameters., ddr/lib/dd_plib_net.c, _net_set_params_pe, 2597>
sms: NOTICE: dd_plib_net_setup(): Interface, net2a, configuration complete, err = 22.
sms: ERROR: _sms_net_enable_iface: Could not enable interface net2a error *** Failed to set link parameters.
sms: ERROR: sms_net_core_config_iface*** Failed to set link parameters.

Interface-specific routing rules tied to the source IP address and egress interface.

After Upgrade and Reboot the interfaces may appear configured, but the interface-specific routing tables and routing rules can be missing entirely for affected interfaces. As a result, network communication may fail even though IP addresses remain configured on the interfaces.
After the affected interfaces are disabled and re-enabled, the routing tables and routing rules are recreated automatically and connectivity is restored.

This issue can occur during interface initialization after a DD OS upgrade and reboot. On affected systems, the network initialization process may fail to correctly configure link parameters, causing interfaces to not fully initialize and preventing expected routing rules from being created.
The issue has been observed on systems using Intel E810 network adapters connected with Direct Attach (DA) cables. As a result, interface-specific routing entries may not be established, leading to connectivity failures on the affected interfaces.
Symptoms may coincide with interface initialization errors recorded during boot or during subsequent network configuration operations.

As an immediate recovery action, restore connectivity by reinitializing the affected network path.

This may involve:

Disabling and re-enabling the affected Data Domain interfaces.
Bouncing or resetting the connected switch ports.
Verifying physical link establishment between the Data Domain interface and the switch.
Confirming that interface link negotiation completes successfully.
Verifying the interfaces return to a RUNNING state.
Confirming that interface-specific routing tables and routing rules have been recreated.
Validating network connectivity after the interfaces have been re-established.

In the investigated case, connectivity was restored after the affected Data Domain interfaces and associated switch ports were bounced. Once the interfaces reinitialized successfully, the missing routing rules were recreated and network communication resumed.
Long-Term Resolution
Customers experiencing this behavior should upgrade to DDOS-8.3.1.40, DDOS-8.6.1.20, DDOS-8.7.0.1, DDOS-8.8.0.0 or a newer maintenance release containing the fix. Upgrading is recommended to prevent recurrence during future reboots, upgrades, or interface initialization events.