VRRP... does it really work?

dirtonth · Fri Apr 21, 2006 2:55 pm

Hi Guys,

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?

savage · Fri Apr 21, 2006 3:56 pm

I've seen this exact thing many times with VRRP on MT, one of the reasons why I stoped using it. They should definately look at adding a virtual MAC to the VRRP Address.

If you change your ARP Cache Timeout to a extremely small amount (such as 1s) this will go away.

aitsecurity · Tue May 02, 2006 4:48 am

Hi Guys,

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?

mmm something is wrong, i was used HSRP is the same VRRP but propietary you know Cisco, and work very great, the VRRP is the open version and the original version, i am thinking this VRRP work , but why not for you,

en HSRP, in the case 3 and 4 you describe in HSRP work fine, the master take the role the again,

i was used for two router, two switche, and two server, and in the server have two ethernet cards, full redundancy, and work very great, when have 3 hello times 10 seg no see the master, the stand-by take the principal role.

i am thinking the VRRP, work better because i think Cisco copy this

Best Regards

.

dirtonth · Tue May 02, 2006 10:55 am

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.

savage · Tue May 02, 2006 7:02 pm

Would be interesting to see how they fix it.

Hope they introduce a virtual MAC address, or have the MAC address move with the IP address. I'm tied up like mad at a new job, so PLEASE post your findings after the release. I'd love to see this fixed!!!

--
C

dirtonth · Tue May 02, 2006 10:10 pm

I will post my findings as soon as they release.

I am suspecting a possible issue in my setup, that if they introduce a virtual mac, the managed switch I have in between might start blocking communication to the second router when the first one goes down because it would see same MAC address on different ports.... let's see what happens

abc123 · Wed May 03, 2006 5:18 pm

that's why you can set up ARP cache timeout on these two ports

There are several other mechanisms which could prevent "disaster" in case you described and maintain desired functionality.

savage · Thu May 04, 2006 10:54 pm

And if you have a non managed 24 port switch? It's a pain to have to manually set a lower arp-cache timeout on all the systems.

What if those 22 systems receive their IP Configuration via DHCP on MT? MT doesn't have a option to set a arp-timeout in a DHCP Scope. Unless you have intelligent switches, it's virtually a pain to configure VRRP to have a working configuration on MT.

Added to that, I have not seen one (other than MT) implementation of VRRP, HRSP, or any form of HA Cluster configuration where it was required that all nodes on a LAN segment accessing the dynamic address, had to have a reduced LOCAL arp-cache timeout. MT should fit in with the rest, not the rest with MT...

Just a thought.

IntraLink · Fri May 05, 2006 8:46 am

I like the idea of plugging in two managed switches, one each to a MT machine.

But the real issue is what clients have in their ARP cache.

So if they can create a virtual MAC then all of the problems disappear, right?

Or does the switch freak out if the MAC suddenly appears on another port?

I would guess not, since I can take my laptop, move it to another port, and it pings out in a couple of tries...

nikmac · Fri May 05, 2006 10:16 am

Hi guys

I had implement a cluster with isa2k & 2k4 and raptor
without any problem.

I unicast mode the vip of external interfaces i was
make a connection of all outside interfaces in a hub
first and after uplink to switch so the switch is register
only one port with mac address. there is note problem

I multicast mode i was direct connect all outside interfaces
in a switch and i have switch flooding, but again without problem

I MT v2.9.6 i was implement the first scenario (with hub)
without problem (the switch is use only one port).
but the mikrotik is not have the VMAC, only use AGRES. ARP

My problem is the vip in vpn. I saw that the connection tracking
is not monitor the ipsec (50) protocol only tcp/udp.
This my problem because after failback the secondary node
is trying to connect to remote peer.

Thanks nikos

nikhil · Wed Jun 07, 2006 3:12 pm

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.

Did you test with 2.9.24 ?

nikmac · Thu Jun 08, 2006 3:22 pm

Yes i was tested the 9.24 and 9.25 MT

The problem i think is layer-2 switch in 9.24
but i was overcoming with connect to MT in a hub first.

In 9.25 i saw that after failback the second MT (the stand by node)
is no register it's mac address in switch L2 and it needs to
disable and enable the interface to register succesfully it's mac address

This problem it does not appear in L3 switch

savage · Thu Jun 08, 2006 3:25 pm

The VRRP is still not working in MT.

There are plenty of posts about it arround the forums... Was supposed to be fixed in .24, it wasn't. .25 has been released, nothing mentioned about it in the changelogs...

nikmac · Thu Jun 08, 2006 3:50 pm

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

Thu Jun 08, 2006 5:43 pm

VRRP currently does not work on VLAN interfaces.

changeip · Thu Jun 15, 2006 2:56 am

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

.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.

Changing MAC addresses across switch ports is not a problem, the switch just learns it on another port instantly. Clients should listen to the gratuitous arp and learn the new MAC - which i think is working except that MT is broadcasting the wrong ip/mac pairs.

C:\Documents and Settings\Tiffany>arp -a

10.20.1.199 00-30-48-56-0d-6c dynamic
10.20.1.212 00-30-48-56-0d-6c dynamic
10.20.1.213 00-00-5e-00-01-01 dynamic

C:\Documents and Settings\Tiffany>arp -a

10.20.1.199 00-30-48-56-7b-58 dynamic
10.20.1.212 00-30-48-56-0d-6c dynamic
10.20.1.213 00-30-48-56-7b-58 dynamic

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

2.9.25 - sent support email with details of configuration.

nikhil · Thu Jun 15, 2006 7:46 am

normis ,eugene, sergejs can you comment on this ?

nikhil · Thu Jun 15, 2006 9:09 am

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...

What are the options ?

savage · Thu Jun 15, 2006 9:19 am

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...

nikhil · Thu Jun 15, 2006 9:57 am

cisco 29xx is a switch no vrrp. VRRP on 3600 is supported i think

savage · Thu Jun 15, 2006 10:02 am

You can configure redundant / failover ports on the switch - which gives redundancy... Bah, regardless, it's off topic. MT must fix VRRP or drop support for it.

Claiming you support something when it is obviously broken and not working isn't really very nice IMHO.

Thu Jun 15, 2006 10:42 am

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...

where? i see first post to be 2006.

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.

savage · Thu Jun 15, 2006 10:56 am

where? i see first post to be 2006.

My appologies. I seem to have had one eye looking elsewhere again... 1st was Apr 2006

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.

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.

Given changeip's post:

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

That just shows me that the standby router (10.20.1.213) will loose all connectivity untill the arp expires from the cache.

I'm not prepared to break my own network to test Mikrotik's software that should have been tested before it was released in any case. If VRRP is working (like you're claiming for the second time now), how on EARTH is it possible that three different IP addresses can have the same MAC address - even though two of those IP addresses sits on different physical machines (mikrotiks)....

At MOST, your Master + Virtual IP must have the same MAC, or your Slave + Virtual IP must have the same MAC. Considering that MT now claims that the Virtual IP uses a virtual MAC - I fail to see AT ALL, how many more than one IP address should have the same MAC address...

changeip · Thu Jun 15, 2006 5:55 pm

I think MT vrrp is getting better, but still not usable. I sent a few support tickets and supouts and am waiting to hear back. There is no possible misconfiguration that would cause the real IP to assume MAC of virtual IP, visa versa. I am sure it is a simple fix and look forward to .27 with a working vrrp. I commend MT people for the work thus far, it's not an easy job! I am glad to see representation on the forums and feedback actually listened to.

MT: If you want access to these 2 test routers again feel free to log in and use them. Vrrp is configured.

Sam

surfnet · Thu Jun 15, 2006 9:00 pm

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?

nikhil · Thu Jun 15, 2006 10:24 pm

Would like to get access to your script

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?

surfnet · Thu Jun 15, 2006 10:38 pm

answer my question and I will give you the script

just kidding

although this script doesnt help if the master never becomes a backup to acutally run the script and disable the olther interfaces. T

this can be found
http://www.mikrotik.com/docs/ros/2.8/ap ... g1.content
---------------------------------------------------------------
:global tmp;:global t;:global iface;:global bool
:set bool 0
:foreach i in [/ip vrrp find backup=yes] do={
/ip vrrp {
:set bool 1
:foreach e in [find master=yes] do={
:set iface [get $e interface]
/interface disable [/inter find name=$iface]
}
}
}

:if ($bool = 0) do={
/ip vrrp {
:foreach e in [find invalid=true] do={
:set iface [get $e interface]
/interface enable [/interf find name=$iface]
}
}
}
-------------------------------------------------------------

airnet · Tue Jun 20, 2006 12:13 pm

VRRP currently does not work on VLAN interfaces.

Yes it does. Weve had it implimented for 2+Yrs on MT VLAN interfaces.

It has never worked 'perfect' like it should with a real virtual mac address, rather it uses garp. Our scenario has 2 MT's acting as a reundant VRRP gateway (on VLAN interfaces) for 20+ Debian servers. It has worked flawlessly for a long time right up to the current installed version of MT that is 2.9.24.

If we unplug/kill the primary MT, the secondary takes over and vice-versa every time without a hitch.
With a stream of 1-second pings going to the debain boxes, they are lucky to miss 2 pings max (every time)

VRRP has certainly had its issues over the time, most notably when using a 'cloned config' you can break stuff because it carries the MAC over from the clone master. (looooong standing bug).
Apart from that, the present implimentation of garp VRRP works great in our books.

Maybe it is only a problem with devices that dont handle garp properly like windoze?

savage · Tue Jun 20, 2006 12:22 pm

Maybe it is only a problem with devices that dont handle garp properly like windoze?

Like another MT?

It's strange. Same cables, same network. Two FreeBSD 4.8 systems using FreeVRRP and Graceful ARPs to release MACs - works FLAWLESSLY.

Two Mikrotiks, 100% same environment, all hell breaks loose. From everything I worked with in my entire life so far that claims to support VRRP / HRSP (Which, I know is different), I've *only* had problems with MT...

changeip · Tue Jun 20, 2006 5:17 pm

You can look in routeros /ip arp and even see the mismatched mac/ip pairs - so MT is confusing itself. You lose communication between boxes when this happens even. Again, the RFC states that the virtual MAC should never cross boundaries with the physical MAC - and we are seeing this happen. No switches, no clients, just plain RouterOS /ip arp shows this even.

Sam

Eugene · Wed Jun 21, 2006 10:29 am

You have to configure VRRP from scratch in the latest version of RouterOS.

Eugene

savage · Wed Jun 21, 2006 10:38 am

-shrugs-

Ok, so changeip will more than likely have a chance before me to test this, but I'll byte Eugene.

I'll buy two more licenses from MT, I will upgrade my software to the latest version, if VRRP does not work, will MT refund me???

Something tells me not, so I'm just wondering how we can proceed here, as you insist that it's working, whilst virtually every post about VRRP on here, indicates it's not...

Eugene · Wed Jun 21, 2006 11:23 am

well, seems that the other posters test with outdated versions

bugs ..., ugh, tend to be fixed over time

Eugene

savage · Wed Jun 21, 2006 11:38 am

I highly doubt that...

I know for a fact changeip tested with new versions, I'm pretty sure he would have with the latest as well as he's following the BGP issue quite closely too. Though, I'm not going to speak on his behalf.

It has worked flawlessly for a long time right up to the current installed version of MT that is 2.9.24.

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.

If I wanted to use intelligent switches, I'd just go buy a Catalyst or something use use redundancy on the switch, instead of Mikrotik all together...

Eugene · Wed Jun 21, 2006 12:04 pm

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.

Eugene

IntraLink · Wed Jun 21, 2006 2:59 pm

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.

Eugene

Yeah, I upgraded from 2.9.7 and the interface assigned to the VRRP Virtual ID were all messed up.

When I tried to delete all VRRP information and start over the interface information was still wrong in Winbox.

Eugene · Wed Jun 21, 2006 3:41 pm

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"

changeip · Wed Jun 21, 2006 4:20 pm

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.

Eugene

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.

Sam

IntraLink · Wed Jun 21, 2006 6:36 pm

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

Sorry about that, where do I send the file, or what is the process for sending it?

Nevermind, I figured it out and sent the support file.

changeip · Wed Jun 21, 2006 6:41 pm

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.

Eugene

Changelog shows nothing fixed in vrrp since 2.9.24 so I don't believe vrrp configuration/upgrade path is the problem.

After configuring VRRP on a fresh /system resetted router (br1) I show this from a remote windows workstation:

10.20.1.199 00-30-48-56-0d-6c dynamic
10.20.1.212 00-30-48-56-0d-6c dynamic
10.20.1.213 00-30-48-56-7b-58 dynamic

10.20.1.199 is the virtual IP - and it should NEVER show the mac of the physical network interface. .212 is the primary IP and .213 is the partner. .199 should ALWAYS have the virtual MAC. Plain and simple, if virtual IP can't decide on which MAC to use there will be problems.

# jun/21/2006 17:33:34 by RouterOS 2.9.26
# software id = 56LL-XXX
#
/ ip vrrp
add name="vr1" interface=6-interconnect vrid=1 priority=255 interval=1 \
preemption-mode=yes authentication=none password="" on-backup="" \
on-master="" disabled=no
/ ip vrrp address
add address=10.20.1.199/32 network=10.20.1.199 broadcast=10.20.1.199 \
instance=vr1 interface=5-cogent disabled=no

Is there anyone that does have VRRP actually working > 2.9.24 ?

Sam

savage · Wed Jun 21, 2006 9:38 pm

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.

changeip · Wed Jun 21, 2006 9:52 pm

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.

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.

The concept of debugging their code... I hate it too really, but I don't feel like throwing out what we have any buying more expensive cisco or other equipment. I feel that if we help Mikrotik debug a more stable product will be available to everyone else - and someday it'll all be worth it. (I hope, crossing my fingers) I will say that if we report bugs and they do not get fixed then that's the time when we move elsewhere and cut our losses, but so far if MT can validate the problem they will fix it usually.

VRRP is not that common in their userbase so it's probably been on the low end of the priority list. VRRP is becoming more and more important and therefore they have more people screaming at them to fix it.

Mikrotik should give away a free L4 license every time someone reports a valid bug report. : )

For the price MT can't be beat.

Sam

Eugene · Tue Jun 27, 2006 6:45 pm

VRRP got fixed in 2.9.27. Please test and report back.

Eugene

changeip · Tue Jun 27, 2006 6:46 pm

Thank you for your hard work Eugene.

IntraLink · Thu Jul 06, 2006 4:19 pm

Anyone confirm this fix yet for VRRP in .27?

changeip · Thu Jul 06, 2006 6:49 pm

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.

Sigh...

Sam

changeip · Fri Jul 07, 2006 1:43 am

2.9.27

I seemed to have totally hosed up one of my routers with vrrp. I configured a vrrp group, and then a vrrp ip address. After testing for 1-2 minutes I simply removed the vrrp ip and then the group. I disabled first, then removed. Verified it was gone with a /ip vrrp export - yep, gone. After 2 reboots, deleting and re-adding the physical IP, etc I am still stuck with a virtual MAC address on that interface... 00-00-5e-00-01-01 is being advertised even though vrrp is not configured. vrrp is still affecting interfaces that have nothing to do with the virtual ips.

Oh man - what to do short of a /system reset?

Took some pcaps, screen shots, and supouts. Will email shortly.

Sam

IntraLink · Fri Jul 07, 2006 4:05 am

That sucks.

If that is a bug I hope they fix that soon. Please let us know what you find out.

I really don't want to install this and have the same issues and then have to re-install the whole router config because of a stuck virtual MAC.

Eugene · Fri Jul 07, 2006 8:45 am

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.

Sigh...

Sam

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.

nikmac · Fri Jul 07, 2006 9:27 am

Hi

In previous versions (2.9.24-25) the gr arp is more slowly
In current version is more quickly

In non inteligent switch (L2 without blocking ports) there is not
problem during failover-failback.

In inteligent switch (like cisco catalyst) the problem remain
(bloking port)
and to overcom this i do this scenario : connect all external interfaces
in hub or dummy switch and then uplink to external switch.

This scenario working for me about on month.

Is possible in feature versions to come the real cluster (hertbeat or
the connection sharing between nodes) ?

Thanks

savage · Fri Jul 07, 2006 11:32 am

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.

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 MAC

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....

Eugene · Fri Jul 07, 2006 1:48 pm

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.
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 MAC

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:

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.

Eugene

changeip · Fri Jul 07, 2006 5:10 pm

Exactly. Eugene, I will see if I can find better details for rfc2338 that explain this. I have a drawing that will explain why this causes major problems.

If virtual MAC is used on all IPs on all interfaces (it is) then entire router looks as if its a single interface now.

rfc2338 is a little vague on what you shouldn't do - but is detailed on what you should do. I will be back in a few with more info for you guys.

Sam

changeip · Fri Jul 07, 2006 8:11 pm

http://www1.ietf.org/mail-archive/web/v ... 00632.html

"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."

rfc2338 isn't very clear about the following:

"Virtual IP should always show virtual MAC"
"Physical IP should always show physical MAC"

but I think that is the intention of the document. The above quote seems to agree with this. VRRP should not mess with interfaces or ip addresses that aren't part of vrrp.

If the physical mac is basically swapped out for the virtual mac, even after deconfiguring vrrp, how can 2 routers participate on the same network anymore? As it stands I can no longer keep my 2nd test router on the network because it has the same mac address - and neither are configured for vrrp anymore. Do I have to /system reset them to get my physical MAC back, or wait for .28 ?

Sam

IntraLink · Fri Jul 07, 2006 11:57 pm

Ah, I think I see your point; two identical MAC addresses, one on each router on different switch ports. And this affects the whole interface MAC even after VRRP is removed?

I'm sure your switch doesn't like that!

If this is the case then can we expect a fix in .28?
I'm waiting until this is resolved before trying it.

changeip · Sat Jul 08, 2006 12:18 am

Bob Hinden was nice enough to reply to an email I sent asking for clarification. Bob is one of the original authors of rfc2338 and the editor for the newest rfc3768. The new rfc basically removed some authentication, otherwise they are the same.

> Can you guys answer some questions below?
>
> 1. Should any non-virtual ip addresses ever show a virtual mac
> address?

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
virtual MAC.

> "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

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.

I sent some followup questions.

> 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.

Yes.

Bob is the maintainer for the vrrp rfc, I hope this clarifies the RouterOS implementation.

Sam

Eugene · Mon Jul 10, 2006 9:39 am

If I understand correctly this means that an interface that is running vrrp should show the virtual mac for all ips.

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.

Eugene

changeip · Mon Jul 10, 2006 9:45 am

It does break things. If I have assigned a local, non-virtual ip on the vrrp interface to administer to box from, or to query snmp, etc I will get only the master. This is workable I guess, just as long as you never need to run vrrp on the same interface you run anything else.

I have 2 problems at this time.

Interfaces that are not part of vrrp are being affected by virtual mac - even though they have nothing to do with vrrp.

I also have deconfigured vrrp and now I cannot get my physical mac back. This means the 2 test routers I ran vrrp on temporarily cannot be powered on at the same time because they have conflicting mac addresses.

Sam

Eugene · Mon Jul 10, 2006 10:02 am

I assume support output file is already sent ?

Eugene

changeip · Mon Jul 10, 2006 10:14 am

I assume support output file is already sent ?

Eugene

Just sent to support. Can you help me get physical mac back so I don't have to /system reset?

changeip · Mon Jul 10, 2006 10:16 am

Ah, I see it modified the actual configuration of that interface...

/ interface ethernet
set 0-inside name="0-inside" mtu=1500 mac-address=00:00:5E:00:01:01 arp=enabled disable-running-check=yes \
auto-negotiation=yes full-duplex=yes cable-settings=default speed=100Mbps comment="" disabled=no

That is not good to modify configuration, it should only use virtual mac when vrrp is in use. Possibly you can just create a virtual interface for vrrp and not use physical interface, maybe this will make things easier to implement.

Sam

VRRP... does it really work?

VRRP... does it really work?

Re: VRRP... does it really work?

Update in Coming Release

Re: Update in Coming Release

Who is online