dump persistence records

I'm currently struggling with the same issue on TMOS 9.4.5 using the 9.6.0 and 10.0.0 iControl assemblies. Exact same exception regardless of using the pool or virtualserver method. If you don't catch the exception the method will return nothing and your app will hum along as if nothing went wrong.

 

Here is the code:

 

    
 string[] sVSList = new string[] { cbVSList.SelectedItem.ToString() }; 
  
             LocalLBPersistenceMode[] oLBPersistMode = new LocalLBPersistenceMode[] { LocalLBPersistenceMode.PERSISTENCE_MODE_NONE }; 
             // PERSISTENCE_MODE_NONE will cause it to return all types. 
             LocalLBPersistenceRecord[][] PulledPersistTable = new LocalLBPersistenceRecord[][] { }; 
             try 
             { 
                 PulledPersistTable = if_iControl.LocalLBVirtualServer.get_persistence_record(sVSList, oLBPersistMode); 
                 //PulledPersistTable = if_iControl.LocalLBPool.get_persistence_record(sVSList, oLBPersistMode); 
             } 
             catch (Exception e)  
             { 
                 MessageBox.Show(e.ToString()); 
             } 
 

 

And attached is the offending HTTP return captured via Fiddler2. Please let me know if there is any other information I can provide.

Thanks kvondersaar

 

 

I did the try/catch, but the did not get the record populated, as you did. So, I am not sure I am having the exact same issue. I did as Joe instructed, and opened a support case - I will post their findings as they become available.

From Support:

 

Perry,

 

 

Our escalation engineer notes that the BIG-IP LTM returns about 82K of data to the client before the iControl application issues a TCP Reset to terminate the connection. He is able to retrieve persistence data via a perl script, which runs successfully against v9.3.1 and v9.4.5-HF2 systems. He plans to update his 9.3.1 system to HF2, to match your environment, and to write a Visual C 2005 test application with which to continue analysis. He also notes that his perl script is able to parse the XML data being returned -- which is essentially identical to the results in the tcpdump/ssldump captures.

 

 

I'll continue updating you as I receive news. Thank you.

 

 

Respectfully,

 

 

Charles Curtis-Stanley | Senior Network Support Engineer

 

F5 Network Support

According to the escalation engineer:

 

 

> I've verified that the LTM is returning correctly formated XML data

 

> while with and without persistence information stored on the LTM. The

 

> customer's packet traces also show that the application buffers the

 

> LTM response and after the data is feed to the XML parser, the XML

 

> parser claims that the returned data is invalid. The data in the

 

> customer's traces are near identical to the XML output from my tests.

 

> Most likely the XML serializer is not able to parse the AoA which

 

> results in the error that they are seeing and if this is the case, this is a limitation of the XML serializer, not a fault of the product. The customer should verify that the XML serializer is able to handle the returned data.

 

 

The decrypted C511568.icontrol.txt file definitely shows well-formed XML being sent in response to the POST request that's submitted to /iControl/iControlPortal.cgi, up to the point where the client system issues a RST response to terminate the TCP connection. I'm not sure what an "AoA" is, but it seems to be the case that the XML serializer used by Visual Studio is not a happy camper when it receives it.

 

 

Bottom line: this seems to be a Microsoft Visual Studio issue, not a BIG-IP LTM iControl problem.Respectfully,

f5 support has created an engineering hotfix (Hotfix-BIGIP-9.3.1-HF6-69.14-ENG) that can be applied on top of 9.3.1 HF6. This will be incorporated into HF7 for 9.3.1.

Installed the engineering hotfix, and am now able to pull persistence records with iControl. Thanks f5 Support! Thanks Joe!