Meraki

jdsilva · ‎Jul 24 2018

@RogerO wrote: my internal apps team which they do not know what URL's they call I'd act surprised... But I'm not. Man, life would be so much better without developers 🙂

jdsilva · ‎Jul 24 2018

I wish I had better whitelist formulas to offer you... 😞

jdsilva · ‎Jul 24 2018

If it is AMP blocking then it _should_ appear under Security appliance > Security centre under the Events tab. Note that I say _should_ ... You could also just whitelist your internal applications in AMP under Security appliance > threat detection. And last thought, what version are you on? We've had much better AMP performance / results up in version 14.x than in some of the older firmwares.

jdsilva · ‎Jul 24 2018

There is no compatibility between the Meraki MX and any vendor for SD-WAN features. I'm not aware of any SD-WAN implementation from any vendor that's compatible with another vendor... You can nail up an IPsec tunnel between an MX and another device, but you will not get any of the SD-WAN features.

jdsilva · ‎Jul 24 2018

You can see the connections being made through the box via Syslog. There's no way to view this information through the dashboard, only via external logging.

jdsilva · ‎Jul 18 2018

@Darrell Not exactly. It can use multiple IP's for inbound traffic. So you can do DNAT on inbound traffic. What you cannot do is SNAT on outbound traffic.

jdsilva · ‎Jul 16 2018

I got mine today too! I didn't realize the MotM's got stuff. I never read that thread before... That was a pleasant surprise this morning 🙂 Thanks as well to everyone who kudo'd and solutioned my posts! And thanks to @CarolineS for all the work on the forums!

jdsilva · ‎Jul 12 2018

That is correct. As Meraki implements RSTP (802.1w) there is only one instance of STP on the switch, and all VLANs will forward traffic based on that instance. On a Cisco Catalyst the default is PVST+ where one STP instance is run on each VLAN, and you can set the priority of each instance.

jdsilva · ‎Jul 12 2018

https://documentation.meraki.com/MS/Monitoring_and_Reporting/Switch_Port_View

jdsilva · ‎Jul 12 2018

That is correct. The uplink port has nothing to so with anything STP whatsoever.

jdsilva · ‎Jul 12 2018

The uplink port is the port the switch is using to talk to the Meraki cloud. It has nothing to do with up- or down-link within your LAN.

jdsilva · ‎Jul 12 2018

Haha! Three different people, three different answers. At least two of us are wrong... If not all three 😞

jdsilva · ‎Jul 11 2018

You use the same "Local Networks" section that you use for AutoVPN. You can't exclude a network from AutoVPN, and include it in third party VPN.

jdsilva · ‎Jul 9 2018

Check out these two links. They should help with this. For OSPF, in what you describe you would just make both part of Area 0. Area boundaries are on layer 3 devices, not between layer 3 devices. You can get a pretty big number of routers in an area without having to worry about areas. https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_Overview https://documentation.meraki.com/MS/Layer_3_Switching/MS_OSPF_Overview

jdsilva · ‎Jul 7 2018

I think this actually is detrimental to your network. You are creating a "shortcut" path that is not representative of the path your clients will use. This dedicated VLAN heartbeat cable leaves you wide open to the scenario where your clients lose connectivity to the active MX, but the active MX does not relinquish control to the secondary thereby taking your entire network down. You want VRRP to move over the path your clients actually use.

jdsilva · ‎Jul 6 2018

That page was not updated due to an oversight I believe. They are aware now that it is outstanding and hopefully it'll get changed soon. In my experience the issues caused by creating the loop at L2 on devices that do not participate in STP are far more detrimental than having VRRP frames pass through one switch between MXes. I would agree that you don't want your VRRP to take the scenic route through your switch fabric to get to the other MX. But if you have problems getting VRRP through a single switch before the dead timer expires then you really have much bigger problems that you need to be looking at.

jdsilva · ‎Jul 6 2018

Very cool. I can see this being quite useful. Nice work!

jdsilva · ‎Jul 5 2018

@MRCUR That could very well be the case. I've only been working with Meraki gear for about a year so I can't say how long it's been there. I'm glad it is there because I would have been very frustrated if I went to do this and needed a whole new piece of hardware to get it done.

jdsilva · ‎Jul 5 2018

@RyanB Not at all! Join the conversation and bring forward ideas! If my assessment of that article is incorrect please by all means call me out on it 🙂

jdsilva · ‎Jul 5 2018

That's incorrect @MRCUR https://documentation.meraki.com/MX-Z/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX#1:1_NAT " It can also translate public IP addresses in different subnets than WAN interface address if the ISP routes traffic for the subnet towards the MX interface. "

jdsilva · ‎Jul 5 2018

@RyanB I dispute it's greatness. See my comments above 🙂

jdsilva · ‎Jul 5 2018

You shouldn't have to configure one of the IP's in the second block to actually be on your provider facing devices... In this case you should just be able to start using them in the 1:1 and 1:Many NAT section of the MX and away you go. The provider should be routing the new block to the next hop IP of 204.1.1.2 (Your MX).

jdsilva · ‎Jul 5 2018

...And, Meraki has officially changed their documentation on this. The heartbeat cable is no longer a recommended configuration. https://documentation.meraki.com/MX-Z/Deployment_Guides/NAT_Mode_Warm_Spare_(NAT_HA)#Recommended_Topologies Yay!

jdsilva · ‎Jul 5 2018

Hi @Pugmiester, I did not mean ARP entries, I mean MAC address table entries. They are not the same.

jdsilva · ‎Jul 5 2018

@GreenMan Yup, I'm with you on the simple path part. I'm just saying that the dedicated VLAN over a dedicated link for "heartbeats" is flawed thinking as VRRP doesn't work that way, and you can't deterministically predict where the DB sync traffic is going. What is needed to complete this setup is a way to flag the heartbeat VLAN as the heartbeat VLAN. Right now there is no such control on the MX.

About jdsilva

jdsilva

Community Record

Badges