VRRP Best Practices

Solved
meraki-newbie
Getting noticed

VRRP Best Practices

Hello all,

 

Currently we have plan to deploy VRRP between MX85 in our DC, as drawn below :

 

dc plandc plan

 

 

Expected traffic flow :

  • GCP > Forti Firewall-01 <static route> MX vIP > ISP on MX85-01 (load balance) > Internet/VPN Meraki Remote Side
  • Internet/VPN Meraki Remote Side > ISP on MX85-01 (load balance) <static route> Forti Firewall-01 > GCP

 

we want to have full redundancy for both traffic direction by using VRRP, but there are some doubt in my head:

 

  1. Could we use private segment for VRRP ? 
  2. If we could run private segment for VRRP, could we run only 1 segment VRRP only for 2 ISP on each MX85?
  3. Or should we define different private segment vIP for each ISP ? such as :
    • vIP segment ISP-A : 10.10.255.0/29
    • vIP segment ISP-B : 10.20.255.0/29
  4. Or we should have to request more public segment from each ISP, to be used as VRRP for each ISP?

 

thank you

 

 

1 Accepted Solution
Ryan_Miles
Meraki Employee
Meraki Employee

The MX requires unique IPs on the WAN side. So, one for MX1 another for MX2 and a third optional one for the VIP.

The LAN side works differently. There are just VLANs and their associated L3 IPs. No per MX IP, nor a VIP. The single IP per VLAN will belong to whichever MX is primary.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.

View solution in original post

13 Replies 13
alemabrahao
Kind of a big deal
Kind of a big deal

This topology is not recommended, firstly because you intend to make a direct connection between the MXes, secondly because on the LAN you need to have the spanning tree running since the MX does not support LACP.
 
So I don't see it as a functional topology.

 

https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair

 

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
alemabrahao
Kind of a big deal
Kind of a big deal

Requirements and Best Practices 

When configuring routed HA, it is critical that both MXs have a reliable connection to each other on the LAN, so the heartbeats of the primary MX can be seen reliably by the spare. To ensure this connection is reliable:

  • The two MXs should be connected to each other through a downstream switch (or ideally, multiple switches) on the LAN to allow for passing VRRP heartbeats.
    • There should be no more than one additional hop between them, and they must be able to communicate on all VLANs.
    • Make sure Spanning-Tree Protocol (STP) is enabled on the downstream switching infrastructure, as a properly-configured HA topology will introduce a loop on the network.
  • When first configuring routed HA, the spare should be added and configured in the dashboard before the device is physically deployed, so it will immediately fetch its configuration and behave appropriately.
  • If a virtual IP is being used, each uplink of the two MXs must share the same broadcast domain on the WAN side.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
meraki-newbie
Getting noticed

so, is that means we need to have another IP public to be used on our Firewall ? and we need to have this public ip configured :

 

  • x.x.x.x/29 (ISP-A) allocation :
    1. x.x.x.1 > ISP side
    2. x.x.x.2 > MX01
    3. x.x.x.3 > MX02
    4. x.x.x.4 > vIP Heartbeat
    5. x.x.x.5 > Firewall
  • y.y.y.y/29 (ISP-A) allocation :
    1. y.y.y.1 > ISP side
    2. y.y.y.2 > MX01
    3. y.y.y.3 > MX02
    4. y.y.y.4 > vIP Heartbeat
    5. y.y.y.5 > Firewall

 

as mentioned  on this link below https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Routed_... :

 

merakinewbie_0-1711980392911.png

 

alemabrahao
Kind of a big deal
Kind of a big deal

 

No, if you look at the recommendations, what I'm talking about has nothing to do with WAN.

 

 

  • The two MXs should be connected to each other through a downstream switch (or ideally, multiple switches) on the LAN to allow for passing VRRP heartbeats.
    • There should be no more than one additional hop between them, and they must be able to communicate on all VLANs.
    • Make sure Spanning-Tree Protocol (STP) is enabled on the downstream switching infrastructure, as a properly-configured HA topology will introduce a loop on the network.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
alemabrahao
Kind of a big deal
Kind of a big deal

In short, I'm talking about ports 2 and 3 of the MXes. Connecting directly to the Fortigate doesn't seem like a good idea to me, the ideal would be to have a downstream switch to carry out VRRP communication and not have a cable directly connected to each MX (its VLAN 2024).
 
It would be a good idea to hire a consultancy specialized in implementing Meraki.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Ryan_Miles
Meraki Employee
Meraki Employee

Your WAN IP config looks ok to me (warning - I'm just starting my first morning coffee, so brain is maybe not at 100% yet). The MX WAN interfaces need unique IPs on each unit in the HA config and another IP for the VIP. It appears you have all that in place.

 

What @alemabrahao is mentioning is the LAN side of the MXs. The MXs don't support LACP or STP. So, you can have redundant links like you show as long as the device on the other side supports and is running STP to prevent loops. Not sure those downstream firewalls would support that in this design.

 

Our recommended topology shows not connecting MXs directly to each other. I'm not sure any document specifically says not to do it. And, I personally see some value in a direct link between MXs as one more layer of protection against a dual active scenario (example topologies). 

 

Also, VRRP is sent on all VLAN interfaces on a MX. So it would also go over the port 2 & 3 of the MXs in your diagram. There's no concept of a dedicated HA/VRRP link on a MX.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
meraki-newbie
Getting noticed

got it, so it means i could applied with this topology design below? as long peer switch device could run STP to block looping

2april.jpg

 

Ryan_Miles
Meraki Employee
Meraki Employee

Might just be minor omissions/oversights in the diagram. But if you have two ISPs there would be two VIPs on the MX HA pair. VIP1 = ISP1 and VIP2 = ISP2.

Also, the diagram mentions 10.10.255.x/29 in a few places. So I'm not entirely sure where that's being used or if it's just a generic reference. On the MX we refer to the VIP as the shared WAN IP(s) and not any LAN side L3 interface/SVI.

But IPs aside the rest of it looks reasonable to me. That said I would very much want to lab it up and test  all failure scenarios prior to deployment.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
meraki-newbie
Getting noticed

Got it, will be applied vIPs for each ISP connection.

"Also, the diagram mentions 10.10.255.x/29 in a few places. So I'm not entirely sure where that's being used or if it's just a generic reference. On the MX we refer to the VIP as the shared WAN IP(s) and not any LAN side L3 interface/SVI."

  • yes my purpose like having VRRP for LAN side using 10.10.255.x/29 segment. 
  • Much like having HSRP and use IPs on :
    • MX1 10.10.255.1, priority 100
    • MX2 10.10.255.2, priority 90
    • MX Standby IP 10.10.255.3
    • Firewall 10.10.255.5
  • So traffic from INSIDE (GCP)/LAN side will have an MX Standby IP 10.10.255.3  as next hop to the OUTSIDE (ISPs)
  • And traffic from OUTSIDE (ISPs) will have an Firewall IP 10.10.255.5 as next hop to the INSIDE (GCP)/LAN side

Could i applied that scenario above ? because it still confusing me, as there are no exact documentation to applied Layer 3 redundancy on LAN side


 

Ryan_Miles
Meraki Employee
Meraki Employee

The MX requires unique IPs on the WAN side. So, one for MX1 another for MX2 and a third optional one for the VIP.

The LAN side works differently. There are just VLANs and their associated L3 IPs. No per MX IP, nor a VIP. The single IP per VLAN will belong to whichever MX is primary.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
meraki-newbie
Getting noticed

"The MX requires unique IPs on the WAN side. So, one for MX1 another for MX2 and a third optional one for the VIP."

  • Could I use private IP for vIP ? rather than public IP as vIP ?

"The LAN side works differently. There are just VLANs and their associated L3 IPs. No per MX IP, nor a VIP. The single IP per VLAN will belong to whichever MX is primary."

  • So is that mean, i just need these configuration below ? :
    • Create Interface vlan 255 10.10.255.1/30  on MX1 and MX2
    • Create mode access vlan 255 on port 2-3 towards LAN side 
    • Create Interface vlan 255 10.10.255.2/30 on Firewall side
    • Create static route between MXs and Firewall

 

 

Ryan_Miles
Meraki Employee
Meraki Employee

Yes

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
meraki-newbie
Getting noticed

thank you for your feedbacks @Ryan_Miles , this will help me a lot.. 🤝

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels