I have been struggling for a bit to find a suitable replacement to our large PPTP/L2TP/SSTP VPN setup.

Is monitoring for multiple sites. Generally keeping the same routes - but nice that with "Secrets/Radius - the routes come and go with the connections/interfaces when they are live (or dead).

Have begun a build of Wireguard - but really struggling with the routes.
Adding Static is an option - but a poor one, but leads to long term issues when forgetting to update.
OSPF - is there, but i've never had luck keeping it stable in ANY scenario, local or VPN... It however is no good, as I want the routes to come into the VPN Concentrator - and not share across the connections (forgot to mention - the WG will be a single subnet at this time - as unlike PTP protocols, a /32 is not that simple). I don't particularly care the routeres are adjacent to each other on the VPN - they will not allow access to each other and the goal is that they will not share routes with each other (a la ospf)
BGP - now, I thought (as with all my previous bgp builds) that BGP was basically point to point - setting up a "Connection" on both ends of an IP link. This is great as you can lock it to sharing with one router, but I presumed meant that not only would i need the 300+ settings on each core - but to add 300+ connections on my VPN concentrator - again, making the management a pain.

However - today - I have found in an initial test, that I can set a subnet on My VPN Concnetrator's BGP and it appears that multiple sessions ARE being established on it - with the single "/routing bgp connection". I need to extend the test to more routers and over wireguard - but this appears to be what I am looking for. The Routes are all passed back to VPN, but only VPN passes back to the clients routers - no multicast and discovery like OSPF and RIP

My Question.

Is this function supported - is it sustainable. Should EVERY BGP be point to point - or is Point to Multipoint BGP a thing. Like, it works - but is there going to be an issue with running one "connection" for all the clients coming in.

For Context - here is the basic BGP code used for the config. IPs are on uplink interfaces and each has an "lo" address to share.

VPN Concentrator BGP "Test" 2 BGP "Test" 3

There is no such thing as a point to multipoint BGP. A session is unicast from one single point to another single point. By configuring the network in connection settings you just allowed listening for incoming connections coming from the specified subnet (a convenient way to have less static config).

Regarding OSPF not being stable

There are only 2 modes that are actually 'stable' on MikroTik - Point to Point and Broadcast. Preferably use the former and place a VLAN between every router, so if you have a multipoint scenario with RouterA on ether1 connecting to RouterB and RouterC, then use i.e. ether1.110 - RouterB and ether1.120 - RouterC, create 2x /30 or /31 subnets and put them on the VLAN interface rather than using a single subnet for both.
Every other OSPF connection method is unstable, it may work ok in select scenario's but I guarantee you'll have problems at scale and over time
I also suggest OSPF timers of 2/1/1/4 and not using BFD (unless its absolutely necessary)

I would get OSPF working and stable before being concerned with BGP. If you're doing the above and its not stable then I can confidently say its not the MikroTik routers that are the problem (at least as of ROS 6.4x up to 7.15, can't guarantee anything beyond that) and thus BGP will not be solving an underlying problem, just not alerting you to it

There is no such thing as a point to multipoint BGP. A session is unicast from one single point to another single point. By configuring the network in connection settings you just allowed listening for incoming connections coming from the specified subnet (a convenient way to have less static config).

Thanks for the input.

Sorry if I ever mentioned "Multipoint" for the BGP - the correct teminology would be "Multi Session" I suppose - but that pushes my query the other way (into running multiple "/routing bgp connection" - which is what I am hoping to avoid)

Yeah - I get that the Sessions are individual - I was wondering if there was going to be any issues by having a single "/routing bgp connection" running those multiple sessions.

To Expand - this afternoon, have just re-jigged the test to run via a Wireguard setup and it seems to work well. Obviously all local with little latency, so still need more testing, but as it stands, I have a single script to dump onto a fresh client that adds WG + Peer, BGP stuff and Filters - and only requires WG "Local" IP to be added.
At the VPN Concentrator Side - obviously I need the WG Peer to configured - but if that is ALL that is required, and I can run the Single "BGP Connection" and have multiple sessions on it - it's gonna be very helpful - I am just having trouble finding ANY documentation that does not involve Multiple "connection" and was hoping for someone to verify the validity of the currently working test config (in case it's not a valid function and Mikrotik patches it out in the future).

Regarding OSPF not being stable

There are only 2 modes that are actually 'stable' on MikroTik - Point to Point and Broadcast. Preferably use the former and place a VLAN between every router, so if you have a multipoint scenario with RouterA on ether1 connecting to RouterB and RouterC, then use i.e. ether1.110 - RouterB and ether1.120 - RouterC, create 2x /30 or /31 subnets and put them on the VLAN interface rather than using a single subnet for both.
Every other OSPF connection method is unstable, it may work ok in select scenario's but I guarantee you'll have problems at scale and over time
I also suggest OSPF timers of 2/1/1/4 and not using BFD (unless its absolutely necessary)

I would get OSPF working and stable before being concerned with BGP. If you're doing the above and its not stable then I can confidently say its not the MikroTik routers that are the problem (at least as of ROS 6.4x up to 7.15, can't guarantee anything beyond that) and thus BGP will not be solving an underlying problem, just not alerting you to it

Thanks for the reply

Yeah, I know - the OSPF thing is me - but for this scenario, this is not the main issue.

The issue is that OSPF is generally Broadcast - as in ALL peers share routes. There is no way to block a partcular peer from getting the routes broadcast.
Yes, you can filter them at the end point - I get that, but it still floods the routing table with invalid entries in V7. There is no way to filter which endpoint gets what routes (from the sender).

As for the vlan Split to make it PTP - I get that will do the job - but when we are talking 300+ interfaces and 300+ subnets... it gets a bit unruly.

Finally - Thanks for the info on the "stable" OSPF Protocols. I have generally only had any luck with nbma and broadcast - but in general when I have had them live - find them to be really slow to update - if they do at all. Will keep that in mind for the next attempt and not using iBPG, as it's MOST likely something I am doing that is the issue. When I was trying "ptp" it was over a larger subent so likely why I had no luck there.

As for BGP - We are a small ISP running on Miktorik for the Main Border (of my own design) - Roughly 500 Fibre Clients. I am quite happy that BGP is doing the trick, and have multiple ebgp and ibgp connection/sessions with Upstream Providers and internally. I was just wondering the implications of running multiple sessions on a single "/routing bgp connection".
I Know - it's a little backwards that BGP is my jam and OSPF is lost on me - but it is what it is.

Cheers again for the info, but unless I can find some info to the contrary - it appears that "single connection/multiple session" BGP may be the winner in this scenario - as testing this far is looking good.

Yes, a single connection matcher to match multiple incoming session connections is the way. It was designed for such scenarios.

Yes, a single connection matcher to match multiple incoming session connections is the way. It was designed for such scenarios.

Cheers mrz - I was worried I was going down some unsupported route.

Will continue on this path and see how we go.

Yes, a single connection matcher to match multiple incoming session connections is the way. It was designed for such scenarios.

Sorry, Did forget to ask - if you are aware...
Is there a limit to bgp sessions - or any documnetation I can look up to max counts.
am Using L6/P1+ licensed routers/CHRs as the VPN concentrators - so i don't believe there is a license limit - but is there a ROS limit or any specific known hardware limits.

Again, thanks for the info thus far.