MX HA - VRRP

[RaphaelL]

Hi ,

Is there a way to view the MAC of the VRRP ? In the dashboard I can see the individual MAC of both MX that are configured in WarmSpace. 

MX1: ends 9e:44  ( Dashboard says PRIMARY )

MX2: ends c2:08 ( Dashboard says SLAVE )

When I click on the edit button ( Security & Sd-WAN -> Spare Status -> Configure warm spare ) the Warm Space MAC showed is the exact same as the MX2 ( ends c2:08 ).

When doing a packet capture , the MAC responding to ARP requests is a bit different than the Primary but ends with the same part ( 9e:44 ) which looks to be the VRRP MAC. 

Why is the warm space  MAC different than the VRRP MAC from my packet captures ?

Thanks , 

[pmhaske]

Greetings,

The VRRP MAC address (virtual mac address) is used by both MXs in the HA pair and will be a part of the VRRP process. LAN of both MX will use this virtual mac address instead of a physical MAC address. The First 3 octets for the virtual mac address will be "cc:03:d9" and is based on Primary MX.

The VRRP MAC address is shared by both MXs for LAN communication. Clients on the LAN will associate this shared MAC address with the MX's LAN IPs. As such, in the event of a failover, LAN clients won't need to update their ARP table with a new MAC address. 

[RaphaelL]

Thanks for the reply. 

Should'nt I be able to see the VRRP MAC in the dashboard ? I was expecting to see it in the Warm Space.

[pmhaske · Accepted solution]

The VRRP MAC address will not be available on the dashboard. But can be easily identified as the first 3 octets are always "cc:03:d9" and the last two octets are always of the primary MX as it sends the virtual mac as a part of the VRRP process.

[Jedediah_Jumbl]

Out of curiosity, is this something that Meraki even details in official KBs or docs anywhere? The closest things that I could find for virtual MACs didn't detail those specific "cc:03:d9" octets as the tell-tale indicator to be mindful of if one found themselves hunting. I happened upon this thread as I was trying to track down what is apparently a virtual MAC. It was only after I got a reply on a case I had opened about this mysterious address that I was told it was a virtual MAC associated with one of my MX devices. After searching, your answer was the top result time and again.

[RaphaelL]

Well it all begins with Meraki not following RFCs. 

https://documentation.meraki.com/MS/Layer_3_Switching/MS_Warm_Spare_(VRRP)_Overview

The virtual MAC address will always begin with 88-15-44

The screenshot of the documentation shows otherwise , and your packet captures will show otherwise. 

If my memory serves me right , I had 2 posts. My MX450 and MX250 were behaving "the Meraki way" but a MX68 HA wasn't.

https://datatracker.ietf.org/doc/html/rfc5798#section-7.3

 The virtual router MAC address associated with a virtual router is an
   IEEE 802 MAC Address in the following format:

   IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in Internet-standard bit-
   order)

   The first three octets are derived from the IANA's Organizational
   Unique Identifier (OUI).  The next two octets (00-01) indicate the
   address block assigned to the VRRP for IPv4 protocol. {VRID} is the
   VRRP Virtual Router Identifier.  This mapping provides for up to 255
   IPv4 VRRP routers on a network

In real world : cc:03:d9:xx:xx:xx 

Documentation : 88:15:44:xx:xx:xx

RFC : 00:00:5E:00:01:XX

Bit confusing eh ?

[pmhaske]

Hello @RaphaelL and @Jedediah_Jumbl,

Linked documentation is related to the switch warm spare and the mentioned virtual mac addressing scheme (88:15:44) is exclusive to switches.

For MX devices virtual mac will be starting with first three octets as cc:03:d9 as mentioned earlier.

According to RFC, the first 3 octets are derived by OUI, and from OUI lookups cc:03:d9 and 88:15:44 are Cisco Meraki. Hence, RFC is followed.

@Jedediah_Jumbl I will add feedback in the MX warm spare KB to add that cc:03:d9 will be the starting virtual Mac address of the MX, similar to the lines that are seen in the MS warm spare KB.

ETA: This is incorrect. Please see my new response below with the correct and updated information. Thanks, and sorry for any miscommunication here! 

[RaphaelL]

According to RFC, the first 3 octets are derived by OUI, and from OUI lookups cc:03:d9 and 88:15:44 are Cisco Meraki. Hence, RFC is followed.

Which RFC ? Because VRRP RFC states that there is already an official IANA OUI reserved for VRRP.

The next two octets (00-01) indicate the
   address block assigned to the VRRP for IPv4 protocol

[pmhaske]

Hello @RaphaelL,

I will take back my previous response, as it does not seem we are compliant with RFC 5798 as you correctly pointed out. Thanks for that!

Implementation of VRRP for HA is limited within MX product models and we don't use it for communication with another vendor for VRRP. We are not claiming that we are VRRP compliant, we just provide HA for MX and MS with our implementation.

Apologies for the error everyone, I have added the feedback to the documentation already as stated earlier.

[Jedediah_Jumbl]

Thank you! Would you happen to know why that note wouldn't have been in there already? Just seemed odd that there was info relating to virtual MACs on switches, but not on MX appliances. In any case, much appreciated for getting it added. Hopefully it will help someone in the future 😄

[RaphaelL]

This was a bug that was fixed in MX 15.40 : 

• Corrected an issue that resulted in MX appliances incorrectly using their WAN interface MAC address when 1) the MX appliances are configured in high availability, 2) the MX appliances are configured as one-armed VPN concentrators, and 3) traffic was being sourced from the shared virtual IP. MX appliances will now properly use the virtual MAC address in these cases.

It did confuse me a lot 2 years ago 🙂