If you only need wireless behind one internet connection it's usually better to use an MX appliance (which can do PPPoE) that has wireless on board MX67W. ... View more

The feature is there, but it seems if you are not using a physically separate mgmt network to reach the cloud you won't be able to set your access switch uplinks to loopguard.  It will yell at you if you try to 🙂 I have yet to justify costs for extra SFP's and fiber connections to each access layer switch for a separate oob network... ... View more

BGP on MX appliances is only meant to import the routes of a site or datacenter into SD-WAN and vice versa to have site subnets available to BGP peers in a HQ or Datacenter site. ... View more

According to the datasheets all switches have a backplane switching capacity equal to the sum of all max portspeeds x2 so that should be non-blocking. The only scenario I can think of is when you have several stackmembers and you oversubscribe interswitch communication. ... View more

It's simple: Does your computer know when it is receiving TCP data from a webserver that it is passing 12 routers on the internet and perhaps passing through an MPLS network?  No it does not.   Your computer if it is connected with a wire uses ethernet to talk inside it's own network which encapsulates IP if it is an IP packet.  It does not speak MPLS or VXLAN or LISP or GRE or whatever might be used upstream.  That's the whole point of using the TCP/IP and OSI reference model.   To give you an example like your case: You have a Meraki switch that will serve clients on a network and the router/firewall or whatever intermediate device is a VTEP.  The Meraki switch will send UDP packets to it's known Meraki cloud servers upstream towards it's default gateway (so that is UDP inside of IP inside of ethernet).  Then the upstream device takes that packet and sees that it needs to send that packet across it's VXLAN tunnel to the VTEP at the other end.  So it encapsulates the ethernet frame inside a VXLAN header and slaps another UDP + IP + ethernet on that and routes it towards the other VTEP. That VTEP then decapsulates the outer headers to reveal the inner packet and sends it on towards the end firewall or gateway towards the internet so the switch's packet is forwarded in the direction of the Meraki cloud. ... View more

Servers, clients or other devices (like a Meraki switch) only use IP to reach other hosts or the internet. They are not aware if their traffic is encapsulated inside a VXLAN header.   So in this case you should be fine 🙂 ... View more

In one armed concentrator mode you only have one uplink, so you can never experience a dual active issue if a VPC peer switch would fail because both up and downlinks would be gone on a single appliance.   However VPC is in itself cannot be used in this case because the MX does not support port-channels. Individual links to both MX'es is okay though. ... View more

The pattern is way more spherical than the MR33. For the MR33 there is a huge difference how you mount it. If there is a 6 dB difference then you effectively double or halve the usable distance in that direction.   By the way the charts on the datasheet are still wrong. On the right the keep messing up their X and Y planes.  I would like for someone from Meraki to finally fix that. ... View more

Nice Bruce, you seem to be the only one sofar that mentions the important fact that the VLAN needs an IGMP querier for IGMP snooping to work properly. This is another case for keeping user LAN's behind a coreswitch instead of directly terminating it to the MX.   I'm curious if the Meraki switches behave correctly in this regard if you would let your management VLAN layer 2 through the coreswitch onto the MX if multicast packets are not flooded across the L3 interfaces into other VLANs. ... View more

I remember Batman saying to Mr Fox about the tumbler: Does it come in black? ... View more

Hmm I believe that last part is a little hard because you can have a multitude of switchtypes in one single dashboard network.   Maybe a pop-up like the QoS and stormcontrol pop-ups you get when you have MS1x series switches in your network would be a better choice.   It's easier to check if something is then to check everything for something that isn't. ... View more

I have used ASA's before.  I haven't seen zones being used for routing??  Only interfaces. ... View more

With zones you are not referring to zone based firewall but rather VRF's then? I don't believe the MX has been designed with multitenancy in mind. Although it's strange the high end models have so many ports it almost begs for this feature. ... View more

The difference between 225 and 250 is clearer than for example the difference between 250 and 350. There is no feature difference, only a larger CAM table and many more interfaces (don't know why so much) and a wider stacking bandwidth. ... View more

If your inner traffic is not tagged, your outer traffic will not be tagged to. Please make a capture on the final switch right before the packet enters the LAN interface of the MX. Or make sure you have rules in place to tag the packets at the MX. ... View more

The feature I find lacking in the MX traffic shaping rules is matching on existing DSCP tags. It's better IMO to give corp laptops QoS trust and let the client itself apply the tagging. Since Teams uses the same source ports for voice like skype4b and the same source ports for video you can easily build a GPO with a netQoS policy that adds support for these. However the voice part which is using UDP 50000-50019 should already be tagged DSCP EF which should be matched by the MX when you use default QoS rules in the realtime queue. Btw normal strategy for video conferencing uses AF4x PHB, not the high throughput AF1x. ... View more

Isn't the MDS line the SAN switch line instead of the Nexus which is more ethernet LAN? I can't seem to find any exact buffer numbers only buffer credits which I am unfamiliar since no dc guy 😜 ... View more

Oh I didn't know that.  Is that written in the documentation somewhere?   So if I follow the logic: The limitation of the OSPF implementation on MX is that they don't support multiple interfaces. Since concentrator mode only has one interface and NAT mode without VLANs basically has one inside interface. So it's not just some weird rule that you had to use concentrator mode for OSPF. ... View more

Yeah it's a strange brain knot someone had when designing the GUI.   It would make more sense to have an upstream diagram and a downstream diagram. What we have here is downstream traffic and total traffic.  So if you squint you can subtract download from total and get the upstream traffic. ... View more

I like how the ASA decouples NAT from everything else. It does make it alot more complex to configure if you have an involved config but you can get by most use cases.   Cisco remains an aeroplane cockpit with loads of buttons and possibilities while Meraki is more like a remote controlled car with a stick and a few buttons. ... View more

The port will negotiate the standard it will communicate on. So if you would have access to the standard specification of 1000BASE-T you'd know what MHz the transmission will be at. However if you go up to speeds like 2.5GBASE-T and 5GBASE-T and 10GBASE-T you'll see the MHz going up. So if you look at Meraki models like the MS350-24x or the MS355 family and most of the MS390 family you'll see support for the higher speeds and thus the higher MHz too.   https://en.wikipedia.org/wiki/2.5GBASE-T_and_5GBASE-T ... View more