ZTIS Configuration and Testing Examples

Switch Template for This Site

All ZTIS configuration should be performed using a switch template. This approach ensures that the ZTIS configuration on all access switches remains consistently synchronized, particularly for the following items:

• Defining static GBP tag assignments.
• Applying switch policies used for ZTIS enforcement.

Avoid configuring GBP tag assignments or switch policies through overrides, even if the option is available. Maintaining configuration consistency through a switch template is strongly recommended.

Below is the switch template provided in JSON format so it can be easily imported and applied. If you plan to recreate this lab, using the template is the recommended method to minimize errors and prevent misconfigurations.

If you decide not to import the above JSON, the same configuration can also be created through the Juniper Mist portal as described below for reference. Follow these steps:

Create a new switch template by navigating to Organization -> Switch Templates. Click the Create Template button and create a new template with a unique name. In this example, the template is named “uap-branch”.

Assign the new template to the site that contains all switches in your branch by selecting the Assign to Sites option. It is important that all switches belong to the same site, so they receive synchronized configurations and share awareness of the same VLANs.

In our case, all three switches are located in Primary Site, hence you should see the configuration below.

Next, configure the RADIUS server for dynamic authentication. In our case, we used the built-in Juniper Mist NAC solution which just needs the following:

• Authentication Servers=Mist Auth

But if you have a different RADIUS or NAC solution vendor, apply the individual configuration.

In the next step, we create the individual networks representing our VLANs. With the above table in mind, the following configuration will be made under Networks:

• First Network
  • We re-use the existing default network
  • VLAN ID=1 is the native VLAN ID on all revenue ports. This allows us in-band management of switches and APs in our branch.
• Second Network
  • Name=VLAN1088
  • VLAN ID=1088
• Third Network
  • Name=VLAN1099
  • VLAN ID=1099

Next, we create the port profiles used in our lab design:

The following port profile is used on our distribution switch only to connect up-link to WAN router with the downlinks to the two access switches:

• Name=UAP-LINK
• Port Enabled=Enabled
• Mode=Trunk
• Port Network=default
• Trunk Networks
  • All Networks=Unchecked/Disabled
  • Networks=VLAN1088 and VLAN1099

For the two VLANs used by separate wired clients, we create three port profiles for each:

• A port profile without RADIUS (NAC) dynamic authentication. This allows initial wired client testing during the lab without enforcement, helping validate the configuration. It can later also be used to apply static MAC address or static VLAN GBP tag assignments for testing. In the template, these profiles end with -no-auth.
• A port profile that uses RADIUS (NAC) dynamic authentication with MAC address–based client identification. For lab purposes, the reauthentication interval is reduced to 30 seconds to avoid waiting up to 10 minutes after configuration changes. This shortened interval is not recommended for production environments. In the template, these profiles end with -mab-auth.
• A port profile that uses RADIUS (NAC) dynamic authentication with 802.1X EAP-TLS for wired clients. EAP-MD5 could also be used to avoid certificates, but it would not support wireless client authentication through APs. In the template, these profiles end with -eap-auth.

Create the following six port profiles:

• Port Profile1
  • Name=vlan1099-no-auth
  • Port Enabled=Enabled
  • Mode=Access
  • Port Network=VLAN1099
• Port Profile2
  • Name=vlan1099-mab-auth
  • Port Enabled=Enabled
  • Mode=Access
  • Port Network=VLAN1099
  • Use dot1x authentication=Checked/Enabled
    • Allow Multiple Supplicants=Checked/Enabled
    • Mac authentication=Checked/Enabled
      • Mac authentication only=Checked/Enabled
      • Authentication Protocol=pap
    • Reauthentication Interval=30 Note: Do not do this in production!
• Port Profile3
  • Name=vlan1099-eap-auth
  • Port Enabled=Enabled
  • Mode=Access
  • Port Network=VLAN1099
  • Use dot1x authentication=Checked/Enabled
• Port Profile4
  • Name=vlan1088-no-auth
  • Port Enabled=Enabled
  • Mode=Access
  • Port Network=VLAN1088
• Port Profile5
  • Name=vlan1088-mab-auth
  • Port Enabled=Enabled
  • Mode=Access
  • Port Network=VLAN1088
  • Use dot1x authentication=Checked/Enabled
    • Allow Multiple Supplicants=Checked/Enabled
    • Mac authentication=Checked/Enabled
      • Mac authentication only=Checked/Enabled
      • Authentication Protocol=pap
    • Reauthentication Interval=30 Note: Do not do in production!
• Port Profile6
  • Name=vlan1088-eap-auth
  • Port Enabled=Enabled
  • Mode=Access
  • Port Network=VLAN1088
  • Use dot1x authentication=Checked/Enabled

Here are example screenshots:

Port Profile1 example:

Port Profile2 example:

Port Profile3 example:

Save your switch template so that it will be applied to the switches. We’ll apply the ZTIS configuration in a later step.

WAN Router Configuration

You can use any WAN router for this configuration as long as it meets the following requirements:

• Provides Layer 2 to Layer 3 demarcation by acting as the default gateway for all VLANs configured on interfaces connected to the branch distribution and access switches.
• Functions as a DHCP server for all VLANs so that wired and wireless clients—and optionally switches and APs when using in-band management—receive DHCP leases.
• Performs source NAT on the WAN interface so traffic from all VLANs can access the internet using translated addresses.
• Supports one native VLAN while the remaining VLANs are tagged toward downstream switches and APs. This enables in-band device management without requiring a dedicated out-of-band management network in a branch environment.

If you select a Juniper Networks® SRX Series Firewall, its configuration can be managed through the same Juniper Mist portal used for branch switches. An example configuration is provided in the referenced documentation and was also used in this setup.

In our lab, we used a Session Smart Router, and a configuration example is included in this JVD.

Below, we provide the WAN Edge template in JSON format for easy import and deployment.

If you are familiar with SRX Series Firewalls and do not use a WAN Edge, we provide a simple Junos configuration that can also be used for this lab below:

Access and Distribution Switch Configuration

Navigate to Switches and select “Primary Site”. Switch to the “List” view, open the hamburger menu in the upper-right corner, and filter by version. You should see the installed Junos versions on the switches. Verify that your access switches are ZTIS-capable and that the installed Junos firmware supports ZTIS. If not, replace the switches or upgrade the firmware.

Now, select the Distribution Switch and configure the Ports with the following port profiles:

• Port Profile
  • Port IDs=ge-0/0/0-2
  • Interface=L2 Interface
  • Configuration Profile=UAP-Link

Next, go to Access Switch1 and configure the Ports with the following port profiles:

• Port Profile1
  • Port IDs=mge-0/0/1
  • Interface=L2 Interface
  • Configuration Profile=UAP-Link
• Port Profile2
  • Port IDs=mge-0/0/3
  • Interface=L2 Interface
  • Configuration Profile=vlan1099-no-auth
• Port Profile3
  • Port IDs=ge-0/0/16
  • Interface=L2 Interface
  • Configuration Profile=vlan1099-no-auth

Then, go to Access Switch2 and configure the Ports with the following port profiles:

• Port Profile1
  • Port IDs=mge-0/0/1
  • Interface=L2 Interface
  • Configuration Profile=UAP-Link
• Port Profile2
  • Port IDs=mge-0/0/3
  • Interface=L2 Interface
  • Configuration Profile=vlan1088-no-auth
• Port Profile3
  • Port IDs=ge-0/0/16
  • Interface=L2 Interface
  • Configuration Profile=vlan1099-no-auth

RADIUS (NAC) Configuration

It is strongly recommended to assign GBP tags for ZTIS through dynamic RADIUS-based authentication using an NAC solution. To assign a GBP tag within the RADIUS access-accept message, you must use one of the following Juniper vendor-specific (ID 2636) attributes. The standard RADIUS attribute Filter-ID (Type 11) cannot be used.

• You can use the older Juniper RADIUS VSA Juniper-Switching-Filter (Type 48 as string). With this attribute, the returned value must be a string similar to the following example: apply action gbp-tag 100.
• Alternatively, you can use the newer Juniper RADIUS VSA Juniper-Group-Based-Policy-Id (Type 53 as integer). With this attribute, the returned value is simply the GBP tag number, for example 100.

Only one of these attributes can be used to assign a GBP tag at a time. The newer attribute is recommended because it still allows the legacy attribute to be used in the same access-accept message to reference an additional ACL filter if required. If the newer VSA is not supported by the RADIUS server dictionary, you can fall back to the legacy attribute instead. The Auth Policy Labels example below demonstrates how both can be used.

The following section provides an example VSA configuration for a FreeRADIUS server.

Since we use the built-in Juniper NAC solution in our example, we first navigate to Organization -> Auth Policy Labels to configure four example labels:

• Label1 is used to identify wired desktop VMs for MAC address-based authentication. All those in our environment start with OUI 0x52:54:00.
  • Label Name=Wired-Client-VM
  • Label Type=Client List
  • Label Values=52:54:00:*
• Label2 is used to define a return attribute for a successful client authentication using the new VSA for GBP tag assignment.
  • Label Name=GBP-100
  • Label Type=AAA Attribute
  • Label Values=GBP Tag
  • GBP Tag Values=100
• Label3 is used to define a return attribute for a successful client authentication using the legacy VSA for GBP tag assignment.
  • Label Name=GBP-200
  • Label Type=AAA Attribute
  • Label Values=Custom Vendor Specific Attribute
  • Attribute1
    • Name=Juniper-Switching-Filter
    • Value=apply action gbp-tag 200

The following auth labels should now be defined:

OPTIONAL: In this lab, EAP-TLS is primarily used for wireless client authentication. This assumes that a public key infrastructure (PKI) is available, including an enterprise root certificate authority capable of issuing client certificates. The required setup steps are not repeated here, as they are already documented in a separate JVD that can be followed for guidance here. The examples for client configuration are also covered in a JVD for Windows and Linux clients here.

Note:

Keep in mind that you can avoid the complexity of certificate creation and enrollment of wired clients by choosing either EAP-MD5 or MAB for wired clients.

By navigating to Organization -> Auth Policies, we define an initial authentication ruleset as follows:

• Rule1
  • Name=Wired-EAP
  • Match Criteria=EAP-TLS AND Wired
  • Policy=Pass
  • Assigned Policies=Network Access Allowed and GBP-200
• Rule2
  • Name=Wired-MAB
  • Match Criteria=Wired-Client-VM AND MAB AND Wired
  • Policy=Pass
  • Assigned Policies=Network Access Allowed and GBP-100

When completed, this configuration should look similar to the example shown below:

Adding ZTIS Configuration

Note:

In a production environment, you should schedule a maintenance window when adding GBP policies for the first time.

Now that the lab configuration is in place, we can proceed with adding the ZTIS configuration. All ZTIS settings must be applied through a switch template to ensure consistent and synchronized configuration across all access switches within the same site (the branch site in this example). Navigate to Organization -> Switch Templates and select the template created earlier. The first step is to define the GBP tag assignments and destination IP address rules as described below:

• GBP Tag Policy1
  • Name=client1
  • Tag assignment=Dynamic
  • GBP Tag=100
• GBP Tag Policy2
  • Name=client2
  • Tag assignment=Dynamic
  • GBP Tag=200
• GBP Tag Policy3
  • Name=vlan1099
  • Tag assignment=Static
  • Select the GBP Values from=IP/Port/Protocol
  • Destination IP Addresses=10.99.99.0/24
  • Protocol=Any
  • Destination Port=<none>
  • GBP Tag=<none>
• GBP Tag Policy4
  • Name=vlan1088
  • Tag assignment=Static
  • Select the GBP Values from=IP/Port/Protocol
  • Destination IP Addresses=10.88.88.0/24
  • Protocol=Any
  • Destination Port=<none>
  • GBP Tag=<none>
• GBP Tag Policy5
  • Name=branch
  • Tag assignment=Static
  • Select the GBP Values from=IP/Port/Protocol
  • Destination IP Addresses=10.0.0.0/8
  • Protocol=Any
  • Destination Port=<none>
  • GBP Tag=<none>
• GBP Tag Policy6
  • Name=internet
  • Tag assignment=Static
  • Select the GBP Values from=IP/Port/Protocol
  • Destination IP Addresses=0.0.0.0/0
  • Protocol=Any
  • Destination Port=<none>
  • GBP Tag=<none>

The resulting configuration should look similar to this:

When using the other static GBP configuration options, keep in mind the following limitations and recommendations:

• Static MAC address GBP tag assignments should be only used when you do not have a RADIUS server deployed. It’s recommended that you use a central RADIUS server for client authentication management as it scales better and you may use client identification based on MAC address OUI vendor IDs.
• Static network assignments (or VLANs) are limited to EX4400 Series only as mentioned above.
• IP subnet refers to the GBP assignment by source IP address which is not supported in branch designs and only possible in campus fabric designs.

In the next step, create the GBP policies that will be used for enforcement. Follow the previously described guidelines when ordering destination rules:

1. All rules that match against a destination GBP tag must appear first in the list. These rules apply only to traffic within the same VLAN, which is a known limitation of ZTIS.
2. IP prefix destinations should then be ordered from the longest prefix to the shortest (assuming they do not overlap), ensuring that more specific rules are evaluated before more general ones. A rule covering internet traffic with a /0 prefix should always be placed last for a given GBP source tag. Destination IP prefixes may also be used for traffic within the same VLAN, but they are required for traffic directed toward other VLANs.

The resulting configuration example looks like the following:

• Switch Policy1
  • Name=client1-policy
  • Source=client1
  • Destination1
    • Destination=client1 (is a destination-gbp tag first in the ruleset)
    • Traffic=allow
  • Destination2
    • Destination=client2 (is a destination-gbp tag first in the ruleset)
    • Traffic=allow
  • Destination3
    • Destination=vlan1099 (is a /24 destination IP-Address second in our ruleset)
    • Traffic=allow
  • Destination4
    • Destination=vlan1088 (is a /24 destination IP-Address second in our ruleset)
    • Traffic=allow
  • Destination5
    • Destination=branch (is a /8 destination IP-Address third in our ruleset)
    • Traffic=allow
  • Destination6
    • Destination=internet (is a /0 destination IP-Address always last in the ruleset)
    • Traffic=allow
• Switch Policy2
  • Name=client2-policy
  • Source=client2
  • Destination1
    • Destination=client1 (is a destination-gbp tag first in the ruleset)
    • Traffic=allow
  • Destination2
    • Destination=client2 (is a destination-gbp tag first in the ruleset)
    • Traffic=allow
  • Destination3
    • Destination=vlan1099 (is a /24 destination IP-Address second in our ruleset)
    • Traffic=allow
  • Destination4
    • Destination=vlan1088 (is a /24 destination IP-Address second in our ruleset)
    • Traffic=allow
  • Destination5
    • Destination=branch (is a /8 destination IP-Address third in our ruleset)
    • Traffic=allow
  • Destination6
    • Destination=internet (is a /0 destination IP-Address always last in the ruleset)
    • Traffic=allow

We do not block any traffic here as we first want to use the monitoring function to review how traffic flows.

When all configuration is finished, your switch policy should look similar to the following:

When saving the templates, keep in mind that this is the first time GBP policies are being applied. As previously mentioned, the packet forwarding engine on all standalone switches receiving this GBP policy configuration for the first time will restart. If a Virtual Chassis is deployed, you must manually reboot the entire Virtual Chassis to activate the initial GBP configuration.

On your access switches, the resulting Junos configuration will look like the example shown below:

In addition to the GBP policies, you will also notice other changes, as the access switch operates like a small, isolated EVPN fabric internally, with policy control based on VXLAN.

Additional Junos CLI on Switches

At the time this documentation was written, the Juniper Mist cloud did have the capability to autodetect and configure links between ZTIS capable Switches. Hence, we help the system and configure these links manually via additional CLI.

Note:

As already pointed out above in a branch design there is no need to configure known ports between ZTIS capable switches. The system will then automatically switch to Multicast L2 message propagation instead of L2 Unicast. Configuring the up/downlinks known for ZTIS gains you the advantage of seeing the GBP-Tags already at the distribution switch connecting your access switches.

On the distribution switch of our lab the Mist-Cloud has detected that the Switch is ZTIS capable and pushed ZTIS configuration and through additional Junos CLI in order to complete the setup we just needed to specify the downlinks to the access switches:

On the access switches we needed to configure the ZTIS uplinks as well. In the future, an auto-detection mechanism is planned to avoid this.

Testing Your ZTIS Design

When running a lab, at the beginning of it one should figure out the MAC addresses of your client VMs (and WAN router) and create a table like the one shown below.

Using native KVM you can use the following commands:

If your desktop VMs are running Linux, you can perform the following steps inside them:

With that knowledge, you can create the following table:

Table 2: MAC Addresses of Our Lab Devices

VM	MAC Address	IP Address	VLAN	Authentication	GBP Tag	Switch	Port
desktop1	52:54:00:79:a7:47	10.99.99.99/24	1099	MAB	100	access1	mge-0/0/3
desktop2	52:54:00:ea:15:ed	10.88.88.88/24	1088	MAB	100	access2	mge-0/0/3
desktop3	52:54:00:c3:53:e1	DHCP Lease	1099	EAP	200	access1	ge-0/0/16
desktop4	52:54:00:db:53:a2	DHCP Lease	1099	EAP	200	access2	ge-0/0/16
ssr1	52:54:00:ef:18:36	10.99.99.1/24 10.88.88.1/24 10.33.33.1/24	1099 1088 1			access1+2	mge-0/0/1

When beginning a new test exercise, it is recommended to follow these best practices to achieve faster and more consistent results:

1. Shut down or stop all wired client virtual machines. This ensures that their MAC addresses age out of the access switches as quickly as possible.
2. Apply any required GBP configuration changes in the switch template.
3. Make any necessary port configuration changes for wired client authentication on the access switches.
4. Verify that previously learned client MAC addresses are no longer present by accessing the access switches through a remote shell and running the CLI command show ethernet-switching table. If you do not want to wait for MAC address aging, you can clear the table manually using the clear ethernet-switching table command.
5. Start the new lab by powering on the client virtual machines.

The example output below demonstrates a clean starting state for a lab, confirming that no client MAC addresses are currently learned:

Let’s begin the first lab with wired clients in the initial configuration shown on the table above. For simplicity, two wired clients are authenticated using MAC address–based authentication. The two other wired clients will use EAP authentication, so we will use EAP-TLS. To support this setup, the wired port configuration on the access switches needs to be changed as follows:

• Access Switch=access1
  • Port Profile Assignment1
    • Port ID=mge-0/0/3
    • Configuration Profile=vlan1099-mab-auth
  • Port Profile Assignment2
    • Port ID=ge-0/0/16
    • Configuration Profile=vlan1099-eap-auth
• Access Switch=access2
  • Port Profile Assignment1
    • Port ID=mge-0/0/3
    • Configuration Profile=vlan1088-mab-auth
  • Port Profile Assignment2
    • Port ID=ge-0/0/16
    • Configuration Profile=vlan1099-eap-auth

In our lab, the distribution switch does not support ZTIS, so we should verify whether the reports are accurate by using the CLI command show unified-access-policy. Note: In a campus fabric environment, for all non–IP Clos fabrics, inter-switch links should be configured as LAG ae interfaces and should display only a single LLDP neighbor, since the uplink distribution switches share the same source MAC address (this is not related to the ESI-LAG MAC address).

After all your wired and wireless clients are onboarded, review the RADIUS NAC reports under Organization -> Auth Policies.

Reviewing the NAC events for wired clients will show the assigned GBP tag value using the new VSA attribute.

Reviewing the NAC events for wired EAP-TLS clients will show the assigned GBP tag value using the old VSA attribute when doing EAP-TLS authentication.

You can review the wired client’s MAB authentication by connecting through remote shell to the switch and using the following CLI commands:

You can review the wired client’s EAP authentication by connecting through remote shell to the switch and using the following CLI commands:

Now review the Ethernet switching tables on both access switches to confirm which GBP tags are associated with the wired and wireless clients.

On the Access1 switch we see the following:

On the Access2 switch we see the following:

This confirms that GBP tags are not only learned locally, as expected on the local interfaces mge-0/0/3 and ge-0/0/16 but are also learned through remote device. We can observe and verify the following:

• A wired MAB client GBP tag learned from a remote access switch appears through the distribution switch interface mge-0/0/1 .
• A wired EAP client GBP tag from a remotely connected access switch is learned through the distribution switch interface mge-0/0/1 .

For the next phase of evaluation, we will use the desktop1 VM along with the firewall counters local to each switch to validate the configured policies. You will also notice this behavior when reviewing the following individual switch configuration:

When scrolling down the page, you see counters for the rules you configured.

However, these rule counters are intended for long-term monitoring and update approximately every three minutes. For lab testing where immediate results are needed, use a remote shell to an access switch and check the counters locally. Before running a test, it is recommended to clear the counters first.

TEST1: Now let’s use the Desktop1 VM (using MAB) to ping our two wired EAP clients that happen to be in the same VLAN but have a different GBP tag assigned.

When reviewing the firewall counters on the Access1 switch, you will observe activity corresponding to this bidirectional traffic:

• gbp_client1-policy_02 is used as it is created for source GBP tag 100 to destination GBP tag 200 containing the ICMP request packets.
• gbp_client2-policy_01 is used as it is created for source GBP tag 200 to destination GBP tag 100 containing the ICMP reply packets.

TEST2: Reset the firewall counters again and then ping the WAN router gateway IP from the Desktop1 VM.

When reviewing the firewall counters on the Access1 switch, you will observe the following:

• The gbp_client1-policy_03 is applied because it was created for source GBP tag 100 with a destination IP prefix of 10.99.99.0/24. In this case, that prefix represents both the client’s VLAN and the WAN router. This enables the creation of rules for clients within the same VLAN, where defining or assigning GBP tags is not possible.

TEST3: Reset the firewall counters on the Access1 and Access2 switches and then ping the Desktop2 VM (located at Access2 in vlan1088) from Desktop1 VM (located at Access1 in vlan1099).

When reviewing the Access1 switch counters you will see output like the following:

When reviewing the Access2 switch counters you will see output like the following:

This is because the bidirectional traffic uses the following flows:

• On the Access1 switch the ICMP request uses gbp_client1-policy_04 for source GBP tag 100 destined to the IP prefix of 10.88.88.0/24 which is the VLAN in which the Desktop2 VM is located.
• On the Access2 switch the ICMP reply uses gbp_client1-policy_03 for source GBP tag 100 destined to the IP prefix of 10.99.99.0/24 which is the VLAN in which the Desktop1 VM is located.

TEST4: Reset the firewall counters again and then ping the switches in vlan1033 for in-band management from the Desktop1 VM.

When reviewing the firewall counters on the Access1 switch, you will observe the following:

• gbp_client1-policy_05 is applied because it was created for source GBP tag 100 destined to the IP prefix of 10.0.0.0/8. In this case, it is used to control traffic within the same branch when multiple VLANs are present, serving as a general catch-all rule for traffic that has not been explicitly defined by more specific policies.

TEST5: Reset the firewall counters again and then from the Desktop1 VM, create traffic towards the internet such as downloading a web page.

When reviewing the firewall counters on the Access1 switch, you will observe the following:

• gbp_client1-policy_06 is applied because it was created for source GBP tag 100 destined to the IP prefix of 0.0.0.0/0. This rule is intended for all non-local fabric traffic destined for the internet and serves as the final rule to be evaluated.

Now that you understand the rules that have been configured and when they are applied, you can begin using them to control or block traffic as needed.

TEST6: Let’s repeat the last lab but this time block the traffic towards the internet. Go to the switch template and right-click on internet and select “deny”.

The rule color will change to red. Lastly, save the template so that it is applied to the access switches.

After the configuration has changed, the traffic is no longer allowed:

Reset the firewall counters again and then from the Desktop1 VM, create traffic towards the internet such as downloading a web page. The traffic now fails since we’ve changed the configuration to block it.

When reviewing the firewall counters, you will see packet counts for traffic attempts, allowing you to monitor when a client with GBP source tag 100 tries to access internet traffic.

TEST7: To block traffic between wireless and wired clients which are in the same VLAN, review the bidirectional policies matched by TEST1 and block them as shown below.

From the Desktop1 VM, ping the wireless clients in the same VLAN.

The firewall counters on the Access1 switch only increment on the matching rule gbp_client1-policy_02 for the ICMP requests: