Meraki

Brash · ‎Sep 27 2023

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 · ‎Sep 27 2023

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

Brash · ‎Sep 27 2023

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 · ‎Sep 27 2023

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 · ‎Sep 27 2023

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 · ‎Sep 25 2023

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 · ‎Sep 25 2023

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 · ‎Sep 22 2023

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 · ‎Sep 20 2023

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 · ‎Sep 20 2023

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

Brash · ‎Sep 19 2023

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

Brash · ‎Sep 18 2023

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 · ‎Sep 18 2023

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 · ‎Sep 18 2023

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 · ‎Sep 18 2023

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 · ‎Sep 18 2023

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 · ‎Sep 18 2023

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 · ‎Sep 18 2023

What model are the switches?

Brash · ‎Sep 15 2023

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 · ‎Sep 15 2023

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 · ‎Sep 12 2023

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 · ‎Sep 11 2023

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 · ‎Sep 11 2023

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

Brash · ‎Sep 7 2023

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 · ‎Sep 7 2023

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

About Brash

Brash

Community Record

Badges