Cisco Wireless 9174 Series Access Points: Delivering high-speed, reliable connectivity for modern applications that can’t tolerate downtime; designed for demanding environments like healthcare facilities, hospitality, manufacturing floors, and large office campuses. This enterprise-grade access point offers tri-band support (2.4 GHz, 5 GHz, and 6 GHz) with both integrated omnidirectional and external antenna connector models, allowing the CW9174E to adapt to unique coverage scenarios and support mission-critical wireless needs. YES YES YES FINALLY an external antenna model! Now we still need an outdoor model that is not the stadium model. And we need one that can supports 2 separate antennas like the C9120AXE and C9130AXE can with the DART connections. ... View more

Not yet, but I don't have any customers running 17.18 yet. I assume the option will only be visible if you have catalysts running 17.18? ... View more

The design where you have SD-WAN via 1 interface and then use a private WAN solution and route via a LAN port of the MX will work but without SD-WAN features. This means the MX will always route over the LAN port unless that route is no longer available. So you can have a ping probe from the MX that will keep the static route alive. So yes you will having routing via the E-LAN but you want be able to route based on latency, jitter, loss as you would if you would have if you connect the E-LAN to the WAN2 port.  So if you can have one E-LAN terminate at a location with a router to the internet to have your VPN registry connection then you could do a true SD-WAN. ... View more

In Meraki SD-WAN appliances you are only able to translate your internal subnets to avoid overlaps with your own networks.  This feature CAN be used to translate your own also to IPsec peers however the other side must translate it's own subnet if they have to be unique to you. If this is not a possibility but you still want to use Meraki SD-WAN for your own WAN then you must use another type of device that does support NAT in any direction like a Cisco Secure Firewall, Cisco Secure Router or a third party device.  Then from the Meraki SD-WAN part you can just route to that device for the remote subnets and make that subnet available over the SD-WAN so all your branches can reach it. ... View more

Hey guys, it is important that you check the actual MAC address in the event log!! It happens many times that one device is using multiple mac addresses that are just 1 digit higher and then that gets pushed to the same dashboard client.  And if that client is identified by it's MAC address then you get that flapping with the same client. I have seen this behavior many times with Synology NAS devices if they are not using LACP (802.3ad) to load balance their upstream traffic.  Then it continues to send traffic using one mac and the next packet with the next mac. ... View more

Then don't forget to enable IGMP querier in the interface settings. ... View more

It has happened before that the name registration takes a while.  Like 30 minutes or so. Usually the first time a MX network comes up the dynamic-m address is available within a minute. Always make sure you test different dns servers. If it still doesn't work, you can try by disabling and re-enabling the feature on the MX status page.  Or by changing the name. If that doesn't work then you'll need the good ol' support. ... View more

I'm curious since TLS decryption is available on C8xxx routers in SD-WAN that they will once again try to make that available in MX mode. ... View more

In any deployment that uses multicast to go from server to client you require IGMP on the switches AND you require an IGMP querier. So you have 2 options depending on your setup. If your multicast transmitter and receivers are on the same subnet and the same VLAN ID then you could keep your routing on the MX.  However your switch which must either a Catalyst or a routing MS switch that supports either IGMP querier alone or full PIM-SM.  And give it an IP in the same subnet as your deployment.  Then you can enable the feature. Important note however that it is IGMPv2 that is supported and fast-leave is not supported in MS switches.  So if your setup requires it then you would need Catalyst switches running IOS-XE with optionally cloud management: source device configured. If however the source and destinations live on different subnets then you need full PIM-SM routing and then you require at least MS250 or Catalyst switches and the routing for both subnets must be done on that switch then. ... View more

Does your video system work with multicast? If it does then you will need to put the L3 boundary of the network on the switches and run IGMP querier on it. If you need PTP then these switches aren't the correct choice for your deployment. I'm quite sure your stream would work perfectly fine if both transmitter and receiver is on the same switch but starts to cut out on different switches. ... View more

Have you done a show run in the cloud CLI to see how the exporter is setup? ... View more

I'm not sure how 17.18 handles it but in 17.15 the Meraki numbering is totally disconnected from the Cisco numbering.  So you could have switch 1 be switch 4 in IOS-XE.  In that version at least you can't renumber your switches on the Cisco side so I'm not sure how it will  handle the modification. ... View more

Yes I have seen it.  I'm surprised they kept the Meraki OS for this one and not go full blown IOS-XE. This makes me wonder If we'll get any of the wishlist features we so desperately need. ... View more

If your traffic traverses autoVPN then my question would be.. do you have 2 ISP's per branch or only 1? If you have 2 you can monitor latency, jitter and load on both lines and even have performance based uplink selection.  The way you monitor this is by going to VPN status and on the bottom side of the page you get the uplink decisions list.  If you have multiple links you can just click on WAN1 or WAN2 on any of the packets going towards the hub you want to check against.  And then you will get that page where you can see the stats between your local MX and remote MX on both uplinks. Alternatively if you want to analyse per packet and CONSTANTLY.  Then you'll need to have two capture devices and do ring buffered captures on both ends of the VPN.  This means you'll have to mirror the switchport going to the MX'es on both ends.  This is laborious but will yield honest and precise results. ... View more

Personally I can't imagine myself staying on the CS train. Disregarding a few dashboard features that are not yet available on 17.15.3.1 or beyond you get better insight into potential issues where you actually need some CLI output to verify.   Dashboard is great for checking endpoints, but checking the device operation is way better if you have cli access. Having said that, nobody is pushing yet to move away from the CS train. ... View more

You have to consider the site 2 site traffic as being another ZONE. So the regular L3 firewall including overriding group policies will not apply to site-to-site traffic. You have to define those separately on the site-to-site vpn page. Advantage is that they are org-wide so you can really structure them from spokes to hub and have single rules containing many sources. ... View more

It is obviously co-term since that one enforces the unified license tier. On the Organization -> licensing page you will see the MX product licensing tier. This will be set to advanced security since your other MX has that license. You cannot mix and match MX license tiers in the same org when using co-term licensing. So you have a few options:   - If you DON'T use SD-WAN between the sites, then create another org and claim the MX and license there and just manage 2 orgs.   - If you DO use SD-WAN between the sites then you will have to make a choice.  Either return the enterprise license and get an advanced security license, OR downgrade the current advanced security license of the other MX device(s) in the org.  You will however lose all IPS/IDS, AMP and content filtering options and you will not gain any license periode this way. ... View more

I also have an update on this kind of issue. So at that customer I used my ekahau sidekick connected to an iPhone to test what happens since phones are more susceptible to this issue but it does happen to all devices. So when your device starts roaming frequently, even to the same AP on a different band the AP suddenly stops forwarding traffic.  The client then actually shows a link local IP 169.254.x.x and either stays like that for one to a few minutes or if you roam to another AP it usually starts working again. It's like the AP is temporarily blacklisting the endpoint like you would have on a Cisco controller. Support is still stonewalling me and lecturing me on different antennas and coverage issues... which is annoying. ... View more

Isn't Meraki supposed to be simple? There is nothing obvious about those health checks automatically making routes and having your traffic selectors set to 0.0.0.0 0.0.0.0. Just give us the option to make the VPN route based explicitly. I see when you choose BGP you can have those fields where you set the tunnel IP's, why take it away when doing static? As said before the whole IPsec VPN configuration must be overhauled from the ground up. It is difficult that you can't choose source subnets per VPN.  That you can't only NAT for one tunnel.  That you can't filter BGP incoming and outgoing entries and that you can't have inbound VPN firewall rules. ... View more

And please start supporting outbound filtering on that BGP session and/or static routing 😜 ... View more

Jep, Sonos is networkwise quite garbage and can even cause network instability because even when they connect with Wi-Fi they sometimes also forward over their wireless backhaul and that behavior can be different per firmware version! Most of my customers connect them wired and we haven't had any issues of them communicating to each other. I believe they use 239.255.255.250 which is the uPnP address to talk to each other.  Make sure you have multicast to unicast conversion set to on in your network (general settings) or else that will cause pains with lost multicast frames. ... View more

Since you are talking about different ACL's you are probably talking about another platform type. Which means the problem is getting the logic out of the original platform. The site to site VPN rules are best used when you have centrally located resources that many branches must be able to reach.  In that case you must be able to identify those central resources and ports they are listening on through your existing ACL's from each location. Then you need to make rules where the destination are those central resources but the source is a group object containing all the sources that make use of that service.  I usually make one rule per source VLAN type (example printers). And at the end of each source vlan group end with a deny RFC1918 group rule so you deny them access to any other private subnet anywhere in the org. ... View more

Maybe you should mirror that downstream port to another port on the MS switch. If the moment you connect that Unify and you see many repeated packets you are probably having a loop downstream and need to fix that first. ... View more

Since it can do less than ISE I would assume those per seat licensing would also cost less? 😜 I'm looking in the direction of the ISE essentials licensing as a guideline. ... View more

Yeah I thought so.  I see they have changed that document. Lucky.  Because requiring advanced licensing AND per seat licensing was going to be a disaster to position this to customers. I would have liked however that they would still have kept the no seat licensing required with advantage licensing since that would have truly pushed the value of advantage.  Only having adaptive policy and two other niche features is not really an incentive to get advantage imho. ... View more