Meraki

CGRE

No wildcard, from everything I've read InTune wont like the wildcard, so networks have to be added individually, you can add multiple names to one profile though, am sure there will be some kind of limit but cant find what that is.

mrpackethead_

.

PhilipDAth

Actually, depending on the backup platform, another solution would be to break the NIC team, and then just give each NIC its own IP address.

AlexCoste

That's good to hear! I'm glad it was sorted.

Bovie2K

This was so helpful.

GIdenJoe

It should. TMGmatrix shows that the T-X is supported on the C9300X-24Y. And the Meraki document that covers Cisco optics compatibility says this: Cisco Optics Compatibility Many of the Cisco Optics that are compatible* with the native Catalyst Switch platform (ex. C9300-24S) are also compatible with the corresponding Cloud Managed/Monitored Catalyst Switch Platform (ex.: C9300-24S-M) including the MS390. • This includes: 1/10/25/40/100G SFP/QSFP fixed wavelength fiber and copper transceivers,

WizIT

Thanks for putting everything together at one place in a beautiful way.

Brash

You beat the official community announcement 😆 Linked here for reference: VLAN database management

GIdenJoe

A session should always take precedence over templated config. There is talk that access manager will also be supporting some basic form of profiling which is basically what smartports do on the LLDP/MAC only side. Access manager will be a licensed feature (either having advanced licensing on your Meraki hardware or a separate license if you don't have advanced) So the place for smartports will be for people who do not want to pay for access manager. But once you have access manager it should completely supplant smartports since you can do all and more with access manager.

GIdenJoe

In early access (organization -> early access) you can enable the VLAN profiles feature. In there you can create VLAN names for VLAN ID's. And subsequently you can use them on access ports and for native vlan in trunks. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/VLAN_Profiles You can also define VLAN groups there which are comma lists of VLAN ID's for use on trunk allowed vlan lists.

0AK13Y

There is a known routing issue according to TAC for Z3s running 19.1.5. Excessive flapping to SDWAN site connections and to secure connect

Michal_Gurbski

Thanks for this link!

RWelch

MX Cold Swap - Replacing an Existing MX with a Different MX

jamess03

I think I answered my own question by labbing this out with some Catalyst switches. There are also some Meraki community conversations around this: Re: Mekari / Cisco - MSTP and RSTP Configuration Questions - The Meraki Community What Meraki is essentially doing with the configuration is emulating RSTP. I don't think you can actually establish the same MST region between every Meraki switch. Instead, you communicate with an RSTP boundary and the behavior is the same. When I configured the exact same Meraki MST configuration used with this new feature - and then connected it to an MST0 instance with a different name and revision number - the "Meraki" switch observed the root switch properly and this was the output: Catalyst-Switch#show spanning-tree mst interface gigabitEthernet 0/1 GigabitEthernet0/1 of MST0 is root forwarding Edge port: no (default) port guard : none (default) Link type: point-to-point (auto) bpdu filter: disable (default) Boundary : boundary (RSTP) bpdu guard : disable (default) Bpdus sent 5, received 225 Instance Role Sts Cost Prio.Nbr Vlans mapped -------- ---- --- --------- -------- ------------------------------- 0 Root FWD 20000 128.1 1-4094 Catalyst-Switch#show spanning-tree MST0 Spanning tree enabled protocol mstp Root ID Priority 32768 Address 6899.cdc2.a680 Cost 20000 Port 1 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32768 (priority 32768 sys-id-ext 0) Address ac7e.8abd.4c80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Gi0/1 Root FWD 20000 128.1 P2p Bound(RSTP)

GIdenJoe

You got me there at least half. You can apply outbound VPN firewall rules towards non-Meraki VPN peers but you cannot block incoming, so you are trusting the external network to not send unwanted traffic.

alemabrahao

Please note: C9K/MS390 runs single instance (0), single region (region1), and single revision (revision 1) MSTP. This is essentially Rapid Spanning-Tree. Please make sure for interoperability with any other non-Meraki platforms, to either run Rapid Spanning-tree or MSTP (not PVST or any iteration, nor any other vendor specific STP implementation). This will ensure that there are no issues with compatibility and functionality. https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)

GreenMan

Every Meraki device is managed by the Meraki Dashboard. What I think you're getting at though; the built-in wireless of an MX64W (the W bit) is separate from the wireless provided by any MR Access Points. Even if you place the MX and the APs in the same Network, the setups are configured via different menus and will not interact with each other. You could, for example, configure an SSID on the MX (via Security & SD-WAN menu) and an SSID with the same name on the APs (via Wireless menu) but the APs and the MX would not co-ordinate channel and power settings (AutoRF), nor would a client device roam seamlessly between the MX and the APs. It should be noted too that the WiFI capabilities of the MX6xW are significantly less sophisticated than any of the dedicated APs shipped in the last half-dozen years.

JessePeden

Are you referring to the SAML auth for SSIDs feature, or the EAP-TLS feature?

rickibiza

redudancy, we cannot 100% rely on the provider. Our locations are on an island and the service sometimes is not so good on high season.

GreenMan

I'm not in PM but my take would be; IPv4 requires NAT - there aren't enough addresses to give each device its own public address. IPv6 was designed to allow every device it's own address, so no NAT required.

CarolineS

@Mad_Dog_82 - Thank you very much for following up on this thread! I'm going to mark your reply as the solution since it seems you have found the answer (even if it's not the answer you were hoping for). Cheers!

GIdenJoe

iSCSI runs on IP. IP runs on ethernet. Meraki switches are ethernet switches, so this will work just fine. There is in fact nothing special about iSCSI switches...but for a way of the server vendors to sell their gear. The only thing that can matter is the performance of the switch. Which means, uplink bandwidth, oversubscription and buffer sizes. Meraki switches are aimed and access layer and not exactly datacenter so the buffers won't be the biggest but if you make sure you design with the correct port speeds, the buffers shouldn't be an issue.

GIdenJoe

We know Meraki is working an a Azure native way of authenticating but this is not ready yet. At this time you can use a combination of SCEPman and RadiusaaS which is essentially a cloud based RADsec server that can be fully used with cert based authentication.

GIdenJoe

It clearly shows that the remote appliances you are trying to reach are offline.

CarolineS

Thanks for this answer, @GIdenJoe! I'm marking it as the solution. @M_Faizal - if this does not answer your question, please let us know what further clarifications you need. Cheers!

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges