About BrandonS

BrandonS

I guess you tried factory defaulting them? Maybe you could try moving some to a different network temporarily with a minimal (or no) configuration and monitor them for a few days to see if they still reboot. This may help rule out a software issue vs. hardware.

BrandonS

I've seen these third party tracking applications that integrate with Meraki: https://create.meraki.io/build/rtls/#how-to-integrate-with-stanley-aeroscout It will depend on what kind of assets and if you plan to purchase tags, I suppose, but it is technically possible.

BrandonS

Is it claimed and added to a network?

BrandonS

@PhilipDAth wrote: That is how I would do it. Thanks for the endorsement. I am not sure why I felt there might be some better way.. I guess a media converter and a cheap copper switch might be another option, but I wouldn't propose it for this particular client.

BrandonS

I have a client with full stack Meraki that has a requirement to share their SM fiber internet handoff with another business unit that wishes to use their own separate firewall with a direct, public IP. My first thought is the only way to do this is with a "breakout switch" in between the fiber handoff the rest of the gear or do it using available ports on their switch stack in a common VLAN. So, I might get 2 new SMF SFP modules and put them in SFP on a switch and create a common VLAN with those two ports and a third copper port (for the other business handoff). Then I can patch the internet handoff fiber to one of those ports and the other fiber port back to the WAN port of the MX. I would keep the IP I have for the MX and let the other folks use an available one from the block and patch into the copper port on that common VLAN. Is there another or better way to do this I am not thinking of? Thanks

BrandonS

SD-WAN is simply a term to describe dynamic and configurable network access via multiple WAN (internet) links. A common example would be to have two different internet service providers connected to a Meraki MX appliance and configure the MX to send voice traffic on the link with the lowest latency, jitter and packet loss. You will be able to monitor the links in the dashboard and see when the MX has made decisions dynamically to route voice traffic over either link. The links may also be site-to-site VPN links to other branches or locations. Many organizations are choosing to move away from expensive dedicated WAN links to SD-WAN since the performance can be similar and the price less. Here is simple diagram depicting two MX appliances each with two internet connections and site to site VPN:

BrandonS

Yes and did you see this? https://meraki.cisco.com/blog/2018/11/prepare-for-ax-wireless-with-meraki-switches/

BrandonS

Tell them if they are caught using hangouts they will be written up and can lose their job ;) Seriously though, blocking applications like that can be very difficult because they use so many different domains and IP blocks to operate. And whatever they use now could change without notice. If you really want to try to do this at the Meraki level your best bet is probably to run packet captures while using Hangouts and see what common URL's and IP addresses you may be able to restrict without breaking other services. Good luck.

BrandonS · ‎11-14-2018

Interesting idea, but I feel like it would not work. How would you connect the antennas? One side of MR has 2x 5Ghz connectors and the other has 2x 2.4Ghz. Would you cross them so each antenna connects to both? I guess you could try, but I would not expect it to work..

BrandonS · ‎11-07-2018

Actually, based on " Also if Z1 is literally just powered on, no LAN or internet cables attached it will reboot bang on 16 mins 45 seconds. I think maybe 2 or 3 times it's rebooted around 14 to 15 mins. " I think you have an easy case to get a replacement shipped out from Meraki.

BrandonS · ‎11-07-2018

I suggest asking your IT support nicely to escalate this to Cisco Meraki support. If Meraki support does not have any good ideas they will normally send out a replacement without much hassle. I manage plenty of Meraki gear and have never heard of anything like the particular issue you describe. I would guess it is either the Z1 is bad or there is some rare compatibility issue with your ISP gear. Replacing the Z1 should help determine where to look next if it does not solve the issue.

BrandonS · ‎11-07-2018

@ph0t0g wrote: Oh, OK. So it's just E.T. phoning home. Thx Haha. Does anyone here remember ROLM? I used to have a bumper sticker back in the 80's that said, "E.T. phone ROLM"

BrandonS · ‎11-07-2018

Why is the title of your post, " Client VPN split tunneling?" I have split combined networks and combined them again and not seen any service interruption or other trouble. I did this most recently to get rid of an old demo MC network I had in one of my combined networks. If anything, you *might* lose historical data like client usage. If that is important, I would call support or research more to find out.

BrandonS · ‎11-07-2018

I am pretty sure that is just part of the normal connectivity testing al Meraki products do. This is for MX, but probably similar for MS, etc. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover

BrandonS · ‎11-06-2018

Very cool. Just don't forget to keep a backup of your floor plans in case they get lost again.. ;)

BrandonS · ‎11-06-2018

Thanks for the great replies! I think the last thing I am wondering is if I need to consider anything for my single switch. I can just plug LAN 1 on each MX into my single switch instead of the two like diagramed here? Or do I want a VLAN for the connectivity between MX also? That seems the same as a direct cable though.. And maybe I want an MS120-8 on the WAN side with two VLANs (one for each ISP between their handoff and the MX's). It looks like a need a total of 3 IP addresses from each ISP, right? Going with number 1-4 on the diagram Comcast: 1: 1.1.1.1, 3: 1.1.1.2 at&t: 2: 2.2.2.1 4: 2.2.2.2 Then also two VIPs like 1.1.1.3 and 2.2.2.3? Thanks again.

BrandonS · ‎11-06-2018

Can someone help me clear up some doubts about how to configure this? I have read https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair and also https://www.willette.works/mx-warm-spare/ 1. Is it not good to connect the MX's directly to each other anymore? Do I need to care why? 2. Do I need 2 switches also? I prefer to have one switch only and only have HA for if one internet goes down or one MX fails. For this instance I am not concerned about 'core' switch failure. 3. How do I handle client VPN if one internet fails? Users need to know two different IP's to connect to potentially? 4. This customer uses public IP whitelisting to access some cloud services. I am not clear on the VIP configuration. I will have one VIP from each ISP that would need to be whitelisted by the service providers I guess? Thanks for any help. I have been working with Meraki for some time, but not yet configured HA.

BrandonS · ‎11-02-2018

Yeah. Since I posted this I have become less and less concerned :). I just wanted to get all switch port configuration and tags, names, etc. done in advance and I feel I still can. I will just save the step of creating the stack in the dashboard for after the gear is physically installed. I think I am assuming correctly that none of the configuration I do in advance on the switches will change when I put them in a stack.

BrandonS · ‎11-02-2018

Previously I have always followed the stacking guide and plugged in each switch individually to connect to the dashboard first and then power them down, connect cables, restart with a single uplink and configure it, but I have a project that needs to move fast and was thinking to try configuring it all before the gear arrives on site. It seems possible, but I am not sure if I should bother trying or not. Has anyone here tried this or have any thoughts? Thanks.

BrandonS · ‎10-30-2018

And note that Threat Grid is not a Meraki product. You need to purchase it as a traditional Cisco item and then there is an integration with Meraki. https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Threat_Grid_Integration

BrandonS · ‎10-29-2018

You can hover your mouse over the green connectivity status bar to confirm if it was a power outage or not. I don't understand your second question.

BrandonS · ‎10-26-2018

No. I hear this often about the reps being unresponsive. It could be for a variety of reasons but since Meraki only sells through resellers I would work with your favorite Cisco reseller to get things done. They should make sure you are matched with correct rep and be able to move trials and other things along.

BrandonS · ‎10-26-2018

@jdsilva wrote: Does on the toilet count? That's right. I went there :P Haha. I came here specifically to see if anyone would mention that :)

BrandonS · ‎10-25-2018

You can do this on the dashboard in appliance status > uplink. Maybe there is way with the API to do them all faster?

BrandonS · ‎10-22-2018

I would try a new SSID with default settings for testing. Then change one thing at a time to see if it breaks again. Did you enable 802.11r or change the RF profile at all?

BrandonS

Community Record

Badges