Hello,

VLAN works fine on VRRP Interfaces.
In wiki stands, I should VRRP Intarface only give /32 not /24. Why should I do this? What is the reason for that?

Work for me.
- ether1 ( 10.0.0.0/30 )
- VRRP1 ( 10.0.0.4/30 )
- VLAN1 ( 10.0.1.0/24 )
- VLAN2 ( 10.0.2.0/24 )
- VLAN3 ( 10.0.3.0/24 )

What I understand have to do.
- ether1 ( 10.0.0.0/30 )
- VLAN1 ( 10.0.1.0/24 )
- VRRP2 ( 10.0.1.254/32 )
- VLAN2 ( 10.0.2.0/24 )
- VRRP2 ( 10.0.2.254/32 )

Thanks for the Explanation

Hi.

I think you have the answer in a old post.

Check this out
viewtopic.php?t=56698

hi,

i still don't get the /32. Now i have 2 vrrps over the same interface configured on two routers. IPs are 1,10 for vrrp and 253,254 for the ethernet interfaces. 1 is held by one router and 10 by the other as master. Both work ok with addresses set as /24, I don't see abnormal cpu usage or traffic volumes while runing over 300 ovpn tunnels over these 2 vrrps.

If you don't use /32s on any secondary IP address (not only VRRP) you will receive broadcast traffic (among other things) twice. This could affect some services and routing protocols. That's also why /32s are always used on Loopbacks, in order to not create a broadcast domain. Whilst MT may create two interfaces (and I hate this), you need to understand that on the NIC, they are still on the same VLAN/Physical Interface. Both will receive any form of broadcast.

If the IPs aren't in the same subnet (i.e. 1.1.1.0/24 and 1.1.2.0/24), then the primary and secondary should be /24, to ensure broadcast traffic is received on both networks (i.e. both broadcast domains are created).

The above, does not hold true for IPv6 as IPv6 does not use broadcast traffic. I stand corrected (I actually need to look at this at some stage), but I believe in the case of VRRP at least, all addresses should be part of the same /64.

Thank you for explaining this

If you don't use /32s on any secondary IP address (not only VRRP) you will receive broadcast traffic (among other things) twice. This could affect some services and routing protocols. That's also why /32s are always used on Loopbacks, in order to not create a broadcast domain. Whilst MT may create two interfaces (and I hate this), you need to understand that on the NIC, they are still on the same VLAN/Physical Interface. Both will receive any form of broadcast.

Ok, I Understand this. That is the Implementation from MT and I have to do that. So that no comic effects occur.

But why I should not create VLAN on VRRP Interfaces?

If I do that, I only need one VRRP per physical Interface and not in each VLAN Interface one VRRP Interface.

If the VRRP Interface is Backup, all VLANs are disable, and is the VRRP Interface is Master, all VLANs are reachable.

Uhm. Vlans are layer 2. Vrrp is layer 3.

I'm surprised that Mt even allow this. It shouldnt work at all.... if you can actually do this in Mt, it should be seen as a bug.

It works on different Hardware without Problems ( I don't use all funktions from MT ). But when it is wrong, I will change it.

I have another question.

I have a public IP range /26. Some IPs I will use on the MT and some on other Systems.

If I work with VRRP, how to do that? Should I add all public IPs that I will use as /32 on the VRRP Interface?

80.80.80.80/32
80.80.80.85/32
80.80.80.86/32
80.80.80.88/32

Thanks

Strange. I've never, ever heard of a vlan on top of VRRP. A vlan (should) be attached to an interface. VRRP is attached to an IP address. MT is the only vendor I know off that creates a new interface for a VRRP instance (which is why you can create the VLAN). Oh well.

If you don't care for a broadcast domain then all of them can be /32s, but you need to route traffic to the router's (interface) via a different IP and/or Loopback then I would guess, as the /32s won't be directly connected on a different router, The reason why one IP is (normally) not a /32, is so that the adjacent router can be directly connected to the subnet, and you can route traffic to it. Nothing wrong with 1.1.1.1/24 on the LAN, and 2.2.2.2/32 on VRRP however, where 2.2.2.2 is routed to 1.1.1.1 on the adjacent routers.

I like it. I mean, it does look wrong (and it probably is), vlans should be on "real" interface (which vrrp one isn't). But it looks like vlans "seep through" vrrp interface and stick to its parent interface and they work fine this way. You can't have two vrrp interfaces on same physical interface and vlans with same number on each vrrp interface and expect them to be isolated. But if you want to load balance a lot of vlans at the same time, this can be nice hack that allows you to do it in much simpler way, instead of having separate vrrp in each vlan. So as long as you don't need to worry about interoperability, and MikroTik doesn't decide that it's wrong and fix it...

Sob, you beat me to labbing it up. When you say one VRRP interface are you also applying multiple addresses, 1 per VLAN essentially, to it?

As far as the question about why it's a /32, it wasn't clearly articulated. The problem is broadcast domain but not because you're going to see twice as much broadcast traffic. You'll have duplicate IP addresses. Think about:

MikroTik1-Eth1 - 192.168.1.254/24 <--> MikroTik2-Eth1 - 192.168.1.253/24

This would leave you with 2 routers on a /24. They have unique IP addresses. Say you want to add VRRP into the mix with the IP of 192.168.1.1. You have to add them as a /32, anycast, IP. Because their is no broadcast domain the same /32 can live on the subnet without causing address duplication issues. The RFC states a non-master VRRP router cannot respond to traffic for a shared IP address, this is why typically you don't see an issue. During state transitions you do have the possibility of it happening. By setting it up as a /32 you prevent that entirely.

To sum it up, use a /32 for your VRRP addresses unless you have a very good reason to prevent any potential duplicate address related issues.

VRRP in this case works just as a simple on/off switch. You need some address(*1) on physical interface and some address(*1) on VRRP interface, to make it come up. Then when you add VLANs on top of VRRP interface, they are active when it's master and inactive when it's backup. I doubt that it was indended, but it's interesting trick.

--
(*1) Even just IPv6 link-local, if you use IPv6 VRRP.