Meraki

PacerX · ‎Apr 13 2020

This helped me also thanks @ww

VictorTJ · ‎Apr 11 2020

Thanks for answer. I realized that the MX doesn't have the same keys and switches do. Thanks.

TruongVX · ‎Apr 9 2020

thank for support.

PhilipDAth · ‎Apr 7 2020

You wont be able to roll back, but if you go Organization/Firmware Upgrades, you can simply deploy the latest stable firmware.

Ssulaimant · ‎Apr 1 2020

Very helpful! I was able to assign a static IP to the router via Local IP Assignment.

PhilipDAth · ‎Mar 31 2020

>I'm going to 500Mbps now The MX67 and MX68 are the best fit here with 450Mb/s of throughput.

trunolimit · ‎Mar 31 2020

Ah. Did it move?

SopheakMang · ‎Mar 30 2020

Try to troubleshoot first , i also used to meet this case. I want you to check on routing table on each MX make sure no conflict subnet. Then can try to open case , ask merkai support to turn off layer3 summary feature from the back end , then let's see the result.

CarolineS · ‎Mar 26 2020

@PhilipDAth wrote: >Caroline is leaving us today for the noble role of full time mother to her children. I'm thinking the charm of having children was worn off now. HA! Yes, I must admit it's a relief every now and then to stick the kids on their iPads and have a meeting (albeit virtual) with grownups!

GIdenJoe · ‎Mar 24 2020

The warm spare automatically gets the same local VLAN and interface config. In an L3 CORE design, just have a transit VLAN that is a /29 or lower because you need at least 3 IP's for your switches in a stacking scenario and 1 IP for the uplink MX. Use access ports on the switches connecting to the MX'es. In an L2 CORE design, use trunks between the switches and the MX'es and use one of the configured VLAN on the MX as native VLAN on those trunks because you should not "drop untagged" traffic because STP BPDU's are sent untagged and I have seen four links in forwarding state due to this.

BlakeRichardson · ‎Mar 22 2020

@Andy88 Insight is an addiontal add on for monitoring web app connections made through a Meraki MX device. https://meraki.cisco.com/products/insight

webfrank · ‎Mar 17 2020

Thanks everybody, I found just few minutes later it was necessary not to specify null fields. I think this should not be an API behavior as this logic should be inside API and not on caller.

John_R_Gudmann · ‎Mar 15 2020

Hi I have just changed some of the network tags to get a better overview. then I wanted to correct the setting for admins but keep running into this error messages. It uses to be straight forward but not this time. Any idea or shall I raise a case? Thanks. John Gudmann

RyanR · ‎Mar 14 2020

Figured this one out - it's a resold SIM from TracFone. While it technically registers back through AT&T, it isn't from AT&T. May not be technically supported, but will work if you change the APN to "Reseller" and specify IPv4. Interesting that the same SIM works fine in a Cradle Point modem, probably worth Meraki looking into.

angeloPV9 · ‎Mar 11 2020

Hi Dave yes I proposed this switch for design. thank you and best regards!!

Brons2 · ‎Mar 11 2020

I wish Meraki did have a VRF capable switch. I could EOL our Cisco router fleet. As it is, I am thinking of replacing them (ASR/ISR) with some Ruckus switches with advanced IP license which my firewall reseller likes and recommends. We do not tax our Cisco routers at all and the ASR were extremely expensive, a switch that supported VRF and VRRP would work fine to replace them.

ETS · ‎Mar 11 2020

I added the address to traffic shaping but it only worked for 24 hrs before it dropped again. I will stick with the local ping batch file until Meraki implements a "keep-alive" option. Thanks for everyone's input.

Qing · ‎Mar 11 2020

Thanks.

Jwiley78 · ‎Mar 9 2020

Ran into this a couple times. Wireless->configure->firewall & traffic shaping. Default is to deny.

redsector · ‎Mar 4 2020

IP-Address conflict with your VMWare-Server. Change the address of the server or (maybe easier) of the accesspoint.

DensyoV · ‎Mar 4 2020

Hi, If you are only concern about the email alerts, then perhaps you can just temporarily disable it instead of turning off the VPN. The problem with turning off the VPN, if you are just using auto for the NAT traversal, its UDP port may change once you re-enable the VPN again and if there is a FW upstream, it may drop the packet if it sees a different UDP port or if it unable to clear the previous UDP flow. hope this helps.

ValleyITPC · ‎Mar 4 2020

Looks like I can only mark one post as solution but thank you Nash for the info!

GIdenJoe · ‎Mar 4 2020

I agree with ww. It's true the MX just forwards BPDU's when they arrive on the native VLAN (unless drop untagged is turned on BAD FEATURE). However if you have a different native VLAN or access port in a different VLAN that BPDU will not be forwarded on. The MX would however receive BPDU's from the root through Dist 2 but on a different VLAN.

Lagcat · ‎Mar 3 2020

thanks all for the replies looks like we are going to move forwards thank you

BrechtSchamp · ‎Feb 28 2020

Good idea!

About ww

ww

Community Record

Badges