MonitorWare Knowledge Base

hello rainer. first i would like to thank you and your team for the excellent help.

great with the file loggging then the forwarding! i would have the device forward to the internet but it uses udp port 514 which is not good for internet traffic. that is why i need to log to a file first as a backup then forward to another syslog via internet, then that syslog will connect via odbc to my sql server...=]. now that you know what i'm trying to do, do you believe this is the best way?

the device i'm using is a 3com 8000 access point. the sample is pretty much it. in the future, i hope 3com will give the option to change port numbers. also, we may start using cisco access points as well. do you know anything about there logging methods?

thanks, alan


This post was carried over from the email support system after receiving permission. We did so because it seems to be of general interest. The moderator.

Alan,

let me quickly wrap up your configuration: you have a device that emits syslog data on port 514/UDP. You have a local WinSyslog that should receive these messages, store them in a file and then forward the message via the Internet (no VPN) to another WinSyslog. Like this:

Device ---LAN---> local WinSyslog ----Internet----> Remote WinSyslog

Is this right?

If so, well, we are in a little trouble (packet loss, etc). With WinSyslog, the best solution would probably be to use syslog over TCP. Please note that there is no standard on syslog/TCP and the mode WinSyslog supports is as such proprietary. Anyhow, it works well when two WinSyslog instances talk to each other. Using syslog/TCP will at least allow WinSyslog to detect when the remote peer is not available and will likely detect many cases where the message could not be delivered (but there still is a slight chance for message log due to the nature of no acknowledgments being exchange by this simple protocol).

A more bullet-proof approach is available with MonitorWare Agent. It offers the so-called SETP protocol, also a proprietary one. SETP has specifically been designed for this requirement, so it is TCP based and allows proper detection of any problems with the remove peer.

You might find the following URL helpful in seeing the differences between WinSyslog and MonitorWare Agent:

http://www.monitorware.com/en/Product/product_comparision.asp

I hope this helps. Please simply let me know any thoughts you have.

Rainer Gerhards
Adiscon

A. Louie wrote:the device i'm using is a 3com 8000 access point. the sample is pretty much it. in the future, i hope 3com will give the option to change port numbers. also, we may start using cisco access points as well. do you know anything about there logging methods?

Alan,

I don't have access to the 3Com Access Point, we use Avaya internally. I'll check on the product site soon. If you have some typical log file samples, I would appreciate if you could email me them to [url]mailto:support@adiscon.com[/url] (I suggest not to post them to the forum ).

Rainer

rainer, i thought one could forward via tcp? that is why i want the local server to capture locally (udp) and then forward via tcp.

the configuration is exactly that. that is what i want to do.

are you still saying it can not be done with winsyslog?

thanks, alan-

Alan,

sorry for being unclear. Yes, syslog over TCP is supported by WinSyslog. It is just that SETP is not supported (only in MonitorWare Agent). Syslog over TCP will most likely provide everything you need.

To elaborate a little more: syslog/TCP is a mapping of the traditional syslog/UDP onto a TCP connection. It is a very lightweight implementation. As such, it is a simplex protocol. That means no acknowledgments are sent (none other than the TCP ACK, which is not seen by the application itself). As such, there are some Windows where a packet loss is potentially possible.

I hope this clarifies.

Rainer

Alan,

while reviewing, I just thought to tell you of an added benefit of TCP. If you use TCP (either syslog/tcp with WinSyslog or SETP), you can encrypt the messages for example with Windows IPSec.

Rainer

rainer, ok...so it seems as if you are telling me that it will work but the application itself will not know about any data loss, etc. well, in my situation, i just need to be sure that the winsyslog msg makes it to the central winsyslog server across the internet (to complicate things, all sites are behind a zyxel 314 using port forwarding). in this case, if tcp performs an ack, that should be enough correct? what would you suggest in my design?

you guys are obviously the experts, if you recommend monitoragent, i will start over...

thanks, alan-

Alan,

I think the syslog/tcp approach should be sufficiently - except when you really, really can not afford to miss any single message.

I know I have written a paper on the effects of simplex protocols in regard to reliability, let me see if I can dig it out

If you would like to try MonitorWare Agent anyhow, the good news is that the configuration is exactly the same as WinSyslog... But again, I feel it is not really necessary in this case.

Rainer

just what i wanted to hear. winsyslog will do the trick. actually, in my situation, i can afford to miss a msg here and there because a client mac may auth 10 times a day...so, it should be fine. i've never seen a client mac auth just once throughout the day.

i'm still trying to figure out the application itself. it has a lot of power, but i just need to know how to utilize this power.

where is that doc file you promised...

thanks for all the help, alan-

well, not actually a doc file, but a text excerpt... I took it from another project spec I am right now working on. It may sound like something is missing at the end... The reason is there is something missing - but this something is not relevant to syslog/tcp as implemented in WinSyslog.

syslog/tcp is a simplex procotol. It relies on TCP exclusively for
reliability. There is no syslog/tcp layer acknowledgment.

As such, syslog/tcp is only reliable as far as the TCP stream is not
broken. If the TCP stream breaks, the sender does not exactly know
which data has actually been transmitted to the receiver and which
not. This is due to the fact that TCP uses a sliding window of
variable size. In short, this allows that the sender sends packets,
receives an acknowledgement from the OS, but the data is still on the
wire. The OS acknowledgment does NOT mean the data is actually
received. While the sender continues to send data, the already OS
acknowledge data is eventually delivered to the sender. If that
succeeds, everthing is fine. If now, however, the TCP stack will
detect the problem over time and notify the sender. However, the
sender does not know exactly where the problem occured and so does
not know what to re-send. Anyhow, it knows at least something went
wrong and SHOULD log an event to a local system event repository.

This behaviour is not completely satisfactory, but the author
believes this is still a major advantage over UDP based syslog, where
message loss is never discovered.

There is also at least one other scenario where the missing
acknowledgments brings uncertainty. If a connection breaks, it is not
sure whether this was a network error or one actually at the receiver
side.

If a temporary network problem breaks a syslog/tcp session, the sender
should re-try to connect to the receiver so that it can continue to
send data once the temporary problem is solved. This is fine as long
as it is a problem in a transit system. Now let us assume the
reciever should store data on a local file system and the file system
runs out of disk space. In this case, we assume the receiver is
configured to shut down in such a situation. As such, it terminates
all syslog/tcp sessions and then shuts down. The sender now, too, detects
the broken session. It again may think that the broken session is a
result of a temporary condition and tries to reconnect immediately.
However, the receiver will not be able to accept the incoming TCP
connection as it is no longer running. As such, the sender must use
multiple retries to confirm that the sender is unreachable.

HTH
Rainer

rgerhards wrote:Please note that there is no standard on syslog/TCP and the mode WinSyslog supports is as such proprietary.

I believe there is a standard for syslog/TCP defined by RFC 3195 (ftp://ftp.rfc-editor.org/in-notes/rfc3195.txt) which works over TCP/601. I've just started looking at the possibility of extending our SYSLOG utilization, so let me know if I'm missing something here... If I'm not missing something, are there any plans to implement?

I'm also wondering about your plans for syslog-sign (RFC is currently in final draft) http://www.ietf.org/internet-drafts/dra ... ign-09.txt
which perfoms signing of syslog packets to ensure reliability (no dropped packets) and integrity. Any plans with respect to this yet?

Any info is appreciated.

Just to follow up on this - we will support RFC 3195 in the near future. The syslog client features are already implemented and a first product - Adiscon's logger - is available to send RFC 3195 messages. The client functionality will be included in the other MonitorWare line products soon.

We are currently working on the server part, which will become available later this year.

Syslog-sign is not yet being addressed, but we have the intention to support it. It will, however, probably take some month from now (just to be on the safe side).

Please also see the news release on Adiscon's logger:

http://www.monitorware.com/Common/en/Ne ... -08-12.asp

Rainer Gerhards
Adiscon