Meraki

cmr · ‎Jan 28 2021

15.42 is in the beta channel, we've been running 15.x for over 18 months on our production MXs including an HA pair of MX250s. We expect it to become a stable release very shortly.

cmr · ‎Jan 28 2021

MX16 is your friend, it is on the FIPS list, we expect MX15 to be moved from beta to release imminently and MX16 should then be available. I'd hold on a short while and ask your Meraki AM for a more accurate timetable.

cmr · ‎Jan 28 2021

There is also 27.6 as a stable release candidate... Only 802.11ac wave2 and newer APs can run the 27.x firmware so 26.x is there for older APs. You have newer models that can run 27.x so you should be running 27.6 in my opinion as it gives you the newer features and appears stable.

cmr · ‎Jan 28 2021

@Peter-Loyen I do agree I would want DHCPv6, just not sure it will form part of the first iteration as a lot of MX installs could get by without it. We use DHCP on about 1/3 of our MXs for instance, the others are all gateways for networks where the switches run the DHCP service and as that is per local VLAN it *could* be done via SLAAC in an IPv6 world if needed.

cmr · ‎Jan 27 2021

All of them (when you live in the UK) 😎

cmr · ‎Jan 27 2021

@ZeeBoussaid I'd give VLAN 500 internet access only, so at least people would have something and you wouldn't be risking the corporate LAN. Also make sure you have an HA ISE setup so it doesn't completely fail, as you would with DNS and domain controllers etc.

cmr · ‎Jan 27 2021

@Atags you could perhaps use a fibre connection as a stack cable, the current stacking cables are absolutely standard twinax cables.

cmr · ‎Jan 27 2021

@Atags as the MX250 WAN ports are SFP+, I'd think you'd be best to run a fibre from the NTE to the MXs

cmr · ‎Jan 26 2021

You need this kind of extender: VGA Over IP Extender - 1920 x 1200 - VGA Extenders | United Kingdom (startech.com)

cmr · ‎Jan 26 2021

Edit, scratch that, you have chosen VGA over UTP (CAt5/6 etc.) NOT Ethernet, so it will not work.

cmr · ‎Jan 26 2021

@MrMDStreet It should work fine, what you need to do is: MS220-48FP - port that sender is attached to: access VLAN 75 (just one you haven't used before) MS220-48FP - port that goes to other building: trunk (by default all VLANs will be carried in the trunk) MS120-48LP - port that comes from the other building: trunk MS120-48LP - port that receiver is attached to: access VLAN 75 (well, the same as the first port configured) The sender and the receiver are now in the same VLAN and should be able to see each other. Put them on compatible IP addresses if they are layer 3 (same subnet) or if pure layer 2 it should be working. There are distance limitations with VGA over CAT5/6 etc. but it is a latency/subnet limitation when over ethernet so you should be fine unless your buildings are very far away from each other.

cmr · ‎Jan 26 2021

@Peter-Loyen I'd agree, but DHCP isn't often part of the IPv6 spec as SLAAC is supposed to be used and implemented by default on BT's HomeHub for example.

cmr · ‎Jan 25 2021

I found another guide that still works, looks promising 😎 http://www.virtualizationblog.in/why-we-need-remote-desktop-services-ip-virtualization/

cmr · ‎Jan 25 2021

@PhilipDAth the page you linked to has links that simply return 404s. We use (used before we were closed by Covid) Citrix XenApp on top of Terminal services and the TS agents are always a bit flakey so I'm pretty interested in an IP per session. Have you used it and is it reliable?

cmr · ‎Jan 24 2021

@KarstenI that's exactly one of my questions, in the MX firmware it explicitly states what version older MXs will get when 15.x is applied, but there is no statement in the MR release notes, other than to state which models won't be upgraded...

cmr · ‎Jan 24 2021

Thanks @KarstenI and @rhbirkelund . With the MX/Z they are in their own networks so I'm thinking it is more simple, the MR features looks as expected, thanks for that. @KarstenI Have you been running mixed MR for a while and does roaming work properly. @rhbirkelund I had a beer in Aarhus about 25 years ago and the locals thought I was Norwegian... Good times 😎

cmr · ‎Jan 24 2021

I know that the 802.11ac wave 1 APs like the MR32 and MR34 cannot run the 27.x firmware, but what happens if you upgrade a network with a mix of wave 1 and wave 2 APs? I'm guessing the wave 1 APs stay on a 26.x version, but do they go to 26.8.1 if they weren't already on that version, or do they simply stay on what they were? If a 26.8.2+ version comes out, will wave 1 APs in a mixed network running 27.x be upgraded or will they stay stuck at 26.8.1? Are there any reliability issues running this mix or is it simply that you cannot use some of the 27.x features? Thank you!

cmr · ‎Jan 23 2021

Wireless firmware versions MR 27.6 changelog New Support for Meraki MT sensors - https://documentation.meraki.com/MT (Wi-Fi 6 MRs) Support for the MR44 to operate in "low power mode" - https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR44_Datasheet#Specifications (MR44) Security fixes CVE-2020-11022 / CVE-2020-11023 (All MRs) Bug fixes MR may experience frequent reboots in networks where UNII-1 channels are not supported, such as Bangladesh, Bolivia, Guyana, Indonesia, Jamaica, Nigeria, Pakistan, Qatar, Tanzania (Wi-Fi 6 MRs) Under certain conditions, successful WPA2-PSK connections are reported as failed under Wireless Health event logs (All MRs) MR may experience intermittent Ethernet connectivity issues when negotiated at mGig speeds (Wi-Fi 6 MRs) Scanning API v3 data intermittently did not provide data for some MR's in the network (All MRs) When two clients had an established data flow between each other on the same MR & SSID, followed by one of the clients roaming away from the MR and then back to the original MR, packet loss was experienced (All MRs) MR may send several RTS frames to clients who leave BSS without stateful 802.11 deauthentication or disassociation, resulting in packet loss for other clients in the BSS (Wi-Fi 5 MRs) "Request failed" error shown when attempting to use the "Cycle port" live tool for MR30H LAN ports (MR30H) MR may get into a state where it stops responding to 802.11 probe requests while still sending 802.11 beacons (MR45/MR55) MAC addresses were getting altered, leading to MRs being unable to check-in to Dashboard (MR42/MR42E/MR52/MR53/MR53E/MR84) If a client roamed away and then roamed back to the original MR within 5 minutes, the MR would disassociate the client (All MRs) Beamforming interoperability issues with certain clients resulted in disconnections and/or poor performance (Wi-Fi 6 MRs) AutoTX power may reduce too aggressively, potentially impacting connectivity for associated clients with low RSSI (All MRs) General performance & stability improvements Known issues 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)

cmr · ‎Jan 22 2021

As @GreenMan said if you have major traffic found between VLANs then route on the switch, if most traffic is going via the WAN then route on the MX. Having said that, we route all sites on the switches as the only sites we have with fast enough MXs to not be an issue, the majority of traffic is between VLANs... i.e. a site with 355s and 40Gb inter switch links to a blade chassis has MX100s that only route at 750Mb severely limiting throughput...

cmr · ‎Jan 21 2021

@DerikA you are all good to go then, we have multiple MS225/MS210 mixed stacks and they work nicely, ours are even connected to 3850 stacks, but we use the 10Gb SFP+ ports as uplinks with STP blocking one port rather than using port channels as we don't need 20Gb throughput.

cmr · ‎Jan 21 2021

I'd hope the replacements are somewhat more performant for a similar cost, especially in terms of raw throughout as that would then be a worthwhile improvement.

cmr · ‎Jan 21 2021

@DerikA you can bundle connections together for performance and availability and like the 3850s a single port channel can have ports from multiple switches in the stack. Unfortunately as @DarrenOC said, you cannot stack MS250s and MS210s.

cmr · ‎Jan 20 2021

@timbaker I think it may be one or the other, if you add (32x1+16x10+4x10+2x40)x2 you get 624 whereas if you lose the (4x10)x2 by only using the QSFP+ ports and not the SFP+ ports, you get 544 which is the published switching bandwidth. I must say, I did not notice if any of the SFP+ ports were disabled when I used the QSFP+ ports and am not planning to be at that site for a few weeks so cannot test again for now. If the ports are an or, I would guess that each QSFP+ port will disable the two SFP+ ports on the same row.

cmr · ‎Jan 20 2021

@timbaker I saw that too, but they are separate in the dashboard (ports 49-52 being SFP+ and 53-54 being QSFP+) so I'd have thought that is not the case. I can confirm that the QSFP+ ports work but I haven't yet tried to use both port types at once.

cmr · ‎Jan 20 2021

Thanks @rwiesmann that does work and isn't too bad, but it reinforces the point that it would be nice to have some release notes...

About cmr

cmr

Community Record

Badges