v7.10rc1 delayed bgp anouncements?

Has anyone experienced an issue where bgp announcements are delayed for ~6-10 minutes? is this a known problem? From time of session up, monitoring using multiple different remote peer devices I’m seeing no announcements until about 6-10minutes after the session establishes?

Thank you for your feedback!

Why the hell are you using v7.10rc1 in the first place? Move to latest stable or latest beta.

Because it has been working and stable, has the specific issue been identified and patched in a future upgrade?

Ensuring proper BGP affinity input/output on all BGP peers based on this:
https://www.youtube.com/watch?v=py4up-lO8zY&pp=ygUMQkdQIGFmZmluaXR5

No problem with BGP advertisement on ROS v7.11.2.

Hard to believe it can chew 1m routes in under 30 seconds but needs 10 minutes to advertise a few prefixes? I’ll try the upgrade

Did you try it at production ?
My announcements with filters also go away within 6-10 minutes after the session is established, on any of the 3 uplinks with fullview.
/routing/bgp/advertisements print - does not print them at this time.

I tried playing with affinity - to no avail. Even on BGP sessions in/out at different processes - the time does not change.
I suspect that the route calculation algorithm first processes Fullview IN, and only then announces my routes OUT.

In comparison BGP at RoS 6.4x was magic.

I’m running ccr2216 and was on 7.10.rc1, my problem is with transit provider when I turn on session it would take 10 minutes before they received the announcements, I’m not sure about your theory with how the algorithm works because I could process 1m routes in ~25 seconds but it took 10 minutes to get 2 prefixes announced, I can confirm that I JUST upgraded 7.10rc1->7.11.2 and this issue is 100% fixed!!!

I found it so funny that running code from 3-4 months ago is “really old” haha, but 7.11.2 did resolve this! (Funny that nothing in the changelog though!!! Freaking Mikrotik!)

Make sure you did it right:

/system routerboard settings
set auto-upgrade=yes

/system/routerboard> print
routerboard: yes
factory-firmware: 6.45.9
current-firmware: 7.11.2
upgrade-firmware: 7.11.2

That step is optional :winking_face_with_tongue:

Who told you that? It in fact broke SFP interfaces in the past if you failed to ensure 1:1 matching. Just because MikroTik stopped publishing RouterBOARD firmware changelogs years ago, it doesn’t mean there’s none.

I’ve worked with many ISPs and WISPs globally who complains about MikroTik issues, only to find out that firmware is 6.x.x and ROS is 7.x.x. After upgrading firmware to 1:1, problems disappeared.

http://forum.mikrotik.com/t/should-i-upgrade-routerboot-on-each-routeros-upgrade/169470/1

model: CCR2116-12G-4S+
firmware-type: al64v3
factory-firmware: 7.7
current-firmware: 7.7
upgrade-firmware: 7.11.2

Hmmmm… firmware to 1:1 between peers or current-firmware: upgrade-firmware ?

Are you sure you’re an engineer, mate? This fundamental stuff in MikroTik.

Obviously current-firmware must match ROS version aka “upgrad-firmware”.

Documentation says: “it is always suggested to upgrade”, not "must’, and for example:
model: CCR1016-12G
factory-firmware: 3.0rc5
current-firmware: 3.41
upgrade-firmware: 6.49.6

work like a charm with BGP :slight_smile:

Mate, some could find you not only an expert in networking but also in arrogance … could you stay at networking?

Good luck, have fun.

I’m no expert, I’m just educated and literate is all.