Forum Discussion

Cory_O's avatar
Cory_O
Icon for Cirrus rankCirrus
Sep 23, 2021
Solved

Error While Adding Peer Devices to Local Trust Domain

Hello,

I am attempting to create a DSC between two 12.1.5.3 VEs using the KB https://support.f5.com/csp/article/K13639.

I execute the following command to add the peer devices to the local trust domain:

modify /cm trust-domain /Common/Root ca-devices add { SECOND_MANAGEMENT_IP_REDACTED } name SECOND_HOSTNAME_REDACTED username admin password SECOND_PASSWORD_REDACTED

For some reason, when executed, I receive the following error:

std exception: ([xmlHelpers.cpp:90 getXPathValue] expected 1 node for //faultstring, got 0), exiting...

I receive the same error when processing the command through the TMUI as well. Self IPs in question are both configured as /30 (192.168.3.1 and 192.168.3.2), and 192.168.3.1 is locked to allow udp:1026 only where 192.168.3.2 also temporarily has tcp:443 allowed in addition as this is required for this step. I have tried setting both Self IPs to Allow Default to see if that was the issue, and it is not. I have also attempted to use an incorrect password, and receive a 'std exception: (iControl authorization failed), exiting...' error, so I know it is not an authentication issue.

Any thoughts? Thanks!

  • I have been working a SR with the support folks, and we have uncovered the following.

     

    I locked down iControl SOAP access to my environment using the steps listed in K17459. Unfortunately, there appears to be a bug where this particular configuration object doesn't recognize CIDR notations.

     

    As an example, I attempted both 192.168.1.0/24 and 192.168.1.0/255.255.255.0 to no avail. If I specify the exact IPs of the two DSC Members as individual IPs, the access is permitted.

     

    The NSE and ENE are working toward writing a bug for this. I will update this thread once they have one assigned.

     

    For those seeing this issue, use the workaround above (Specify individual IPs instead of CIDR) and you'll be able to continue with your work!

     

    HTH

1 Reply

  • I have been working a SR with the support folks, and we have uncovered the following.

     

    I locked down iControl SOAP access to my environment using the steps listed in K17459. Unfortunately, there appears to be a bug where this particular configuration object doesn't recognize CIDR notations.

     

    As an example, I attempted both 192.168.1.0/24 and 192.168.1.0/255.255.255.0 to no avail. If I specify the exact IPs of the two DSC Members as individual IPs, the access is permitted.

     

    The NSE and ENE are working toward writing a bug for this. I will update this thread once they have one assigned.

     

    For those seeing this issue, use the workaround above (Specify individual IPs instead of CIDR) and you'll be able to continue with your work!

     

    HTH