BGP session dropped after 48 hours—anyone else?

Been running a small anycast setup on three VPS nodes for a project. Two weeks ago I moved the third node to Contabo after OVHcloud raised their power pricing. Session came up fine, full table, no issues. Then at exactly 48 hours it drops. Not flapping—clean teardown. Log shows

NOTIFICATION sent (Hold Timer Expired)

I figured my side was at fault. Tweaked keepalive from 60/180 to 30/90. Same result. Dropped to 10/30. Same result. Always 48 hours, almost to the minute. Opened a ticket. Two days later they reply: "Their network stability feature automatically terminates BGP sessions exceeding 48 hours to prevent resource exhaustion."

No mention in their docs. No knob to turn. Just silently implemented.

Node is a E3-1270v6, 65W TDP, single RU. Not like I'm burning their switch fabric. Anyone else hit this?

They are treating BGP as a TCP application rather than a routing protocol. The Hold Timer Expired notification is misleading—they are likely sending a manual Cease or administratively resetting the TCP session at their edge. A proper implementation would use the BGP Cease Notification Code 6 (Other Configuration Change) or at minimum honor your negotiated hold time.

What you observed is not rate limiting or resource exhaustion. A single BGP session with standard keepalives consumes negligible memory and CPU. Their explanation conflates session longevity with stability. I would check if they are also filtering your announcements on re-establishment—some providers re-apply prefix-lists only at session start, and a forced reset functions as a crude policy refresh mechanism.

RPKI validation and IRR sets are unaffected by session duration, so this is purely operational theater.

I observed similar behavior with Vultr in 2024-Q3. Session teardown occurred at 1.728E5 seconds with 2.0E0 ms convergence delay. Their support cited "dynamic resource reallocation" [1]. No RFC documents a 48-hour maximum session lifetime. RFC 4271 specifies hold timer negotiation in Section 4.2 but imposes no upper bound [2].

[1] Personal correspondence with Vultr network operations, 2024-09-15.
[2] RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", 2006.

This is why I keep BGP sessions on tier-1 providers only for production. My Contabo box runs WireGuard back to my Vultr node in Chicago and I just static-route. Not worth the headache for $6/month.

That pattern is diagnostic. If the hold timer were actually expiring, reducing it would change the interval. The 48-hour fixed cycle confirms an external scheduler, not protocol failure. They are likely running a cron job or equivalent against their edge routers.

I have requested their IRR route and AS-SET objects for a client before. Their filtering is manual and ticket-driven. Expect a 72-hour turnaround if you need a prefix re-advertised.

That tracks. The teardown is too clean for a timer issue. No log spam, no flaps, just

NOTIFICATION sent (Hold Timer Expired)

Meanwhile I'm just scripting the session restart. Crontab every 47 hours. Feels ridiculous but it works.

I run BGP on two OVHcloud instances in Gravelines for my personal anycast DNS. Never had this 48-hour problem but the power pricing hit me too. Added 4 EUR/month per server. I looked at Contabo for the third node, saw no mention of BGP limits in their VPS terms, and stayed with OVHcloud. This thread confirms my suspicion that they hide the limits.

I did same with Hetzner years ago for their "no BGP on VPS" policy which they also did not document clearly. Now I have dedicated there and no issues. Contabo's dedicated also does not have this limit? Their price starts at 40 EUR so maybe worth if you need stable anycast.

No idea. Their dedicated starts higher than my project budget. I'm tempted to just move the third node to Vultr Sydney since pam3 says they stopped the 48-hour thing, but then I eat USD pricing and latency to APAC is rough from Chicago.

Actually wait, pam3, when did Vultr stop? You said 2024-Q3 but not if it's still happening.

I migrated away in November 2024. Cannot confirm current behavior. Their Melbourne datacenter was stable otherwise. I now use Telstra Enterprise for BGP in region, which is overkill for your use case.

My citation [1] was from their NOC directly. No public status page mentioned it.