For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

DC_Jordan_18536's avatar
DC_Jordan_18536
Icon for Nimbostratus rankNimbostratus
Feb 08, 2015

Redundancy add new device to peer list

when adding the device on peer list give me the below message Trust daemon returned an error: 0107146f:3: Self-device unicast source address cannot reference the non-existent Self IP (192.168.1.245); Create it in the /Common folder first.

 

application delivery
deployment
LTM

2 Replies

  • NikhilB's avatar
    NikhilB
    Icon for Employee rankEmployee
    Feb 08, 2015

    The unicast failover address need to be reachable from each of the peer units. Ping each one from one another. If there is an issue then reachability would be what needs to be addressed first.

     

  • StephanManthey's avatar
    StephanManthey
    Icon for Nacreous rankNacreous
    Feb 08, 2015

    Hi Mawad,

     

    before adding a new device to list of trusted peers it will be necessary to have the settings done for failover, config sync and mirroring.

     

    These settings can be found in WebUI via Device Managment > Devices > Device Properties (Connectivity).

     

    Another nice-to-have from my perspective is a unique device certificate. But that´s not mandatory.

     

    Device trust is independent from device certificates. Instead so called device trust device identity certificates (dtdi.crt) are used which are signed by the device trust certificate authority (dtca.crt) of the device group.

     

    To rebuild a cluster I used to set all but one device into "forced offline" mode, reset device trust on all machines, make sure to have settings done as described above and start to add peers on the remaining active unit.

     

    This needs to be done on the active unit only.

     

    Once you are done, you can add all devices to a sync-failover device-group and do the initial sync.

     

    One more thing to mention: forcing a vCMP guest into device mode "forced offline" used to break all interface communications of this guest. That´s why this part will not work in vCMP environments (applies to TMOS v11.2.1 - v11.5.1 as far as I can say).

     

    Thanks, Stephan