Meraki

cmr · ‎May 7 2021

Well, it turns out I might need to apologise to Meraki as it appears that the switch may well be routing properly and it was simply that we had multiple devices that had either lost part of their config, failed or were simply slumbering after being unused for the best part of a year in lockdown! We now have only two devices that don't route properly, one is being replaced as it doesn't seem to hold its default gateway and the other is the management interface of a Force10 switch which is accessible from the other switches in the same VLAN so I have given up trying to properly fix it! On a positive note 14.21 seem the most stable out of 12.28.1, 12.33, 14.19, 14.20 and itself!

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!

irwin · ‎May 6 2021

Hello Bruce, Thank you for your detailled answer !

eddiex · ‎May 4 2021

Thank you very much for the clarification. The branch office does use 10M ISP for everything. All branch traffic(internet and corp data) go back to the VPN tunnel back to main office. So, if the branch office need go to Google, it will first tunnel back to main office, and then go out to the internet through the main office's firewall. Like full tunneling. In this case, will QoS makes any impact? Thanks

Bruce · ‎Apr 29 2021

@Shadius, yes that is correct. And when you split a network you won't lose any configuration on the switches.

PhilipDAth · ‎Apr 29 2021

In this case, we have a one arm MX with two AutoVPN tunnels to a spoke. The one-armed MX will return the traffic to the spoke via whichever AutoVPN tunnel it came in on.

Bruce · ‎Apr 29 2021

If you’re doing a renewal of licenses then the number of licenses you purchase needs to match the number of devices. A renewal effectively replaces your existing licenses with exactly what is on the order. If you add additional licenses then you get another device license, but the co-term date is adjusted as the license ‘flows’ across all devices in the organisation. For your two access points, yes, you need to purchase two licenses. No, you can’t purchase one 5 year one, there is no way to split it.

Bruce · ‎Apr 29 2021

At the moment you can’t, they’re not supported on Group Policies. See, https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Network_Objects_Configuration_Guide

PhilipDAth · ‎Apr 28 2021

30 meters. Is there no chance you can't run fire? Perhaps a chain between the building roofs and run the fibre over that, along a fence, in a trench, etc?

MEmami · ‎Apr 27 2021

Hello, as the new firmware is in Beta and doesn't support some features like multicast over LAN, Could you please tell me, how long does it take to get a productive version of MX16.x Firmware? We need to run anyconnect on our devices but as long as the firmware Beta version is, we can not use it in the production world. Best Regards!

Bruce · ‎Apr 27 2021

@rossmeraki glad you got it working - always good to see the simplicity of the Meraki kit in action 😀

Bruce · ‎Apr 26 2021

It's a bit hard to assist remotely, but I can make some suggestions. Was the site survey done as a 'predictive' survey, or did you have one done after all the access points were installed and configured. If you haven't had an active site survey done since the installation you should really do that to understand what the RF looks like. You should also do a new site survey if there have been any changes in neighboring buildings or their occupancy (new tenants can mean they're generating new interference). You also need to look at the capability of the devices you're using. If they can all make use of 802.11a/g/n (i.e. no 802.11b) then you should be setting a minimum bitrate of 12Mbps - this disables 802.11b which will improve overall performance of the network, which you need for VoIP (802.11b is unsuitable for wireless VoIP). What's the approximate distance between access points? Are they mounted on steel beams or similar?

Bruce · ‎Apr 24 2021

1) Generally the impact will be minimal as most of this is done in ASICs, there may be a small overhead for the first packet when the forwarding tables are populated. (I’m not fully up to speed on the MS switches, and it’s probably different for the MS390 switches too). 2) Not that I’m aware of, all ACLs configured on a network are applied to all switches in that network. Note the limitation of ‘Maximum ACL limit is 128 access control entries (ACEs) per network’. Also with the MS390, note that it currently ignores any ACLs where a VLAN is specified.

Bruce · ‎Apr 22 2021

@NadiaK, yep, you are completely correct about the MX. Although the MX doesn’t generate its own BPDUs, it does forward BPDUs that it receives out other ports. You’re limited to how you can influence the traffic flow to just modifying the root bridge priority on the switches.

bsbswilson · ‎Apr 22 2021

We are working at full upload speed now. Thank you everyone for your input and I hope this thread helps someone else some day. After testing the 3 devices that we have on hand at this point again several times, we determined that something in the network config is to blame. I'm guessing it is the WAN traffic shaping policy that looks correct in the UI, but behind the scenes was actually broken in some way. All 3 devices, on various firmware versions, work as they should with full upload bandwidth once we built a new network. If we apply the old network to any of them, the upload limit comes back.

Bruce · ‎Apr 21 2021

In response to the second part... >Will this significantly decrease performance in the network as Meraki stated? The decrease in performance is due to the additional VPN tunnels that the MX has to maintain. In a hub and spoke each spoke will have between 1 and 4 VPN tunnels depending on the design. When running in hub mode the MX is having to maintain 1 to 4 VPN tunnels to all other hubs in the organisation... a significant increase, which is what creates the load on the MX. You need to check the MX Sizing Guide to see how many VPN tunnels your devices will support.

Inderdeep · ‎Apr 21 2021

@CptnCrnch @Thanks a lot !

Indetech · ‎Apr 20 2021

You are absolutely correct. the additional IP's are routing through the WAN interface even though they are a separate subnet from my WAN configuration.

ObaidN · ‎Apr 19 2021

Thank you @Bruce . Yes I am aware that I would only be able to use 1x ISP as active.

CarolineS · ‎Apr 19 2021

@DarrenOC dark mode request noted? 😬Probably it won't happen until after our community platform vendor releases a snazzy new frontend update they've been promising for a while (which I believe will be coming out by the end of this calendar year). So.... hang tight?

EduardoVillegas · ‎Apr 19 2021

Thanks Karstenl

Zac123 · ‎Apr 16 2021

Thanks for the replies all! It sounds like migrating while running the routers in parallel is the best way to swap this out. Thanks again.

Bruce · ‎Apr 15 2021

Whether you need a new SSID or nor depends on how your Eduroam service is setup. I know here all the participating education institutions have a separate SSID called EDUROAM, specifically for this service. As @ww stated, under Network Access for the Eduroam SSID, select ‘Enterprise with’ option and then ‘my RADIUS server’. You’ll then be able to enter your RADIUS server details further down the page.

AnthonyMaddick · ‎Apr 13 2021

Hi Bruce, you have hit the nail on the head.

CptnCrnch · ‎Apr 9 2021

Great job, gentlemen! 🤗

About Bruce

Bruce

Community Record

Badges