Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- About Aaron_Wilson
Community Record
167
Posts
79
Kudos
7
Solutions
Badges
12-08-2020
09:10 AM
Same. "User" is contained in all user based networks, and the site code for company locations. VPN hubs have a different naming convention. Nicely groups things together, and the filter + naming standards make it super easy to find anything.
... View more
12-07-2020
06:33 PM
2 Kudos
Don't think of network like "wan", think of it like physical location. If you had 20 physical locations would you want to look at a flat view where you couldn't differentiate which subnets went to which physical location? Of course not. Network is honestly a poor name. If you only have cameras is "network" a good name? Nope, "location" or "site" would be better. A location can have a MX, sketches, APs, cameras, etc.
... View more
11-29-2020
12:56 PM
Are all of the Meraki switches non-blocking, or only certain ones?
... View more
11-27-2020
07:05 AM
Since the Meraki's are going to separate switches I'd be worried about the trunk being lost and the Meraki's going dual active. While I cannot find my Meraki document I referenced years ago, Aaron's article still exists: https://www.willette.works/mx-warm-spare/ However, it does look like Meraki treats warm spare slightly different between NAT and concentrator modes: "In order to receive heartbeats in a one-armed concentrator configuration, both VPN concentrator MXs should have uplinks on the same subnet within the datacenter. For Routed mode configurations, both concentrators must be able to communicate using the LAN ports." If you make the directly connected ports a dedicated /30 subnet you shouldn't have to worry about loops or anything. I have mine setup this way....but I also run NAT mode 🙂
... View more
11-26-2020
03:37 PM
Do any video guys care about configuring a network switch? Probably not, which is probably why Netgear and others are preferred. Also, this isn't an insult, as I am one of those "video guys". Been doing audio/video for just about 20 years, I just happen to also belong to our network team and cross pollinated to network. Heck, just the other day I had to spin up a Dante mic and DSP for some work stuff. I grabbed the smallest PoE layer 2 switch I had from the supply drawer (it was a Crestron switch). It powered the devices, passed the packets and the gear is none the wiser. Sure, I could have used one of the Meraki switches I had in the adjacent drawer, but I didn't want to deal with a switch that took longer than 5 seconds to boot...lol
... View more
11-26-2020
03:18 PM
1 Kudo
I suspect they dont prefer Meraki for NDI because Meraki probably has little interest qualifying it. If you look at the list of certified switches from Audinate for Dante, it doesn't include Meraki. But they work just fine. While I have not done anything with NDI specifically (only Dante), if the core specs pan out you should be OK. Backplane (non-blocking) is probably the most critical.
... View more
11-26-2020
03:08 PM
Should not lose any settings or matter, but it should be pretty easy to test if you have a couple spare pieces of gear. 🙂
... View more
11-26-2020
06:29 AM
So it sounds like this page requires your non-Meraki VPN to be connected, correct? If that is the case and the page is not part of your Meraki network it does not make a lot of sense. Is the page you are trying to load part of the vpn tunnel and not a split tunnel exclusion?
... View more
11-25-2020
05:52 PM
I'm curious, why did you just not just directly connect the two MXs for the heartbeat using its own vlan? That is an acceptable design from Meraki.
... View more
11-25-2020
05:43 PM
That is an odd setup, and it would seem to make more sense to have them all combined together. I presume the same support team provides support to all of the devices, correct? With different networks you could have different permissions. Maybe someone else will chime in with an advantage to this, but to me it seems very odd.
... View more
11-25-2020
05:38 PM
The running joke is the MX64/65 also double as coffee cup warmers.
... View more
11-15-2020
05:08 AM
It's just silly to force the entire org to be on that model, especially since it includes Insight which is not org centric. You can already split IP range from VPN, not sure why you have to force an org upgrade to split a single networks traffic from VPN when detecting by app rather than IP range.
... View more
11-05-2020
02:24 AM
1 Kudo
I agree with the above, set the range once and never try to grow. Always easier to slice up, never easy to combine. I put all my templates in /19 ranges just to be safe, regardless if I carve up as a /24, /29, etc. Maybe the Meraki is having an issue trying to grow from the bottom end? Rather than growing from the upper end?
... View more
10-19-2020
10:48 AM
1 Kudo
Correct, vlan can be on a layer 2 switch without needing to be configured on the layer 3 switch. In my picture you will see 1234 exists on the switch, but not the MX. If you configured 1234 on the switch and any layer 2 trunks it should work just fine. The part I have not tested/confirmed is if the MX will pass the "1234" vlan when "allow all vlans" is enabled on a MX trunk port. You cannot allow just 1234 on a MX trunk link without it being configured, and obviously there would be no layer 3 routing if you did not configure it.
... View more
09-23-2020
05:35 PM
1 Kudo
vzwinternet is the correct apn. It's what I have on my mx67c. Have you connected it via hard wire first? After that, remove the hardwire and give it a solid 5 minutes.....just don't touch it. Sometimes mine acts goofy on initial load. Otherwise, it's been working great on Verizon.
... View more
09-17-2020
03:36 AM
Those vlan numbers are funny
... View more
09-16-2020
03:41 AM
You can look at the arp table or client stats page to see the mac addresses, then look up the manufacturer in a mac address database. Really only works well if you have a few devices or something is jumping out at you.
... View more
09-11-2020
12:06 PM
All is working fine with static route in place. Time now to see why the Z3 keeps freaking out. Thanks all!
... View more
09-10-2020
01:30 PM
I have made further progress today. I finally got things to connect after I switch my testing from a Z3 and MX67 to a MX67 and MX65. The Z3 was NOT happy with the VPN to the MX67 for who knows why. Either there was something wrong with the hardware or the auto vpn was getting seriously screwed up. Yea, I was hoping for layer 2 bridging, but I'd be OK with a single static entry. Here is what I have working so far: -Company A configured as hub using 192.168.10.0/24 for vlan and injecting into VPN -Company B configured as single arm spoke, has 192.168.1.70 from 192.168.1.0/24 range -Company A can ping Company B 192.168.1.70 over VPN -Company B can ping Company A VLAN IP 192.168.10.1 -Company A devices can ping Company B 192.168.1.70 As soon as I get Company B to enter a static route for 192.168.10.0/24 via 192.168.1.70 I think that will get things to work! *fingers crossed*
... View more
09-09-2020
07:00 AM
KRobert - Company B is spoke, in single arm mode. Regarding making a LAN port a L3 interface, how do you define the gateway/next hop? If I create a VLAN on the MX at Company B of 192.168.0.0/24 and give the MX an IP of 192.168.10.2, how do I tell it and Company A to use 192.168.10.1 (the actual Company B router) for everything? Karstenl - Maybe it is a NAT issue. The spoke works fine when in dual-arm mode, but flip to single-arm and it gets all kind of angry. To me it would seem weird that the VPN can establish in dual-arm mode but not establish in single arm mode. Also, my testing is with just the WAN port connected, I didn't move beyond that because of the lack of VPN connection. I can't place it in a DMZ because A) one may not exist and B) trying to make this as low config as possible. The desire was to just drop a single-arm Meraki into an office to bring in the tunnel. Then with just a static route on their network for return traffic (192.168.0.0/24 via MX LAN IP) the Company A location could access their entire 192.168.10.0/24 network. My goal is to not require separate internet or DMZ for the outside interface terminating the VPN. Trying to go with a cookie cutter method for unknown networks. It's a funky setup I know, but just trying out something new.
... View more
09-09-2020
05:04 AM
Stick with me on this one, it's an odd request..... Lets say I have two companies, A & B. A is 192.168.0.0/24 B is 192.168.10.0/24 Company A has a normal MX hub, nothing special. For arguments sake, dual-arm with public IP on WAN interface. Company A buys Company B (again argument sake, no legal concerns) and wants to access their network for whatever reason (again, this is all technical). I have been trying to lab this out but am failing. My thought was to slap a MX on Company B network in single arm mode. Company B MX would receive 192.168.10.10 IP address and access internet from existing local network connection. Company B adds static route of 192.168.0.0/24 via 192.168.10.10 Company A learns of 192.168.10.0/24 via VPN route table For the most part the Meraki gear seems to accept this configuration. The part which doesn't work is the AutoVPN between spoke and hub. It sees the peer but has red indicators showing it's not established. I know this is reverse of your typical deployment, but I am trying to work around the fact you cannot create a L3 interface on a MX of the local LAN.
... View more
08-20-2020
10:17 AM
An update, if anyone cares. Support is saying the VPN exclusion is meant to override the default route checkbox, but not routes learned via VPN. Which in my mind is pointless. If a certain route is learned from a hub, but you need to exclude that route at a branch so it goes via the NAT interface, that is what the option should (also) allow.
... View more
08-03-2020
01:36 PM
Has anyone tested this? It's not working for me. I have a spoke site with the default route box checked, so all traffic goes back to the main head-end. I also have a 0.0.0.0/0 route advertised from the hub to the spoke sites. I added ANY 1.1.1.1/32. If I try to ping from the spoke site Meraki (vlan, default, or internet) it does not work. Doing a trace from a device connected to the Meraki shows it's still following default route. Do we know if routes advertised from the main hub have a higher priority than the VPN exclusion? Now, if I use trace route on the Meraki this uses ONLY the WAN interface rule and bypasses all settings/rules/routes. Works just fine, but this is expected.
... View more
04-27-2020
06:55 PM
I guess someone wasn't happy with the behind the scenes view and/or association with the specific American only non-round ball league 😉
... View more
04-25-2020
11:43 AM
Nice! Though, all that money and tech and I see a table top projector....with serious keystone. Hilarious!
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 634 | 03-06-2021 09:13 AM | |
| 289 | 09-16-2020 03:41 AM | |
| 869 | 12-02-2019 02:49 PM | |
| 1251 | 10-31-2019 05:36 PM | |
| 751 | 10-04-2019 10:39 AM | |
| 10587 | 03-01-2019 02:21 PM | |
| 1425 | 01-08-2019 03:51 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 634 | |
| 5 | 1251 | |
| 4 | 1425 | |
| 3 | 751 | |
| 3 | 4880 |
