The isam appliances allow you to use bonding or network aggregation. (https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.0/com.ibm.isam.doc/admin/task/tsk_cfg_aggregated_int.html).

This is a good idea for the “data” interfaces, IF

  • you are using the hardware appliance
  • have only a single network you connect to (single subnet)
  • you have a need for higher total throughput
  • your network switch supports LACP ( 802.3ad )

It is also possible to setup Dynamic Link Aggregation (lacp) for the management interfaces - although you can use the interfaces on the hardware appliance for whatever you want them to do, the first 2 are marked on the box as “management”.

It sounded like a good idea to do this - create a bond between the first 2 interfaces (albeit a bit overkill, because there is no need for the higher throughput on the management interfaces).

But it turns out, it can be a bad idea in recovery situations (depending on how close you are with your network team ).

To activate LACP , you first have to configure the bonding configuration on the appliance and then change the network ports on the switch you connect to from static ports to aggregate ports (terminology may vary).
ISAM will then briefly disconnect and reconnect, with a working bonding interface.

So far , so good.

The problem begins when you run into problems and want to reset the appliance (of you don’t have problems, you just want to reset the appliance).

The appliance then goes back to a default configuration, where the first interface tries to obtain an ip address over dhcp.

This fails, because the switch is still configured for LACP , and not for a simple static port. The appliance does not get an ip address.

No worries, you can connect to the appliance using the serial console interface (a connector is included with the appliance). You can then use putty or securecrt or some terminal program to open a serial connection to the appliance.

Now for the problem :

the console interface does not provide possibility to configure bonding on the interfaces. This means you cannot get the management interface up and running , so you cannot access the LMI.

Note that this not have to be a huge problem, depending on your organization.

  • you can activate/configure another interface as management interface, where you can connect to the LMI on
  • you can ask your network team to de-activate LACP on the switch
  • you could use a different type of bonding/link aggregation , that works with normal static ports (I have not investigated other modes in detail)

But in large organizations, getting every part of it to do exactly what you want at the right time can be challenging . The simpler solution is to not use bonding at all for the management interface, and keep the second management interface as a backup (unconfigured). In case of failure of the first interface, you can activate the second interface using the serial console.