Good Day.
Background:
We have about 1500 Routers, and there are about 12 000 PPPOE users between all the routers. (routers Range from CCR to RB433)
Currently the users gets local IP adreses in the 10.0.0.0/8 Range from pppoe Pools, and we use OSPF areas to only advertise the Ranges per Router.
Aggregating ythe user IP's basically.
Some users gets Public IP adresses via PPPOE, and that /32 adresses gets "redistribute connected routes" via OSPF.
We also use OSPF between Towers.

Everything works very good this way, but we are facing a challenge.

We need to provide all the 12k users with dynamic Public IP adresses, that will be handed out by Radius.
We can not use Pools, the main reason is we will waste net-blocks assigning it to Routers, and we will not have enough Public adreses. so we will have to use Concurrent connections, so only a active user will have a Public IP.

Due to the geographical size of the network, we cannot use PPPOE concentrators, thus the reason for individual smaller concentrators.
In a perfect world all users could use concentrators in a central location, but there is no central location to do this, and it wont make logical sense.

I was advised to use BGP to redistribute connected routes, and use a Route reflector to do this, probably something from Juniper, the Vrr they provide, as I understand mikrotik can not be a Pure standalone Route reflector, due to it loading the routes in the forwarding table only.

BGP are suppose to run light on CPU and RAM, and will not be sensitive to link state changes like OSPF, as the routing table will carry about 15k Routes in total, where 12K will be via BGP.


SO this is a Big project and a Mission, as there is not allot of people available with experience in this kind of setup, as it has to do with scaling.
My plan is to use the Route reflector to provide the Next HOP to the other routers.

Is there anybody that are willing to give advice on this type of setup ?
Maybe this is not the perfect way to do this ?

Please advice.

Thank you

Somehow this just doesn't sound like a good idea to me.

I think that if you broaden the scopes of your "pools" to be regional (and not per-router) then you should be able to efficiently utilize aggregation to minimize your OSPF database / routing table w/o sacrificing IP density.

On our network, we assign the smallest "pool" size possible to each router, and just either increase the size of the pool, or add additional small pools as necessary. The routers' pools come from regional pools, which can be aggregated at ABRs in order to minimize the number of routes in the table.

Also, if you use small ranges at the edge, you can still have "roaming" hosts - e.g. routerXYZ has range 192.0.2.0/29. It announces this summary prefix into OSPF, so customers with .1 through .7 will be aggregated into this summary range. RouterABC has range 192.0.2.16/28.... Now suppose customer with IP 192.0.2.3 moves onto router ABC, then ABC will announce 192.0.2.16/28 and 192.0.2.3/32. This will ensure that all addresses will be reachable, but the majority of "non-roaming" users' addresses will be aggregated into ranges.

Careful planning of your ranges can ensure efficient aggregation w/o the need to use BGP, which is really a poorly-suited IGP.

I have considered that, but it just get so complicated to manage it in areas, as we have allot of areas and an "area" can have more than 10 links to other areas.
I did consider it, but it sounds hectic and can get complicated to manage..

I think carefully managing and planning pools will work like you suggest, to keep the pool sizes very close to the amount of users on that tower.

I will always run OSPF as the IGP, and will continue to do so, I just had the understanding that BGP will handle the amount of client routes better if each client gets a dynamic IP from Radius.

I understand that OSPF can get unstable at a certain point above 10 routes ?
We are at 3500 now.

Thinking hard .......

I understand that OSPF can get unstable at a certain point above 10 routes ?

If OSPF gets unstable with 10 routes, its implementation is hardly broken.
OSPF should have zero problems with 10, 100 or 1000 routes
But it's true you should not import your BGP table into OSPF.

Hi, I made a Typo, I meant 10 000 Routes.

I am not sure how i will handle that.

Another problem is the depletion of IPV4, so if we continue adding clients we will run out of V4 Publics, and we will have to give some clients local IP's again.

And to Go v6 only wont really work at this stage.

So the challenge is the Scaling and Growth, as we experience 30% clients grownt, sitting on 12K clients connections now.