I am having a bit of an issue getting a working routing configuration with a pair of MikroTiks.

My configuration consists of two RB750 routers each connected to separate network switches via eth2 (port 3). The switches are connected together via a single port. The routers are connected to each other via eth1 (port 2). Both of the routers have a connection to an upstream provider via eth0 (port 1).

The eth0 interfaces each have a /30 for routing to the upstream provider. The default route on both routers has a gateway on this interface and the gateway is monitored via ping. This is a "manual fail-over" configuration. The eth0 interface on both routers has the same address so someone can simply move the cable if one router should cease to function. Yes, I know. Don't ask. This part is functioning exactly as intended.

The eth1 interfaces have addresses in the 10.0.20.0/30 network. This is so that no matter what is happening on the eth2 interface, the routers can always talk to each other. This is also configured as a default route with a metric of 2. This ensures that if a router does not have the cable connected to eth0 it can still route packets out to the world at large. This part is not functioning properly because of what is happening on eth2.

The eth2 interfaces have a VRRP interface sitting on top. Both the eth2 interfaces and the VRRP interface have addresses in 10.0.10.0/24. The VRRP functions perfectly and the other systems connected to the switches have no problem with the gateway moving around.

The problem comes in with what happens when the switch connected to the router with the uplink cable attached (we can call it router1) fails. Or the link from that router to the switch fails. It does not matter either way. In this scenario, the VRRP fails the gateway to the router without the uplink cable attached (router2). Packets destined for a non-local network are then sent to router2 as expected. Since router2 has no uplink, the default route with a metric of 1 is not active and router2 uses the default route with a metric of 2 to forward packets to router1 via the 10.0.20.0/30 network on eth1. Then router1 forwards packets out over the uplink. So far so good.

Inbound packets are a different story. The packets arrive across the uplink to router1. An address in the destination network exists on one of the router interfaces so the connect route is selected even though the link is down. As a result, the packets never get forwarded to router2 so they can be forwarded on to the network. In testing, if I disable the 10.0.10.x address on router1 and thus remove the connect route, everything begins working perfectly.

So here is the rub. I need some way to keep the router from routing packets when the interface is down. I use "down" here fairly loosely as I would like to make sure other hosts are reachable even if the link is up. I think I can use netwatch and some scripting to simply disable the address like I am in testing, but I want to make sure there is not some better way I am overlooking.

Things I cannot change:
- One uplink only.
- VRRP... I have to support clients which have the ability to only talk to a single gateway. Unless there is another way to move the gateway IP address, VRRP is it.

Any input would be much appreciated. Cheers.

I believe there are bugs in VRRP or something - I had to fail (by setting priority) a few times during initial config to get VRRP working. I didn't think much of it as the peer VRRP is Mikrotik 3.x and I had to make changes to support the older VRRP version too.

Yesterday about 24 hours ago we had our network go down, took a while to track down the issue. From inside the network the router was pingable for some clients, not others - From outside router was pingable - But forwarding wasn't working.

We reset router and noticed everything came up a few moments, then went back down - We believe the "up" was while VRRP was on the backup router (we reset thinking perhaps something was hung, we used reset button on router).

We proceeded to interface vrrp set 0 priority=100 to fail to the other Mikrotik, everything was fine. Tonight we have a maint window in case anything goes wrong and did a interface vrrp set 0 priority=225 (to go back) and all is fine.

*IF* there is a bug in the routing code where an interface drops out randomly this is very significant for those running VRRP.

Anyone else experiencing anything similar? Unfortunately I didn't have the luxury once we found the router was the issue to gather much data, instead we had to fail over quickly to backup router.
Steve Radich

While I cannot speak for bugs in such an old version of RouterOS, I can say my configuration is working just fine. I have another VRRP setup with redundant uplinks and it works great as well. You did not state which interfaces run VRRP. If you are only running it on the external interface and using some other method on the internal interface you will have essentially the inverse of my problem.

Make sure you are not running into the problem of flapping interfaces. I have a script which monitors the availability of network resources form the normal master MikroTik. If the internal link on it goes down, the script will disable certain IP addresses on that link. You have to be careful as to which addresses you monitor because if the alternate route becomes active and makes these addresses available from the master it will bring the interface online again thus making the address unavailable. You then get a cyclic or flapping situation.

Another problem may also be your network switches. Certain low-end or mid-grade network switches take a while to update the MAC table. When VRRP hops the addresses this MAC table needs to recognize the MAC is no longer on the original port. VRRP does issue a request in this regard when it fails over, but not all switches will respond appropriately. If you were unable to reach the MikroTik from only some internal addresses, I suggest you take a look at your MAC table on the switches to see on which ports ports they have the VRRP MAC address registered.

Let me know what you find.

bitshop, I have same issue.
For some reason, at some moment, Master VRRP router just stops forwarding data. It response on ping from MT, but do not respond on ping from inside network, or not forwarding any packet from internal network.
VRRP is on internal network address, so it is connectable from WAN links.
I could not find reason why it happens, ARP table both on Master MT and next switch is fine (virtual VRRP MAC).
As ping continue to work, backup MT do not switch over, and I just get disconnect with internal link.
If I change priority, disable and enable, or reset MT, I get VRRP to work again.
I have tried to make script to detect VRRP failure, but not sucsesufull for now, as connection with other MT and rest of internal network is existing even without VRRP on non virtual IP.

How have you resolve this issue ?

P.S. MT version 5.20

Hi,

Did you find solution? I have same issue with two RB493 (5.22). When I disable vrrp interface forwarding works fine.
I'm also using OSPF, but the problem seems to be connected with vrrp.

Regards,
Marcin

I have made a script that ping internal switch using VRRP ip address from primary router, and if ping fails, it disable and enable VRRP interface.
This script is started every 3 seconds.
That way, connection will not broke even if VRRP process stops for a second.