About Brash

Brash

Your syntax is right. That should give you back an HTTP 200 along with some other data. It definitely seems like the connection is getting blocked somewhere.

Brash

I personally haven't set the TLS version in my scripts. Not sure whether that would cause a problem or not. As @PhilipDAth mentioned - the error could be indicating a connection problem to the API backend. For reference, this is a script that I use quite frequently without issue. Meraki/Meraki Update Switchports.ps1 at main · Brash92/Meraki (github.com)

Brash

Plenty of bountiful goodness in this thread! Congratulations @serhansaridag, @Slobs2, and @Naveed

Brash

Port mirroring is typically used for troubleshooting, or special traffic conditions (eg voice recorders for VOIP). It would not be a good idea to use this for the purposes you're describing. Instead, as suggested above you should be able to achieve your outcome by simply tagging the WISP uplink traffic onto an unused vlan to send it across the fiber to the MX WAN port - Both the WISP cat5 port and the fiber port going to the MX tagged as access ports. With that said, the best option is to have the ISP run the to MDF instead.

Brash

It seems like Meraki may not currently support it. https://community.meraki.com/t5/Wireless-LAN/Alphanumeric-Sender-ID-using-Twilio-account-API/m-p/195556/highlight/true#M26468 I suggest opening a support case to confirm. If it's critical for your business, I'd also suggest reaching out to your Cisco rep to let them know.

Brash

The orange LED status for the MX is expected - no connectivity to the Meraki Cloud. Are you seeing any link lights come up at all? Can you try connecting a different computer or a different port? Does the MX show in the dashboard as having never successfully connected? By default, the MX should be running a DHCP server and issue your client an IP if connected on the LAN port. You can then connect to the local status page to complete the WAN IP configuration.

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

Community Record

Badges