Meraki MX Warm Spare basic Setup understanding

SOLVED
MikeSip
Conversationalist

Meraki MX Warm Spare basic Setup understanding

Hi,

 

I am currently in the process of deploying meraki devices in my network, but I am just trying to wrap my head around some concepts with the meraki MX devices.

 

  1. Does the MX device support ether-channel ? as i intend to have a stacked LAN switch and two trunked interfaces going down to the Core switch, below is my Topology.

 

 

MX topology.PNG

 

2. With the MX Warm Spare configuration, i can't seem to understand how the VRRP worked on the LAN side, as i can't see a place to have the VIP configured, but from my research it says the secondary MX device would assume the IP of the primary MX, do i need to configure the secondary MX with a Physical IP?

 

3. Does the MX support Dynamic routing(OSPF) with the LAN device, so that I can have the connection between the Core switch and the MX device to be doing dynamic routing.

1 ACCEPTED SOLUTION
BrechtSchamp
Kind of a big deal

Hi Mike,

 

  1. The MX does not support Etherchannel. Nor does it do RSTP. That topology works because the switches support RSTP and will eliminate any loops.
  2. On the LAN-side no VIPs are used. Both need a physical IP address. One Virtual MAC address is used by both MX's though. That's described here: https://documentation.meraki.com/MX/Networks_and_Routing/NAT_HA_Failover_Behavior
    "In addition, 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 failover, LAN clients won't need to update their ARP table with a new MAC address."

    You can also find more info about that here: https://tools.ietf.org/html/rfc3768#section-7.3 . Take a look at section 7.3 and 8.2.
  3. OSPF support in MX is limited to exporting the AutoVPN routes towards the core router via OSPF. It will not learn routes from OSPF. For that you need to look into the MS line that has more OSPF support.
    Sources:
    https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets
    https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing
    https://documentation.meraki.com/MS/Layer_3_Switching/MS_OSPF_Overview

 

View solution in original post

15 REPLIES 15
BrechtSchamp
Kind of a big deal

Hi Mike,

 

  1. The MX does not support Etherchannel. Nor does it do RSTP. That topology works because the switches support RSTP and will eliminate any loops.
  2. On the LAN-side no VIPs are used. Both need a physical IP address. One Virtual MAC address is used by both MX's though. That's described here: https://documentation.meraki.com/MX/Networks_and_Routing/NAT_HA_Failover_Behavior
    "In addition, 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 failover, LAN clients won't need to update their ARP table with a new MAC address."

    You can also find more info about that here: https://tools.ietf.org/html/rfc3768#section-7.3 . Take a look at section 7.3 and 8.2.
  3. OSPF support in MX is limited to exporting the AutoVPN routes towards the core router via OSPF. It will not learn routes from OSPF. For that you need to look into the MS line that has more OSPF support.
    Sources:
    https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets
    https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing
    https://documentation.meraki.com/MS/Layer_3_Switching/MS_OSPF_Overview

 

Thanks alot for the clarification.

You're welcome.

Hi,
can you help me eleborate this statement ? Using the same setup what does this mean ?
"If a virtual IP is being used, then each uplink of the two MXs must share the same broadcast domain on the WAN side."

Mateen
MikeSip
Conversationalist

in simple terms it means the WAN port needs to be in thesame VLAN, so you need to find a way to split the interface, either with a dedicated breakout switch or using one of your network switch, in other to split the interface you have to have three interfaces in same broadcast domain(VLAN) and in thesame subnet " the internet circuit, WAN port on both the Active and Spare MX".

Mateen
Getting noticed

Thanks for the reply but i still didnt get it...
My setup is :
1 ISP with 2 routers connected to 2 MXs and that is connected to MS switch stack. 1 public IP for each MX and 1 VIP.

ISP1 ISP1
| |
MX1 MX2
| |
MS SWICTH stack

WAN ports on MX1 and MX2 to be configured on same VLAN ? can i do that on my MS SWITCH stack ?

MikeSip
Conversationalist

yes you can use your current MS stack, Example WAN port 1 (MX1), WAN port 1 (MX2) and Internet circuit connected to your MS stack on a dedicated vlan, the Active MX will use the shared virtual IP (VIP) when sending traffic out to the Internet.
 
              ISP
                |
   ___MS-Stack___
  |                           |
MX1                   MX2
 
 
Mateen
Getting noticed

Got it, Thanks. This will make it a bit complex and if i do not want to do it this way i can just skip the VIP ? and configure warm spare without VIP if its possible ? Will get redundancy on WAN via meraki's WAN monitoring and on LAN through VRRP ? just wanting to confirm i have understood it correct.
BrechtSchamp
Kind of a big deal


@Mateen wrote:
Got it, Thanks. This will make it a bit complex and if i do not want to do it this way i can just skip the VIP ? and configure warm spare without VIP if its possible ? Will get redundancy on WAN via meraki's WAN monitoring and on LAN through VRRP ? just wanting to confirm i have understood it correct.

You don't have to use a VIP on the WAN-side. Consequences of not using one are described here:

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

 

Quote: 

Use MX uplink IPs: When using this option, the current Active MX will use its distinct uplink IP or IPs when sending traffic out to the Internet. This option does not require additional public IPs for Internet-facing MXs, but also results in more disruptive failover because the source IP of outbound flows will change.

Use virtual uplink IPs: When using this option, both MXs will use a shared virtual IP (VIP) when sending traffic out to the Internet. This option requires an additional public IP per uplink but allows for seamless failover because the IP address the network is using to communicate with the Internet will be consistent. The VIP for each uplink must be in the same subnet as the IPs of the MXs themselves for that uplink, and the VIP must be different from both MX uplink IPs.

To configure a new network with warm spare failover, create the network as you would normally and add the Primary MX. Then add the Secondary MX using the process described above.

Regardless of which option is selected, both MX devices will need their own uplink IP addresses for Dashboard connectivity.

Dashboard configuration should always be performed before the Secondary MX is physically connected to the network. 

 

On the LAN side no VIPs are needed either. The process is described more in detail here:

https://documentation.meraki.com/MX/Networks_and_Routing/NAT_HA_Failover_Behavior#VRRP_Mechanics_for...

Thanks

will this suggestion also work without problems - when I´ve 2 ISPs?

 

  ISP 1           ISP 2
       |                  |
___MS-Stack___
   |                      |
MX1               MX2

 

if yes, is there anything to keep in mind according the physical cabling?

cmr
Kind of a big deal
Kind of a big deal

Yes, as long as you are only using the stack for internet connection splitting and they are not in the same 'network' as the MXs. 

 

I use basic 5 port layer2 switches to split the ISP connections and keep the MSs for the internal network.

 

Also remember that you need 2-3 IP addresses for each ISP

""Yes, as long as you are only using the stack for internet connection splitting and they are not in the same 'network' as the MXs. ""

 

why would that be a problem? do you`ve more detailed information or experiences about this?
cmr
Kind of a big deal
Kind of a big deal

If you have the switches split to both be external and internal then you have two issues

 

  • Client mapping and topology etc. will get confused, leading to data that doesn't make sense
  • From a security point of view, you are creating a serious risk that doesn't need to be there, I personally wouldn't want to create that risk just to save the cost of a couple of L2 switches.
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