What is syslog? Ports, severity levels, and RFC 3164 vs. RFC 5424

Syslog is a logging protocol that defines how systems format event messages and transmit them to a local log file or a remote collector. A syslog message carries a priority value encoding a facility (the type of source) and a severity (how urgent the event is), a timestamp, the originating hostname, and the message text. Two documents define the format: RFC 3164 describes the original BSD version, and RFC 5424 specifies the current IETF standard that obsoletes it.

The protocol began as the logging mechanism for the Sendmail mail server in the 1980s. It spread with BSD Unix until it became the default logging system for Unix-like platforms and network equipment — all without a written specification. The IETF documented the "observed behavior" of existing implementations in 2001 with RFC 3164, then published a proper standard in 2009 with RFC 5424.

RFC 5424 describes three roles in a syslog deployment: an originator generates messages, a relay forwards them, and a collector receives and stores them. One process can hold several roles at once. An NXLog Agent instance, for example, often acts as a collector for nearby network devices and a relay toward a SIEM.

Syslog uses UDP port 514 by default and TCP port 6514 for TLS-encrypted transport. Plain TCP syslog most often runs on TCP 514, although IANA assigns that port to a different service.

TCP 514 is the row that trips up firewall reviews and audits. The IANA service name registry assigns UDP port 514 to syslog, but TCP port 514 to the old remote shell (rsh) service. RFC 6587, which documents how the industry has run syslog over TCP, acknowledges that TCP/514 became the most common choice even though the port "is actually assigned to the Shell protocol." The RFC carries Historic status, meaning it records existing practice rather than defining a standard, and its IESG note recommends the TLS transport from RFC 5425 over plain TCP.

For firewall planning, that translates into three practical rules:

Both syslog formats begin with the same element: a priority value in angle brackets. The PRI value packs two codes into one number:

Take <34>, the value both RFCs use in their own examples. Dividing 34 by 8 yields a facility of 4 (security/authorization messages) with a remainder of 2 (Critical). A parser reverses the math: severity is PRI % 8, and facility is PRI / 8, rounded down.

RFC 3164, published in August 2001, carries Informational status. Its stated purpose was to describe the observed behavior of existing implementations, which is why so much variation survives among devices claiming to "speak syslog."

A BSD syslog message has three parts (PRI, HEADER, and MSG), which on the wire usually look like this:

Here is Example 1 from Section 5.4 of the RFC:

Reading left to right: <34> is the priority (facility 4, severity 2, as calculated above). Oct 11 22:14:15 is the timestamp in Mmm dd hh:mm:ss format. mymachine is the hostname, su is the TAG naming the process, and everything after the colon is the CONTENT.

The format’s limitations are concrete, and they bite in production:

RFC 5424, published in March 2009, obsoletes RFC 3164 and is the current standards-track definition of syslog. It keeps the PRI mechanism and replaces everything after it with a versioned, structured header:

The same event from the BSD example looks like this in RFC 5424 format (Section 6.5, Example 1):

STRUCTURED-DATA is the headline feature. It carries key-value pairs in named blocks, so a receiver can extract fields directly, with no guesswork about the message text. Example 3 from the RFC shows one element with three parameters:

The SD-ID (exampleSDID@32473) is namespaced with an IANA private enterprise number, so vendors can define their own fields without collisions. The <165> decodes to facility 20 (local4) and severity 5 (Notice) with the same formula as before.

RFC 5424 also pins down message sizes: Section 6.1 requires every receiver to accept messages of at least 480 octets and recommends supporting 2,048, with individual transports free to allow more.

One structural change matters for network planning. RFC 5424 defines only the message format; transport moved into companion documents, RFC 5426 for UDP and RFC 5425 for TLS. That is why the port table above references those documents and not RFC 5424 itself.

Which one should you use? Emit RFC 5424 wherever you control the sender — the timestamps alone justify it. On the receiving side, plan to accept both indefinitely. In our experience at NXLog, network appliances, embedded systems, and older Unix hosts still ship BSD-format messages, often with vendor-specific quirks on top, and that traffic won’t disappear on any schedule you control.

NXLog Agent handles both formats through the Syslog extension, which provides parsers, format converters, and the octet framing required by TLS transport. The syslog integration guide covers the full range of scenarios; the three configurations below cover what most teams need first.

To test any of these without touching production senders, generate a message with logger, which ships with util-linux:

The -p auth.crit flag produces facility 4, severity 2 — PRI 34, the same value as the RFC examples above.

When you run more than a handful of agents, NXLog Platform manages their configurations centrally and stores or relays what they collect, so you change a port or a certificate once instead of on every machine.

Syslog earned its place by being simple. One name still covers two message formats, three common ports (one of them unofficial), and transports with different delivery guarantees. Once you know where those seams are, the protocol becomes predictable.

Key takeaways:

Get the ports right, normalize at ingest, and the rest of the pipeline gets easier. To collect, parse, and forward syslog at scale, see the syslog integration guide or explore how NXLog Platform centralizes agent management.