The Meraki Community
Register or Sign in
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
  • About merakiinsanity
merakiinsanity

merakiinsanity

Here to help

Member since May 5, 2021

Tuesday
Kudos from
User Count
AutomationDude
AutomationDude
1
PhilipDAth
Kind of a big deal PhilipDAth
1
cmr
Kind of a big deal cmr
1
UCcert
Kind of a big deal UCcert
1
View All
Kudos given to
User Count
AutomationDude
AutomationDude
2
View All

Community Record

9
Posts
4
Kudos
0
Solutions

Badges

First 5 Posts
Lift-Off View All
Latest Contributions by merakiinsanity
  • Topics merakiinsanity has Participated In
  • Latest Contributions by merakiinsanity

Re: UpdateDeviceSwitchPort Response

by merakiinsanity in Developers & APIs
2 weeks ago
2 weeks ago
Found that it produces an Assertion Error exception with the following value: "stpGuard" cannot be "dkgfjh", & must be set to one of: ['disabled', 'root guard', 'bpdu guard', 'loop guard']   Exactly this info I was looking for.   Thanks a lot for your help! ... View more

Re: UpdateDeviceSwitchPort Response

by merakiinsanity in Developers & APIs
2 weeks ago
1 Kudo
2 weeks ago
1 Kudo
Ahh sweet, I'll certainly have a look. Thanks ... View more

Re: UpdateDeviceSwitchPort Response

by merakiinsanity in Developers & APIs
2 weeks ago
2 weeks ago
Thanks for the reply.   The check is mainly for console feedback and logging. I was hoping that if an incorrect value was given for a key in the switch_port_conf dictionary (e.g. 'stpGuard': 'asdfg'), a response would be given indicating this as the reason that the update was unsuccessful. This would then be fed back to the user via the console or log file.   I suppose I will just have to put the print statements inside an "if new_port_config:" statement. Currently it's in a Try block which gives a NameError exception if the new_port_config variable isn't there.   This is more of the code for more context: for port in switch_ports[1:2]: if port['type'] == 'access': # New port configuration change switch_port_conf = { 'rstpEnabled': False, 'stpGuard': 'bpdu guard' } # Update switchport with new config try: new_port_config = dashboard.switch.updateDeviceSwitchPort(switch['serial'], port['portId'], **switch_port_conf) except meraki.APIError as e: meraki_error(e) except Exception as e: other_error(e) # if the port update was successful display the new config from the update response try: if new_port_config['rstpEnabled'] == switch_port_conf['rstpEnabled'] and new_port_config['stpGuard'] == \ switch_port_conf['stpGuard']: print(f"New Configuration updated on port {port['portId']} on {switch['name']}:") print(f"\tRSTP Status: {new_port_config['rstpEnabled']}") print(f"\tSTP Guard Mode: {new_port_config['stpGuard']}") else: print(f"Failed to update config on port {port['portId']} on switch {switch['name']}.") print(f"Current configuration:") print(f"\tRSTP Status: {port['rstpEnabled']}") print(f"\tSTP Guard Mode: {port['stpGuard']}") except NameError as e: print(f"Update failed on port {port['portId']} on switch {switch['name']}")       ... View more

UpdateDeviceSwitchPort Response

by merakiinsanity in Developers & APIs
2 weeks ago
2 weeks ago
Hi   When running the following code, if the update was successful, I get the expected JSON response of the port configuration as it is after the update was successful.   However, if the update wasn't successful, for example I get the stpGuard option an invalid option, the new_port_config variable doesn't get create. Can I presume then, that there is no response if the update was unsuccessful and therefore I only need to check that the new_port_config exists, rather than checking against any articular content of the response?   for port in switch_ports[1:2]: if port['type'] == 'access': # New port configuration change switch_port_conf = { 'rstpEnabled': False, 'stpGuard': 'bpdu guard' } # Update switchport with new config try: new_port_config = dashboard.switch.updateDeviceSwitchPort(switch['serial'], port['portId'], **switch_port_conf) except meraki.APIError as e: meraki_error(e) except Exception as e: other_error(e)     ... View more

What are the most "Oh yeah, that's cool" scripts that you've made?

by merakiinsanity in Developers & APIs
‎03-18-2022 02:39 PM
‎03-18-2022 02:39 PM
Hi   Our network doesn't really require much change but I'm wanting to expand my script portfolio for future jobs I may go for. I was hoping I could get some ideas for them from some of the scripts that you may have done.   I'm not looking for the actual code, just ideas for functionality and maybe scenarios where they've been useful. ... View more

Timeout for one network but not the other

by merakiinsanity in Developers & APIs
‎05-08-2021 12:05 AM
‎05-08-2021 12:05 AM
Hi   I've started learning the Meraki Python API and been going through the following example from the library:   https://github.com/meraki/dashboard-api-python/blob/master/examples/org_wide_clients_v1.py    I've changed to base_url to https://api.meraki.com/api/v1   I have two networks in use. For the first network I get a Timeout error, but not for the second network. I've tried increasing the single_request_timeout parameter to various value from 90 up to 300 seconds.   I've also reduced the perPage parameter of the getNetworkClients call down to 100 from 1000.   Even with perPage as 100, I successfully get the first page shown by: 2021-05-08 07:54:05 meraki: INFO > networks, getNetworkClients; page 1 - 200 OK   But each subsequent call produces the following: 2021-05-08 07:55:05 meraki: WARNING > networks, getNetworkClients - HTTPSConnectionPool(host='n121.meraki.com', port=443): Read timed out. (read timeout=60), retrying in 1 second   However, once it moves onto the 2nd network, regardless of what single_request_timeout or perPage parameters I use, every page is successfully retrieved.   Does anyone have any insight why the 1st network fails but the 2nd one is succeeding? ... View more
Labels:
  • Labels:
  • Dashboard API

Re: L3 Firewall Port Range

by merakiinsanity in Security / SD-WAN
‎05-06-2021 12:10 AM
‎05-06-2021 12:10 AM
I've had to expand 2 rules on my Watchguard's, into 6 rules on Meraki. Although I could put the 3 port TCP range for Avaya into the rule above.     I've also noticed that you can't put subnets from the Switch Routing & DHCP, or even the VLANs configured on the MX itself, into the source of the firewall rule, so I've created a Network Object for it so if I need to update the subnet, I'l just have to update the Switch subnet and remember to do the Network Object ... View more

L3 Firewall Port Range

by merakiinsanity in Security / SD-WAN
‎05-05-2021 10:33 PM
2 Kudos
‎05-05-2021 10:33 PM
2 Kudos
Hi again   Our org uses a cloud platform that requires destination UDP ports 10000-60000 to be open to their ip range. Unfortunately, Cisco hasn't given the ability to enter ranges (for both ports and IPs other than CIDR) for some reason known only to themselves.   Before I do something I really don't want to do, namely allow any port number, is there some other way I can tell the rule to only look at port 10000-60000 without having to put in 10000, 10001, 10002 etc etc. Even then, I'm sure I'll hit a limit at some point. This seems like really basic functionality that should be catered.     EDIT: Ok, so I've found a workaround. It seemingly can't cope with having a range in a list. So I can have 10000-60000 in it's own rule, but having 3478, 10000-60000 is beyond its capability. Have to have a separate rule for port 3478, despite it all being UDP.   Apologies if I sound frustrated, it's because I'm extremely frustrated. ... View more

L7 confusion

by merakiinsanity in Security / SD-WAN
‎05-05-2021 01:36 AM
1 Kudo
‎05-05-2021 01:36 AM
1 Kudo
Hi   I'm in the process of migrating from a couple of Watchguard's to a couple of MX450s.   I'm looking at utilising the L7 firewall rules but have become utterly confused. Unless I'm total out-of-date, best practice for firewall rules is to have a catch-all deny rule at the bottom of the ACL, so you deny everything except for traffic you explicitly allow.   L7 firewall rules only come into play on MXs if the traffic has been allowed by L3, at which point L7 can deny it. However, surely, if you have a catch-all deny rule as is best practice for firewalls, the L3 rule will be denying a lot of these services anyway.   What would be infinitely more useful would be being able to configure *allow* rules at L7, so that if the traffic is denied at L3 based on non-wellknown port number for example, it then allows it through at L7 because it matches that particular service. ... View more
Kudos from
User Count
AutomationDude
AutomationDude
1
PhilipDAth
Kind of a big deal PhilipDAth
1
cmr
Kind of a big deal cmr
1
UCcert
Kind of a big deal UCcert
1
View All
Kudos given to
User Count
AutomationDude
AutomationDude
2
View All
My Top Kudoed Posts
Subject Kudos Views

L3 Firewall Port Range

Security / SD-WAN
2 581

Re: UpdateDeviceSwitchPort Response

Developers & APIs
1 118

L7 confusion

Security / SD-WAN
1 699
View All
custom.footer.
  • Community Guidelines
  • Cisco Privacy
  • Khoros Privacy
  • Privacy Settings
  • Terms of Use
© 2022 Meraki