delete it and recreate it ... View more

I've found the gnome (top left) ;-[]     ... View more

I started to post a screen shot and then saw you had posted already . . . duh Who is the guy on the left? ... View more

He's a gnome on his gnomio - he's looking for an appropriate buddy (its SF - no gender assumptions)     ... View more

@Antohinf wrote: Thanks I will look into this a little more now!   So my setup needs to be ISP router --> Meraki AP ----> Meraki AP(SHED) --> Cisco 3560 switch --> VIRL Server The problem with doing it this way is that performance will always be compromised and, depending on how close your neighbours are, throughput is likely to be variable. Using PTP tech to link the man-cave with the ISP router, throughput will be more reliable, more resilient and faster.   You haven't indicated what the distance is between the cave and the house. Or what other Wi-Fi is active in the area.     ... View more

@PhilipDAth wrote: Yes. All stand alone Meraki APs can do this using MESH mode. https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Mesh_Networking But,   It depends on range, and meshing can restrict throughput.   There are two other options Use a point-to-point wireless link (3rd party inexpensive) between the house and the shed Fit a powerline adapter, modern ones have much improved throughput, using the existing power cable.     ... View more

I thought they were ZZ Top   ... View more

Hi You will find helpful information here - https://www.draytek.co.uk/support/guides/sky-mer-setup-guide    I have different problems with BT TV Sport, which uses a form of multicast that is not currently handled by MX devices. My solution is to put a Router ahead of the MX and have the TV multicast connection bypass the MX. The MS switch does handle everything correctly.   There are cheaper solutions from the likes of Billion and Asus, but this one offers a lot of flexibity as far as NATing goes, IPv6 etc. and there is an option to have a LTE modem built in, for failover.               ... View more

You may need to check if there is a need for devices on the internal VLAN to directly access devices on the IoT VLAN. Which will result in another requirement. Depending on what is being done, connecting remotely may not always achieve what is required. ... View more

@SAU wrote: I have 200 APs on a small university campus, most in dorms. We have a number of students that think it is a good idea to bring in their own wireless routers. I have contained most that are not smart enough to rename the device but a few sharper ones now name the device similar to their phones so it is harder to find them in the Rogue/other SSIDs list. What is a reliable way to prevent these devices from accessing the network without containing all Rogues? I don't know what effect containing all SSIDs would have on the Rokus and Xboxes, etc.   Thanks for any suggestions In the long run, it might be simpler to find a way of accommodating the students' need to use their own routers. If they are bringing in their own devices because the service being offered is inadequate, then it will be more productive to address the shortcomings, than start a fight that ultimately the administration will lose.   If the students are doing it to wind up the administration, it sounds like they are winning.     ... View more

err - audio and video ... View more

@MauH wrote: Interesting, if you end up giving this a try please let me know if it worked. If I can get some of this cast devices I will give it a try myself. Mau   I will get onto this before Christmas. At the moment, all the sound and audio Chromecast capable kit is Sony, which is a broadcaster standard. I just love the way that once I set up casting, the smart device can be turned off and the cast continues. So, in the first place I am looking at having small personal devices for audio casting and will be testing the Bang+Olufsen BeoPlay M3. For testing purposes, I suspect a Google Chromecast dongle would work. It has options that allow one to do 4K video and also to hardwire everything, rather than Wi-Fi the link to the internet.   Incidentally, the IP address scheme should read -    Sec VLAN   - 192.168.20.0/23 (IP range 192.168.20.1 - 192.168.21.255) DHCP 192.168.20.11 - 192.168.20.255 VLAN ID 20 MX 192.168.20.1 Insec VLAN - 192.168.21.1/24 (IP range 192.168.21.1 - 192.168.21.255) DHCP 192.168.21.11 - 192.168.21.255 VLAN ID 21 MX 192.168.21.1     ... View more

@MauH wrote: Hi @Uberseehandel,   Depending on the type of casting device you use there will be a limitation from where you can cast. As far as I know Chromecast wont let you cast if they are on separate VLANs (different broadcast domain).  Mau Thanks for that. I'd noticed that behaviour already, hence my idea of setting the VLANs up as follows -  Secure VLAN - 192.168.20.0/23 (IP range 192.168.20.1 - 192.168.21.255)  DHCP 192.168.20.11 - 192.168.21.255  VLAN ID 20 MX 192.168.20.1 Insecure VLAN - 192.168.21.1/24   (IP range 192.168.21.1  - 192.168.21.255)  DHCP 192.168.21.11 - 192.168.21.255 VLAN ID 21  MX 192.168.21.1   The idea being that the devices on the secure network (VLAN 20) see the cast capable devices as being in their broadcast domain, but the insecure cast capable devices do not see the members of VLAN 20.   In effect, what I am looking to do is set up a series of "security zones", and control the interactions between the zones.   The reality is that as the use of IOT devices becomes more pervasive, there are going to be reasons to use known insecure devices as well as devices whose security status is protected, and have them interact with each other. So from a smartphone one can set up casting by an internet connected speaker or monitor/tv, or control a door lock, or interact with the known high security risk "smart" meter the power utility insists on installing.    I'm concerned that if I set up this overlapping VLAN scheme that it might have unintended consequences.   Thanks again.       ... View more

@DAHG wrote: True to a certain degree. The manufacturer can't test all environments. Beta is supposed to be ~90% there. Nothing wrong with releasing Beta. Once a Beta release has been out for a while and no major bug reports are coming out, then you release a RC. A RC is supposed to be production ready code. That should attract more customers to load it. Wait a bit, if no bug reports come in, release it as Stable. Have you spent your entire life drinking the manufacturers' cola?   I can't even begin to express how many ways what you say is wrong. But I guess you are used to it, and have no expectations of anything better. To be honest, software development has gone backwards over the last 40 years.     ... View more

@DAHG wrote:     I've loaded plenty of RC and Beta releases on non-critical systems. I don't have the luxury of having non-critical firewalls. Today's reality is that one needs to use test environments that accurately reflect the production environment. In the next 18 months being able to point at how the manufacturer classifies software releases will no longer serve as a lifesaver in a CYIA defence. I've always worked with critical systems, what the manufacturer says is immaterial, the onus is on us to get it right.   ... View more

@DAHG wrote: I'm sorry, but that is hogwash. I've been in IT well over 35 years, and over 15 of those of software development. There is a difference between Beta, RC and Stable. There are a lot of industries that are prohibited from running anything but Stable.   If Meraki thinks a firmware version is ready, then move it to the Stable track. It isn't just a Meraki thing, it is a West Coast/Industry thing. The continuous drip-feed of software/firmware features which is being adopted by more and more manufacturers, means, in reality, that testing has been moved to the users, and we don't get paid for it. To be honest, Meraki is comparatively good - compared to Juniper, MS, Apple and . . .   I blew my stack at a huge software/hardware co earlier this year and ended up talking to real people just below the  C-level. They admitted that they had just the same problems I was having, like losing access to storage accounts . . .     In networking, this means that one has to have a test lab, and make one's own mind up about which releases work in the environment into which they will be released into. Not ideal, but better than getting exasperated.   I think if one is running alpha/beta software, one should be given testing scripts and have a formal system to interact with to records results and track faults. ... View more

Hi Tony I have some mobile applications for the Z3. If we do not use the Poe capability, what specification power supply can we use? Thanks ... View more

@marhill2 wrote:     Ubersee -  . .  . Also most Cisco boxes are complicated to setup when it comes to IPTV from a service provider, at least it was for me when I had AT&T Uverse. My work around was just to include the IPTV boxes into the native VLAN 1 and they worked fine.    Marcus   Thanks for your suggestion. I guess there are a number of ways of implementing multicast, and the Far East, Europe and North America do it differently. Despite being told by Meraki support that the MX won't handle BT's flavour of SSM IP TV, I have tried setting up some firewall rules, without success - e.g. an outbound rule that allows anything to 224.0.0.0/4, 109.159.247.0/24 (the ranges used by BT). Testing is simple, I use VLC Media Player on a workstation and then rtp://234.81.130.4:5802 - which is the unencrypted test channel. I know the switch is OK as I have used it with the BT POS "HomeHub" and it works.   All this is slightly more difficult for me as I'm not a network engineer, although I have several MNO clients, I tend to do strategy, Informatics and projects, so there is always somebody else to look after the configuration side. But I did quite a lot of packet capture and sent them off to the support folk at one of my previous Bay Area stack suppliers, to no avail.   By one of life's ironies, sitting in Meraki's UK office is the engineer who set up how the IPTV box was to interact with the multicast streams and all the required network infrastructure, unfortunately he is fully engaged working on the UK government's sclerotic IT infrastructure and heading up the Meraki phone technical side for Europe (can't come soon enough).   Cheers   ... View more

The MX/Meraki system could be really excellent as a home system, but it doesn't do Multicast properly which rather nixes home deployment as far as IP TV from SSM content providers. For parents, the ability to control the kids' mobile devices is ace, as is the integration of CCTV and VoIP.     ... View more

@marhill2 wrote: Its tough getting used to a GUI based platform when you have been in the CLI for so long. It's probably more difficult than giving up smoking. But worth it, as mostly fewer typos. ... View more

@ccnewmeraki wrote: Well, SSM is just a term for IGMPv3 over IPv4, or MLDv2 over IPv6. With IGMPv3 the router and end OS all have to take part in the multicast group, so it's router and OS dependent. ASM (the older, more usual form of multicast) uses IGMPv2 or MLDv1. It sounds like the problem is that IGMPv3 isn't implemented on some of the non-ISP provided routers you have tried. I can't find any info claiming that the MX range does implement this, so it's likely this is the case. https://documentation.meraki.com/zGeneral_Administration/Other_Topics/Multicast_support#IGMP_Support_on_the_Cisco_Meraki_Security_Appliance "MX Security Appliances will forward IGMP traffic for a single broadcast domain. It does not forward multicast traffic upstream, between VLANs, or over a VPN." This sounds to me to be talking about the older ASM IGMP versions, not IGMPv3 / SSM. I'd still suggest trying the ISP-provided router (which will implement IGMPv3 for your network) for the NAT, and use the MX in bridge-mode (which as long as it doesn't have a firewall rule in place shouldn't block the traffic). You don't lose any MX advanced security features in passthrough-mode, it will still provide client tracking, AMP, IDS, AV, and firewall capability to your devices. Hi There is more to it, than you are suggesting.   Meraki claims to be able to support multicast, including SSM, on the MX. But when I lodged a support case they came back stating that it is not supported as the TV broadcasters are using it - which is a specific IEEE standard, that many US suppliers do not implement, for whatever reason. I only use modems that are certified BT compliant. The MS is IGMPv3 compliant, the MX is not, in this context.   To quote Meraki -    Cisco Meraki security appliances can pass IPv6 traffic in pass-through mode, but no traffic analysis or manipulation is possible when using IPv6.   The irony is that Meraki employs as an engineer the person who developed how this form of SSM was to operate whilst previously employed by BT.  So they know how to do it, but when they get round to it, who knows. Korean, Japanese and Taiwanese manufacturers know how to make this work, but then they have very advanced networks, beyond steam punk.         ... View more

@ccnewmeraki wrote: Have you tried the MX in passthrough mode rather than NAT mode? (I.e BT Router > Meraki MX > Switch) The meraki support page for IPv6 States: https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility "Cisco Meraki security appliances can pass IPv6 traffic in pass-through mode" Hi   The problem is that Source Specific Multicast, as used by content providers  (aka Broadcasters), is not correctly handled by the MX, it isn't an IPv6/IPv4 problem, BT is running its Sports channels (including 4K) on IPv4, I don't know if they have added IPv6 support to the subscription channels, although Meraki's Dimitrie Sandu should know the answer to that. In any event Teredo tunnelling is being used, at least in my part of the network.   I considered trying the IPv6 approach, but some of the MX Advanced Security features are lost.   So I have ordered a Draytek 2862-K router which does handle BT SSM correctly. If the trial goes well, I'll consider switching to the 2862 with LTE failover built-in. The router has other capabilities, including running RADIUS and NAT flexibility, which could simplify small deployments. I shall run a cable from the router to the switch and out to the STB on its own VLAN. The switch handles SSM fine. All other traffic will go from switch to MX to 2862, least that is the plan . . .   Thanks for your interest, its good to know I'm not shouting in a vacuum.   ... View more

I'm not sure if it is a Bay Area or a West Coast thing.   But, Meraki is the third network equipment supplier I've used this year (its not over yet) that bangs out "nominally" tested software fixes, under the label "beta" and then expects users to put them into production. One of our major software suppliers from a little further north of the Bay appears to have given up on end-to-end and user-acceptance testing. I'm fed up with it.   Way back when,  we kept a Test Factory that ran two and half shifts per day, seven days per week. This sort of discipline seems to have gone by the board in recent years. I'm told it is all in the name of progress and what the customer wants.     ... View more