Hi All,

This is my first post, so please be gentle hehe.

I hope someone can help me or point me in the right direction. Attached is a rudimentary drawing of our network.
CCR1 has 2x PPPoE servers running. One on VLAN10 and the other on VLAN11. There is no bridge on this CCR.

In the normal flow of the network, PPPoE vlan 10 serves R1 & R3 connected clients, and PPPoE vlan 11 serves R2 & R4 connected clients.
We have a backup link between R3 & R4. At this stage we disable the port that links R3 & R4 on R3, and when one of the vlan connections go down for whatever reason, we enable that port and all clients are then served via the PPPoE server on the active vlan.

My question is, is there a way to automate this process. R1, 2, 3 and 4 all have bridges setup with all ports added, so they are acting as glorified switches. Any help would be greatly appreciated. Bear in mind that during normal circumstances we need the network separated as per the image. Only when one vlan fails, we want to divert traffic of affected segment over the other vlan. Also, there are no further vlans in the network. Only from CCR to R1 & R2.

well... sure there is a possibility to automate the process using scripting (where you monitor something and based on the changes of the monitored value you change some settings), but why don't you use a backup pppoe server in both VLANs instead? Or at least why don't you use STP on the complete ring, so that in case of link failure the clients would access CCR1 via the other path through the ring?

Thanks for the reply. The PPPoE is not a concern for us, as it works 100% when there is a failure on one of the vlan links. Its just that we have to manually enable/disable the backup link on the routers.

Well, I have a problem to understand what a "VLAN link" actually means. There is a physical link that may fail, and there is a VLAN which is just a data element - a tag on a frame, so how does a "VLAN link failure" look like? Do you use a 3rd party transport network where frames carrying a specific VLAN tag are forwarded via a specific network path?

For L2 redundancy, STP is largely used (although not originally intended for that purpose) or a proprietary flavor of the mesh protocol can be used in Mikrotik; the latter prevents hardware swicthing from being used but that may only become a disadvantage if R1..R4 support hardware switching, and it has no advantages over MSTP in a simple ring topology like yours. More advanced L2 redundancy protocols exist these days but not (yet?) implemented in RouterOS.

With MSTP, you can set different link preferences for different groups of VLANs, so when everything works, VLAN 10 may take the shorter path to R1&R3 and VLAN 11 may take the shorter path to R2&R4, and the "long path" may only be used by either if the respective short one breaks. For that, you need to add a bridge to the CCR, configure MSTP on all 5 devices, move VLAN10 or VLAN11 to a dedicated MST instance, and configure own link costs for that instance.

So no scripting needed - it's pure static configuration, and the dynamic changes of the topology are controlled by MSTP itself.

MSTP alone is not good when optical links are used, as optical links can fail only in one direction and MSTP cannot detect such a failure.

Hey sindy, a virtual link is easy, you cant touch it smell it feel it, but its there

I would guess he means the physical cable linkage so that if a rat eats a cable between server and right or left side, the connectivity lost to clients can be re-established via the other hardwired (not chewed) connection.

Well, I have a problem to understand what a "VLAN link" actually means...

Thanks sindy,

Yeah so the two vlan links are seperate fiber links that we lease from a provider to a datacenter where they go into the datacenter switch (which we have no access to) and those vlans are assigned to the port where our CCR goes into. Both VLANs come in on physical port1 on CCR. That is where this is getting me a bit confused.

Hey sindy, a virtual link is easy, you cant touch it smell it feel it, but its there

I would guess he means the physical cable linkage so that if a rat eats a cable between server and right or left side, the connectivity lost to clients can be re-established via the other hardwired (not chewed) connection.

Lol yeah something like that

For the sake of clarity here is a new image:


During normal flow, traffic should flow from:
R3 -> R1 -> Sw -> CCR
R4 -> R2 -> Sw -> CCR

If lets say link between R1 & switch goes down traffic should flow:
R1 -> R3 -> R4 -> R2 -> Sw -> CCR
And so on.

To make this happen we enable the port on R3 that links it to R4
Thats the process I need automated either via script or routing protocol. Whichever will work best

And sindy you are correct that sometimes the fiber links go down one-way, so thats is something else to consider

Excuse my French, but that's a mess. The solution is just semi-redundant (the carrier's switch and the connection from it to your CCR is a SPOF, and so are your individual routers as each subscriber is apparently connected to just one of them), so you can protect the whole scheme only against a failure of one of the two links between R1, R2 and the datacenter. And you'd have to use dirty tricks in order to be able to use STP because "your" L2 network consists of two islands isolated by "their" L2 network. Also, you didn't state whether the interface between R1, R2 and the carrier's switch closest to them is tagged or untagged. Nor have you stated the model of R1 .. R4.

The dirty trick would be to make use of the fact that RouterOS can tag even STP BPDU frames with VLAN tags because /interface vlan is just a stupid tagging/untagging pipe, so you would create a bridge on the CCR, attach a single common PPPoE server to it, and make the tagless ends of both /interface vlan member ports of that bridge. This way, the carrier's switch would (hopefully) handle the BPDUs sent by this bridge as ordinary payload ones, but in order that this obfuscation worked, your traffic would have to stay tagged all the way through the carrier's network, up to the R1/R2 handover point (so R1 and R2 would untag the received traffic, not the carrier's gear).

The scripted solution would look the following: you would assign two IP addresses, from different subnets, to the two VLAN interfaces on the CCR to which the PPPoE servers are attached, and an address from the VLAN 10 subnet to R4 and an address from the VLAN11 subnet to R3. R3 and R4 would use /tool netwatch to monitor the transparency of each other's primary path to the CCR (using netwatch), and the up-script and down-script would enable and disable, respectively, a bridge filter rule preventing PPPoE-discovery frames from being accepted on ingress from the R3-R4 interconnection. I.e. when R4 would stop receiving responses from CCR's IP in VLAN 10, it would stop blocking PPPoE-discovery frames towards broadcast MAC address from clients connected to R1 and R2, thus allowing them to establish new connections to the PPPoE server in VLAN 11. It's up to you whether you would filter also PPPoE frames towards the CCR's MAC address, which would mean that as soon as the primary link would recover, the existing PPPoE sessions to the backup server would be broken immediately, or whether you would let the clients continue using the "wrong" server until you take a manual action.

Thanks Sindy. We opted for the scripted solution and it works a treat.