Recommendations | Juniper Networks

Review the JVD extension for WAN router integration.

For this fabric type, we recommend using the L3 eBGP integration approach.

All fabric networks should be configured in the following way to avoid inconsistency:

First, create them as part of your switch template for a site.
Then, import the created networks as part of the campus fabric dialogue and assign to VRFs.
Even if the system allows you a local network creation on a switch, do not use this option.

Do not manually configure VRFs locally on any switch. The fabric usually does this automatically on an as-needed basis.

The current exception to this rule is for a Layer 2 WAN router integration through transport VLAN. Review the JVD extension for WAN router integration and follow the example in the appendix.

When using DHCP relay configuration for the fabric:

Review the JVD extension which covers DHCP relay configuration.
Only use the fabric dialogue for configuring DHCP relay and no local configuration directly on a switch.

When designing and using Virtual Chassis:

Virtual Chassis can only be used at the access switch layer of a campus fabric environment:
When designing a Virtual Chassis, it is not advised to use the maximum number of supported members listed in the Virtual Chassis Overview (Juniper Mist). A good rule of thumb is to use roughly half of the stated maximum. This helps prevent bandwidth oversubscription on the VCPs that form the ring between the chassis members.
Create and assign separate templates for Virtual Chassis systems that have the same number of members. Avoid applying identical port configurations to Virtual Chassis setups of different sizes. This approach allows the system to apply configuration changes directly, without repeatedly checking whether the ports defined in the template actually exist on the local Virtual Chassis.
All Virtual Chassis configurations should be done through the Juniper Mist cloud and the Modify Virtual Chassis dialogue. Additional CLI or CLI commands should not be used for managing a Virtual Chassis.

Consider Juniper Mist Edge integration when you have more than 2,000 wireless clients.

Each Juniper Mist Edge should connect to only one service block function, and this connection should be made through a LAG. On the campus fabric side, a corresponding ESI-LAG will be configured to match it.
Design the network so that traffic remains anchored to a single Juniper Mist Edge under normal conditions, switching to another only when a failover is required.
Assign VLANs for wireless clients only at service block functions where a Juniper Mist Edge is integrated and do not also stretch or reuse them at the access switches.

Unassigned access ports should be configured with a quarantine VLAN or disabled ports using a template. Review the example here.

If possible, use a different VRF for the quarantine VLAN to isolate this traffic.
Best practice is also enabling “STP Edge” in the quarantine port profile.

When deciding how to manage port configurations dynamically:

Using RADIUS or a NAC system to assign VLANs and filters is the recommended method, particularly for customers using Juniper Mist Access Assurance.
Dynamic Port Configuration is considered a less preferred option.

When using Dynamic Port Configuration:

Avoid matching by MAC address if the device supports LLDP.
Don’t match by MAC address if ports are enabled with dot1x.
The use of a filter-id should be avoided. In most cases, this is unnecessary when ports are 802.1X-enabled and a dynamic VLAN can be assigned through RADIUS.
Avoid a high number of port flaps for a DPC-configured port.
Refer switch insights to ascertain the individual configuration is applied.

Traffic towards a third-party RADIUS Server is expected to use inet.0 via the management port, same as the management traffic towards the Juniper Mist cloud, for example, underlay. This allows you to fine-tune the MTU for the UDP Packets send towards such a service in case it is needed.