Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Freeform Design

Blueprints

When creating a new network with Freeform reference design, you start by creating a Blueprint. As with the other reference designs, the Blueprint contains all elements associated with an operating network managed by Apstra. There are a few key differences in how Blueprints are structured and used in Freeform. The Data Center reference designs require design and build elements such as logical devices, interface maps, racks, and templates. These steps are unnecessary in a Freeform design because configuration details and device links are created directly into the Blueprint. When creating a new Blueprint, you simply select the Freeform Reference Design, as shown.

Topology

After creating a new Freeform Blueprint, you can begin designing your network topology. As with the DC Reference Architectures, all design work is done from the Staged Blueprint tab. The Staged topology editor area in Freeform is where you interact with the elements to create your network design and architecture. The topology editor is a new capability in Freeform that allows you to create bespoke network designs in an interactive manner. You can select networking devices and connect them interactively by defining links between them. These devices can be internal or external as shown below.

To access the topology editor, click the Edit button on the Topology view.

Internal devices are under Apstra management and must be mapped to device profiles that model the device capabilities and interact with the device using agents. External devices are not directly under the Apstra management umbrella but can still be modeled in the topology view for interaction with internal devices, for example, links and speeds. External devices do not utilize device agents or models. You can create links between devices, single or multiple, or even create aggregated links. You can interact with the topology to re-arrange the design layout, add links, and edit colors or tags, for devices and links. You can perform Create, Read, Update, and Delete (CRUD) operations by selecting the system's gear icon. You have the option to perform CRUD operations for both individual objects and objects in bulk.

Colors

You can use colors to create quick visual grouping and distinction between Apstra devices. For example, devices connecting to firewalls can be red while devices doing IP-Forwarding only can be orange.

Tags

In Apstra, Tags are a powerful feature. Tags are a way for you to assign metadata to Apstra-managed resources. These Tags can help you identify, organize, search for, and filter Apstra resources: currently devices and links. Tags are also useful to help you categorize resources by purpose, owner, environment, or other criteria. Because Tags are metadata, they are not just used for visual labeling, but they are also applied as a property of the node in the Apstra graph database. This node property, or device property, is then available for you to reference in Jinja for dynamic variables in config generation and the Apstra real-time analytics via Apstra's Live Query technology and Apstra Intent-Based Analytics.

For example, you can use tag `firewall` to render a specific description

See more examples of how to access and use tags in the Jinja Support section.

Creating Systems

You can create a system from the Topology view or the Systems view:

  1. From Staged > Topology > Topology Editor

    Use the first two icons in the bottom menu to create either an internal or an external system. The new system appears in the Topology view. Before creating an internal system, you import its Device Profile into the Blueprint catalog, then you assign it when creating the internal system.

  2. From Staged > Systems

    This method automatically adds the new systems to the Topology view. You can choose to create a new system from an existing managed device or create a new system with a specific device profile and assign a managed device later once the equipment is ready and part of the Apstra-managed devices.

Creating Links

Links are used to connect objects or devices together. Links can be single or aggregate links. These links can have parameters assigned to them via the topology editor “gear” icon. The links can have IP addresses, and tags assigned.

Device Profiles

Device Profiles define the capabilities of supported hardware devices. Some feature capabilities have different behaviors across NOS versions, and thus, capabilities can be expressed per NOS version.

In the initial versions for Freeform, only Device Profiles from Juniper Networks are supported.

You must import Device Profiles into your Blueprint before you can start building it. Then you can use those devices in the topology editor in the blueprint.

Config Templates

Since the design of the network elements in Freeform is arbitrary, the device configurations are not automatically rendered by the Freeform reference design; rather, the configuration is left for you to define completely. Beginning in Apstra 4.1.1, we introduce the concept of a Config Template specifically for Freeform to drive device configuration. Config Templates can be very simple and static to very complex and programmatic depending on the use case and level of automation you are comfortable with. Config Templates support the use of Jinja2 template language which can optionally interact with the device context and property sets.

Nesting (composable) Config Templates

As Config templates support Jinja templating, a powerful nesting feature is supported that allows you to include a section of a config template from the list inside of another config template. Nesting config templates has two main benefits. The first is that with nesting you can separate various services, configuration sections, and so on, out to common components and create dedicated config templates for them.

For example, assume that you have a base system stanza configuration for banners, logins, NTP, and so on, for most of your Juniper devices. Instead of copying and pasting the same configuration into each of your device templates, you could create a dedicated config template for the base system config. Then, you just reference that template from within another template.

Since you can only assign one config template to each system, the second benefit is that all entities of any nested config templates are inherited automatically.

As an illustration, the config template junos_configuration.jinja below is a single config template with several nested config templates, such as junos_system.jinja.

The nested junos_system.jinja template is used to render the system hostname.

Rendering Order

Configuration is rendered in order of the config template.

Property Sets

Property sets are collections of key-value pairs that you import into blueprint catalogs to use in Config Templates and IBA probes. The use of Property Sets is optional, but it provides a valuable capability that allows you to fully parameterize config templates to separate the unchanging portions of the config template from the actual variables. Said another way, property sets allow you to enrich the Device Model used to render configuration in an arbitrary and flexible manner.

For example, the configuration of NTP on all devices in the enterprise may be consistent, but with differing time sources or strata per geography. The NTP config template can be built using a variable that is different for each of these areas. In this case, you can use the property with the name "ntp".

It's important to use correct syntax; key values are case sensitive.

The config template would be constructed with {{ntp}} in place of the actual IP address you want to use for the NTP server. The same Config Template is imported into all blueprints, but blueprints running in the East region would have the “EAST” Property Set imported, and blueprints running in the West region would have the “ WEST” Property Set imported. Property sets are by default blueprint wide, or global in context.

Freeform also supports property sets that can be assigned to a device specifically. This allows for you to set up specific property sets and assign them and use them only in a specified device. Property Sets are part of the Graph; their values can be used in IBA probes.

The examples above show that property sets can be accessed via the Device Context (left) or the graph (right)

Data Structures in Property Sets

Freeform Property Sets support advanced data structures you can use to accomplish different use cases. Freeform Property Sets support any of the typical Python data types such as:

  • Arrays (list of items)

  • Boolean: True or False

  • Int: 1, 2, 3 etc.

  • Float: 1.2, 3.65, etc.

  • String: “Hello World”

  • Dictionary: {“asn”: 65432, “lo0”: “1.2.3.4/32”}

The example above shows different data types in a Config Template

You can reference the property set globally or assign it to a system in the blueprint. The screenshot below shows a property set built using a nested dictionary (dictionary of dictionaries) data structure.

You can recurse the dictionary using the keys, and using the keys as values as required, for example:

  • esxRedTrunk is the link tag name to be used as an interface description

  • 99, 100, 101 are the VLAN ID / trunk members & irb.<value> to be assigned

  • subnet / description / gateway are also used to derive meaningful configuration

Deploy Modes (Deploy / Ready / Drain)

You can set the deploy mode of your systems in Freeform (same as in Data Center blueprints).

However, in Freeform, you define the configuration rendered when a system is in each mode.

You can use the Deploy Mode to conditionally render different configurations, such as whether to render routing protocol sessions or to indicate how particular route maps would render on a device. An example would be if the device was set to “Drain” it would have specific Jinja to generate a configuration that removed the dynamic routing protocols.

The Deploy Mode of a system is exposed to the user in the Device Context, which can be referenced in Config Templates as Jinja variables.

The Deploy Mode of neighboring systems are also available.

Changing the Deploy Mode of a system has no effect on the rendered configuration if it has not been referenced by the Config Template assigned to the system.

An example of how this could be accomplished in a Jinja Config Template is as follow:

In this example, both the protocols.jinja and policy_options.jinja become active when a given node is in either the ‘deploy’ or ‘drain’ state. You can modify the behavior to suite individual needs.