Meraki

KarstenI · ‎May 25 2021

It should work as it is "normal" UDP traffic. Is the managed device (the AP) configured to respond to the public IP of the request? BTW: What about using a VPN to manage the internal devices?

PhilipDAth · ‎May 24 2021

I don't know. I have not tested that scenario.

Twitch · ‎May 24 2021

@cmr @KarstenI - Turns-out that our last mile circuit provider had their end of the circuit at the demarc configured wrong. As soon as they fixed it, speeds became normal. So, at this point, our first VPLS connection is up-and-running successfully. I'm going to go home and get some sleep now. Cheers! Twitch

KarstenI · ‎May 22 2021

Licensing ... I am so happy that I don't have to deal with Windows licenses as that is always done by the customer or other companies. It's enough to have to deal with all the Cisco licensing stuff! But for this specific customer, the MAB devices were managed in ISE.

DarrenOC · ‎May 21 2021

hi @cmr - that MS355 uplink one you've highlighted red is interesting....

KarstenI · ‎May 20 2021

Yes, that looks good! But as a fraidy-cat, I wait some versions for my home network. The WAF of working WLAN is more important. The office network is scheduled to upgrade on the weekend (not that important). 🙂

Hugo2 · ‎May 17 2021

thanks for you answear, It is clearer to me

Paul_kanm · ‎May 14 2021

Thank you very much, I will propose this solution to my superiors because it is the only solution available in my case

SandroZ · ‎May 14 2021

The correct answer for last week question was B! If you want to read more about survey mode and how to use it you can take a look here also as bonus reading how to change le local status page credential

PhilipDAth · ‎May 13 2021

The easiest option is to redirect all your traffic. Just tick the "default route" option and make it a full tunnel. https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Default_Route

PhilipDAth · ‎May 13 2021

It works in any SFP or SFP+ port. It makes no difference if it is a LAN or WAN port.

DBCK · ‎May 13 2021

Thanks Philip, the problem i had with that is Meraki limits the duration to 1200 seconds (20minutes) or 100,000 packets and even filtering on UDP it runs for around 25 seconds and ive hit the 100,000 packets allready which is why i needed a more specific expression for the range i was looking at.

RumorConsumer · ‎May 12 2021

@KarstenI @Bruce Haha thank you both. This is great. My bandwidth is rarely saturated (250x250 fiber) so Im going to not worry about it. Sounds like thats the suggested path at least for now.

cmr · ‎May 11 2021

@KarstenI we wanted to trunk all the VLANs that need DHCP to it as an MX needs an interface to create a DHCP scope and our main data MX pair use a transit VLAN between them and the L3 MS210 stack to keep the site to site routing simple (a class b range that is broken down into multiple class c VLANs on the L3 stack).

KarstenI · ‎May 11 2021

Strange, I've read that document but missed that sentence. Thanks for pointing this out.

KarstenI · ‎May 11 2021

If there is no RADIUS request, it is likely the default PMKsa-caching on the APs. You could: Ask Meraki Support if they can disable it. Not sure if that is possible. Reduce the session timeout on the RADIUS-server to limit the amount of time the client could continue with disabled account.

PhilipDAth · ‎May 10 2021

I almost never use one-armed mode. I prefer to set up the DC like any other site. I also prefer to have a cheap backup domestic Internet circuit plugged into WAN2. This means if the DC has a catastrophic failure you can still get to the MX, and AutoVPN can still failover to the cheap circuit. Having dual circuits also allows you to configure SD-WAN policies so that if the main DC circuit degrades you can take advantage of that cheap circuit, or you can offload bulk traffic you don't care so much about onto the cheap circuit. VPN concentrator mode allows you to do BGP, and supports more complex active/active configurations.

KarstenI · ‎May 10 2021

@DarrenOC Completely lost stacks? Once/Twice (1*Catalyst and one heavily misbehaving Meraki stack after an upgrade). Even buying original Cisco SFP+ had been a good solution compared to the additional grey hair caused by this ... 😉 But yes, it happens so seldom that it probably should not be the main concern.

KarstenI · ‎May 8 2021

@DarrenOC Good to know that it really can be done that easily.

Dennisvw99 · ‎May 6 2021

I got my answer! Steve Harrison, Senior Technical Marketing Engineer at Cisco Meraki and writer of Exploring Snort | Cisco Meraki Blog told me this: 'due to the current out of band (i.e. parallel process) nature of the Snort daemon in the MX architecture, no additional latency is added to the packets. This operating model will change in the near future though and whilst we have not finalised testing to to prove these assumptions, the parallel threaded workflow nature of v3 of the Snort daemon (used in MX16+ codes) will mean that we anticipate the additional delay to be in the realm of 10-100 microseconds and no more.' Thank you for the replies!

hmc250000 · ‎Apr 22 2021

Yes, it is working fine on the sonicwall however. And fyi it is because of the limitations of the site to site VPNs between Meraki and non Meraki peers that we still have the sonicwall on our network. Aren't the Meraki MX's doing stateful inspection? I believe that keeps track of incoming and outgoing sessions something like that.

EduardoVillegas · ‎Apr 19 2021

Thanks Karstenl

Inderdeep · ‎Apr 16 2021

Thanks @DavidLowe , My answer was correct 🙂

cmr · ‎Apr 11 2021

CPU is same as 16.4, i.e. more than 15.x

GreenMan · ‎Apr 9 2021

Just one thing to add to this; there's only an implicit allow if the packet is received on a LAN interface. If it's on a WAN / Internet port (with no matching outbound session), it hits an implicit deny - of course!

About KarstenI

KarstenI

Karsten Iwen

Community Record

Badges