About Brash

Brash

No experience directly with this bug but I'm not running Beta firmware anywhere in my environments. If this is a production environment, I'd suggest avoiding Beta releases. My suggestion is to run Stable Release Candidates on a pilot site and Stable releases on all other sites.

Brash

The port has auto negotiated down to 100mbps. This is typically a cable issue - bends/breaks in the cable causing 1 or more pairs to be broken, too long cable run etc.

Brash

The only way to verify is to attempt claim them to a dashboard and make sure it works. If it says they're already claimed then you're out of luck.

Brash · Re: Meraki Dashboard Outage today - 2023-09-20

It's fine for me. Might be a problem specifically with your shard. What is the number at the start of the URL (https://n...meraki.com)?

Brash

To clarify this a bit further, you can have a LAG of ports that span across different switches within a physical stack.

Brash

Sounds like you're looking for "Where should users go after the splash page?" under the splash page settings

Brash

The MX LAN port connecting to the switch should be a trunk port. The native vlan will typically be either the management vlan of the switch (if you haven't configured the management vlan in the switch configuration), an unused VLAN, or none.

Brash

The reason for the original behaviour you saw is because the ports on the MX are configured for Trunk Native VLAN 10 and Access VLAN 10 (for your environment with only the one VLAN, they are pretty much the same thing). Your computer is on the default VLAN (VLAN 1) until it hits the MX at which it is placed onto VLAN 10. When changing the switchport to VLAN 10, you mess up the tagging flow and your traffic is dropped. VLAN segmentation is definitely the way to go. What you've got above is a good start. My suggestions would be: - Keep the Management VLAN and corporate devices VLAN. I personally don't see a need for the "MX84 Appliance VLAN) - Segment the printers and other devices to a different VLAN if possible. - Remove the native VLAN on the MX ports and set the VLAN on the switch access ports instead When making changes like this, ensure you have a decent maintenance window and have someone on-site who can connect locally to the devices should they accidentally go offline from the dashboard. For example, depending on the existing config, it's very easy to take the switch offline when changing the config on the MX.

Brash

There isn't really a 'proper' method for connecting two switch stacks together. My suggestion is to use at least two links across both switches in the stack and aggregate them into a port-channel. However, please ensure you read the release notes for your switch version. There are some known issues around cross stack port-channel. Eg. Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage of up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10)

Brash

It will probably 'work' but you may have unexpected issues. As the link states, the radio's will be enabled regardless of whether the antenna are connected or not

Brash

As per the FAQ, all ports should have antenna connected. "On a 4x4:4 AP however such as the MR84 and MR86, there should be no unused ports. These APs have four dual-band antenna ports (and therefore do not have 2.4 or 5GHz labels). None of these ports should be left unconnected because all four ports will always be active even if one radio is disabled. MR84/86 APs should have all four antenna ports connected" https://documentation.meraki.com/MR/Other_Topics/Frequently_Asked_Questions_regarding_Cisco_Meraki_Antennas#Can_I_leave_unused_connectors_uncovered.3F

Brash

Ok, they're both capable of 10Gbps. Sounds like it could be an issue with the fiber then. I would do a loop back test on both sides to rule out the switches and SFP's

Brash

What model are the switches?

Brash

When you say unregistered, are you meaning unlicensed/unclaimed? I don't know the answer but it seems to me that would be a very niche scenario. For example, if the MX loses connectivity to the Meraki cloud but maintains site-to-site connectivity for whatever reason, it will reboot within 8 hours anyhow, causing the site-to-site vpn to go down. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Behavior_during_Connection_Loss_to_Cisco_Meraki_Cloud#MX_security_appliance.2FMG_cellular_gateway

Brash

Odd that it would happen suddenly. Have you made any changes on your RADIUS server? The EAP config must have the correct server name. Other than that, have your root or intermediate certs recently expired? Potentially the problem clients didn't receive a renewed root cert via AD and therefore won't trust the RADIUS server cert.

Brash

The only use case I'm aware of is for Electronic Shelf Labelling solutions. Hanshow Electronic Shelf Labels (ESL) Integration with MRs - Cisco Meraki SoluM Electronic Shelf Labels (ESL) Integration with MRs - Cisco Meraki

Brash

I haven't tested but I assume when you select Hub as the mode, the hubs listed in the JSON request are interpreted and configured as Exit Hubs.

Brash

There sure is: https://developer.cisco.com/meraki/api-v1/update-network-appliance-vpn-site-to-site-vpn/

Brash

If you cable the topology this way, it will work but spanning tree will disable one of the ports in order to prevent a loop (the MX will pass along the bpdu's).

Brash

Navigate to Security & SD-WAN -> Appliance Status -> Tools Theres's an option there to show the output of the ARP table.

Brash

As is said above, check your WAN failover behaviour. As a side note, if the network is templated, you can't change the behaviour. It is hard configured to graceful.

Brash

As far as I'm aware this has historically not been the case. It's possible they are doing this now as it looks like Meraki will soon be changing up their licensing where an MX64 and MX67 will use the same license SKU https://documentation.meraki.com/General_Administration/Licensing/Meraki_MX_Subscription_Licensing

Brash

🤦 Yep, "Noting" was definitely what I was going for. Autocorrect has some other ideas. 😄

Brash

Nothing that this doesn't apply to individual switches within a stack. They must all be in the same network and will all upgrade simultaneously.

Brash

Your best bet is to delete the stack, recable and build new stacks. From a config perspective, not sure what you mean about getting the existing config. I can't recall whether deleting the switches from the stack factory resets them or whether you need to do that manually to clear the old config.

Brash

Community Record

Badges