Forum Discussion
Event Notification with PERL and SSL/TLS
I'm using the PERL sample for Event Notification (http://devcentral.f5.com/wiki/iControl.EventNotificationListener.ashx). It works fine, as long as I'm using HTTP as the transport method. However I'm having problems when I switch to SSL/TLSv1 (by using 'SSL_version => 'TLSv1', SSL_server => 1' when creating a SOAP::Transport::HTTP::Daemon object). The LB then sends some Events to the Listener, however if the Listener dies or gets stopped, the LB stops sending Events even if I restart the Event Listener. I don't even see packtes with tcpdump, so the LB seems to be "stuck" somehow after the Event Listener died.
This behaviour is different from what I see with HTTP, where I can restart the Event Listener without any problems, as the LB will immediately send new events as soon as the Event Listener is running.
BTW: The Enterprise Manager uses SSL as well, so I think this should basically work (output created with Event Subscription Client - http://devcentral.f5.com/wiki/iControl.EventSubscriptionClient.ashx)
Details for Subscription 'XXXXXXXX-1974-5E1B-7819-XXXXXXXXXX'
Name : EM config change subscription: x.x.x.x
url : https://x.x.x.x/emupdate/subscription?uid=31
credentials (:) type AUTHMODE_BASIC
ttl : -1 min_events_per_timeslice : 1
max_timeslice : 1
enabled_state : STATE_ENABLED EVENTS EVENTTYPE_DELETE EVENTTYPE_CREATE EVENTTYPE_MODIFY
As you can see, EM uses https://.
Any idea what could cause this behaviour of the LB (LTM 6900, 10.2.0 HF2) when using SSL/TLSv1?
Any idea how I can troubleshoot this?
Thank you!
Regards
Kurt Knochner
- Some additional information:
- Hi Kurt, glad you are trying out the event notification interface. You asked a lot of questions so I'll try to start by explaining how eventd works and hopefully that will get you covered.
At the core of BIG-IP is our configuration engine mcpd. It contains a notification service for daemons on the device to notify them when the state of it's configuration changes (ie. an object is added/deleted in the GUI).
I wrote eventd as another one of those listening daemons. Right now, the only way to configure eventd is by building a client with the iControl Management.EventSubscription interface (which you probably figured out). The client then configures "listeners" which contain what type of notifications it wants to hear about.
The eventd sits in a event loop listening for events. When one occurs, it looks in it's configuration (stored on disk under /config/eventd.xml) for listeners that want to be notified of that specific state change. It then pushes the change into a queue for each listener.
Listeners can be configured to buffer responses based on various criteria (see the EventSubscription's create method.
When the threshold for a notification occurs (max messages, timeslice, etc), it will attempt to make a connection to the EventNotification interface on your listener. If the connection attempt fails, it retries a couple of times (also configurable). After the retry limit fails, it will put the listener in a "disabled" state. The only way to bring this back up is to re-enable it with the EventSubscription methods. This is probably what's happening to you.
As for a SSL connection, I honestly haven't tested that. I'm not sure why it wouldn't work and I'm not sure if it's a client thing (in my daemon) or a server thing (on the perl side). Definitely something I'll have to test out when I can get to it.
As for the user field, that was originally included as a future placeholder if we ever got the username included down in the configuration daemon for changes. That was on the roadmap at the time but still hasn't been implemented so for now, the username will be empty.
If you want to debug eventd, you should do the following
1) bigstart shutdown eventd
2) $ /sbin/eventd -d -f
That will run eventd in the foreground printing debug statements.
Hopefully this helps clear some things up.
-Joe
- Hi Joe,
- Hi Joe,
- UPDATE: I've done some further checks. Apparently the perl listener is part of the problem. Sometimes it dies directly after the SSL CLIENT HELLO (coming from the LB), however only if I start the SOAP Server with the option TLSv1, which is strange, as eventd offers TLSv1 anyway !?!? Seems to be a bug in the perl IO library.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com