cancel
Showing results for 
Search instead for 
Did you mean: 
0 Votes

Connectivity Tester / Rediscovery

In my use of LXCA, on occasion, we have servers and/or chassis with (connectivity) against their name, or to be offline entirely. This results in being unable to deploy firmware to these servers, or in the case of being offline we can't monitor the state of them. When this occurs we normally restart the XCC/IMM and then restart LXCA. In some cases we just restart LXCA.

We would like to manually (via GUI) attempt a re-connection to a specific server (XCC/IMM/CMM) which is offline or has connectivity issues without a restart of LXCA. 

 

During the reconnection attempt to the IMM/XCC/CMM, detailed information would be useful. For example,

IP ping test = passed

Port Connectivity test = passed

Endpoint API test = passed

.....

Attempting connection = passed

 

Ideally, if the tests pass, then the connection should be successful. Any failures should show detailed information of what failed. eg, couldn't connnect from eth0 on LXCA (IP X.X.X.X) to IMM (Y.Y.Y.Y) over PORT Z.

 

Having this would allow for tests to be done with internal networking teams to 'attempt the connection' which can be shown as being dropped or blocked.

 

 

Comments
Lenovo Staff
Status changed to: Tell Us More

s3069260,

 

Thanks for your feedback.  

 

You are correct that connectivity issues generally stem from the state of the XCC/IMM; and restarting XCC/IMM is the most effective way to recover.  Note that we are continuing to work towards fixes on both sides to help avoid this problem rather than work around it, but your suggestion makes sense for the cases where connectivity is still lost. 

 

Would you consider it acceptable if the main function of the "reset connection" feature you suggest was in fact to reset the XCC/IMM on the managed system? 

 

 

Paper Tape

Reset the XCC/IMM on the managed system probably wouldn't work (would it?), as the connectivity to that endpoint (from LXCA) is down/noncontactable.

 

I was thinking two steps:

1. Re-attempt connection (or rediscovery)

2. Report on connection attempt and cause of failure.

 

The report is where its important. It should state,

- the source IP which the connection was made (LXCA eth0)

- what device it couldn't connect to (CMM or IMM, provide destination IP)

- the port it was trying to communciate over 

 

These three pieces of information would allow us to identify the device which is causing the communciation problem (IMM or CMM) and we can restart that management device. Additionally, and more importantly, if that failed, we can start network captures to see where the data is going across our network and it provides the source, destination and port. The 'reattempt connection' feature also allows to generate failing traffic for live network troubleshooting.

 

If you can add the ability, or option, to restart the IMM/CMM through LXCA during this process that would be a value-add.

 

 

Lenovo Staff
Status changed to: Considering Implementation

Thanks for this suggestion. 

 

We are working with the XCC/IMM teams to improve connectivity and the ability to recover from disruptions in it. 

 

Note that in the meantime you can already reset the IMM/XCC en masse using the Power Actions menu, and then perform Refresh Inventory on those systems once reset is complete.  This is a two-step process that would be close to the one-button solution you requested.  

 

I'm moving this to Considering Implementation because your idea about providing some specific information about the status of the recovery is interesting and useful.  

 

JGM

Top Kudoed Authors