mirror of
https://github.com/rsyslog/rsyslog.git
synced 2025-12-19 22:00:42 +01:00
49 lines
2.9 KiB
HTML
49 lines
2.9 KiB
HTML
<html>
|
|
<head>
|
|
<title>Notes on IPv6 Handling in Rsyslog</title>
|
|
</head>
|
|
<body>
|
|
<h1>Notes on IPv6 Handling in Rsyslog</h1>
|
|
<p><b>Rsyslog fully* supports sending and receiving syslog messages via both
|
|
IPv4 and IPv6.</b> IPv6 is natively supported for both UDP and TCP. However,
|
|
there are some options that control handling of IPv6 operations. I thought it is
|
|
is a good idea to elaborate a little about them, so that you can probably find
|
|
your way somewhat easier.</p>
|
|
<p>First of all, you can restrict rsyslog to using IPv4 or IPv6 addresses only
|
|
by specifying the -4 or -6 command line option (now guess which one does
|
|
what...). If you do not provide any command line option, rsyslog uses IPv4 and
|
|
IPv6 adresses concurrently. In practice, that means the listener binds to both
|
|
addresses (provided they are configured). When sending syslog messages, rsyslog
|
|
uses IPv4 addresses when the receiver can be reached via IPv4 and IPv6 addresses
|
|
if it can be reached via IPv6. If it can be reached on either IPv4 and v6,
|
|
rsyslog leaves the choice to the socket layer. The important point to know is
|
|
that it uses whatever connectivity is available to reach the destination.</p>
|
|
<p><b>There is one subtle difference between UDP and TCP.</b> With the new
|
|
IPv4/v6 ignorant code, rsyslog has potentially different ways to reach
|
|
destinations. The socket layer returns all of these pathes in a sorted array.
|
|
For TCP, rsyslog loops through this array until a successful TCP connect can be
|
|
made. If that happens, the other addresses are ignored and messages are sent via
|
|
the succesfully-connected socket.</p>
|
|
<p>For UDP, there is no such definite success indicator. Sure, the socket layer
|
|
may detect some errors, but it may not notice other errors (due to the
|
|
unreliable nature of UDP). By default, the UDP sender also tries one entry after
|
|
the other in the sorted array of destination addresses. When a send fails, the
|
|
next address is tried. When the send function finally succeeds, rsyslogd assumes
|
|
the UDP packet has reached its final destination. However, if rsyslogd is
|
|
started with the "-A" (capital A!) was given on the command line, rsyslogd will
|
|
continue to send messages until the end of the destination address array is
|
|
reached. This may result in duplicate messages, but it also provides some
|
|
additional reliability in case a message could not be received. You need to be
|
|
sure about the implications before applying this option. In general, it is NOT
|
|
recommended to use the -A option.</p>
|
|
<p><i><b>*</b>rsyslog does not support RFC 3195 over IPv6. The reason is that
|
|
the RFC 3195 library, <a href="http://www.liblogging.org/">liblogging</a>,
|
|
supports IPv4, only. Currently, there are no plans to update either rsyslog to
|
|
another RFC 3195 stack or update liblogging. There is simply no demand for 3195
|
|
solutions.</i></p>
|
|
<p><font size="2">Last Updated: 2007-07-02<br>
|
|
Copyright © 2007 by Rainer Gerhards, released under the GNU GPL V2 or later.</font></p>
|
|
|
|
</body>
|
|
</html>
|