Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Feature Request - Daisy-chain SmartConnectors using SmartMessage

Feature Request - Daisy-chain SmartConnectors using SmartMessage

Currently, if an administrator wants to connect a series of SmartConnectors together, eg:

Device --> Local Office SmartConnector  --> Data Centre Aggregating SmartConnector --> ESM

They must use one of:

- CEF TCP (for reliable transport)

- CEF UDP (for simplicity/load balancing)

- CEF UDP Encrypted (encrypted, but not reliable)

- SyslogNG TLS  (encrypted, reliable, but not compressed)

It would be very useful for the upstream SmartConnector to support receiving SmartMessage as a protocol, as sent by the downstream connector. This would then provide a connector-to-connector protocol which is:

- Reliable (failure detection supported)

- Encrypted

- Compressed

- Authenticated

There are lots of reasons for daisy-chaining connectors, such as:

- Aggregating very large numbers of connectors (eg. branch office or agent connectors) down to a number that ESM can handle being directly connected to it

- Aggregating connectors to a point before/after a load balancing architecture, where it is much easier to aggregate the feeds first

- Relaying through aggregators that are needed to simplify firewall rules at different zone boundaries

This request is to add "SmartMessage" as a device type that can be received by a Connector, to the SmartConnector framework

- This would simply be a type of connector selected on installation or configuration, in the same way as "Syslog Daemon" or "ArcSight CEF Syslog"

- It would allow the receiver name (configured on the downstream connector) to be defined, or to accept any receiver name

- It would provide support a means for downstream connector authentication/registration, similar to when registering a connector to ESM, to protect against rogue connectors being associated in order to send spoofed events

4 Comments
rudi.jager@hpe. Absent Member.
Absent Member.

Hi Damian, thank you for bringing this up, this is actual very usefull for two projects I'm working. If required I can specify details to product management for the business case.

dskeeles@hpe.co1 Absent Member.
Absent Member.

I guess feel free to add them here, Rudi, if you can publish/generalise them

dparker@siempli Absent Member.
Absent Member.

Need exactly this feature! Any word on if/when it will be made available?

Outstanding Contributor.. douglas.baker@h1 Outstanding Contributor..
Outstanding Contributor..

I wrote a JIRA for this a while back, I called it a 'relay connector'.

I don't actually see anything unique/special about 'smartmessage', I think that it is all covered by CEF with every intermediate Connector except for the originalAgent being Syslog-ng.

To me smartmessage means Logger Destination, during connector configuration ESM is always referenced as some other ESM encrypted, and in the agent.properties is distinguished https .vs. smartmessage. But both are TCP/SSL aren't they?

I think just moving CEF around on the intermediate (relays) is the way to go and then chose your transport UDP/TCP and if necessary encryption, noting that it seems finally some (CEF?) TCP TLS issues have been addressed in the last 3-6 months. When you get to the 'end' and the Destination is a 'consumer' then you drop out with the appropriate destination formatting.

I probably have missed something in the 'need' that isn't handled above.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.