I endorse @MerakiDave's comments and would add.   The requirement when designing a wireless network is to provide an acceptable level of accessibility, throughput and consistent reliability wherever users need wireless access.   This requirement is NOT well served by network designs which prioritise a minimal number of APs rather than meeting the requirement. Far better to have more APs operating at lower RX volumes than fewer powerful shouty APs.   At the end of the day, the success or otherwise of the network design will be assessed by the perceived performance by users. ... View more

@Ahmed83 wrote: although the MX firewall but all the IPTV streaming is not passing through it as it's local on the LAN As the IPTV streaming is limited to the (V)LANs you may get everything to work correctly. ... View more

@Ahmed83 wrote: we are not subscribed to IPTV service, we have our Cisco IPTV solution on premises, so IPTV system is operating on our local LAN, it was working perfectly fine with conventional Cisco 4500 and 2960 switches, but we are now changing our LAN to Cisco Meraki switches. Without any information, I can only say that in all probability, you will not be able to migrate the Cisco IPTV solution to the Meraki platform, if using an MX appliance and MS switches, but, if you are using the MS switches alone, you may be able to configure them correctly. Different flavours of Multicast require quite different configurations.   One can run IGMPv3 through MS switches, but not the MX. ... View more

@Ahmed83 wrote: Hi everyone,    . . . . IPTV system components including Cisco DCM and receivers all physically connected to server farm switches which is then connected to the 2 core switches.   we have . . .  2 different subnets/vlans for set top boxes and TVs. my question is how the multicast should be configured on Meraki according to the best practice including: - Which interfaces should be configured with multicast enabled and which should be configured with querier? Multicast comes in several different flavours.   You have not specified the ISP/provider's specifications for the IPTV services you have subscribed to. Without those specifications, it is impossible to advise on how your network components should be configured. Some varieties of Multicast are not passed by the MX security appliances. ... View more

@Nick wrote: That does sound like its going to require an overhaul if Alexa requires the ability to contact the devices. Which by the sounds of it won't be a small job! If a Chromecast compatible IGMP proxy/reflector were to be implemented on the MX range, then there is every probability that a device on a VLAN other than that which the Chromecast devices use could connect to the desired Chromecast/Alexa device.   It is worth experimenting with enabling the Bonjour gateway   For me, it was more cost effective to use another brand of switch and security appliance to allow the network to be split into two parts - one for the known secure devices, and one for everything else. ... View more

@MerakiDave @BrechtSchamp    I have my Chromecast capable devices on their own VLAN.   A smartphone, needs to be on the same VLAN to control the Chromecast device. However, once the device has started casting, the phone can detach from the VLAN.   At some stage I shall experiment with Bluetooth, although, at present, the IoT WiFi is not Bluetooth aware, but technically the Chromecast devices can use Bluetooth. There are security reasons for being very careful with Bluetooth.   In this environment, the video devices, including Smart TVs, do not stream videos as directed by another device(phone), but rather connect to the internet source directly, at the margin, this allows greater throughput and smoother playback.   Devices which need to access screens, STBs, playout systems etc, use HDMI to connect, not Ethernet. ... View more

@PhilipDAth    Most BT HomeHubs cannot be configured to pass-through, although they can support a DMZ. Similarly, they cannot turn off NAT. There may be a new HH which does all this, but I haven't been offered it. To add to the problems, we have double-NAT. ... View more

@b-lo wrote:  . . . I have the MX64 acting as a Passthrough.  The uplink is to mt BT Home Hub.  My issue is that when the MX64 is introduced to the network it causes some crazy high latency which affects, strangely enough, wirelessly connected devices. . .  It is so bad my Echo, won't even stream music, whilst the MX64 is in the equation.   I am thinking of disabling the wi-fi on the BT Home Hub and using the Meraki AP connected here to the MX,   The questions which occur to me are: Why are you still using the BT HH Are you sending BT IPTV to the MX Are your Echo devices connected to the MX What is your VLAN configuration BT IPTV requires that an IGMP Proxy be configured on the router. You can't do that on the MX. Whilst the MS switches handle IGMP snooping, it may not be possible to configure the MX to pass-through the multicast stream from the BT HH to the MS switch.   I solved this problem, but it required building a second physical network. The second network handles all the IoT kit, guest wireless, multicast playout devices, a/v devices. Lots of VLANs.       ... View more

@hosokawaw wrote: Hi   A question i need configure 1 router with 1 port ADSL. If I consider some model MX i will be coverage ?   regards William Hosokawa Originally I had an MX64 that was connected to the ISP's termination via a modem (Vigor 130 UK model). This was a PPPoE connection. For security reasons and the need to have an IGMP Proxy configured, the MX64 uplinks to a 3rd party security device with 2 LAN ports, one for the MX64 and the other for the multicast networks, IoT, Chromecast etc. The third party security device's WAN port is connected to the original Vigor 130 modem.   Note: confusingly there is both a modem and a router named Vigor 130. The router is sold in the US, the modem in UK and Europe. Do not assume they are interchangable. ... View more

@PhilipDAth wrote: Here is a challenge for you - try and find a client with a 160Mhz capable radio to be able to use it. Nobody asks you that down the pub . . . ... View more

@MerakiDave wrote: Got it, understood. Hang in there, it'll be there eventually but unfortunately I don't have a timeline. 26.1 just because the latest beta but it's not there yet, keep an eye on the release notes though. Please don't go there. It is a waste of time, it performs poorly, it will never be usable because most of the time the channels will overlap, to some extend with the DFS, APC, CAC channels, so there will be frequent outages of up to 60 minutes.   Much better if Meraki devotes more resource to developing 802.11ad networks (including mesh), distance in the 60GHz spectrum is improving all the time. Meshing will work because there is plenty of bandwidth for backhaul as well as connecting to client devices.   The 5GHz portion of the spectrum is overcrowded, there are numerous more pressing use cases than static WiFi, it is headed towards completely autonomous configuration, weighted towards overall spectrum usage efficiency rather than individual requirements. Anybody interested in this stuff should attend the ITU World Congresses. The future of fixed PTMP WiFi is pretty dystopian. ... View more

@EricNathan wrote: Has anyone been able to figure out how to route Chromecast broadcasts from one VLAN to a maobile device on another VLAN? I'm working with an MX64. Rather than "kick against the pricks", because I've been there with an otherwise nice Juniper SRX, I am not going to even attempt routing Chromecast broadcasts on an MX, because the MX is deficient as far as Multicast and IGMP Proxies/Reflectors are concerned.   In fact there is no way to get an MX to handle the flavour of multicast used by content providers to distribute programs (subscription TV).This is commonplace in Britain, Europe and much of East Asia. It is not commonly encountered in the US, although I'm aware of some services that use IP4 Multicast that requires the use of an IGMP proxy on the router in the subscriber's premises.   Chromecast also uses Multicast. Routing multicast requires feature enablement on the MX which has not occurred despite repeated requests. Strangely, the switches do handle multicast traffic properly (IGMP snooping).   The good news is that there is a solution.   We installed a security appliance, switch and WiFi access points and VLANned the heck out of the new network, as it is designed to handle all the goats and bad boys - smart appliances, smart TVs, security kit, Chromecast, Bonjour, guest WiFi etc.   Instead of connecting to the VDSL modem, the MX now connects to a LAN port on the third party security appliance, which passes the MX traffic through to the Internet. Rather than allow devices (typically phones) connected to a MX VLAN access to the third party network, I grabbed some smartphones that are now used as if they were remote controllers for Chromecast. I'll admit it is an affluent solution to an affluent problem. They can be switched off once the Chromecast device has started casting.   This works, security is improved, We have not had a repeat of the power company's smart meter trying to get to the Internet (which is what kicked off the redesign in the first place).   Interestingly, I have a neighbour who turns off his computer system at night, including the router/modem. This causes his smart TV to try and get to the internet via our guest WiFi network, all night. This turned up on an exception report and it has been permanently blocked, although it keeps trying. Smart TVs do the weirdest stuff. ... View more

@jdsilva wrote: Yeh as @Uberseehandel  is alluding to, you're likely using an unsupported SFP. All Meraki devices with SFP ports support a variety of fibre based SFP's. You'll need to ether use the genuine Meraki or Cisco parts, or find a another compatible SFP. When I was having issues with another manufacturer's 8 PoE +2 SFP switch, I discovered that the switch used generic Broadcom hardware. Now, I have the two switches next to each other, the similarities are striking. It would make total sense to use Broadcom hardware for a small access switch. I like these switches because they are silent. They have some drawbacks in common.  Neither is ideal if handling even rudimentary multicast video streams. ... View more

I use a copper transceiver in the SFP socket of an MS120-8 FP, with no issues. It uplinks to an MX. The same transceiver has previously been used in other manufacturers' equipment without issues.   SFP module AVAGO - 1000BASE-T: 1.3 Gbps (Part ABCU-5710RZ-HP1, Serial: AN10019Z61 ) ... View more

I tested and all was fine. It may be that because all servers and storage are in the Cloud, that everything got tidied up when that was implemented. About the same time, I also did a lot of tuning to minimise delays from mismatched packet sizes and recall some changes were DNS related. I am overdue revisiting the packet size mismatch issue, as some network devices can now handle packets up to 9K in size, and the last time I addressed this issue, activities such as using the browser had become much more snappy. For anybody else considering diving into the murky waters of MTU and MSS, I would advise them that manufacturers define frame sizes differently  (Cisco uses different standards for different OS), so take nothing for granted. ... View more

Are you using Anaconda or Miniconda on the mac? Try the one you are not using. I expect serpentine labyrinths when playing the snake charmer these days. https://conda.io/docs/user-guide/install/macos.html  ... View more

@Silas1066 wrote:     So I created VLAN 101 and assigned the uplink to 192.168.101.10 /24 I then created a SVI interface 101 on the switch with an address of 192.168.101.4 , with a default gateway of 192.168.101.2 (the MX)   A little counter-intuitive,   . . . It is counter intuitive, but not for the reason you gave. 101 is reserved in many networks for a good reason. Think about it, hint, Big Brother is watching . . . ... View more

@Daghan wrote: I think that is a great suggestion, I'll make sure the community gets regular updates. Sadly, regular is one of those warm fuzzy words that doesn't actually mean anything.   In case the engineers have overlooked it, how is development of the MX's Multicast capability, and most importantly, an IGMP Proxy because more and more content providers are depending upon this for distribution to end users. Any number of home networking routers can handle this, why not Meraki? ... View more

That does look good, thanks for the url.   Eventually it will be incorporated into rack that is designed for "show", rather than efficiency. Chrome keystones with OCD patch cables - a nightmare to make it up, but it will be on show when it is finished, 2 brands of hardware running split networks and apart from Ethernet, there are HDMI, and Thunderbolt/USB connections (along with some audio). Flash, but not cost effective.   ... View more

MX65 - 256mm x 132mm x 25mm   MX68 - 284mm x 178mm x 27mm   So WIDER, DEEPER, THICKER, (I mean the MX68). ... View more

@PhilipDAth wrote:     For example, without looking, what does this symbolise?     Your thoughts?     I think I have something like that on my toaster (Dualit)   ... View more

Yes, the MX works perfectly well with BT Infinity. I have used a Vigor 130 modem in bridge mode to connect the MX to the Open Reach termination box.   However, unless and until I see it demonstrated, I say that the MX cannot pass the BT variety of multicast (BT Sport etc) correctly. Don't waste time trying to make the MX handle it.   The way I solved the problem was to put another security device between the modem and the MX and have that device direct the multicast stream to the appropriate devices.   It helps if the other security device can disable NAT on the port it uses to connect to the WAN port on the MX, although it appears not to be mandatory in most cases.   ... View more

@LarryS wrote: Scouring some of the posts here, looks like there might be a beta that has multicast.  I'll see if I can get that going.  Which beta is that?   To get multicast to work in my environment I have had to put a third party security gateway ahead of the MX. This additional security device routes the Internet originated multicast encrypted stream to a playout device that is compatible with the stream architecture, via a switch that can be configured for IGMPv3 snooping (don't want to flood the network).   An unexpected bonus is that using this architecture one may keep all unsafe devices(think anything "smart") away from the secure network protected by the MX. There are several devices connected by HDMI cables that bridge the two environments.   Is there such a thing as a "smart" device? I doubt it. Is this just a domestic issue? No, we are already deploying smart lighting and similar in commercial environments. ... View more

If you must use 2.4GHz then ONLY USE BANDS 1, 6 AND 11, otherwise you will have problems with interference between the different and overlapping channels. Remember there is a lot of other kit around that uses the 2.4 GHz band.   Experiment with turning the radios' transmission volume down as low as possible, consistent with coverage requirements. Shouty APs cause operational problems.   Some laptops don't have 5GHz????? Are there any left that old? Worst case put in PCMCIA cards (remember them?) or some kind of USB or USB to Ethernet dongle so that 5 GHz is available.   ... View more

You may find it helpful to read the Mesh Deployment Guide.   Also, disappearing SSIDs are often a consequence of DFS functioning correctly, radio volume is adjusted by APC and the duration a radio is off-air is determined by CAC.   I wonder if the deployment has been validated, in the field, by a Meraki engineer with an appropriate background. ... View more