Meraki

jdsilva · ‎Aug 7 2018

It's more of an aggregate really. Let's say we have an MX that is rated for 2Gbps unencrypted traffic, and 1Gbps encrypted. If you were to, say, drive 500Mbps of encrypted traffic through it you would then only be able to get about 1Gbps of unencrypted traffic through it at the same time (not 1.5Gbps). In our testing we've found that you can use the general rule of thumb of encrypted traffic counting 2x towards the total throughput of the box.

jdsilva · ‎Aug 7 2018

FINALLY one of these with USB C! I can actually use this with my phone 🙂 Thanks @CarolineS!

jdsilva · ‎Aug 2 2018

I was seriously unimpressed when I looked at this file to day to discover it was encoded in some stupid format. Booo!

jdsilva · ‎Aug 2 2018

Nope. that's about all you get. However, a few of the settings you're asking about are implied already. https://documentation.meraki.com/MX-Z/Content_Filtering_and_Threat_Protection/Threat_Protection#Intrusion_Detection_and_Prevention

jdsilva · ‎Aug 2 2018

In my previous job I rolled out this sort of solution using Digi WR44's and Aruba AP's. Worked like a hot damn. As far as using an MX my initial concern is that there's no option for an internal SIM instead forcing you to go with a USB modem. Vehicular vibration makes that a very bad idea in my mind. I guess you could super glue it in, but if only there was an MX with an integrated modem... We also used Private IP SIMs to do this so our traffic never hit the Internet. Not all providers have this option, but it's a nice solution to avoid IPsec over the Internet. SD-WAN is making this less of a thing though.

jdsilva · ‎Aug 1 2018

Nice work guys! And thank you to everyone for the kudos.

jdsilva · ‎Jul 25 2018

Holy crap! I can't believe that worked! OK, so if you want to do a LAN to LAN hairpin you can leverage the 1:Many NAT feature to make this happen. To test this I have a Raspberry Pi behind an MX on VLAN 10 with an IP of 192.168.100.5. I then created the following 1:Many Nat rule under Security appliance > firewall: So then as a test I then SSH'd to the 1:Many IP, which "hairpins" me back to the same Raspberry PI. Very cool. I expect this would work the same for a 1:1 NAT as well. So while not quite a true hairpin, it does the exact same thing.

jdsilva · ‎Jul 25 2018

I don't think you can... The MX only NAT's between WAN and LAN interfaces... There's no way that I'm aware of to do a LAN to LAN or WAN to WAN NAT on it. But... Maybe you can sort of do the same thing if you create a 1:1 or 1:Many NAT... Hang on let me try this...

jdsilva · ‎Jul 25 2018

Hey. All you have to do is enable load balancing globally under Security appliance > Traffic shaping and the MX will use both. You don't have to set up any performance classes or VPN flow preferences unless you want apply rules to specific traffic. The global setting will apply to all traffic.

jdsilva · ‎Jul 25 2018

Yup

jdsilva · ‎Jul 25 2018

Nope, you shouldn't need a rule on the MX. It'll just pass through whatever markings are already there. You would only need something if you wanted to give it some sort of priority.

jdsilva · ‎Jul 25 2018

That looks like a capture from the radio side? What does a capture on the wired side look like? Also, if you're marking AF41 then that's in the IP headers and not the 802.11 headers.

jdsilva · ‎Jul 25 2018

I totally put this in the linked thread instead of here... There I go posting before I've had coffee again... ================================= This may not be related, but if you're trying to prioritize your RTP traffic you should be aware of some changes made in Wired 14.5 and 14.6. The only place I've seen this documented is in the changelog and not in the KB. It does seem to work well in all the testing we've done.

jdsilva · ‎Jul 25 2018

Damn, wrong thread...

jdsilva · ‎Jul 25 2018

This may not be related, but if you're trying to prioritize your RTP traffic you should be aware of some changes made in Wired 14.5 and 14.6. The only place I've seen this documented is in the changelog and not in the KB. It does seem to work well in all the testing we've done.

jdsilva · ‎Jul 24 2018

Clients always make the decision. 802.11r doesn't change that. 802.11r doesn't even influence that. You're talking about 802.11k. https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview#How_do_802.11k_and_802.11r_help.3F

jdsilva · ‎Jul 24 2018

Are they Cisco or Meraki? If they're Cisco then you can default them and either hook them up to a controller (LWAPP mode) or just reconfigure them (autonomous mode, if they support it). If they're Meraki then they will still be owned in the dashboard by the third party and there's nothing you can do with them unless they release them so you can claim them to your own dashboard.

jdsilva · ‎Jul 24 2018

Hi @BlakeRichardson. That's not a very nice thing to assume. Shame on you for your baseless accusations! 😉 I also think you're thinking about 802.11k, or perhaps 802.11v, not 802.11r. r has nothing at all to do with clients roaming decisions.

jdsilva · ‎Jul 24 2018

Oh c'mon. What are you doing on your laptop, while moving, that you can actually tell the difference?

jdsilva · ‎Jul 24 2018

802.11r is really only useful in a wireless VoIP deployment. The rest of the time... Meh. It doesn't really affect the user experience.

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

What the the details of the message hidden in the "more" link? I want to say that this iPhone is sending unsolicited RADIUS messages but those wouldn't be "response" messages I wouldn't think.

About jdsilva

jdsilva

Community Record

Badges