Meraki

DCooper · ‎Jan 30 2018

@AbrahamMunozNot sure what version your on but there was a bug that exhibited the exact behavior in older version of code. Make sure your on the latest GA.

DCooper · ‎Jan 29 2018

Community, If you haven't seen the Meraki integration with Alexa here are a couple of videos and development/setup guide information around it. Feel free to share any comments or development with the community! Videos https://www.linkedin.com/feed/update/urn:li:activity:6360505361736310785 https://www.youtube.com/watch?v=dfHxSDMS82U https://www.youtube.com/watch?v=N7xOYmCt_ZQ Github https://github.com/meraki/alexa-skill?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3BW9AmY7IJTgWNTQ3FC74Yvw%3D%3D

DCooper · ‎Jan 25 2018

Either design should work, the second design is more optimal so stick with that. Do you have egress security on the firewall southbound in your sandwich DMZ? I have a hunch that is blocking traffic, You’ll know if it still doesn’t work, take a look at the logs. @PhilipDAth FWIW-We are told that that AutoVPN LAN termination feature only works from MX to MX.

DCooper · ‎Jan 24 2018

Typically (but not always) devices without a fan don't have a MIB or monitoring capabilities, this is industry wide and is a physical limitation not something in software. There are temp alerts on our Meraki MS switches that will come through via syslog/event log, just no way of pulling this information via MIB.

DCooper · ‎Jan 23 2018

Yes sir, leave that unchecked to stay protected.

DCooper · ‎Jan 23 2018

This would disallow the use of multiple profiles or certificates on a device. You can have multiple payloads on a device to manage it, this would just disallow a user from allowing another source to manage the device. Try googling "malicious profiles ios" and you will see what this button is used to deter from.

DCooper · ‎Jan 19 2018

@btgraberPlease email cmno@meraki.com and they will get you taken care of! Thanks!

DCooper · ‎Jan 18 2018

Another quick note: There isn't a easy way in the API or scripting to bulk pull the network names so that is going to be the drawback.

DCooper · ‎Jan 18 2018

@merakipacMX product development has the most focus out of any Meraki product. SD-WAN market has a 70% YoY growth, we are investing more in SD-WAN now more than ever. If you remember the days when wireless 10+/- years ago there were 12+ vendors and it was a land grab. That is happening now in the SD-WAN marketplace. We understand we can't do everything and once you hit 3 WAN connections I promise a price tag way beyond what your used to paying for Meraki comes with that. We have some very advanced routing and features in the development pipeline that will elevate our solution, but we can't do everything.

DCooper · ‎Jan 18 2018

@merakipacNo plans to make the USB a part of the SDWAN Active overlay. We are pushing people in the field to use Connected IO, they have a ethernet model and ship with a IMEI for your favorite WISP. I am almost positive they have support in Australia as well. If you run up against the need for 2+ WAN connections we are pushing people to a Viptela based solution.

DCooper · ‎Jan 18 2018

Your correct, this is a manual process for now unless you script it out. If your using templates this obviously will not be an issue. Here is a Python Script to enable VLANS. This is not supported by Meraki Support but will do the trick - https://www.dropbox.com/s/gvefg6i48ll4ltt/enable_vlans.py?dl=0

DCooper · ‎Jan 18 2018

I would need to test when I’m back in the lab but if I remember right there is a Syslog message when the uplink status changes. WAN1=0 WAN2=1 ... Just another option since it’s not built into dashboard yet.

DCooper · ‎Jan 17 2018

These events will occur when STP convergence occurs, but that would normally be across all active ports. With individual ports showing these changes and client devices are connected to it it can mean that the port went down/up for a moment or that the client device stopped sending packets for some time, then traffic was once again seen sent by the client. Are you having issues with specific ports and users complaining of connectivity loss or is this primarily event log related?

DCooper · ‎Jan 15 2018

@CGL That is the latest MIB information we have. Monitoring via SNMP with any vendors tool will be very basic and not include the additional information your seeking. If you invested in the MX product line you would be able to pull netflow statistics that can provide some of that information your looking for.

DCooper · ‎Jan 13 2018

Wired or wireless? Did you have the SSID in NAT mode?

DCooper · ‎Jan 12 2018

@PresITsupportYour correct. To elaborate on this comment "WAN 2 would be active like the documentation you linked" as it pertains to VPN SA's being established it is always Active/Active. Tunnels are built by default at all times on all links, however, I assumed you meant Active/Passive in the sense of actually sending flows down the the tunnel tied to WAN2. Your probably only failing over the flows if there is a hard or soft failure on the VPNSA/WAN1 link, which is the most common basic setup I see.

DCooper · ‎Jan 12 2018

Punch tunnel through the LAN interface has some specific use cases. MX in NAT mode can now accept AutoVPN tunnels from other Mx's. Use Case: If you had an MX at your HQ and that the default route was to your MPLS Cloud back out the LAN interface. Remote site MX's trying to VPN would use the interface IP of the HQ MX (as per https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS), which means at the HQ MX traffic would ingress through the MX inside LAN to the outside interface where the tunnel was terminated just to egress back out the LAN port. This feature was introduced in all v.13 code and the change means that in this specific use case, the HQ MX will listen and form punch Tunnel VPN connections on it's LAN interfaces. Stay tuned for more documentation on this feature.

DCooper · ‎Jan 12 2018

So a couple of things. 1. On the Openfield VPN Settings please remove the Local networks information you have put in there. 10.0.0.0/8. You don't need that information in there because you have the checkmark checked on the remote site for a full tunnel VPN. So no matter what for that remote site it is sending traffic back via a full tunnel VPN regardless of that setting. That setting is only for split-tunnel modes for remote sites to tell them what subnets reside back at your headend. 2. Make sure your PC is NOT connected to the wifi, it looks to be connected wired. If it is, which I suspect, it will respond to the wireless Gateway as opposed to the MX for any traffic that isn't on it's L2 segment.

DCooper · ‎Jan 11 2018

Add this route in on the L3 switch and you should be good to go. ip route 100.100.100.0 255.255.255.0 10.14.130.149 Any new remote MX's or subnet/VLANs you configure will need a route on your L3 switch pointing back to the MX-10.14.130.149

DCooper · ‎Jan 11 2018

Can you PM me your serial number of the device so I can take a look? I want to make sure I’m giving you the right configuration change. My assumption is that we need to add in a default route 0.0.0.0/0 back out of the LAN side pointing to your L3 switch as the next hop. Just want to confirm that by looking at the setup in Dashboard.

DCooper · ‎Jan 11 2018

You need to use a comma between the CIDR notations. Ex. "192.168.1.5,172.16.0.0/12". Please see see this document https://documentation.meraki.com/MX-Z/NAT_and_Port_Forwarding/Troubleshooting_Port_Forwarding_and_NAT_Rules

DCooper · ‎Jan 11 2018

Are you doing full tunnel VPN? In the spoke VPN settings the default route checked? If so my config above needs some tweaking.

DCooper · ‎Jan 11 2018

Did you add any routes into the MX to point to your other networks? Anything that says “directly connected” other than the subnet the MX is on needs to be added to the MX to point back to the L3 switch.

DCooper · ‎Jan 10 2018

Have you tried using systems manager? We have restrictions within that product to turn it off. As it pertains to iOS It does have to be a supervised device via DEP or Apple Configurator.

DCooper · ‎Jan 9 2018

Ok, I'm a little confused now as to where the Layer 3 is setup on the work network. Does the core switch own the default gateways to all of the 192.168's? Then the core switch has a route up to the ASA? We are fine on the remote network just need to get the routes figured out on the work side and this will start working.

About DCooper

DCooper

Community Record

Badges