Meraki

GIdenJoe

It depends greatly if you are just using layer 2 on the switch and only have the 1 SVI for management purposes versus doing full routing. In the case of just doing L2 you shouldn't have any problems. Just create the initial interface with the default route. However in routing I have found that uac sometimes can mess with the default route if uac chooses a different interface for downstream subnets.

GIdenJoe

Hmm, indeed once your design asks for distribution switches that are physically separated you need 9500/9600 with Stackwise virtual if you want to keep a simple layer 2 design. In your case by using 9300's this is no longer possible so yes having a spine-leaf architecture with a EVPN fabric would be an option.

GIdenJoe

On the MX family datasheet found https://meraki.cisco.com/product-collateral/mx-family-datasheet/?file The last page has a section on the model mapping to their t-shirt size licensing and there medium and large still refer to MX67, 68 models what should be MX75/85 and 95/105.

GIdenJoe

To even further my point: If you look at the license naming you will see these two devices marketed as small: So according to the subscription t-shirt sizing these are the small tiers and we already have the XL tier. So to complete the set we will need new medium and large tiers 😉

GIdenJoe

Yes the 192.168.1.4 will be the next hop for your Fortigates to reach the inside networks. So while the individual MX'es have their own IP's, These IP's will only be used for cloud management and the uplink testing because you enabled the vIP feature. This means the active MX firewall will respond to ARP requests of the Fortigate on the 192.168.1.4 address. Usually the virtual MAC consists of a Cisco OUI and the last 24 bits are derived from the 24 bits of the primary firewall. It may also be a good idea to disable NAT on the WAN uplink of the MX.

GIdenJoe

This is another case why Meraki needs to make the disable client sampling on specific ports configurable instead of the only excluse uplinks at it does now. In many designs you have 2 internet providers on opposite ends of the campus where you can't just use dumb switches between the ISP router and the MX WAN ports due to no fiber supports. So then you need to be able to pass that traffic on the same switches but on a dedicated WAN VLAN. For these ports we should be able to disable the client sampling feature.

GIdenJoe

Yes there are some posts on this community where Philip explains how you can use SAML attribute claims to add a SAML attribute named "vpnpolicy" which then contains the string that matches the name of a Meraki group policy. You will however need to have Meraki support enable the Client VPN SAML group policy feature. Please refer here: https://community.meraki.com/t5/Security-SD-WAN/AnyConnect-SAML-Group-Policy-assignment/m-p/137691

GIdenJoe

Throughput of newer generations is always alot higher, so I only take the form factor and port layout into account which is identical to the MX67/68 models which for me is enough to place them in that category. The 50% listprice pricehike is probably more to put it in line with Cisco pricing which is usually higher but I think that subsequent models will be around the same of this model at launch.

GIdenJoe

The C8111-MX is a direct replacement for the MX67 while the C8121-MX is a direct replacement for the MX68. The models even look like their predecessors but are a bit larger. But the port layout should be very familiar. These boxes will come with MX software on there and should not be able to transition to IOS-XE anytime in the near future so these are just faster versions of the MX67-68. Feature set should be identical like any MX platform.

GIdenJoe

That's about the map I have in my head 😉 Only part I didn't have is the left most column since I wasn't working in IT then.

GIdenJoe

This is because they still need to figure out how they will license the C9200, C9400,C9500, C9600 series that don't have a cloud management license past 2029.

GIdenJoe

The standalone switch must be connected to your stack instead and never directly connected to MX devices due to the spanning-tree issue. You always should connect your MX devices to 2 devices if possible but not more. So you build your network topology with your switches, they are the center of your network while your MX'es are at the edge. So you have 2 stacked switches as distribution switch (and access if you have a small network) that connect with two cables to every other switch stack (or individual switch if not stacked). Below an example where the MX'es are connected to the switches acting as distribution layer switches.

GIdenJoe

Since the MX devices don't do spanning-tree it is a bad idea to connect more than two logical switches to the MX devices, especially with trunk ports. This is because the spanning-tree messages go up to the MX and are just forwarded out the other ports causing in best case unwanted ports to be blocked or worse STP instability. In case your MX'es are in the same locations and you have a switchstack then connect both MX'es to 2 switches in the stack. So MX1 to switch 1 port X and switch 2 port X, and then MX2 to switch 1 port Y and switch 2 port Y. Since the switches are stack you will only predictably block only 2 links on that stack. If case your MX'es are in separate locations then connect each MX to two ports on the nearest stack.

GIdenJoe

I also don't like multiple locations sharing the same STP topology. That is just asking for trouble. If the circuit is provided through the router of the ISP and that router will only be connected with an individual link towards your switching then yes I would definitely disable STP on that port, but on that port alone. Alternatively you could also ask the provider if they could put a BPDU filter on their interface leading to your own switches.

GIdenJoe

Traffic initiated from inside going to a WAN will always be NAT'ed to either the physical IP or Virtual IP(in case of HA pair). The 1:1 and 1:Many NAT functionalities are meant for traffic initiated from the outside going in. I haven't tested 1:1 NAT's recently to see if their traffic is always NAT'ed to that IP but this is irrelevant for your design question.

GIdenJoe

At this moment Meraki dashboard accounts are completely separate from cisco.com accounts. So I have to assume the announcement will not apply to dashboard users. Dashboard admins can however enable MFA once logged in and navigated to their profile (top right user icon).

GIdenJoe

Hi all, I have noticed that the proactive pcap section now allows you to select what types of events you can trigger the pcaps for. However I'm not sure if it is a GUI limitation or an actual limitation. According to the GUI setup I can only select one major category and then filter within the sub events of that category. So let's say there are certain auth events AND assoc events I want to capture I get the idea that it is not possible. The documentation does not mention the new selector options yet either. Any thoughts?

GIdenJoe

For many of the advanced features there are nice documents explaining how to use it. However in many of these cases it is not easy to know if the license is essentials or advantage tier. It would be handy to also have a section in those documents that mention it. Feature VRF (no mention of license level, also not in the licensing documentation): https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Networks_and_Routing/VRF_for_WAN_Appliances https://documentation.meraki.com/Switching/MS_-_Switches/Design_and_Configure/Configuration_Guides/Layer_3_Switching/VRF In the document however about cloud EVPN there IS a mention of advanced licensing. https://documentation.meraki.com/Switching/Cloud_Management_with_IOS_XE/Design_and_Configure/Cloud_Fabric_(BGP-EVPN_VXLAN_Fabric)

GIdenJoe

I think workflows is a visual representation of API handling that comes with it's own environment to run the code on. So this is very handy since you don't need to set up your own "server" to run your code on. And since it can talk to just about anything it is a nice centralized place to do stuff. I have only dabbled in it a bit on a need to have basis. For example: during our years of operation we have multiple orgs in our msp portal that are pointing network flows to our cloud based syslog for troubleshooting purposes. Since not every engineer documented it and has forgotten of a few we now need to loop through all our orgs to find which networks have syslog server configured to our server. So I'm working on that 😉

GIdenJoe

The Cisco networking sub can contain W7 AP's, C9350 switches and 8K routers. You can freely combine these with MR, MS, MT etc.. licenses in the same subscription. You only need to make sure the amount of the devices are correct.

GIdenJoe

Not sure about that. But since the settings aren't that hard you could use the API to copy the identical settings from network to network.

GIdenJoe

The issue came back. Even dashboard orgs without mandatory timeout get the 5 minute treatment now.

GIdenJoe · ‎Feb 5 2026

Also validate some configurations in your network. If you configured any MX IPv6 stuff, these will be disabled when enabling HA due to lack of support on HA pairs. Yes still after all these years. Configuring the warm spare before you add it physically to the network does not seem to cause any downtime in my experience. Be aware of your WAN situation. Are you going to use a virtual IP or not? Using virtual IP is better for failovers since you just pass the virtual IP from the primary to the spare. However in a single deployment you are using that IP as physical IP on your primary so you would need to move that device to another WAN IP before enabling the virtual IP function and assigning the original IP.

GIdenJoe · ‎Jan 30 2026

The prices are a bit lower than ISE session licenses. And I do believe an ISE like environment is running the radius services. They could of course do a little extra effort and provide full blown profiling and perhaps an optional native cloud PKI so you don't need to rely on MS Cloud PKI or SCEPman.

GIdenJoe · ‎Jan 30 2026

You can only have 2 way QoS if you are in control of the full flow between two sites. That means if you have a full tunnel between your branches and your DC and your internet POP is there then you have full control over the flow of traffic between the DC and the branches. Since your bw is lower on the WAN side than LAN side the enforcement is usually upstream. That means upstream can be managed from the branch upstream side but in case of your DC can also be managed from the DC MX going towards your branch. The moment you use split tunnel you have no control how packets arrive from the public internet.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges