merakiSwitchProfiler

Copy switchport profiles and settings like QoS, ACLs, SNMP and Syslog from a source template, without having to bind your networks to it, giving you a lot more freedom and control over individual configs and firmware preferences.

Table of Contents

Introduction

Prerequisites

How to use

Caveats

<a id="intro"></a>

Introduction

Cisco Meraki Configuration Templates and Switch Profiles allow organizations to manage large numbers of switches distributed across many locations in a simplified manner, centralizing configurations in one point. However, they also introduce a number of limitations:

1. All sites bound to the template must conform to a single firmware version, and must be upgraded together
2. It removes the option of using Staged Upgrades, forcing all upgrades within a site to happen concurrently
3. It forces all template-bound networks to conform not only to the same Switch Profiles, but also to the same Group Policies, QoS settings, ACL rules and other network-wide settings
4. It limits local divergences in switch port configurations, as any changes to the switch profiles will be pushed out to all bound switches

This tool allows decoupling of firmware upgrades and network settings from switch port configurations, and offers additional flexibility in deploying port configuration changes, like defining ports to be ignored during configuration pushes, and only pushing changes to a subset of your switches. All of this is achieved via Tags:

• Network Tags identify networks the tool will operate on and copy Network-wide configurations to (Group Policies, QoS, ACLs, Alerts, Syslog, SNMP, Traffic Analytics)
• Switch Tags identify switches within these networks that will have their ports synced to profiles that carry the same name as the tag (including associated Access Policies and Port Schedules)
• Ignore Port Tags identify ports that should not be updated by the script, even if the script is operating on other ports in the same switch. This allows preservation of local overrides and protecting critical ports like uplinks and server ports

The script also has the added flexibility of allowing you to reference a configuration template as a source that resides in a different organization than the one where your switches currently exist on, permitting syncing configurations across organizations. It also allows the definition of a template for switch port profiles, and a separate different template for Network settings, decoupling port-level configurations from ACLs, QoS, Alerting and other settings for added flexibility.

All of this is done without ever binding switches to configuration templates, which allows you to keep completely separate firmware upgrade procedures across networks, and keeping advanced functionalities like Staged Upgrades available.

<a id="prereq"></a>

Prerequisites

1. Active Cisco Meraki subscriptions in the orgs where the script will be run
2. API access enabled for these organizations, as well as an API Key with access to them. See how to enable here
3. A working Python 3.0 environment
4. Install libraries in requirements.txt
5. Create a configuration template for housing your configurations, and optionally a second configuration template if you wish to decouple Group Policies, QoS, ACL, Alert, Syslog, SNMP configurations from the switch profiles template.
6. Set up switch port profiles for each of the types of switches you will deploy in your environment in the source template. You can see how to configure port profiles here
7. Set up Group Policies, QoS, ACLs, Alerts, SNMP, Syslog, Access Policies and Port Schedules in source templates.
8. Deploy additional standalone networks with switches in them

<a id="howtouse"></a>

How to Use

1. Clone repo to your working directory with git clone https://github.com/Francisco-1088/merakiSwitchProfiler.git
2. Edit config.py

• Add your API Key under api_key in line 2
• Add the Organization ID of the organization where the source configuration template exists. You can find your Org ID easily by right clicking anywhere in the screen while logged in to your organization, and clicking "View Page Source". In the resulting page use "Find" to look for the keyword Mkiconf.org_id

• Add the Organization ID of the organization where your target standalone switch networks exist. These networks may be combined networks, and may reside in the same organization as the source template, but don't have to. You can find this organization ID in the same way outlined in the previous step.
• Add the Source Template ID for the configuration template storing all of the switch port profiles created in Prerequisites #5. You can find this ID easily by navigating to your Configuration Template in the Meraki Dashboard, right-clicking anywhere and choosing "View Page Source". In the resulting page use "Find" to look for the keyword Mkiconf.locale_id. Copy the number between the quotation marks, and prepend the string L_ right before it, and add it to the configuration file.

• Add the Source Template ID for the configuration template storing all of the other network configurations defined in Prerequisites #6. This template can be the same as the one that holds the port profiles, but can also be a different one if you want to decouple these pieces of configuration. You can find this ID easily by navigating to your Configuration Template in the Meraki Dashboard, right-clicking anywhere and choosing "View Page Source". In the resulting page use "Find" to look for the keyword Mkiconf.locale_id. Copy the number between the quotation marks, and prepend the string L_ right before it, and add it to the configuration file. For example, if your template's ID is 34567897, the value you should input in the configuration file is L_34567897.
• OPTIONAL: Modify the tag under dst_network_tag to a tag of your preference. You may use switchProfiler if you want. This tag is used to identify networks that your script will deploy configurations to.
• OPTIONAL: Modify the tag under dst_switch_tag to a tag of your preference. You may use switchProfiler if you want. This tag is used to identify switches that your script will deploy switch port configurations to.
• OPTIONAL: Modify the tag under ignore_port_tag to a tag of your preference. You may use ignore if you want. This tag identifies ports within a switch that you DO NOT want to make configuration changes to. The script will not make any changes to these ports even if it's deploying configs to other ports in the switch.
• OPTIONAL: Modify verbosity and logging settings. By default, the script will show you every step it's going through, and will prompt you before making any configuration changes. It is recommended to use it this way while you're testing the script, and for debugging purposes. verbose displays additional information about the data gathered from the source networks. supervised prompts you before every configuration change, allowing you to skip it. console_logging enables API log messages to appear in the console. You may set any of these to False if you do not want this level of logging.

3. Run pip install -r requirements.txt from your terminal
4. Tag networks you want to work on with the same tag you defined in config.py under dst_network_tag

5. Tag switches you want to copy switch port profiles to with the same tag you defined in config.py under dst_switch_tag
6. OPTIONAL: You may use the provided switchTagger.py and switches.csv files to automatically tag your switches. You have to modify the sample CSV with your own switch serials and the tags you wish to assign to them separated by commas as a string. You then execute this script with python switchTagger.py
7. Tag these same switches with one additonal tag that has the exact same name as the switch port profile you want to deploy on this switch from your source template. For example, if you want to copy the switch port configs on a MS410-16 profile named ms410-16-t1, you must tag a corresponding MS410-16 switch with the tag ms410-16-t1.

The tagged switches in the picture will receive the configura