VRRP - did I get this right?

RouterOS General
1

Hello fellas,

I’m planning on utilising VRRP to provide resilience for my border routers (I have used CARP on FreeBSD before, however I really like MT interface and it makes it much easier to troubleshoot issues with less tech-savvy people).

Anyway, I have configured everything correctly. At least I think I have.

I’ve got:

  • YIN - IP 192.168.1.254


  • YAN - IP 192.168.1.253

VRRP interface is created successfully, priority on YIN is 254 so it’s a master. IP that I assigned to VRRP interface is 192.168.1.1.

Now, as quickly as VRRP interface is enabled, VRRP IP comes up, which is good. However slaves’s IP address, i.e. YAN’s is going down. I can’t ping it even from YIN even though I can see VRRP keep-alive packets coming from it. As soon as I reboot YIN – the master – YAN’s IP (192.168.1.253) comes back up and VRRP interface falls back to YAN.

As soon as YIN comes back up, VRRP goes back onto YIN and YAN disappears from the network.

Now my question is whether it is standard behaviour of VRRP or perhaps I’m doing something wrong here and I should be able to reach both nodes even though one of them is master.

Any comments much appreciated.

2

Bump!

3

Where are those yin and yan IPs actually assigned? did you put them on the underlying interface, or on the vrrp-interface itself?

And are they a /30, a /24, or what?

4

The are assigned to interfaces above VRRP. To picture this there is:

--> ether1 --> vlan2 --> vrrp1

YIN and YAN IPs are assigned to vlan2 (i.e. 192.168.1.254 and 192.168.1.253). 192.168.1.1 IP which is supposed to be the highly available gateway is assigned to vrrp1.

All IPs comes with netmask /24.

Thanks for reply and do let me know if you need more information.

5

Just to follow up on this as I was thinking about it again, wouldn’t that actually caused routing issues?

If YAN is backup and it’s bringing down 192.168.1.1 IP with /24 mask it’s going to cut off 192.168.1.253 route as well (i.e. it’s going to remove 192.168.1.0/24). The question now is, whether this is the correct behaviour?

I will connect a remote KVM to YAN today and test it out to see whether the route really disappear. If it does, the question will be whether it’s the correct behaviour – I guess I will have to dig out VRRP RFC to see that. I’m pretty sure that on FreeBSD I could have both physical and carp interfaces with IP addresses assigned from the same network.

6

Investigation continues. I have connected KVM over IP to YAN.

When I reboot YIN, YAN comes back up and is reachable, but as soon as YIN comes back up after reboot it takes over and YAN disappears off the network.

I have checked the routing tables – they are exactly the same when YAN is down as well as it’s up. The only change is that vrrp interfaces is going up and down depending on the YIN’s state. As expected.

And one interesting thing. While YAN is unreachable over the net I can ping from it the whole local network, i.e. 192.168.0.0/24. However I can’t ping it from the network (so the other way round).

If anyone has any ideas as for whether it’s normal behaviour I would highly appreciate comment.

Thanks!

7

In a VRRP test environment we have it set up like this (except with different IPs):

ex:
router1 ether1 vrrp common-switch
router2 ether1 vrrp common-switch

router1 ether1 192.168.10.1/30
router2 ether1 192.168.10.2/30

router1 vrrp 192.168.1.1/24
router2 vrrp 192.168.1.1/24

And router1 and router2 have connections to each other besides via ether1.

I haven’t tried it with a vlan, but I imagine that should work.

8

Yeah, that’s kind of set up is working fine for me, too. The problem appears to be if you want to have all IP addresses – the ones assigned to interfaces and to VRRP in the same network :frowning:

9

Is there some reason you want them in the same network? I don’t think it was meant to work that way.

There is the network(s) that are being redundantly served by vrrp, and then there is the management network that vrrp uses for its own housekeeping.

10

I suppose that from the point-of-view of the Kernel, all the ether1, ether2 and the VRRP interface are all separate interfaces.

Having the same network on all three would cause it some difficulty in working out what interface it should use to send data to the 192.168.1.0 network.

Try a different subnet on the ‘real’ ether1+2s and see what happens.

11

Purerly practical. I got a /28 from our provider. Now:

  • 1 IP is a network address


  • 1 IP is a broadcast address


  • 1 IP is my ISP GW


  • 5 addresses left for me

The way I want to use those 5 addresses is:

  • 1 address for one MT router so I can access it at any time do do eg. configuration changes


  • 1 address for another (backup) MT router so I can access it at any time


  • 1 IP that’s going to be a virtual IP being also GW through which my ISP will be routing all other classes into my network

Theoretically I could use different class for the purpose of the communication between the hosts, but having looked at the RFC document[1] VRRP communicates by sending packets to multicast. So that should not really make any difference.

Neither there is anything in the [1] that would suggest using same network IPs as for virtual IP should not work.

[1] http://www.faqs.org/rfcs/rfc2338.html

Cheers for the follow up! Appreciate it!

12

Just read this and then headed back to http://wiki.mikrotik.com/wiki/Manual:VRRP-examples where there is exactly the same scenario as I have described with one slight difference – netmask for the VRRPed IP address is /32. Did the same in my set up and voila! All dandy!

Both routers available on their public IPs and are “sharing” the virtual /32 IP between them accordingly without any problems!

Thanks everyone for suggestions!

13

Hm, interesting. It appears the current wiki documentation and the previously available documentation differ significantly in how to set it up. I think I understand why both methods work, but I shall study further.

When doing it the “old” way, private IPs should be sufficient for the management part of it.