Meraki

GIdenJoe

I hope they can influence it enough to make it feel like we are used to.

GIdenJoe

This document has not been updated in a while (https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Client_VPN/AnyConnect_on_the_MX_Appliance/Authentication) However it says there that Cert only authentication is a beta feature. You can always configure always-on in the Secure Client VPN profile editor however to avoid any login prompts you would indeed need to be able to use certificates only to avoid the login prompt. However this does present security issues because you are not using MFA at that point. Inside the profile editor you can configure a DNS check that will see if you are on the local network of the company or not (trusted network). If not it will automatically create the VPN.

GIdenJoe

If you disable FT 802.11r on the SSID then every roam will be a full radius session meaning your clients will take longer to roam between AP's and the load on your NPS server could increase much if you have a high client count. If that does not sound appealing to you, then perhaps first try to fully troubleshoot the clients if possible. That means, check if the issue happens on specific clients (NIC model and driver version) or in case of IoT devices, the device as compared to other devices. I would personally not like to have to disable FT just for a handful of clients.

GIdenJoe

EEE is only applicable to Catalyst switches. The option to enable or disable the feature will only appear for switchports on Catalyst switches. So if you're running MS switches then they don't even do EEE.

GIdenJoe

If you have the SD-WAN plus co-term license or the advantage subscription license you do get application based SD-Internet policies. So if chatGPT is in one of the categories there you could select it that way. I don't believe you can just add an URL as a matching criterium.

GIdenJoe

When running IOS-XE natively you have to use an SVI for management of the switch. So if for example your VLAN for switch management is VLAN 30 then just click the redirect to the Routing and DHCP page and there you can create that SVI on that switch on VLAN 30. When creating that interface since it is the first SVI on the switch you will also be able to fill in the DNS and default gateway fields.

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 😉

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges