Meraki

PhilipDAth · ‎Jul 16 2018

Wahoo, my loot arrived yesterday. Thanks @CarolineS and everyone else who gave out all the Kudo's and Solutions.

PhilipDAth · ‎Jul 14 2018

I just tried it as an Organisation Admin in Chrome, and I could see the "Show key" button. If you are not using Chrome, perhaps try that. Otherwise it sounds like you might need to be an Organisation Admin to retrieve the key.

PhilipDAth · ‎Jul 12 2018

Perhaps something upstream is doing policy routing, and routing the requests via an alternative circuit and NATing it.

PhilipDAth · ‎Jul 12 2018

I wa running 10.26 for quite a while without issue. I upgraded to 10.29 earlier this week and so far no issues - but that is not much time.

PhilipDAth · ‎Jul 12 2018

You can see layer 3 VLANs, because they have an IP address configured on them - but there is no where to see a list of all the configured layer 2 VLANs.

PhilipDAth · ‎Jul 12 2018

You could use static route tracking. https://documentation.meraki.com/MX-Z/Networks_and_Routing/MX_Routing_Behavior#Static_Route_Tracking If it is a managed service the service provider should be doing something like HSRP for you, making the two routers appear as one. If this is an Internet service though I don't know what you can't just use the normal WAN ports on the MX.

PhilipDAth · ‎Jul 12 2018

You have to expect some things to be broken in a BETA ... This just started with the form. 🙂

PhilipDAth · ‎Jul 12 2018

This could vary by the shard you are on. Log into the dashboard and then in the top right go to Help/Firewall Info. It will give the specific IPs for your shard.

PhilipDAth · ‎Jul 11 2018

You should be able to just correct the typo. What happens when you try? Otherwise just delete that VLAN and create it again.

PhilipDAth · ‎Jul 11 2018

I'm a bit grey on this one, but I'm about 75% sure that no matter what you configure, ClientVPN can not be used to access remote resource on the other side of a non-meraki VPN.

PhilipDAth · ‎Jul 10 2018

I don't know - but Meraki primary supports LLDP.

PhilipDAth · ‎Jul 10 2018

Enable LLDP on the lan switch, and then look at that info.

PhilipDAth · ‎Jul 10 2018

I'm with @Adam, I often have spare TwinAx cables on hand as well. It is definitely the cheapest way of doing 10Gb/s.

PhilipDAth · ‎Jul 10 2018

As @AjitKumar says, all you really need to do is just move the MX to the new network, and it will get a new config.

PhilipDAth · ‎Jul 10 2018

If you go into the actual switch port to the CDP/LLDP section on the right hand side is a link called "raw". This display a lot more of the CDP/LLDP info. It is possible you might need to be running 10.x code to see this. Can't remember.

PhilipDAth · ‎Jul 10 2018

I stand corrected. I had based my answer off the specifications. The MS120 specifications don't mention support for DHCP relay. I knew they didn't have DHCP server support, so that also seemed reasonable their was no relay support. https://meraki.cisco.com/products/switches/ms120-24#tech-specs I just had a quick look, and indeed the option does appear when you have mentioned.

PhilipDAth · ‎Jul 9 2018

The Powershell service doesn't support negotiating to a stronger cipher suite? I'm amazed!!! It should support upgrading to stronger crypto without needing a code change.

PhilipDAth · ‎Jul 9 2018

You won't be able to use OSPF between the sites - you should not need it. In each case, the default route for each switch should point to its local MX. The MX will need to know the routes in use at each site already, and you simply include those in AutoVPN.

PhilipDAth · ‎Jul 8 2018

Make sure the case of the SSID exactly matches.

PhilipDAth · ‎Jul 8 2018

You can pattern match on part of a string with the Called-Station-ID attribute. In this case, if you put just the SSID it should match. https://blogs.technet.microsoft.com/netgeeks/2017/05/02/how-to-authenticate-multiple-wifi-ssids-on-a-single-nps-server-radius/

PhilipDAth · ‎Jul 8 2018

If you are getting an ACCESS-REJECT that means the Microsoft NPS RADIUS server is refusing to allowing the client to connect. You need to go and look at the policy or logs on this server to see why it is rejecting the client.

PhilipDAth · ‎Jul 7 2018

@JasonCampbell the only test that is used to determine if a unit is alive is weather it can talk to the cloud. VRRP is used strictly for a FHRP. An MX only participates in VRRP if it can talk to the cloud. If it loose that connection it stops speaking VRRP completely.

PhilipDAth · ‎Jul 7 2018

@CHN I think you might need to convert your video to MP4 and upload it again.

PhilipDAth · ‎Jul 7 2018

@JasonCampbell you say: "While VRRP packets will flow thru all VLANs, having a dedicated physical link on its own dedicated VLAN that VRRP packets flow thru allow for the shortest path on a VLAN that is exclusively VRRP packets. True, VRRP will go out all VLANs -- but in case of any sort of congestion or link failure in the switch stack, you have a dedicated link and VLAN that will still allow VRRP packets to make it to the warm spare. So, IMO, it is still advisable to use a dedicated link with a dedicated VLAN to ensure timely arrival of VRRP packets to the warm spare without having to worry about the rest of the network." I don't think you understand the purpose of VRRP. VRRP is a protocol to provide protection for the default gateway of a VLAN. It allows clients configured with that default gateway to remain working during a failure. Having VRRP running on a dedicated VLAN between two MX units is - pointless.

PhilipDAth · ‎Jul 6 2018

To prevent clients talking to each other you need the client isolation feature - but this is not supported by the built in AP's. You need a standalone MR. Yes you could allow clients on different SSID's to talk to each other. The easiest way would be to bridge both SSIDs to the same VLAN.

About PhilipDAth

PhilipDAth

Philip D'Ath

Community Record

Badges