2 MXes and one provider, IP-address conflict at WAN port

SOLVED
redsector
Head in the Cloud

2 MXes and one provider, IP-address conflict at WAN port

Hello,

I have got two MXes MX68CW-WW and both are connected with the same IP address to the providers router.

The MXes are built as an primary master and a passive MX (only one licence)

Now I got one IP-Adress from the provider and I took it on both WAN1 - ports at the MXes. Now I have a IP-Address conflict. Does the passive MX propagate this address?

How can I resolve that problem?

 

thanks

1 ACCEPTED SOLUTION

I see, I will buy in future SonicWall firewalls again, no trouble and one IP WAN address. Just not a little disappointed about Meraki.

View solution in original post

10 REPLIES 10
redsector
Head in the Cloud

Its configured as "warm spare" and "Use MX uplink IPs"

And I have got only one IP address from the provider.

I thought that the warm spare wont´s speak with that address unless there is a failover.

But what I see is that both MXes are spaking with that WAN IP address.

KarstenI
Kind of a big deal
Kind of a big deal


@redsector wrote:

But what I see is that both MXes are spaking with that WAN IP address.


Yes, both have a connection to the dashboard. It is completely different compared to for example an ASA where you can configure it with only one usable public IP.

There was a Sonicwall Firewall/VPN-Router stack, and it worked. Now I stand here with two MXes and it doesn´t work as expected.

KarstenI
Kind of a big deal
Kind of a big deal

Well, different products behave differently. Given that the feature-set especially of the MX is quite restricted, good planning is more important than ever.

 

KarstenI
Kind of a big deal
Kind of a big deal

Here is what I would do in that case:

 

1) Ask the ISP for a /29. Could cost some bucks but would be the best solution.

2) If not possible, think about the MG21. Yes, it is expensive, but you could connect the device to both MXes WAN2. You have more redundancy on the primary MX and the spare MX has dashboard connectivity.

3) If that is also not possible, there are probably no options than using cold standby. Better than no redundancy.

KarstenI
Kind of a big deal
Kind of a big deal

This is not how MX HA works. Both units need individual connections to the internet, you can not share one IP on both appliances.

Two/three solutions come to mind:

1) use a separate IP for the second MX

2) Use a different ISP on the spare MX, that could be e simple LTE-router just for dashboard connectivity, and in case of primary MX failure, you connect the primary ISP to the second MX

3)  Use the second MX as a cold spare

DarrenOC
Kind of a big deal
Kind of a big deal

Hi @redsector 

 

As mentioned by @KarstenI each MX requires a separate IP address and you'll also require a third for VRRP between the two devices.

 

Do you have a couple of Layer 3 switch's to hand (stackable)?  Place these infront of your MX's.  Terminate your single ISP connection into these.  Create a /29 subnet/VLAN (anything smaller and you won't have enough IP's) i.e 10.10.10.0/29 and assign as per below.

 

10.10.10.1 SVI on switch

10.10.10.2 MX1 WAN interface

10.10.10.3 MX2 WAN interface

10.10.10.4 VRRP

 

Make 10.10.10.1 your MX dfg

 

Not ideal but gives you your MX High availability.

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.

There is only one MS210-24 switch, no Layer3.

KarstenI
Kind of a big deal
Kind of a big deal


@DarrenOC wrote:

Hi @redsector 

Do you have a couple of Layer 3 switch's to hand (stackable)?  Place these infront of your MX's.


Here the L3-switches had to do the NAT. Makes the switch-options to pick from quite limited.

 

I see, I will buy in future SonicWall firewalls again, no trouble and one IP WAN address. Just not a little disappointed about Meraki.

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