I am trying to implement a setup using VRRP. RouterOS is 2.9.21. First I went straight away to using VRRP with VLANs and Bridges implementation but that failed straight away. So I decided to test VRRP to its basics. When I did so, I was getting the following result:
1. Pinging Dynamic IP works when both Master and Backup are online. ARP shows that the host is piniging the Master.
2. When Master goes offline, ping works. ARP shows that host is pinging Backup (which is now Master).
3. When Master is back online, ping works. ARP shows that host is still pinging the Backup!
4. When Backup goes offline, pinging stops.
Why aren't the 2 boxes using a commong virtual MAC as well for the dynamic address?
I have been through the forum searching on VRRP and most questions are not being answered.... can Mikrotik help out please?
I have emailed Mikrotik about the problem, and the guys told me that there wil be an update dealing with these issues in release 2.9.24. I am waiting for that release to retest and post my feedback.
.199 is the virtual IP. It should ALWAYS have the 00-00-5e-00-01-01 mac address. You will see after failover and back that the real MAC is being mixed around with the virtual MAC which definately confuses clients.In 9.25 the problem is the second node
after failback it doesn't register the primary mac
of ethernet and steel catch the 00:00:5e:00:01:01.
This mac address is owned by first node after failback.
So i loose the communication with secondary node
and must disable and enable vrrp in this node
What are the options ?I guess, now we wait for .26 again...
I'm just about ready to give up on VRRP and MT. How long has it been now, still no workable fix. In the release thread of .25 - I was actually told that "it does work and I need to go and test it". I guess, it does NOT work, regardless of what MT said.
I wonder what the next excuse/reason/etc will be from MT for it not working...
where? i see first post to be 2006.I just noticed something...
First post of this thread: 20 Aug 2004
Todays Date: 15 Jun 2006
Shocking!!! And it's still on going... Almost 2 years and still no fix to a problem? I guess purchasing a support contract from Mikrotik won't help much either, as this is a software issue rather than a configuration issue.
Hmm, wait it out or buy a couple of Cisco 29xxs... Choices choices...
My appologies. I seem to have had one eye looking elsewhere again... 1st was Apr 2006where? i see first post to be 2006.
There, I definately do not agree with you. Sure, using intelligent switches, you can get VRRP to work because you can tell the switch not to hold (cache) the MAC addresses... On dumb switches - or even hubs, I cannot see how this will work.you should start by sending supout.rif files to support with specific problem description, and easy steps how to reproduce the problem. we are not talking about lack of features now, we are talking about you saying "it doesn't work at all". we have yet to see a mail about a problem that is not configuration issue.
That just shows me that the standby router (10.20.1.213) will loose all connectivity untill the arp expires from the cache.C:\Documents and Settings\Tiffany>arp -a
10.20.1.199 00-00-5e-00-01-01 dynamic
10.20.1.212 00-00-5e-00-01-01 dynamic
10.20.1.213 00-00-5e-00-01-01 dynamic
I am setting up VRRP to be used as a reduntant router.. so I have each fo the 3 ethernet interfaces setup with their own VRRP vrid.
I am using the MK script that should run when a Master turns to backup. The script will disbale all other interfaces. This helps when only 1 interface fails.. of course you want the entire router offline, not just the one interface. so the MK script will disbale all other interfaces on the master router, which allows the backup router to take over all interfaces. And then when the master comes back online, it runs the script to enable all the interfaces, and thus take over all the routing.
The problem occuring is that the Master, nerver becomes a backup. When I unplug the ethernet cable from the interface, it still shows it as master.
my question is.. how do you make master be a backup?
Yes it does. Weve had it implimented for 2+Yrs on MT VLAN interfaces.VRRP currently does not work on VLAN interfaces.
Like another MT?Maybe it is only a problem with devices that dont handle garp properly like windoze?
Yet, I *know* this has been tested on .25, and did not work (MAC addresses was still screwed up - the posts are on this very thread). Sure, you can get this to work using intelligent switches and disabling your arp cache - but those, are hacks - not a fix. In my eye they don't count.It has worked flawlessly for a long time right up to the current installed version of MT that is 2.9.24.
Yeah, I upgraded from 2.9.7 and the interface assigned to the VRRP Virtual ID were all messed up.The problem with the latest version is that you have to configure VRRP _from scratch_, not just upgrade the router. That's why Sam got negative result.
I started VRRP from scratch on 2.9.25, did it change that much in .26 that it needed to be restarted from scratch? Problem was I tried to remove the config all together and it still wanted to use the virtuals- even with no VRRP... I ended up having to /system reset to clear it. I will try again today on 2.9.26 and post the results, which I think are the same, but will do for testing sake.The problem with the latest version is that you have to configure VRRP _from scratch_, not just upgrade the router. That's why Sam got negative result.
Sorry about that, where do I send the file, or what is the process for sending it?as always, send support file ... There is no help to anyone to simply say "it doesn't work". An appropriate reply would be "works for us" :D
Changelog shows nothing fixed in vrrp since 2.9.24 so I don't believe vrrp configuration/upgrade path is the problem.The problem with the latest version is that you have to configure VRRP _from scratch_, not just upgrade the router. That's why Sam got negative result.
There are virtual macs in the 00:00:5E range, but they bleed between real/virtual ip addresses and cause problems. There are gArps as well I believe, seen them with ethereal. I think vrrp has come a long way since the earlier versions, it just needs a little bit of fixing to be stable for production use.Against my believes - it's not my job to debug MT software, I've tested with .26 (new install) as well tonight - same issue. No virtual MAC, no Graceful ARPs, not RFC compliant.
I've been told to shut up though, seeing that I'm apparently not allowed to criticize MT. Wish you the best changeip :) It's ok Eugene... Ban me if you want - it will be your loss, not mine.
Actually, VRRP master router will change the mac address of the interface to a virtual one, causing ALL addresses on that interface to be advertised with this virtual mac address.From what I can tell its working better - but still unusable in our configuration. Maybe it's something I don't understand about vrrp - maybe not. Problem we are having is that the non-virtual ip on ALL interfaces is getting the 00-00-5e mac addresses causing non-vrrp clients to break. Is vrrp supposed to affect all other mac/ip pairs on the router, or just the virtual ones? I think its the latter, but rfc2338 doesn't specify.
And that's *exactly* where you are going wrong! The Virtual Mac, has nothing per say, to do with the interface! The static IPs must still have the real MAC, *only* the switching IP, must be bound to the Virtual MACActually, VRRP master router will change the mac address of the interface to a virtual one, causing ALL addresses on that interface to be advertised with this virtual mac address.
Hm, and where exactly is it written? There are no restrictions in the current RFC regarding the use of virtual MAC address for the addresses not part of the virtual router.And that's *exactly* where you are going wrong! The Virtual Mac, has nothing per say, to do with the interface! The static IPs must still have the real MAC, *only* the switching IP, must be bound to the Virtual MACActually, VRRP master router will change the mac address of the interface to a virtual one, causing ALL addresses on that interface to be advertised with this virtual mac address.
Once the IP is released and moved to the master, the Virtual MAC simply moves to the new Virtual IP, associated with the standby system.
You're simply going about this the wrong way. I guess, I pass on .27 as well now.... :roll:
rfc2338 isn't very clear about the following:"I understand how startling this observation can be, but it's
just basic IP logic, nothing VRRP specific about it. Once
you get your thoughts around it, VRRP falls out nicely.
In particular, you realize that there is only one reason, ever,
to use the VR's MAC address as the source of an ethernet packet,
and that is to teach the ethernet switching infrastructure
where to send packets with that MAC address as the destination.
That is accomplished by sending the advertisement packets with
the VR MAC address as source since those packets are known to
be sent at the appropriate times."
If I understand correctly this means that an interface that is running vrrp should show the virtual mac for all ips. I also understand that vrrp is interface specific and should not affect interfaces / ips that are not part of a vrrp group.> Can you guys answer some questions below?
> 1. Should any non-virtual ip addresses ever show a virtual mac
VRRP as specified doesn't use virtual IP addresses. It talks about
address owners and backup routers. Once VRRP is enabled on an
interface the virtual mac address should always be used.
It is possible to configure VRRP so there are only backup routers
(e.g., no IP address owner). This case isn't covered in the
specification. In this case, since the IP addresses are not owned by
any physical interface, they could be considered virtual IP
addresses. In this case, the physical mac would continue to be used
for owned addresses not running VRRP. But the intended use of VRRP
there is an address owner.
> 2. Should any interfaces, not part of a virtual router, be
> affected by vrrp? Meaning should a local ip on a non-vrrp
> interface ever use the virtual mac?
No. The virtual mac is only for interface running VRRP.
> 3. Is my statement below correct?
> "Virtual IP should always show virtual MAC"
Partially. All IP addresses used in VRRP should always show the
> "Physical IP should always show physical MAC"
No, except in the case I describe above. Once VRRP is enabled for an
IP address on an interface, the virtual MAC should always be used.
Suggest rereading Section 8.2 "Host ARP Requests".
Hope that helps,
Bob is the maintainer for the vrrp rfc, I hope this clarifies the RouterOS implementation.> I think I now understand more clearly ... will you let me know if
> these are true statements?
> 1. All ip addresses on the interface vrrp is running on should
> show the virtual mac address, even locally assigned non-vrrp ips on
> the same interface.
Yes, except for an IP address that is not part of any VRRP virtual
router. If that is what you mean by locally assigned non-vrrp IPs,
then no for that.
> 2. IP addresses on the same router, but not belonging to the vrrp
> interface, should never show virtual macs.
That's how it should work. Technically, there is no reason IP addresses not part of the virtual router should use the virtual mac, but this simplifies implementation a lot without breaking any standards.If I understand correctly this means that an interface that is running vrrp should show the virtual mac for all ips.