Forum Discussion
gmtiwill_127449
Nimbostratus
Nimbostratusget_al_active_connections() crashes iControlPortal.cgi
Whenever I execute the following code, iControlPortal.cgi crahses. The error in the syslog is pid 381 (iControlPortal.c), uid 1: exited on signal 6 (core dumped). The code is as follows:
my $soap = SOAP::Lite
-> uri('urn:iControl:ITCMLocalLB/Connections')
-> proxy("https://$sHost:$sPort/iControl/iControlPortal.cgi"
);
my $resp = $soap->get_all_active_connections(
SOAP::Data->name(mirror_flag=> 0),
);
Am I doing something wrong here? I am able to execute this method against a BigIP that does not have any connections, but consistently get a 500 Internal Server Error when executing against the production SLB.
Thanks,
Will
11 Replies
- Currently, *most* connection and persistence information can be mirrored between a redundant pair. In the past, I wrote an emulator for shining a little light on the mirroring process. Lately, it has occurred to me that this same sort of thing--connection add and delete events--might be useful for customers for data mining purposes.
If I were architecting something like this, I'd mirror the traffic to a machine setup for traffic monitoring* and put some logic on *it* to create classes** that I then passed to bigip via iControl. Furthermore, you could even use the existing aol class on BIGIP to help alleviate the monster proxy issue.
*I assume there are existing products with this capability. If not, this sort of filtering would be uber-trivial (it's easy since the IP header contains addressing information *as well as* the packets total length) to implement on top of Linux' SOCK_PACKET stuff. NB: "easy" depends, I guess, on how much traffic you have since you might have difficulty keeping up. That being said, the amount of processing you'd need to do for classification is tiny. Someone with higher performance requirements might do something less naive and put classification and preliminary aggregation in the kernel and have a corresponding user-space process grab data periodically via an ioctl. This is significantly more work.
**external or internal. Small benefit: the rule is constant. BIG benefit: classes are well-equipped for large datasets. Lookups are currently O(log n) for internal classes and O(1) [NB: at the expense of memory] for external ones. - [quote:85423441dc="Joe"]No problem. I just sent of a message to one of the developers asking about the best way to alter individual persistence records. Odd are that you will have to use a Class within a Rule to accomplish this. I'll post back when I have an answer.
-Joe[/quote:85423441dc]
Beyond clearing sticky records, manipulating persistence records via a user interface isn't available. As Joe alluded to above, you'd do something like the following instead (untested so I'll undoubtedly get the rule syntax wrong):if (client_addr one of spider_class) { use (pool spider_pool) } else { use (pool happy_customer_pool) }
It's not persistence per se, but it's essentially the same thing. Furthermore, as I stated above, spider_class should behave well with large N.
NB: I suggest querying bigip for the aol class so you don't accidentally add the AOL mega-proxies into spider_class. - No problem. I just sent of a message to one of the developers asking about the best way to alter individual persistence records. Odd are that you will have to use a Class within a Rule to accomplish this. I'll post back when I have an answer.
-Joe 
gmtiwill_127449Thanks for the reply. I agree that mirroring traffic somewhere else and using another utility to create the connection counts would work best, but the timeline is the major consideration (mgmt. wants this up in the next day or two). If we do eventually go that route, we would want to utilize layer 7 information to do additional filtering (e.g. filter OUT any connections that have "normal" user-agent strings) so we would likely be doing more than just counting connections but I think utilities like snort can provide this information rather natively.
The difficult part polling this information is in obtaining connection rate information. Since I am only able to see a current snapshot of the connection table and will inevitably have a relatively large window between polls, knowing how many connections per second a client is establishing will be impossible. That being said we'll attempt to use some statistical analysis to derive that metric.
On a slightly different note, my plan to "persist" suspect clients to a single back end node will be possible if I am able to manually alter the persistence table via iControl. Is this the best way to go about this and is there an easy way to specify which node a client will "stick" to?
Thanks again. This has been a very enlightening discussion.
Will
