MikroTik

Do we have to rebuild the VRRP definitions after upgrading to 2.9.24?

Everything seems ok, but I don't think it's working.

WinBox shows the M for master on the master box and the B for backup on the backup box, but shouldn't there be another indicator that they are talking to each other (I forget what that looks like)?

2.9.24 vrrp weirdness... just begun a test using 2 brand new installs (/system reset). Seems that the master uses its own mac address until it fails over and then uses the virtual - or not consistent anyhow.

Prefail:

-> Virtual
10.20.1.100 00-30-48-56-7b-58 dynamic
-> Two routers
10.20.1.126 00-30-48-56-7b-58 dynamic
10.20.1.127 00-30-48-56-0d-6c dynamic

After fail:

-> Virtual
10.20.1.100 00-00-5e-00-01-01 dynamic
-> backup router - shows virtual MAC - ??
10.20.1.127 00-00-5e-00-01-01 dynamic

After master recovers:

10.20.1.100 00-30-48-56-0d-6c dynamic
10.20.1.127 00-30-48-56-0d-6c dynamic

So it seems the virtual MAC is not being used 100% of the time. The .100 address should ALWAYS have the 00-00-5e mac address correct?

Configuration is as follows:

master:
/ ip vrrp
add name="vr1" interface=ether5 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.100/24 network=10.20.1.0 \
broadcast=10.20.1.255 instance=vr1 interface=ether5 \
disabled=no


backup:
/ ip vrrp
add name="vr1" interface=ether5 vrid=1 priority=100 interval=1 \
preemption-mode=yes authentication=none password="" \
on-backup="" on-master="" disabled=no
/ ip vrrp address
add address=10.20.1.100/24 network=10.20.1.0 \
broadcast=10.20.1.255 instance=vr1 interface=ether5 \
disabled=no

-shrugs-

No need to upgrade to .24 for me then.... If only MT would have been kind enough to send a gracious arp when the IP was moved, then everything would be fine...

I think it is sending arps, just with the wrong MAC... I need to bust out ethereal to double check so don't take my word for it yet.

Sam

I am interested in this as well without redundancy we are also just waiting to be hit hard.

It's doing much more...

Unless you made a typo:

10.20.1.100 00-30-48-56-7b-58 dynamic - V
10.20.1.100 00-00-5e-00-01-01 dynamic - V
10.20.1.100 00-30-48-56-0d-6c dynamic - V

If a virtual MAC address is used, and that MAC is shifted between the master / slave servers (Like a Virtual MAC is supposed to work), howcome it change? Nevermind the change, but the VRRP Address moved from the master, to the slave, back to the master. Three moves, three different MAC Addresses????

10.20.1.127 00-30-48-56-0d-6c dynamic - S
10.20.1.127 00-00-5e-00-01-01 dynamic - S
10.20.1.127 00-30-48-56-0d-6c dynamic - S

The SLAVE IP Address, is a Fixed IP. VRRP has NOTHING to do with it. How come the Slave's MAC address, also changed???? This, can cause HAVOC on certain implementations...


I hate to be funny here, but perhaps MT should just look at FreeVRRPd and slap that onto MT... Atleast then we have something that works and is usable... How long has this been going on about VRRP now?? And still MT is unable to deliver

Enough is enough MT... Please... Fix this!

The SLAVE IP Address, is a Fixed IP. VRRP has NOTHING to do with it. How come the Slave's MAC address, also changed???? This, can cause HAVOC on certain implementations...

That was my observation as well... the non-vrrp IP & MAC shouldn't ever change. Also, the virtual IP should never show a real MAC - only the virtual one. I will take some packet captures to get some more details.

Sam

Yes, it seems the virtual IP is being overwritten with the physical MAC on certain packets.

RFC2338 Paragraph 8.2 states you should never see phsyical MAC on the virtual IP - it will confuse clients arp caches.

8.2 Host ARP Requests

When a host sends an ARP request for one of the virtual router IP
addresses, the Master virtual router MUST respond to the ARP request
with the virtual MAC address for the virtual router. The Master
virtual router MUST NOT respond with its physical MAC address. This
allows the client to always use the same MAC address regardless of
the current Master router.



The above image shows the virtual 10.20.1.100 being exposed with the physical machines MAC. I do see packets from 10.20.1.100 also with the 00-00-5E-00-01-{VRID} MAC but this type of response forces the client to use a new MAC.

Small bug to fix - probably not hard once they figure out whats wrong.

Sam