When are we getting more than two WAN ports

[cmr]

I saw when the MX85/95/105 models were released that the datasheet say only two active WAN ports are supported at the moment.  This suggests that we might finally get the ability to have more than two connected WANs (excluding built in or USB cellular) in the not too distant future.

Is there any estimate of timeline on this as I cannot be the only customer who really needs this feature?

For anyone interested, we always install two fibre lines at each site with as much diversity as possible, but I'm now approaching the third occasion when both are affected by roadworks at the same time meaning we have to hook up a temporary Copper-fibre hybrid connection and an MG to try and maintain connectivity.  Having more WAN ports, even only as failover, would be a godsend.

Please Meraki, please!

[Make_IT_Simple]

This would be a feature request at the moment. If Meraki has enough feedback, they may think to have new generation MXs with 3 or more WAN ports. On the other hand, even if they are planning to release something in the future, they won't be able to announce it publically. This could also be a software/hardware limitation. BUT, it would be great to have more than 2 WAN interface because cellular sucks 🙂 

[Ryan_Miles]

Going to be well off in the future. Are you deploying HA MXs? You can always connect provider 1 & 2 to MX1 (primary) and provider 3 to MX2 (spare). This doesn't allow load balancing across all three, but it does meet the failover requirement. And one could argue having 3 WAN providers, but only a single MX isn't a great disaster avoidance design.

[cmr]

We want to load balance the two main connections and have a backup VDSL and cellular as connectivity is critical to us.  They are all HA pairs and I've been asking for 4 years so far, but still live in hope! 

I'm thinking we might need to double stack MXs, bit that really isn't the cleanest design.

[Ryan_Miles]

One approach would be this then. LB the main connections on MX1. If both fail or the MX fails it will roll to the spare MX in which you could use VDSL as primary then fail to cellular/MG (in this example) or whatever uplink behavior you want. Additional benefit is on the newer MX models WAN 2 provides PoE for a clean deployment with the MG. 

Requires additional MX purchase, but only one license.

[cmr]

So to move from where we are, I'd guess we delete the virtual IPs, that should then allow us to assign the VDSL and MG IPs to the warm spare device's WAN ports. 

If both fibre WANs went down (as is expected in the roadworks), then the SD-WAN would just rebuild over the VDSL and the MG, as they are load balanced for fibre and the MX doesn't know it has different circuits now...

How would the solution deal with the fact that the fibre and VDSL/MG bandwidths could be very different, is it just a 'hope' moment?

[Ryan_Miles]

Correct, you wouldn't use VIPs anymore. As for the bandwidth differences. The MX is going to use whatever it has access to. Not sure I understand the question. 

[cmr]

Also, the fibres are MPLS, so the tunnels are built using the actual device WAN IPs, whereas the VDSL and MG are internet, so would build direct to the main DCs internet IP (as opposed to its actual WAN port IP).  Do you foresee any issues there?

[Ryan_Miles · Accepted solution]

Meaning the MX with fiber uses private WAN to form tunnels (NATs to same IP as the hub does) and VDSL & Cell would use internet path? AutoVPN should figure that out. It should be the same as if a single MX had a private WAN link and internet link. It can/prefers to build the tunnel over the private IP network. If that doesn't work it will use public IPs/internet path.

[cmr]

Thanks @Ryan_Miles I am going to test this tomorrow and will report back what I find 😎

[cmr]

Managed to test with a mix of MPLS and internet and did get it balancing across the two.  A couple of observations:

• You have to disable virtual IP for both WANs, it would be better if we could have a VIP on one WAN and use MX IPs on the other.
• The virtual IP has to be static so having one carrier on the primary MX with the other on the secondary forces disabling VIP.  If it supported DHCP this would be better.
• When the primary WAN (over MPLS) no longer has connectivity beyond the local site (MX physical interfaces still up), it takes about 5 minutes for the WAN IP at the top of the interfaces tab to update and even when it has, on the VPN status page it says no connectivity to VPN registry and the NAT type shows the now disconnected IP and NAT type etc.  However the VPN actually only has 15-20 seconds of downtime at most.  I left if for over 10 minutes to see if it would fix itself.
• Putting the MX WAN ports behind another MX in the same Org caused the VPN to never come up.  No firewall rules blocking anything so not sure what is going on there.  Might be something to do with it being the DHCP server for the switch VLANs behind the other MXs...

[cmr]

Tried on the site where we actually need it and just couldn't get the SD-WAN to come up on the direct internet connection.  It works fine for internet traffic, no errors anywhere, just the tunnels don't establish. 

The only difference between the sites is that the working one has MX100s and the failing one has MX84s.  We've got support to arrange a downgrade to 15.44 to see if it makes a difference and replaced the patch lead to the new ISP device, which made 4 out of the 11 tunnels come up, spread randomly across three of the other sites.... 

[cmr]

15.44 did fix it (or the reboot did) and we survived the outages on the main fibre lines.  I have since upgraded back to 16.16 and this time all links came up on both WAN ports whether they be MPLS or direct internet.  Ultimately it works, but if you get any issues try a reboot first!

[Owen]

Fortigates can do up to 512 WAN links when setup using SDWAN, just saying.

[cmr]

LOL, that is a lot, Sophos can do as many as there are physical ports on the device (minus 1 for LAN and one for HA if you are using it).  I'm sure Meraki will move to more (3 or 4) but it may well only be on the newer MXx5 devices...