Meraki

Brash

I've found the monitored 9500's can be a little flakey connecting back to the dashboard after upgrade/reboots. You can do some small amounts of troubleshooting yourself: Basic telnet tests documented under "ensure reachability" Cloud Monitoring for Catalyst Onboarding - Cisco Meraki Documentation Check if the tunnel is up show crypto tls-tunnel sessions I've also found sometimes that just 'time' allows it to eventually connect.

Brash

As stated by @Mloraditch , 30 days is the max from the dashboard. I recommend deploying some monitoring software that can record and hold that data for larger amounts of time.

Brash

As said above, there's currently no way to monitor the temperature of the MS210 and MS225 switches from the dashboard. There may be a way that Meraki support can see it from the backend but I'm not entirely sure on that.

Brash

You may not necessarily see problems from the misconfiguration. Based on what you've described and the fact that VLAN 1 isn't trunked, it sounds like your network is essentially split into two separate STP domains, with the border between the Nexus and the Meraki (due to BPDU's not going across the link). A packet capture would definitely confirm this behaviour. Similarly, you could look at STP counters on the nexus. Something along the lines of the below will show sent and received BPDU counters on the interface: show spanning-tree interface <interface number> detail Note: The above command is an IOS-XE command and thus might differ slightly on NXOS

Brash

These are all incredibly creative and very impressive.

Brash

Congratulation @RWelch!! Huge achievement

Brash

Looks great. Nice job @Green_Networker

Brash

If they were ordered as C9300-M, they will be in Meraki managed mode out of the box.

Brash

@joebrug wrote: Okay. You're confident that Cisco RPVST and Meraki RSTP can talk as long as VLAN 1 is available? I only ask because something I read said to change from RPVST to MST. It was probably one of the many footnotes in Meraki docs that I cant find right now lol. Yes, one of my networks has C9500's running RPVST with Meraki MS switches connected off them. They interoperate fine exchanging BPDU's on VLAN 1. The doc suggests changing to MST for a fuller interoperability (for example, having an RPVST device on either side of a Meraki MS will prevent them from exchanging BPDU's). This is important if you're using a range of different switch vendors across your network, but less important if you simply have a couple of Cisco switches sitting on the side. @joebrug wrote: and looks like I need to allow it over the trunk to the Meraki interface Ethernet1/10 description Uplink to Meraki 9300 switchport mode trunk switchport trunk allowed vlan 20,50,172,1000,1010,1020 mtu 9216 It appears so yes. If this is a prod network, keep in mind there will be some reconvergence when you allow VLAN 1 as currently both switches would have different root bridges.

Brash

Yes, that's correct. The Meraki gear, including catalyst in Meraki mode uses VLAN 1 for STP BPDU's. So, if the nexus isn't using VLAN 1 or if VLAN 1 isn't allowed on the trunk, the switches won't receive the BPDU's. My understanding of the doc is essentially that the Meraki switch (or Catalyst switch in Meraki mode) shouldn't be the root bridge when connected to a switch running RPVST. For your scenario it sounds like the Nexus should be the root bridge until you remove it from the network. For clarification, are your C9300's running in Meraki managed or Meraki monitored mode? If Meraki monitored, they'll be running RPVST out of the box and thus are fine to be the STP root bridge. If Meraki managed mode, they'll act more like an MS and therefore, the Nexus should be the STP root bridge.

Brash

This is a funny, but likely true scenario.

Brash

You're correct that Nexus/Catalyst use RPVST whilst Meraki uses RSTP. These are technically interoperable. but the Meraki device will send STP updates on VLAN 1 only. You need to ensure that VLAN 1 is trunked between the two switches. Additionally, (from memory) the native VLAN on each side of the trunk has to match, otherwise you can have the VLAN 1 tag stripped off the packet and it natively tagged as a different VLAN. Also, as per the documentation, it's not suggested to have the Meraki switch be the root in this scenario. https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#Rapid-PVST

Brash

My main question is: how did the attacker gain access to her system behind the NAT? If I obtain someone's public IP address and port, can I exploit their system? What methods might the intruder have used to compromise the machine? There are many opportunities that attackers can use. I've listed a few common ones below: - An attacker can hijack an existing insecure session to a compromised web service - An attacker can use tactics (usually social engineering) for the session to be started from the client side. This is usually social engineering or domain typo squatting etc. Because these tactics get the client to establish the session, NAT and inbound firewalls doesn't provide any benefit of security or obscurity.

Brash

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

Brash

I personally stay on the stable firmware train in production and generally keep up to date within 1-2 weeks of releases. I'd argue that it's not particularly feasible to get version recommendations from the community. I don't think one single version will run perfectly across all platforms and all use-cases. The best thing to do is look at the known issues in the release notes and the fixed issues in the release notes after (if you're not aiming for the latest version) to determine what's applicable to you and what's not.

Brash

"RMA is not acceptable for us." Is there a reason that you won't accept an RMA for the crashing appliance? It's always possible it's an actual hardware issue which an RMA may actually resolve. Having worked for vendors before, I know with certainty that manufacturing duds do occur and these devices can be anywhere from unstable to DOA. You can also push your AM to request an EFA if absolutely required. Have Meraki support requested the device reboot logs/dump from the local device portal? When I've had random reboots, this is typically where they have been able to find a cause of the issue, whether it be a known bug or other. Beyond these, there is a known issue related to MX75 reboots which can only be resolved by RMA - Re: Meraki MX75 Random reboots - The Meraki Community Meraki support should be able to confirm it from the reboot logs/dump.

Brash

I don't have any specific knowledge around LogicMonitor. Based on your comments I'm guessing you've seen this Reddit thread but in case your haven't. https://www.reddit.com/r/meraki/comments/twppv8/comment/iku5i3c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Brash · ‎Jan 28 2025

Most likely, this is due to the way the MX implements FQDN's in L3 firewall rules. FQDN-based L3 firewall rules are implemented based on snooping DNS traffic. When a client device attempts to access a web resource, the MX will track the DNS requests and response to learn the IP of the web resource returned to the client device. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#FQDN_Support Essentially, the DNS lookup and response for the website must pass through the MX unencrypted for the MX to snoop it and be able to match for later traffic. If the MX does not receive a DNS lookup, it does not apply the rule. The MX will also periodically time out the FQDN to IP mapping (I'm not sure what this timer is) so if the client has a longer cache, or simply uses the IP only, the MX may stop enforcing the rule.

Brash · ‎Jan 28 2025

Good point! I had thought about this but wasn't sure if it was worth the extra management overhead for patching and licensing. That said, it is definitely cleaner from an AutoVPN point of view. Additional admin access isn't currently a requirement, but I can see a few ways in which that may shift in the coming year or so. I'll mull it over a bit more, but I think this might be the way to go. 👍

Brash · ‎Jan 28 2025

Ah I forgot about that doc. Cool. I'm not a huge fan of hidden backend configurations but it's good that the option is there.

Brash · ‎Jan 27 2025

I've got a bit of a weird design challenge that I figured I'd get some other's opinions and also ask some clarifications. I'm Managing a network of ~30 sites all corporate networks. All of these sites connect back to the DC using a Hub/Spoke model. 7 of these sites now need to have a side-by-side public network for some public access services. These also need to connect back to a server that manages and maintains these public services. I've proposed the following design. The public MX's would be in separate networks and create a separate hub-spoke AutoVPN to the corporate. Whilst the switch is logically in the corporate network, it will have both public and private traffic separated by VLANs. The VLAN gateways are on the respective MX's A couple of things to note here: Security and separation of public and private networks is the primary concern Eg. Technically these networks can be converged to a single MX and AutoVPN, but a single fat fingering of a firewall rule can bring it all crumbling down Money isn't a big concern - Having two MX's with licenses for each of these 7 sites is fine from a financial perspective The corporate MX's have Umbrella integration with SIG Tunnels - The separation as above prevents public traffic from having corporate Umbrella policies applied My main question is: If I'm not mistaken, the public hub will create a tunnel with the private hub. I've heard there is a way to disable this in the backend. Has anyone had experience with this?

Brash · ‎Jan 27 2025

Congratulations all, and especially to the fresh faces joining the club 🙂

Brash · ‎Jan 25 2025

Weird. Shard 280 working fine for me

Brash · ‎Jan 24 2025

In order to renew, you'll need to renew all licenses. To just extend your Co-Term date, you'll need to purchase and apply an additional new license.

Brash · ‎Jan 20 2025

Agreed with what @ww mentioned. Check that the SonicWall aggregation is configured to use LACP. Otherwise the Meraki switch won't be able to negotiate the port-channel.

About Brash

Brash

Community Record

Badges