Meraki

Ryan_Miles

And that logic all changes in 18.2 with backup WAN (3rd WAN) in which SFP 1, 2, and copper port 4 are the active ports. But that aside the MX75-105 use paired WAN interfaces in which if a SFP is detected on boot it will become the active port and its paired copper WAN (if it exists - MX85-105) be be disabled (SFP 1 & copper 3 = pair 1, SFP 2 & copper 4 = pair 2).

Ryan_Miles

Providing link to what was mentioned above https://documentation.meraki.com/MX/MX_Overviews_and_Specifications/WAN_behavior_on_MX75%2F%2F85%2F%2F95%2F%2F105#MX85.2F95.2F105 Is your SFP in physical WAN port 1 (top) or 2 (bottom)? And was it inserted on boot?

Ryan_Miles

If you're referring to this comment in the release notes "AutoVPN tunnels may briefly drop and re-establish after configuration or WAN connectivity changes if 1) the MX is configured in high availability (HA) mode and 2) both AutoVPN peers are running MX 18" it's supposed to be fixed in 18.107.6 and 18.205.

Ryan_Miles

I get the same error whether I attempt it on MX1 or MX2. I've also requested a doc review as the note in there seems incorrect IMO.

Ryan_Miles

Not sure if the behavior has changed over time, but if use of VIP is enabled both WAN 1 & 2 fields require an entry. This is what happens when you leave WAN 2 VIP blank. As for your second question the WAN 1 & 2 can be on different subnets on MX1 and MX2 if not using VIPs. Of course failover won't be as seamless as things like natted outbound flows, VPN tunnels, etc would change IPs when failing from MX1 to MX2.

Ryan_Miles

You've perhaps already come across my deck as it's been posted in other threads. I show this exact process and it's not disruptive to existing templates/networks/devices.

Ryan_Miles

If I'm not mistaken the hubs would need to be configured as spokes. The doc mentions it in step 5. SIG hubs prevent hub to hub tunnels so I'm pretty sure a regular hub will not form a tunnel with a SIG hub. If someone knows differently feel free to correct me.

Ryan_Miles

No clue. Can't find any documentation on the use case for it. But I did find an open bug that says once a route is created or edited to have a value in that field it cannot be removed. So, I would steer clear of it.

Ryan_Miles

As @IvanJukic mentioned I've seen this occur on initial MS deployment and it should go away/age out. You should also be able to delete the unnecessary leases at any point.

Ryan_Miles

I've tested that and it doesn't appear to change the yellow icon issue on the Org overview page for a MX operating on cell

Ryan_Miles

You should open a Support case on this. That is not expected behavior. I have a customer with 900 MX68CWs deployed with cellular and they're green as long as the WAN port is active/healthy.

Ryan_Miles

Yes that MG bug still exists unfortunately. And it's not necessarily related to the MX as the original thinking was to visually indicate when a MX-C fails over to cell. But I agree that for anyone that runs a MX-C on cell as primary it would be nice to have an option to configure the logic to show it not in an alerting state. That would be a feature request. Today, a MG can only be connected to cell WAN. So it really shouldn't be yellow on the Org overview page unless again there was an actual problem.

Ryan_Miles

I recommend you open a Support case so they can take a look

Ryan_Miles

As the note mentions - future

Ryan_Miles

From the MS Family datasheet "MS130 mGig (-X) models and MS130R are hardware-ready for the Adaptive Policy feature with a future firmware upgrade and advanced license."

Ryan_Miles

Yes

Ryan_Miles

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_Miles

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_Miles

Support can help with an Org split (which includes licensing). This is a coordinated effort and special process of keeping configs intact while splitting the Org. The other option is create a new Org, rebuild configs there, move devices, then move your licenses. You can do all those actions including the license move without Supports involvement. https://documentation.meraki.com/General_Administration/Licensing/How_to_do_a_License_Transfer_in_Cotermination

Ryan_Miles

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_Miles

Every mGig phy I've seen can go down to 100 Mbps. And it's a configurable value on the port.

Ryan_Miles

I found your Support case. The org you claimed these into is set for per device licensing. The licenses are claimed, but neither are assigned to devices. You claimed the larger license on March 20th. PDL licenses if not assigned will activate it 90 days which is the June 18th date you see (March 20 > June 18 = 90 days). https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_Overview/The_Science_behind_Per-Device_Licensing#90_Day_License_Activation_Window You need to still assign the licenses to your devices and you'll be good to go. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_Overview/Meraki_Per-Device_Licensing_-_Configuration#Assigning_a_License_to_a_Device_(Devices_Tab)

Ryan_Miles

I was addressing the teleworker/tunneled SSID scenario and what expected behavior is. The Meraki DHCP SSID issue is something different.

Ryan_Miles

Yes, if the MX is not reachable or rather if the tunnel from the MR to MX cannot be established the SSID won't be broadcast. Basically the data path is broken so even if the SSID was broadcast clients wouldn't get anywhere if there's no data path.

Ryan_Miles

One more example of a Cisco phone on the Z3 PoE port showing both CDP and LLDP info. { ports: { port5: { cdp: { sourcePort: "port5", deviceId: "SEPxxxxxxx", address: "10.244.200.227", portId: "Port 1" }, lldp: { sourcePort: "port5", systemName: "SEPxxxxxxx", managementAddress: "10.244.200.227", portId: "omitted:P1" } } }, sourceMac: "omitted" }

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges