MikroTik

Dear SysAdmins,

Ports in the firewall are allowed, everything used to work correctly, no config changed - however, for the past few weeks, we've noticed that our BGP connection is stuck on "connect" which means new routes are not being advertised and any changes are not taken effect.

The only way to resolve this is ask the DC to manually reset the BGP on their side and it goes back to idle->connect->established.
Rebooting the CCR or switching it off completely for a few hours does not make any difference.

https://prnt.sc/Pw9m293QXXHI

Anyone experienced the same issue? And if so, how was it resolved?

Thanks

I assume that remote peer is also MT?

I assume that remote peer is also MT?

No, they must be using a different equipment. But all was working perfectly fine without any changes to our config. Suddenly it stopped establishing and shows "connect" instead of established

Anyone available to help?

Your firewall is very strange (and unsafe)! I presume you are doing debugging and will remove those rules that allow everything at a later stage?
When the connection is stuck in "connect" it means the SYN/ACK SYN/ACK sequence does not complete, likely a problem with the connection or a firewall.
Does it help to disable/enable the peer on your side?
There is a known problem in RouterOS v6 where connections that do get through the connect phase get stuck in the "open sent" state.
But that is something different that what you see here. On routers which have outgoing BGP connects (that are passive at the other side) I need to use this scheduled script: That "unsticks" those connections. When disable/enable resolves it for you you can try such a scriot with state "connect".

Thanks so much for your response.

Unfortunately, the disable/enable does not help It still gets stuck at the "connect" stage Even a reboot of the CCR does not re-establish the connection.

Will hope v7 upgrade fixes it. Waiting until v7 is super stable before upgrading then will report back once done to see if the issue still remains.

Thanks again

That is not a problem on your side, you should contact the remote peer maintainer to resolve the issue.

In case you want to debug it and/or provide evidence, use the packet sniffer with appropriate settings (protocol tcp, port 179, maybe other filters like interface or IP) and saving to a file. Let it run for a while and stop it. Download the file and load it in Wireshark.
Most likely you will see only SYN packets to the remote, and no reply. But maybe there is other info in there.

About the "open sent" issue @mrz: it would be nice when there was a timeout and reconnect in case "open sent" does not proceed to an established session.
That happens when BGP is used between two MikroTik routers, one side active and one side passive, and the connection is flaky. When both are active it does not happen.

Hello
We have a number of RB that just do BGP and nothing else.
For example we install a RB with the latest 6 long-term, no firewall rules, in fast-path for bgp.
we deliver (for exmaple) multiple connections to our end users.
eth1: WAN gpon
eth2: WAN FWA
eth5: to the customer routers.

It happens a lot of times that the connection remain stuck in open sent, and the other end is (PASSIVE) perfectly reachable. The remote end 90% of the time is MT, almost always v7.
The situation doesnt recover even if from the remote side we disable the PASV flag. We only resolve disabling and re-enabling the peer in the bgp configuration of the rb v6.

We solved the situation upgrading the router to 7.10.2 evenif we got sometimes slower performance because of the missing route-cache (for exmple in the 2011 we have a big performance hit)

I can confirm that the issue I mentioned above (for which I posted a workaround) seems to be resolved in v7.
So that might be the reason why upgrading solves the problem for you.