❓ Share public IP pools between routers ?

RouterOS Beginner Basics
1

Hi friends,
I’m using CCR1072 for PPPoE AC & Core router in the past but now I’ve split it to 4x CCR1036 for better performance and lower CPU usage.

My question is I can able to share my Public IP pools from Core to child PPPoE AC routers that all of them can use the whole blocks not only that routed self ?
Mikrotik_PPPoE_SharePublicIpPool.jpg
For example if one of my Public pools is 5.250.14.0/24 then :
Is there able PPPoE AC1 can assign 5.250.14.1 and PPPoE AC2 also can assign 5.250.14.2 to their clients?

Note : because of IP Pools specified from radius server, we will not have IP assignment duplication problem.

2

someone said I must use OSPF but don’t find any example of it , I try it too but not success yet .

3

It is possible to do that, but it is not a very good idea. When a connection is made or disconnected there is a route update.
This can cause a lot of overhead and even an avalanche where the router is so busy processing the updates due to disconnected
sessions that it will disconnect sessions because of the busy CPU, and thus causes even more work.
There is a presentation about this on the MikroTik Youtube channel (impossible to find due to the flood of recordings of MUM events).

4

Unfortunately, there’s no option for pooling/clustering DHCP servers in routerOS.
We’re running DHCP on a FT-protected CHR vm on a ESXi cluster and use a DHCP relay on the ACs.
-Chris

5

The ISC dhcp server is pretty flexible but I’m not sure if it does this exact thing. It probably can solve the problem in some way. It does failover and management of pools between servers. I’m running it with failover to a peer on 2 raspberry pi’s.

6

i’ll do (I actually did this with a system that has ~20k users on it) the following:

  1. use RADIUS to assign addresses for each incoming PPPoE session from the pool you defined.
  2. the core router shall advertise the pool as an aggregate w/o specific entries. say you use the ‘network’ command in bgp. this assumes you will run bgp with the rest of your network
  3. the core router shall have blackhole routes for the pools, say in /24 chunks - this is to make sure that packets arrive to unused addresses will get dropped (no ping-pong)
  4. the ACs shoud “redistribute” the connected prefixes into BGP (i’ll say bgp, as there will be lots of prefixes, and bgp is stable enough to handle them)
  5. on the core router assign ‘no-advertise’ community to the BGP sessions with the ACs (to make sure the /32 entries will not be leaked)
  6. core router shall advertise only a default to the ACs (no-advertise from the previous line will make sure no specifics will be re-advertised to the other ACs)

this way all the packets that have dst ip pointing to the pool will be routed to the core.
if the address is not used, the packets will be discarded
if it is used, then there will be a /32 pointing to the AC where the subscriber is connected to
so the packet will be routed to that AC, then to the connected customer.

the ACs just see the default coming from the core AND the route entries for each connected subscriber
so if the packet’s destination address that comes from a subscriber

  • is another subscriber connected to the same AC, the packet will be routed there
  • is another subscriber connected to a different AC, the packet will take the default route towards the core, then the dst ip will be looked up from all the bgp routes of all connected subscribers, and it will be sent to the respective AC then to the subscriber
  • is some address in the rest of you network or on the internet, then the packet will take the default to the core, then based on the routing table entries to some outside interface

this setup works and scales pretty well. as i said we had this in operation for 2 years with 20k subscribers distributed in 16 devices