This article explains the log message ‘kernel: could not associate protocol KA format’ its meaning, and the potential impact on the system. 

We could observe below log messages continuously

Aug 13 14:03:41.651 2025 labroot_RE0: %USER-3: re1 Aug 15 14:03:41.651 2025 labroot_RE1 other-RE: kernel: could not associated protocol ka format for (45824, 33996) no proto ka info

Aug 13 14:04:00.740 2025 labroot_RE0 : %USER-3: re1 Aug 15 14:04:00.739 2025labroot_RE1 other-RE: kernel: could not associated protocol ka format for (45824, 9934) no proto ka info

Aug 14 07:32:33.602 2025 labroot rpd[14590]: %DAEMON-4: bgp_peer_addr_ok: Connection attempt from unconfigured neighbor: 2003:778::22e6:0:1+8203

Aug 14 07:32:33.602 2025 labroot rpd[14590]: %DAEMON-4: bgp_listen_accept:7347: NOTIFICATION sent to 2003:778::22e6:0:1+8203 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: Connection attempt from unconfigured neighbor: 2001:778::22e6:0:1+8203

Aug 14 07:32:33.758 2025 labroot rpd[14590]: %DAEMON-4: bgp_peer_addr_ok: Connection attempt from unconfigured neighbor: 2002:ae8:3::3:9572:1+54301

Aug 14 07:32:33.758 2025 labroot rpd[14590]: %DAEMON-4: bgp_listen_accept:7347: NOTIFICATION sent to 2001:ae8:3::3:9572:1+54301 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: Connection attempt from unconfigured neighbor: 2001:de8:4::3:9572:1+54301

Aug 14 07:32:34.476 2025 labroot rpd[14590]: %DAEMON-4: bgp_peer_addr_ok: Connection attempt from unconfigured neighbor: 2002:768::a203:0:1+25258

Aug 14 07:32:35.654 2025 labroot rpd[14590]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 70.219.229.0 (External AS 6777) changed state from EstabSync to Established (event RsyncAck) (instance master)

Aug 14 07:32:35.673 2025 labroot_RE0 : %USER-3: re1 Aug 14 07:32:35.672 2025 labrootRE1 other-RE: kernel: could not associated protocol ka format for (45824, 9934) no proto ka info.

This log refers to the Keepalive (KA) protocol association for a session identified through ports (45824, 33996). Protocol_ka is having table which will have all the protocols registered for KA and there are scenarios when the table is not having the protocols registered for KA then we land into the socket getting opened and closed.

These logs mean the kernel expected to find keepalive protocol information for a session/flow, but none was available.  It indicates a stale keepalive packet for a session that no longer exists.

These are non-service impacting.

This does not affect routing or forwarding and can be ignored or filtered.

The ports mentioned are ephemeral (dynamic) ports chosen by the OS when sessions are created. They are not mapped to a fixed protocol. These messages are related to internal RE keepalives over those TCP sessions.

We also observed the following BGP error log messages appearing prior to these specific logs. Customer has been advised to review the configuration of these BGP neighbors, and if they are not required, to remove them.

These log messages are matching with internal PR. According to the PR  these logs are harmless and the mentioned error logs were getting printed due to lookup failure, even for the cases where protocol KA is not registered. 

In the cases of bgp precision-timers it makes use of kernel to send keep-alives.

If precision-timers is not configured, in that case protocol KA won't be registered to the proto_format_table. Even for the LDP protocols these proto_ka is not applicable.

So, for the cases where it's not registered we are seeing the error logs as could not associate to jsr socket pair.

To avoid these logs, we are adding an entry for the cases where the precision timer is not configured i.e len set to DEREGISTER_KA_FMT. In this scenario while associating to socket pair in jsr_jsm_associate_ka_info, we will set the jsr_jsm_proto_ka to NULL.

For the cases where proto_ka is not registered, the log level has been reduced as it's not necessary to notify the customers.

And In the PR permanent fix is to upgrade the device into Junos release 23.1R1.

NIL