State-change: [mhop:no peer:10.95.0.90 local:0.0.0.0 vrf:default ifname:eth1.333] up -> down reason:control-expired

General questions
1

Hi all,
We are experiencing the below error and could not find a proper solution to fix this. Can anyone help?

Oct 04 07:22:04 host1 systemd[1]: Starting Serial Getty on ttyS0…
Oct 04 07:22:04 host1 systemd[1]: Started Serial Getty on ttyS0.
Oct 04 07:22:04 host1 agetty[50210]: /dev/ttyS0: not a tty
Oct 04 07:22:17 host1 bfdd[1215]: state-change: [mhop:no peer:10.95.0.90 local:0.0.0.0 vrf:default ifname:eth1.333] up → down reason:control-expired
Oct 04 07:22:17 host1 systemd[1]: serial-getty@ttyS0.service holdoff time over, scheduling restart.
Oct 04 07:22:17 host1 systemd[1]: Stopping Serial Getty on ttyS0…
Oct 04 07:22:17 host1 systemd[1]: Starting Serial Getty on ttyS0…
Oct 04 07:22:17 host1 systemd[1]: Started Serial Getty on ttyS0.
Oct 04 07:22:17 host1 bgpd[1185]: %ADJCHANGE: neighbor 10.95.0.90(Unknown) in vrf default Down BFD down received
Oct 04 07:22:17 host1 agetty[50216]: /dev/ttyS0: not a tty
Oct 04 07:22:18 host1 bgpd[1185]: [EC 33554503] 10.95.0.90 unrecognized capability code: 71 - ignored
Oct 04 07:22:18 host1 bgpd[1185]: %ADJCHANGE: neighbor 10.95.0.90(Unknown) in vrf default Up
Oct 04 07:22:18 host1 bgpd[1185]: bgp_update_receive: rcvd End-of-RIB for IPv4 Unicast from 10.95.0.90 in vrf default
Oct 04 07:22:19 host1 bfdd[1215]: state-change: [mhop:no peer:10.95.0.90 local:0.0.0.0 vrf:default ifname:eth1.333] init → up
Oct 04 07:22:27 host1 systemd[1]: serial-getty@ttyS0.service holdoff time over, scheduling restart.
Oct 04 07:22:27 host1 systemd[1]: Stopping Serial Getty on ttyS0…
Oct 04 07:22:27 host1 systemd[1]: Starting Serial Getty on ttyS0…

2

it doesn’t clear what is the issue , although , it seems that BGP peer doesn’t accept the capabilities , you can try configuring it :

set protocols bgp neighbor x.x.x.x disable-capability-negotiation

3

Hi Fernando,

Thank you for the reply. We have seen an intermittent flapping issue where the service provider confirmed that no physical drops on the interface facing the vmware device.

We have seen this message frequently in the log.

I’m not sure this was a bug, as we didn’t make changes to the Vyos router settings.

We are happy try this setting if that solves the problem.

Thank you.