- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
warm spare with only 1 public Ip
Hi,
I have 2 MX100 in a /30 network (facing internet ) with only one public Ip.
Should I :
Use MX uplink IPs or Use virtual uplink IPs ?
and in each case what Ip should I give to WAN interface of each MX ?
thanks
Solved! Go to solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Mr-cook
I am afraid this is going be a challenge.
We will not be able to establish warm spare with a /30 IP Pool unless we keep a NAT Router before the MXes.
Ideally we request for a /29 IP Pool to ISP for such configuration.
Ajit
AjitsNW@gmail.com
www.ajit.network
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Mr-cook
I am afraid this is going be a challenge.
We will not be able to establish warm spare with a /30 IP Pool unless we keep a NAT Router before the MXes.
Ideally we request for a /29 IP Pool to ISP for such configuration.
Ajit
AjitsNW@gmail.com
www.ajit.network
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to add to @AjitKumar 's reply, each MX must have its own unique IP address to maintain a connection to the Meraki cloud. They cannot share one IP for this function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this possible using 2x/30s? 2 different ISPs?
I cant seem to find any implementation example that depicts the setup.
Unfortunately we cannot afford to change Public IP addresses at the moment and will have to stick to /30s.
We have 2x /30s and I am thinking of connecting ISP1 to Primary MX and ISP2 to Spare MX.
Would that work?
I also have a question regarding the IPSec VPN. We have an IPSec VPN with Azure terminating on Primary MX via the ISP1 and a remote access VPN terminating via ISP1 as well.
We would need to configure the same settings for ISP2 on both the Spare MX and the Azure end? Yes?
Any direction in this regard would be appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ObaidN, you can definitely terminate ISP1 on Primary MX and ISP 2 on Standby MX, but be aware that you will only be able to use the ISP service which is on the Active MX (normally the Primary MX). If the ISP1 service fails the Primary MX will detect that and hand over operations (via VRRP) to the Standby MX, at which time ISP2 will become your active link.
You can either connect both services to WAN1 on their respective MX devices if they are a similar bandwidth, or if they are different bandwidths you can connect to WAN1 on Primary MX, and WAN2 on Secondary MX, which will allow you to specify the different bandwidths (but still only one will be active at a time).
The other alternative is you put a small device between each ISP service and the MXs to 'split' the services. Something like a MikroTik hEX might do the job (depending on bandwidth). All you essentially need it to do it terminate the ISP connection and NAT it, and connect to both WAN1s on the two MXs and provide a /30 private IP address range to each (and repeat for the second ISP and the WAN2 on each MX).
It would be a bit like an MG21 but replacing the 4G/LTE modem with an Ethernet interface <-- hint to the Meraki product team guys and gals.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you @Bruce . Yes I am aware that I would only be able to use 1x ISP as active.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you can get a /29, that's also nice for troubleshooting. Gives you spare IPs for connecting other equipment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't stand when providers do a /30 on business circuits.