I have a client who has 4 x DSL connections to the same ISP and I am unable to get all 4 x connections working at the same time on 4 x separate RB750 PPPoE interfaces.
When I activate the additional PPPoE interfaces the status does not change from “disconected”.
In other words there is no attempt to establish a link.
To get round the problem I am using 1 x PPPoE connection to a DSL modem/router in bridge mode and 3 x DHCP client connection to 3 x DSL modem/routers in DHCP server mode.
This is not ideal.
I know the RB750 can support multiple PPPoE connections as I have 2 x DSL connections in my office, but these are with different ISPs.
Is my problem something to do with the fact that the 4 x DSL connections are with the same ISP and therefore on the same DSLAM?
I would appreciate any advice as this is a difficult problem to troubleshoot without ordering additional DSL connections from another ISP.
When you say “on 4 x separate RB750 PPPoE interfaces”, do you mean that you have attached each of the four /interface pppoe-client to its own /interface ethernet or they are all bound to the same /interface bridge and the ethernet interfaces to which the modems are connected are member ports of that bridge? In the second case, all the PPPoE clients would be seen as having the same MAC address, which might make the DSLAM ignore all but the first one. So the right way is to detach the ethernet interfaces from the bridge and attach each /interface pppoe-client directly to its own ethernet interface; that way, each /interface pppoe-client will use the individual MAC address of the ethernet interface to which it is attached and the DSLAM should accept all four connections.
Note that pppoe interfaces 2, 3 & 4 are disabled as ether2, ether3 & ether 4 are currently being used as DHCP client WAN interfaces connected to router with same pppoe authentication details.
As I said in original email the pppoe interfaces don’t appear to attempt a connection, with connection status remaining “disconnected”
As Sindy said, if those ethernet ports are assigned to bridge, remove them.
Check the log as well, what is the error message when fail to connects? Any attempt or re-attempt when the connection status remaining as “disconnected”?
I have the same issue like you with two internet services from same provider. From memory, it is because of those two PPPoE connections issue the same gateway IP that can mess up the routing table.
At the end I’ve switched one of the service with another provider.
I’m afraid the OP hasn’t got that far as to get a gateway IP address collision. But the issue you describe should be resolvable by not allowing the pppoe-clients to add default route and instead add the routes manually, indicating the interface names as their gateways. This makes it impossible to implement a script-less failover but removes the confusion regarding gateway IP address.
I don’t know how feasible it is for you to play with one of the connections, but it would be nice to see the packet sniff from the ethernet port as the pppoe client attempts to get up. Along with the table of MAC addresses associated to the individual ports of your RB.
All except pppoe1 are disconnected without any routes created.
creating a route for each with interface as gateway makes no difference to connection status.
I feel that someone must have come across this before, but the only reference I can find in forums is with multiple pppoe connections to same dslam over a single interface.
Unfortunately I cant order 4 x DSL connections from another ISP to see if it is an ISP issue.
The gateway IP conflict is too far from the pppoe layer, it cannot cause the pppoe to disconnect.
The only issue I can imagine is Mikrotik sending from a single MAC address by mistake, confusing the DSLAM, or that Mikrotik’s pppoe process ignores the information about packet source interface and is confused by DSLAM MAC address being the same on both sessions.
What I’m trying to say is that as almost everything is implemented in software, the behaviour may be a bug or mere omission of an unexpected scenario on Mikrotik side. Without seeing the real traffic it is all just wild guessing; with a capture, it will still be guessing but less wild.
When debugging this, I would first unplug 3 ethernet cables and see if the remaining one comes up, then try with all 4 one at a time,
and see if all 4 PPPoE links works when used stand-alone.
While going, I would check the local and remote address obtained from each of the links and see if they are different.
Also check the default route obtained from them.
When that all looks sensible I would try with 2 and see what happens.