Since I joined Juniper Networks in April of 2020, I’ve been fortunate enough to be working on switching configurations with Mist Wired Assurance. I wanted to take a few minutes to talk about my experiences and guidance on structuring the configuration. Note, these are my thoughts and in no way reflect official recommendations from my employer.

When it comes to Wired Assurance, there is a tremendous amount of flexibility in how you can structure your configuration. But with all that flexibility comes choices in terms of how best to optimize your config. I don’t want to say there’s a right way and a wrong way, but there are methods to ensure you have the best experience in both deploying your network, as well as maintaining it long term.

---

Example Scenario:

• The organization is multi-site
• Most sites have the same set of VLANs, but not VLAN IDs are consistent
• Some sites have additional VLANs and port usages.

My Preferred Method:

• Keep template configuration as generic as possible
• Only place configuration as high in the hierarchy where it applies to all switches in that scope
• Keep switch specific configuration at the switch level.
• Keep overrides as small as possible.

By approaching the configuration from an operational point of view, I try to maximize what I call “configuration re-use.” Configuration re-use can be thought of as “code re-use” in that you are trying to minimize the amount of configuration we have to create and maintain. The general idea is to keep the configuration as high in the hierarchy as possible where it applies to every switch under that hierarchical level. We also want to keep everything as generic as possible in the template.

In our example organization, we have a consistent set of VLANs. However, the VLANs at several sites are different IDs. At a couple of the larger sites, we also have some additional VLANs and port-profiles.

Template Level:

To solve this scenario, we’ll start by picking the generic Network names and VLAN IDs. If you have a standard VLAN ID for each network, define that at the template level and the port-profiles common across all the sites the template. For trunks between switches, I typically will allow “all-networks” since all switches at a site will generally have the same VLANs. For non-switch trunks, I will generally prune VLANs as needed.

Site Level:

Try to avoid overriding the port-profile to a different network (VLAN), as this overrides all settings on the port profile (Keep overrides as small). Overriding the whole port-profile will break the port-profile inheritance and result in you having to configure those settings in multiple places. It’s better to override the VLAN ID on the network so you can retain all the inheritance on the port-profile. If needed, add a port-profile at the site for site-specific use-cases.

Reminder: Things that you create at the site-level will apply to all switches at a site.

Switch Level:

The switch-level is where individual switch-specific things live. IP management addresses, IRBs, OOBM addresses, etc., all get defined here. If you have VLANs or port-profiles that only live on a single switch, you can define these here. This level is also where I recommend the configuration of most switch ports.

Switch Port Configurations:

While you can use switch selection rules to configure all ports on switches at the template/site level, I would encourage restraint when doing this. My general approach is to configure ports that won’t change and that are consistent across switches. Generally, this means uplink ports, and I use a few simple rules based on the switch model and role. The reason for this is so you don’t end up with a bunch of overrides for every port that can lead to confusion. It also requires superuser rights to modify the template. You can also define a port range if you want every port to start as a specific port-profile.

Update 3-Jan-2021: If you have a very standardized config where the ports are configured the same way on every switch, you can get away defining the port mappings at the template level. However, I find most networks have a high number of exceptions and these exceptions tend to grow over time. Leading to my recommendation of having them at the switch level.

Additional CLI commands:

I have a couple of rules about additional CLI commands to help keep things clean and keep you out of trouble later.

1. If the feature exists in the UI or API, use those methods over additional CLI commands. Using built-in capabilities prevents having to undo/redo these configurations later, which will be impactful.
2. Avoid using additional CLI commands that are required for the device’s connectivity to function. They can be very complicated to work with, undo or change in the future.
3. You have to pick between additional CLI commands at the template or the site. My preference is it pick one. If you need more specific additional CLI commands down the hierarchy, you can apply them directly at the switch level.

Additional Templates:

It does not always make sense to have a single template for every site. If you have multiple sites with the same set of requirements, instead of overriding each site individually, it can make sense to have a different template. However, it is easy for templates to get out of control quickly. Remember, part of the value of templates is to reduce the amount of configuration work. Carefully evaluate if the effort to create and maintain more template outweighs overriding and adding configuration multiple times.

Site Variables for VLANs and RADIUS

One thing that you can do is leverage site variables for things like VLANs and RADIUS servers. This allows you to specify the variable value in the site configurations and not have to create overrides. However, I would reserve this for deployments where the VLAN is unique at every site, as each site will need this value populated.

Alternate approaches:

Let’s talk about other ways to structure your configuration.

Template Everything:

One of the things I frequently see is defining too much (or everything) at the template level. This approach seems to show up often when folks first approach Wired Assurance and configuration. I also feel like it has the most significant number of challenges.

Pros:

• It keeps all configuration at a single level

Cons:

• Individual configurations rely heavily on switch matching rules.
• Trunks require manual pruning, and all VLANs exist on all switches.
• Requires Super User access to modify the template
• Results in a large number of overrides at the switch level.
• Overriding the switch matching rules at the site involves the recreation of those rules at the site level.
• Individual IPs at this level require using additional CLI commands, which adds technical debt.

Switch Everything:

This approach is very labor-intensive and error-prone for humans. But it aligns well with a mature netDevOps strategy where you are defining these things in some external source of truth and pushing the entire config to the Mist cloud. Think Ansible works-flows where you are pulling the data from Netbox or NSoT and format them for each switch individually.