TCP Syslog?

I was provided that link previously, but that bug ID applies to a narrow set of devices (ASR5K) and releases.  Is there other documentation saying Cisco is not sending complete syslog packets?  The first and last device we tested with was a Catalyst 2960X stack and we wanted to filter storm control messages into an event.  What we found was that unless we used .*, the filter would not match and the results were garbled.  I assume this means there is an undocumented dependency on RFC5424.

An RFC 3164 syslog message format is:

   The full format of a syslog message seen on the wire has three
   discernable parts.  The first part is called the PRI, the second part
   is the HEADER, and the third part is the MSG.  The total length of
   the packet MUST be 1024 bytes or less.  There is no minimum length of
   the syslog message although sending a syslog packet with no contents
   is worthless and SHOULD NOT be transmitted.

There is a hostname field within the HEADER part:

   The HEADER contains two fields called the TIMESTAMP and the HOSTNAME.
   The TIMESTAMP will immediately follow the trailing ">" from the PRI
   part and single space characters MUST follow each of the TIMESTAMP
   and HOSTNAME fields.  HOSTNAME will contain the hostname, as it knows
   itself.  If it does not have a hostname, then it will contain its own
   IP address.  If a device has multiple IP addresses, it has usually
   been seen to use the IP address from which the message is
   transmitted.  An alternative to this behavior has also been seen.  In
   that case, a device may be configured to send all messages using a
   single source IP address regardless of the interface from which the
   message is sent.  This will provide a single consistent HOSTNAME for
   all messages sent from a device.

I captured UDP/514 traffic from one random Catalyst switch we saw some issues on and this is the result:

14:47:02.785771 IP (tos 0x0, ttl 254, id 3202, offset 0, flags [none], proto: UDP (17), length: 139) calswerp01.52088 > <<TARGET>>.syslog: SYSLOG, length: 111
        Facility local6 (22), Severity alert (1)
        Msg: 724147: Feb 26 14:47:01.775 PST: %PLATFORM_ENV-1-[|syslog]
14:49:49.366330 IP (tos 0x0, ttl 254, id 3203, offset 0, flags [none], proto: UDP (17), length: 154) calswerp01.52088 > <<TARGET>>.syslog: SYSLOG, length: 126
        Facility local6 (22), Severity alert (1)
        Msg: 724148: Feb 26 14:49:47.351 PST: %PLATFORM_ENV-1-[|syslog]
14:52:03.216378 IP (tos 0x0, ttl 254, id 3204, offset 0, flags [none], proto: UDP (17), length: 139) calswerp01.52088 > <<TARGET>>.syslog: SYSLOG, length: 111
        Facility local6 (22), Severity alert (1)
        Msg: 724149: Feb 26 14:52:02.208 PST: %PLATFORM_ENV-1-[|syslog]

So, it seems like the HEADER part is not there, but even this case is considered in the RFC:

4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP

   If a relay does not find a valid TIMESTAMP in a received syslog
   packet, then it MUST add a TIMESTAMP and a space character
   immediately after the closing angle bracket of the PRI part.  It
   SHOULD additionally add a HOSTNAME and a space character after the
   TIMESTAMP.  These fields are described here and detailed in Section
   4.1.2.  The remainder of the received packet MUST be treated as the
   CONTENT field of the MSG and appended.  Since the relay would have no
   way to determine the originating process from the device that
   originated the message, the TAG value cannot be determined and will
   not be included.

   The TIMESTAMP will be the current local time of the relay.

   The HOSTNAME will be the name of the device, as it is known by the
   relay.  If the name cannot be determined, the IP address of the
   device will be used.

   If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the
   PRI part, then it MUST check that the total length of the packet is
   still 1024 bytes or less.  If the packet has been expanded beyond
   1024 bytes, then the relay MUST truncate the packet to be 1024 bytes.
   This may cause the loss of vital information from the end of the
   original packet.  It is for this reason that it is RECOMMENDED that
   the PRI and HEADER parts of originally generated syslog packets
   contain the values and fields documented in Section 4.1.

Basically, if the hostname is not provided, it is the connecting IP address, as all other syslog receivers assume.  Perhaps the issue here is that log4j is failing to fill in those fields as documented in the RFC?

Most network equipment generally emits RFC3164 format despite the newer/obsoleting RFC, and we have to live in the real world.  We experience no issues with Cisco format on any syslog server we use like syslogd, rsyslogd, syslog-ng, etc., and we've had no issues with SumoLogic. 

I would say at minimum, if there is a required RFC version, that should be documented.  More to the point, the real world where folks have to do actual useful monitoring must be accounted for.