Meraki

GIdenJoe · ‎May 8 2020

Hmm, normally it's better to have them next to each other and share the LAN subnet. If you can spare another public IP, Put that IPsec VPN terminating MX on the public internet. This article by Aaron Wilette has a great example: https://www.willette.works/merging-meraki-vpns/

GIdenJoe · ‎May 7 2020

That honour is still for the Cisco Nexus line of switches 🙂

GIdenJoe · ‎May 5 2020

A customer of mine did not have an expiring cert, but after a windows update, the cert was replaced by a wildcard for some bizarre reason.

GIdenJoe · ‎May 2 2020

Ok, that makes sense. So the reporting you see in dashboard also will only mention the best uplink's status. So it will continue to show the WAN1 connection to multiple registries using public IP while the other uplink is behind NAT.

GIdenJoe · ‎May 1 2020

True, there are alot and I mean ALOT of little playrules you have to follow for whatever reason to get something to work. In your case you'll probably need a an extra router/firewall at one of the sites and static route from your MX device to that router and then make that route available through autovpn to the other MX site.

GIdenJoe · ‎May 1 2020

Hi, silly little detail. Say you have a site where the MX has a direct internet IP over WAN1 and another behind unfriendly NAT on WAN2. WAN1 is the primary uplink but you do want to send/receive select traffic over WAN2. You need to set the public IP and port of WAN2. However you only have one public IP and port field. Since both your pub IP's will obviously be different, how do you set this only for the non primary WAN so the primary WAN can still use it's public IP and own port. And why does it only show the status of the primary WAN in the VPN status page? Thanks in advance 🙂

GIdenJoe · ‎May 1 2020

And the documentation states that MX'es will not route traffic coming from AutoVPN to IPsec VPN and vice versa.

GIdenJoe · ‎Apr 29 2020

Hi, Just wondering if there is a reason why there are no ESX/KVM/Hyper-V versions available of the vMX appliance. There are alot of designs that fall apart because the client wants to use a cloud provider that is NOT AWS/Azure but rather a private ISP based cloud or Openstack based cloud. And usually they use a bunch of MX'es at their sites using the MPLS link locally and trying to use an IPsec VPN because they can only use a pfSense at those cloud providers because of the lack of a vMX for private cloud. Then we have to deal with manual procedures when a link goes down because IPsec only works on one link and it's only policy based instead of route based... or asymmetric routing issues... It would have been alot easier if a vMX would have been available so we can do AutoVPN SD-WAN to other clouds outside of AWS/Azure.

GIdenJoe · ‎Apr 29 2020

Is there a reason you'd want to transmit at 24 dBm?

GIdenJoe · ‎Apr 27 2020

Natural load balancing can also come from not using omni directional antennas. You have to think about the logic of a client. Assume you have an entryway into an office and the clients first connect to that AP. Then they go a little further in the office but still have plenty strength towards the first AP so they will never roam. The only way a client will actually join the AP right on top of it is if the user disables and re-enables the WiFi. So yes you have roaming suggestions from the AP's through 802.11v. But in some spaces you might want to go MR42E with a patch antenna pointing straight down causing a more downtilt signal and a less spread out signal. This will cause the clients to drop off one AP and connect to the next.

GIdenJoe · ‎Apr 24 2020

Everyone seriously working with Meraki needs to know proper wireshark capturing. Since we don't have any debugging tools on Meraki products (please add!) we are mostly relying on network knowledge of protocols and expected behaviors in combination with packet captures to figure it out. It's a nice getting started article 🙂 BTW: a Meraki AP only captures incoming frames. Not outgoing frames! Just a gotcha.

GIdenJoe · ‎Apr 22 2020

Great 🙂 I don't see how you can still get overwhelmed when you're coming FROM the ISE world but oh well 😉

GIdenJoe · ‎Apr 22 2020

It was a browser issue. The right part was not showing at all. I had to grab back at iexplore 😜

GIdenJoe · ‎Apr 21 2020

I stand corrected 😉 I never really consider the MX to forward between LANs as much as I do to the internet. But still in that regard you're right.

GIdenJoe · ‎Apr 21 2020

@AmelieS, I clicked the green button on the registration page. The page seems to reload but I don't see anything else. How do I know I'm subscribed?

GIdenJoe · ‎Apr 21 2020

In my understanding Adaptive policy will be an implementation of Trustsec. On switches this requires hardware support to be able to forward frames with an extra L2 header like that. Since that has always been a Cisco only thing, the current MS switches cannot support it. But since the new MS390 uses the UADP chip from Cisco it has the hardware support. MX appliances are like routers that do advanced forwarding using software. So they can support this through software support only.

GIdenJoe · ‎Apr 21 2020

Yeah, the 3d makes it even easier to view. Do mind that your covered distance will be en exaggerated version of the antenna plot like in the previous pictures you shared. For every 6 dB you drop you halve the distance covered. So when the software gives a predictive heatmap you'll see the inward ripples better like on your 5 GHz antenna pattern. Especially if you put the antenna horizontally you should see a gap of coverage in the four diagonal directions.

GIdenJoe · ‎Apr 19 2020

I see, according to the Cisco documentation you could use the adapter. However if you're doing a pure layered design where distribution switches only connect to access layer switches you actually connect the MX'es to an access stack instead of directly on the distribution layer. But that is of course if you want to be nitpicky in the design.

GIdenJoe · ‎Apr 19 2020

That can be a bit confusing if you also deal with Cisco AP's because some of them have the XOR radio enabling them to point to antennas in different direction because the extra radios is also set to 5 GHz and puts all it's spatial streams on one antenna for radio 0 and the other antenna for radio 1. If you go to Cisco Live events you can see the setup like that.

GIdenJoe · ‎Apr 18 2020

Hi, The M74 and 84 are usually wall mounted. So the antenna are vertical in this case. In that case your azimuth signal spread (the almost perfectly round one) will be seen from the top view and your stretched view from the side If you would ceiling mount the AP so the antennas stick out horizontally your Azimuth would be viewed from one of the side or frontviews. The top view will show an orientation of the elevation pattern (the stretched one)

GIdenJoe · ‎Apr 15 2020

If you have disabled the advanced security features (AMP and IPS) you still have to make sure your uplink speed is set correctly in the traffic shaping page. If that parameter is set lower to your actual max bandwidth your MX will enforce the configured speed by shaping to it. That's how the MX can correctly calculate bandwidth for it's CBWFQ config.

GIdenJoe · ‎Apr 15 2020

From your end you could try a factory reset with the pin in hole solution for 20 seconds. Sometimes that retries the whole process that could have been stuck. If that doesn't work then you'll need to open a case and the Meraki support agent will change some backend parameters and the switches will magically work 🙂

GIdenJoe · ‎Apr 14 2020

That's just the thing. If you want application aware routing and priotization between sites you need the SD-WAN features which does use AutoVPN. It's the whole setup of these devices. Last I checked you still need an internet breakout on your MPLS cloud to negotiate the tunnels unless Meraki has a way of sharing WAN1 information over WAN2 to facilitate the tunnels or a way to manually tell how to form the VPN tunnels.

GIdenJoe · ‎Apr 13 2020

Non Meraki VPNs use ESP tunnel mode encap. However Meraki VPNs encrypt their packet directly under UDP. Screenshot below, mind that 10.10.10.x is the actual WAN IP of the MX but it's behind a NAT.

GIdenJoe · ‎Apr 10 2020

You should also use 2 MS switches to redundantly connect your 2 ISP's. These can be the same switches you use to connect the LAN side of your MX'es to your network. But be sure to follow the documentation here: Define 3 ports on switch 1 with an external VLAN for the WAN1 circuit towards both MX'es Define 3 ports on switch 2 with another external VLAN for WAN2 circuit towards both MX'es. So now you only have fate sharing between one ISP and one switch. Don't mix your external VLANs between the switches or you'll have fate sharing between ISP and MX and switch.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges