Mikrotik CCR 1009 two IP Pools /24 PPOE server

I am small ISP using Mikrotik CCR 1009. and Noob when it comes to RouterOS. I have few issues. I will list them in two or three separate threads.

Config are as follows.

  1. Sfp 1 is WAN 1 (telco 1)

  2. Eth 1 is WAN 2 (telco 2) 2nd line for redundancy

  3. ETH 2 is main Output to clients running PPPoE server with Pool 103.xxx.x79.1 /24
    PPPoE Pool1 is 103.xxx.x79.60 to 254 (2-59) is reserved for static clients or later use

  4. DMA is my radius server.

Now everything is running fine. Except following…

I wanted to run separate PPPOe on ETH3.

  1. I made a second Pool 2 of 103.xxx.x78.2-254
  2. I assigned 103.xxx.x78.1/24 to ETH 3.
  3. 2nd separate PPPoE server with above IP running on ETH 3.

Now. PPPoe Connects but Internet Doesn’t run. i can access CCR thru winbox or web. BUT internet does not run on clients. what am i doing wrong.

Thanks

There is no need to assign an IP address to ether3, and you can share a pool across multiple PPPoE servers if required.

You have a public /23?

Thanks for the quick response. i know there is an option of ‘NEXT POOL’

  1. I have two /24
  2. I wanted to run two servers with separate pool (two /24) on two different ports that goes to to different OLTs . Is this efficient ?

why is net not working on 2nd POOL. that was my 1st question

Thanks

It doesn’t affect the Mikrotik, depends if it is a sensible division of your IP space.


why is net not working on 2nd POOL. that was my 1st question

Any number of things - firewall rules, routing. Impossible to say without seeing the configuration.

The PPPoE connection actually establishes the IP’s on the router so you don’t have to physically run any of the IP’s for Local (or Remote) in /ip address as they’ll get dynamically added when the PPP establishes.

You can have 1 profile
1 Pool
Then 1 ‘PPPoE Server’ per interface

When users dial-in, PPPoE is a L2 protocol so doesn’t require an IP, then on establishment of the tunnel it creates the correct dynamic entries.

Can help more if you post your full config (/export hide-sensitive)

Please check!

Thanks
rigatech.rsc (35.8 KB)

bump! on this

For your issue in the other thread:

Now i cannot access my Radius Server ( 103.xxx.x79.49 ) from my Clients side (PPPoE Clients) that are using above POOL (obviously)

The issue is with the subnets. Each PPPoE client gets its own /32 subnet of just one device. Additionally for some unknown reason you have placed the same subnet as a /24 on that same physical interface used for PPPoE.

A bit of theory - when a device needs to send traffic, first it has to determine whether the destination is on the same network or a different network. The way it does this is it applies its own subnet mask to both its own IP and the destination IP and does a bitwise AND comparison. If the results of this match, the sender knows that the other device is on the same network as it is, and sends an ARP request for that device’s MAC address to send the packet directly. If the results do not match, the sender knows that the other device is on a different network, and the sender sends the packet to the router instead so that it can be delivered to that other network.

So lets use an example - suppose you have a client on 103.xxx.x79.88 and it wants to connect your RADIUS server on 103.xxx.x79.49. First, the client would do a bitwise AND comparison using its own netmask, for both the source and destination IPs for the packet. This netmask is 255.255.255.255, in CIDR terms a /32:

Source IP: 103.xxx.x79.88
Source netmask: 255.255.255.255
AND comparison result: 103.xxx.x79.88

Destination IP: 103.xxx.x79.49
Source netmask: 255.255.255.255
AND comparison result: 103.xxx.x79.49

The two bitwise AND comparison results in this case do not match - one ends in 88 and one ends in 49. As a result, the PPPoE client correctly knows that it has to send the packet through a router to reach the RADIUS server as it is on a different subnet (and it is in fact on a different subnet).

This initial packet will make it to the RADIUS server and the RADIUS server will try to respond. In order to respond, the RADIUS server has to determine whether the PPPoE client is on the same network as it or a different network. In actuality we know that the PPPoE client is on a different network (a network of just one IP, network address 103.xxx.x79.88), but the RADIUS server has to use the bitwise AND comparison like before to try to determine whether the PPPoE client is on a different network. It does these calculations and gets these results:

Source IP: 103.xxx.x79.49
Source netmask: 255.255.255.0 (/24)
AND comparison result: 103.xxx.x79.0

Destination IP: 103.xxx.x79.88
Source netmask: 255.255.255.0 (/24)
AND comparison result: 103.xxx.x79.0

In this case, because the RADIUS server’s subnet mask is 255.255.255.0, the AND comparison results match - both are 103.xxx.x79.0. The RADIUS server then (incorrectly) thinks that the client is on the same network as it, and that it doesn’t have to send the packet through the router. It does an ARP request, asking 103.xxx.x79.88 what its MAC address is. Because this client is not actually on the same network, there will be no response to this ARP request. The RADIUS server then gives up on trying to send the response since it doesn’t know what MAC to send it to.

The best solution here is to make the subnet that the RADIUS server is on smaller than a /24, perhaps a /26 which would include the first 64 IPs, so that it didn’t overlap with the PPPoE range.