any advice pls, im running VRRP-Load sharing and VLANS.
I can't make it work.It seems like i need to play with script.

Does anyone know how can i avoid using the script

i know where is the issus, but im not sure how can i fix it up


/interface vrrp
add interface=e2vl4078 name=vrrp-m-vl4078 priority=254 vrid=77--------->VRRP-Master
add interface=e2vl4077 name=vrrp-s-vl4077 vrid=40--------------------------->VRRP-Slave

/ip address
add address=192.168.1.4/24 interface=e2vl4077 network=192.168.1.0
add address=192.168.1.253 interface=vrrp-s-vl4077 network=192.168.1.253------>once i disable this it work, but that one is here for failover
add address=192.168.1.254 interface=vrrp-m-vl4078 network=192.168.1.254
add address=192.168.1.3/24 interface=e2vl4078 network=192.168.1.0

Why are you using two different vlans here with the same subnets? Both VLAN 4078 and VLAN 4077 are using the 192.168.1.x/24 network. I can imagine that this does strange things with routing. Could you explain a bit more what you are trying to do here? From a client perspective what would you like to happen?

i wish if i can use one, but i'm using VRRP load sharing.
Simple i'm using two VRRPs , and that why i need teo VLANs

https://wiki.mikrotik.com/wiki/Manual:V ... ad_sharing

You can have multiple VRRP instances within one L2 segment. In fact that is what the Load Sharing wiki shows you as well (they just put it all on ether1). If you need vlans (because, for example, you need to have a separate management network or something) just put this on the same VLAN. So:

and on other site, same thing.
Ive done this,but i cant remember what kind of issues i was getting.
Let me try one more time. l'll come back to you

1. re-wording what @JelleM wrote: all routers negotiating using VRRP which one of them will listen on a particular IP address must be in the same L2 segment (VLAN). They use that same L2 segment to inform each other about their state.

2. re-wording what @JelleM wrote as well: you can have multiple VRRP interfaces, each with an individual MAC address and with an individual IP address, in the same subnet, with different priorities of the routers. So while all routers are alive, each VRRP interface is in master mode on one of them; once one of the routers fails, the VRRP interface that preferred this router goes up on the next one by priority. So this is the way to provide the load distribution among the routers.

3. if you run different VRRP instances at different physical interfaces of a router, it can happen that one physical interface goes down and another one stays up, so the router can't reach one of the networks it is supposed to route between.

3a. to prevent that router from staying a VRRP master in the surviving network, you have to use the on-master and on-backup scripts on the /interface vrrp rows - once the physical interface goes down, you have to lower the priority of the VRRP instances on the other physical interface. But there's a catch, VRRP determines its state based solely on reception of the VRRP packets from other routers in the group. So when a physical interface goes down, the VRRP interface attached to it becomes a master as it can't see any incoming VRRP packets. Hence the on-master script must check the state of the underlying interface and take an appropriate action depending on it, which is to increase the priority of the VRRP instances attached to the other interface if its underlying interface is up, and to decrease it if its underlying interface is down. The on-backup script just restores the normal priorities.

3b. instead of the scripts modifying priority, you may prefer to use a backup route to the network that goes missing via another router in the source subnet. This will result in the packet being delivered and ICMP "better gateway available" message sent back to the source, which may or may not honor it, but this way is not compatible with stateful firewalls on the routers, as the traffic paths are not symmetric. Synchronization of the connection tracking database from the master router to the backup one is only available in RouterOS 7.

Completely make sense what @JelleM suggesting.
I was looking for more ethernet-vlans to achieve something which it seems like doesn't fit in this scenario, or i need to find other solution.

Thanks @JelleM @sindy