About cmr

cmr

1) option 150 or similar for voice server IP 2) host dhcp on an HA pair of MXs or a stack of MSs 3) works fine, we moved our HQ from Cisco 3850 stack to MX many months ago, it is actually better. 4) easy view of options, many scopes possible, I'm sure there are some issues but we've not had any

cmr

As mentioned in another thread by @AnythingHosted 27.3 has been released and has the below fixes and issues: Bug fixes Reduced aggregate upload throughput on 2.4 & 5GHz radio for Windows clients (MR45/MR55) Malformed packets received by the BLE radio may cause the MR to reboot (MR42/MR52/MR53/MR84) Wireless clients passing minimal amounts of traffic may be displayed as wired clients (All MRs) If a client roamed from an MR, and then after 5 minutes roamed back to the original MR, the association was rejected on 802.11w-required SSIDs (802.11ax MRs) Interoperability issues with some older clients and/or drivers resulted in the clients getting into states where they could not pass any traffic (802.11ac Wave 2 MRs) Scanning radio could enter an invalid state and lead to the MR rebooting (802.11ac Wave 2 MRs) Known issues Under certain conditions, successful WPA2-PSK connections are reported as failed under Wireless Health event logs (All MRs) Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84) Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (All MRs) I received an email from Meraki support at 17:03 (UTC+1) saying that all my 27.2 networks would be upgraded over the next week to 10 days, so they must be pretty keen to bin 27.2!

cmr

Hi @PeterJames the MG21 is considered a WAN by the MX and unfortunately you can only have WAN1, WAN2 and cellular. There is also the option to get support to convert WAN2 to behave as a cellular interface if you want

cmr

Are the APs allowed to talk out to the Meraki cloud, the information about what they need to talk to is on this page: https://documentation.meraki.com/zGeneral_Administration/Other_Topics/Upstream_Firewall_Rules_for_Cloud_Connectivity Cheers, Charles

cmr

Well 12.22 is out now (obviously 12.20 and 12.21 didn't make the cut) but the bugs remain unless you have a 390 where some more are fixed: Bug fixes Traffic handled by a static route can fail to be routed properly on non-MS390 switch stacks MS390 firmware upgrade progress can reflect as 0% on local status page despite progressing normally Also added is that the MS390 upgrade process will now take a more Meraki time as opposed to an IOS-XE time, although this is from 12.10 onwards... 😎

cmr

The only way I have used more than 2 ISPs is on an SD-WAN concentrator at the core of multiple MPLS networks. I did ask a senior Meraki tech about more than two and he said that they had had occasional requests, but it was not on the priority list

cmr

I can't believe after all the confidence they built up, it as dashed at the end; scandalous!

cmr

Indeed, @RumorConsumer I think the best way to approach it is; do I need the extra possible bandwitdth or user density that the wider channels can give, if so can I afford it without overlapping channels.

cmr

If you have two WANs then it is a little more tricky as the main graph only shows overall for both...

cmr

@RumorConsumer glad to see you found the issue, that does of course all make sense, I found some similar issues with trying 80MHz channels even with all bands enabled. There seem to be a max of three channels and where I am that means one of mine has to overlap directly with one of the neighbours, so I too moved down to less, but cleaner, bandwidth.

cmr

I've long given up with the topology diagram, it always has ghost devices and at one of our sites three separate red diamonds that are all the same Cisco switch stack. We even get it at pure Meraki sites, as you have 🤔

cmr

@MarcAEC I think that is just confirming the unfixed bugs and quite normal. However I agree that some to seem to stay around for an awfully long time!

cmr

If you use a device for IT staff (say a small MX or a Z3) then you can give lots of access to those devices and different access between them if needed. Then you can use the client VPN for normal users. I am testing this right now 😎

cmr

Option 1 every time 😎

cmr

@Jwiley78 yes, perfect, and the great thing is that is all there really is to do, it just gets on with it after that 😀

cmr

I believe it is down to power saving. It appears that the current 26.x and 27.x firmwares don't like Intel 802.11ac chipset power saving at all and you get high latency, disconnects, bad password etc. It does seem to affect some other devices but I have personally only seen it on all 802.11ac Intel chipsets. 802.11ax is okay and I don't have anything older.

cmr

@Jwiley78 the virtual !P is the one you will appear to be coming from to the rest of the world. The other two required IPs are one for each box and are used for failover management

cmr

@carl222 I would not use no switchport, I would use switchports in a VLAN and put the IP addresses on the VLAN interface (SVI). The MX ports are L2 as you thought

cmr

Thanks @MerakiDave the view now shows correctly for switches with only the one network where I have an out of date beta generating a warning 😎 I'll add a wish for the MX out of date betas to show there.

cmr

If you are billing per GB then in the client view, select only appliance clients and you can then see how much data they have used in the period, do some testing though as I'm not sure it 100% correlates with what is actually used so you may need to apply a factor.

cmr

We use MX pairs and 3850s as our main routing switches, but we stack the 3850s and then wire the MXs as you have. This has worked well for the last year. With your setup where the 3850s are independent I would be careful about the second MX to 3850 connection as you may well get spanning tree issues. In terms of the layer3 on the 3850s we don't use a routed port, we use a VLAN interface so that you can have multiple switch ports in that network (both MX LAN interfaces) so in your case, I think the VLAN would need to be on both switches using HSRP between them and 192.168.1.2 would be the VLAN HSRP interface IP. Your other routing settings look correct to me.

cmr

@Mohammad yes, I believe that is the case, when load balancing is configured on an MX100 you will see it as below (this one is part of an HA pair so you see the virtual IPs as well): The cellular is always only used if the wired is down, hence different options

cmr

@Mohammad if you want to have both active, then you need to enable load balancing on the SD-WAN & traffic shaping page.

cmr

@redsector it is only available for per device licensing and has to be applied to a complete network within an organisation.

cmr

I still have the issue I had with 27.1 on an MR55 where Intel 802.11ac wireless adapters have appalling latency and drop packets when the laptop is on battery and the wireless adapter engages power saving mode. It does look connected so that may be what you are seeing?

cmr

Community Record

Badges