FRR 9.1 sockopt_tcp_mss_get failed

[SwimGeek]

Describe the bug

Noticed an error in the FRR log after trying to troubleshoot a problem where zebra and bgpd seem to be out of sync.

• Did you check if this is a duplicate issue?
• Did you test it on the latest FRRouting/frr master branch?

To Reproduce

Only one of our routers is doing this. Have not worked out a way to reproduce it yet.

Expected behavior

No errors in the logs. Would expect frr and bgpd to know about the same routes, stay in sync.

Versions

• OS Version: Debian 12
• Kernel: 6.1.44
• FRR Version: 9.1
• Mellanox Spectrum1 switch (but probably not relevant)

Additional context

The following shows up in the frr log, 4 log entries every 60 seconds:

Feb  7 18:04:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor
Feb  7 18:04:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor
Feb  7 18:04:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor
Feb  7 18:04:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor


Feb  7 18:05:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor
Feb  7 18:05:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor
Feb  7 18:05:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor
Feb  7 18:05:56 cpt-ter-rs2 bgpd[3514793]: [MY9SR-DJGDC][EC 100663303] sockopt_tcp_mss_get failed: getsockopt(-1): Bad file descriptor

Any idea what event is happening every 60 seconds to trigger that error?

Do you have advice for troubleshooting cases where zebra and bgpd routes are not in sync. We add /32 routes based on DHCP events. Routes get added via 'ip route add n.n.n.n/32' command. Zebra learns these routes. We expect the routes to then be sent via iBGP to a 2nd switch running FRR. A small % of the /32 routes do not get distributed and are not in bgpd (but they are in the kernel and they are known to zebra).

[SwimGeek]

Hi

Found the problem with route distribution and that was fixed.

But still interested to understand the log messages. Still seeing them.

[ton31337]

I assume you have some scripts that query "show bgp neighbor" every 60 seconds?

[SwimGeek]

Hi, yes - some monitoring tools run "show bgp neighbor" every 60 seconds.