Switch Configuration Options

Choose an authentication server for validating usernames and passwords, certificates, or other authentication factors provided by users.

• Mist Auth—Configure Juniper Mist Access Assurance, a cloud-based authentication service, on your switch. For this option to work, you must use a port with dot1x or MAB authentication. For information, see the Juniper Mist Access Assurance Guide.

• RADIUS—Select this option to configure a RADIUS authentication server and an accounting server, for enabling dot1x port authentication at the switch level. For the dot1x port authentication to work, you also need to create a port profile that uses dot1x authentication, and you must assign that profile to a port on the switch.

  The default port numbers are:

  • port 1812 for the authentication server

  • port 1813 for the accounting server

After selecting an authentication server, configure additional details for the selected server as required. You can configure information that include:

• Timeout—Duration in seconds after which the authentication request times out.

• Retries—Number of retries allowed.

• Enhanced Timers—By default, EX Series switches have a range of 30-60 seconds for various communication timers between the switch and the client device. Enabling this option enhances these timers between 2 and 10 seconds. You can further modify them by changing the authentication server Timeout and Retries.

• Load Balance(Applicable only to RADIUS)—By default EX Series switches use the first RADIUS server. This option randomizes the configuration of the order of servers on a per-switch basis. This ensures load balancing across multiple RADIUS servers.

• Interim Interval—Specify the frequency (in seconds) at which the authentication server is updated with information about an active user session.

• Source Address(Applicable only to Mist Auth)—Select a source network. This network should be part of a Layer 3 or IRB interface created with a static IP address.

• Dynamic Request Port—Specify a change of Authorization (CoA) port.

set system authentication-order radius
set system radius-server radius-server-IP port 1812
set system radius-server radius-server-IP secret secret-code
set system radius-server radius-server-IP source-address radius-Source-IP
set system login user remote class class

set system login user RO class read-only
set system login user OP class operator
set system login user SU class super-user
set system login user remote full-name "default remote access user template"
set system login user remote class read-only

To use TACACS+ authentication on the device, you must configure information about one or more TACACS+ servers on the network. You can also configure TACACS+ accounting on the device to collect statistical data about the users logging in to or out of a LAN and send the data to a TACACS+ accounting server.

In addition, you can specify a user role for TACACS+ authenticated users within switch configuration. The following user roles are available: None, Admin, Read, Helpdesk. When the TACACs+ authenticated users do not have a user account configured on the local device, Junos assigns them a user account named 'remote' by default.

The port range supported for TACACS+ and accounting servers is 1 to 65535.

Configure the domain name server (DNS) settings. You can configure up to three DNS IP addresses and suffixes in comma separated format.

Configure Simple Network Management Protocol (SNMP) on the switch to support network management and monitoring. You can configure the SNMPv2 or SNMPv3. Here are the SNMP options that you can configure:

• Options under SNMPv2 (V2)

  • General—Specify the system's name, location, administrative contact information, and a brief description of the managed system. When using SNMPv2, you have the option to specify the source address for SNMP trap packets sent by the device. If you don't specify a source address, the address of the outgoing interface is used by default.

  • Client—Define a list of SNMP clients. You can add multiple client lists. This configuration includes a name for the client list and IP addresses of the clients (in comma separated format). Each client list can have multiple clients. A client is a prefix with /32 mask.

  • Trap Group—Create a named group of hosts to receive the specified trap notifications. At least one trap group must be configured for SNMP traps to be sent. The configuration includes the following fields:

    • Group Name—Specify a name for the trap group.

    • Categories—Choose from the following list of categories. You can select multiple values.

      • authentication

      • chassis

      • configuration

      • link

      • remote-operations

      • routing

      • services

      • startup

      • vrrp-events

    • Targets—Specify the target IP addresses. You can specify multiple targets.

    • Version—Specify the version number of SNMP traps.

  • Community—Define an SNMP community. An SNMP community is used to authorize SNMP clients by their source IP address. It also determines the accessibility and permissions (read-only or read-write) for specific MIB objects defined in a view. You can include a client list, authorization information, and a view in the community configuration.

  • View(Applicable to both SNMPv2 and SNMPv3)—Define a MIB view to identify a group of MIB objects. Each object in the view shares a common object identifier (OID) prefix. MIB views allow an agent to have more control over access to specific branches and objects within its MIB tree. A view is made up of a name and a collection of SNMP OIDs, which can be explicitly included or excluded.

• Options under SNMPv3 (V3)

  • General—Specify the system's name, location, administrative contact information, and a brief description of the managed system. When using SNMPv2, configure an engine ID, which serves as a unique identifier for SNMPv3 entities. You have an option to use the device MAC address as the engine ID. Using MAC address ensures the engine ID’s uniqueness and stability without much manual intervention.

  • USM—Configure the user-based security model (USM) settings. This configuration includes a username, authentication type, and an encryption type. You can configure a local engine or a remote engine for USM. If you select a remote engine, specify an engine identifier in hexadecimal format. This ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host. If you specify the Local Engine option, the engine ID specified on the General tab is considered. If no engine ID is specified, local mist is configured as the default value.

  • VACM—Define a view-based access control model (VACM). A VACM lets you set access privileges for a group. You can control access by filtering the MIB objects available for read, write, and notify operations using a predefined view (you must define the required views first from the Views tab). Each view can be associated with a specific security model (v1, v2c, or usm) and security level (authenticated, privacy, or none). You can also apply security settings (you have the option to use already defined USM settings here) to the access group from the Security to Group settings.

  • Notify— Select SNMPv3 management targets for notifications, and specify the notification type. To configure this, assign a name to the notification, choose the targets or tags that should receive the notifications, and indicate whether it should be a trap (unconfirmed) or an inform (confirmed) notification.

  • Target—Configure the message processing and security parameters for sending notifications to a particular management target. You can also specify the target IP address here.

  • View(Applicable to both SNMPv2 and SNMPv3)—Define a MIB view to identify a group of MIB objects. Each object in the view shares a common object identifier (OID) prefix. MIB views allow an agent to have more control over access to specific branches and objects within its MIB tree. A view is made up of a name and a collection of SNMP OIDs, which can be explicitly included or excluded.

For more information, see Configure SNMP on Switches.

Configure static routes. The switch uses static routes when:

• It doesn't have a route with a better (lower) preference value.

• It can't determine the route to a destination.

• It needs to forward packets that can't be routed.

Mist supports IPv4 and IPv6 addresses for static routes. The IPv6 support is available for destination and next hop addresses.

Types of static routes supported:

• Subnet—If you select this option, specify the IP addresses for the destination network and the next hop.

• Network—If you select this option, specify a VLAN (containing a VLAN ID and a subnet) and the next hop IP address.

• Metric—The metric value for the static route. This value helps determine the best route among multiple routes to a destination. Range: 0 to 4294967295.

• Preference—The preference value is used to select routes to destinations in external autonomous systems (ASs) or routing domains. Routes within an AS are selected by the IGP and are based on that protocol’s metric or cost value. Range: 0 to 4294967295.

• Discard—If you select this check box, packets addressed to this destination are dropped. Discard takes precedence over other parameters.

After specifying the details, click the check mark (✓) on the upper right of the Add Static Route window to add the configuration to the template.

To configure any additional settings that are not available in the template's GUI, you can use set CLI commands.

For instance, you can set up a custom login message to display a warning to users, advising them not to make any CLI changes directly on the switch. Here's an example of how you can do it:

set system login message \n\n Warning! This switch is managed by Mist. Do not make any CLI changes.

To delete a CLI command that was already added, use the delete command, as shown in the following example:

delete system login message \n\n Warning! This switch is managed by Mist. Do not make any CLI changes.

• Define an Open Shortest Path First (OSPF) area. OSPF is a link-state routing protocol used to determine the best path for forwarding IP packets within an IP network. OSPF divides a network into areas to improve scalability and control the flow of routing information. For more information about OSPF areas, see this Junos documentation: Configuring OSPF Areas.

• Enable or disable OSPF configuration on the switch (at the switch level).

For more information on how to configure OSPF through Mist, refer to OSPF Configuration for Switches.

Juniper EX series and QFX series switches provide excellent port security, including DHCP snooping, Address Resolution Protocol (ARP) inspection, and IP Source Guard. You can enable these options for all or selected VLANs on the switch from the Mist portal. DHCP snooping must be enabled for DHCP issues to be included in the Wired Successful Connect SLE.

DHCP Snooping monitors DHCP messages from untrusted devices connected to the switch. When enabled, DHCP snooping extracts the IP address and lease information from the DHCP packets and stores it in a snooping database. Port security on the EX switches uses this information to verify DHCP requests and block DHCPOFFERs received on untrusted ports (DHCP DISCOVER and DHCP REQUEST are not affected).

• IP Source Guard works only with single-supplicant 802.1X user authentication mode. It uses the DHCP database to validate source IP addresses and MAC addresses that are received on an untrusted port, and drops those packets that do not have matching entries in the database.

• ARP Inspection examines the source MAC address in ARP packets received on untrusted ports. It validates the address against the DHCP snooping database, and if the MAC address cannot be found, the packet is dropped. You can use the CLI to check ARP statistics, such as number of invalid ARP packets that it receives on each interface and the sender’s IP and MAC addresses, by typing the following commands in the CLI shell: show dhcp-security arp inspection statistics, and show log messages | match DAI

By default, the DHCP protocol considers all trunk ports as trusted and all access ports as untrusted. We recommend that you only connect a DHCP server to the switch using a trunk port, or, if you must use an access port, be sure to explicitly configure that port as trusted in the port profile or DHCP will not work.

Note that if you connect a device configured with a static IP address to an untrusted port on the switch, the MAC-IP binding may not exist in the DHCP snooping database; the packets will be dropped. You can use this command show dhcp-security binding in a CLI shell to troubleshoot DHCP issues and see what bindings are listed in the DHCP snooping database for the switch.

Configure SYSLOG settings to set up how system log messages are handled. You can configure settings to send the system log messages to files, remote destinations, user terminals, or to the system console.

For help with the configuration options, see Configure the System Log.

PORT MIRRORING

Configure port mirroring.

Port mirroring is the ability of a router to send a copy of a packet to an external host address or a packet analyzer for analysis.

Mist supports both local and remote port mirroring. In local port mirroring, the source ports and the destination ports (monitor port) are located on the same network switch. In remote port mirroring, the source ports and destination ports are not on the same switch. In this case, the source port forwards the packet copy to the remote destination port through the connection achieved by the ports between the two switches.

In the port mirroring configuration, you can specify the following:

• Input: The source (an interface or network) of the traffic to be monitored. Along with the input, you can specify whether you want Mist to monitor the ingress traffic or the egress traffic for an interface. If you want both ingress and egress traffic to be monitored, add two input entries for the same interface - one with the ingress flag and the other with the egress flag.

• Output: The destination to which you want to mirror the traffic. You can specify a interface, network, or an IP address (in the case of a remote destination). You cannot specify the same interface or network in both the input and output fields.

Routing Policy

Configure routing policies for the entire organization (Organization > Switch Templates) or for a site (Site > Switch Configuration). These routing policies will only be pushed to the switch configuration if it is tied to the BGP Routing Protocol. The Routing policies that are already defined inside the BGP tab of a switch will now appear on the Routing Policy tab. The routing policies are tied to protocols such as BGP or OSPF. A routing policy framework is composed of default rules for each routing protocol. These rules determine which routes the protocol places in the routing table and advertises from the routing table. Configuration of a routing policy involves defining terms, which consist of match conditions and actions to apply to matching routes.

To configure a routing policy:

1. Click Add Routing Policy on the Routing Policy tile.

2. Provide a name to the policy, and then click Add Terms.

3. Provide a name to the term and specify other match details such as:

   • Prefix

   • AS Path

   • Protocol

   • Community—A route attribute used by BGP to administratively group routes with similar properties.

   • Then—Then action (Accept or Reject) to be applied on the matching routes.

   • Add Action—Additional actions such as prepend AS path, set community, and set local preference.

4. Click the check mark (✓) on the right of the Add Term title to save the term. You can add multiple terms.

5. Click Add to save the routing policy.

Enable switches with DHCP option 81 support. When this option is enabled on a switch, the clients connected to that switch can send their fully qualified domain name (FQDN) to the DHCP server while requesting an IP address. This allows the DHCP server to update DNS records accordingly.

You can enable the DHCP option 81 at the site level (Site > Switch Configuration) and device level (Switches > Switch Name) as well.

With VRF, you can divide an EX Series switch into multiple virtual routing instances, effectively isolating the traffic within the network. You can define a name for the VRF, specify the networks associated with it, and include any additional routes needed. You can specify IPv4 or IPv6 addresses for the additional route.

Basic settings to identify and enable the port.

• Trunk—Trunk interfaces typically connect to other switches, APs, and routers on the LAN. In this mode, the interface can be in multiple VLANs and can multiplex traffic between different VLANs. Specify the Port Network, VoIP Network (if applicable), and Trunk Networks.

• Access—Default mode. Access interfaces typically connect to network devices, such as PCs, printers, IP phones, and IP cameras. In this mode, the interface can be in a single VLAN only.

Select this option to enable IEEE 802.1X authentication for Port-Based Network Access Control. 802.1X authentication is supported on interfaces that are members of private VLANs (PVLANs).

The following options are available if you enable dot1x authentication on a port:

• Allow Multiple Supplicants—Select this option to allow multiple end devices to connect to the port. Each device is authenticated individually.

• Dynamic VLAN—Specify dynamic VLANs that will be returned by the RADIUS server attribute 'tunnel-private-group-ID' or 'Egress-VLAN-Name'. This configuration enables a port to perform dynamic VLAN assignment.

• MAC authentication—Select this option to enable MAC authentication for the port. When this option is selected, you can also specify an Authentication Protocol. If you specify a protocol, it must be used by supplicants to provide authentication credentials.

• Use Guest Network—Select this option to use a guest network for authentication. Then select a Guest Network from the drop-down list.

• Bypass authentication when server is down—If you select this option, clients can join the network without authentication if the server is down.

• Reauthentication interval—In a switch port profile that uses dot1x authentication, you can configure a timer that controls how often a client reauthenticates itself with the RADIUS server. The recommended value is 6 to 12 hours (21600 to 43200 seconds). The default value is 65000 seconds.

• Server Reject Network—Select this option to connect users to a specified VLAN (such as the guest network) in the event that the authentication server rejects the user-authentication attempt. You can configure this option at the switch-level, site template-level, or organization template-level.

• Server Fail Network—Select this option to connect users to a specified VLAN (such as the guest network) in the event that the authentication server cannot be reached or fails to respond. You can configure this option at the switch-level, site template-level, or organization template-level.

You need to also do the following for dot1x authentication to work:

• Configure a RADIUS server for dot1x authentication from the Authentication Servers tile in the All Switches Configuration section of the template.

• Assign a dot1x port profile to a switch port for the RADIUS configuration to be pushed to the switch. You can do this from the Port Config tab in the Select Switches Configuration section of the template.

  Mouse-over the port to see the RADIUS-assigned VLAN field. Ports with dot1x enabled are assigned a new VLAN by the RADIUS server when the 802.1x authentication is successful. This view is especially useful when checking whether a given VLAN on a port has changed following dot1x authentication.

  Figure 1: Radius Assigned VLAN on a Dot1x Port

Speed

Keep the default setting, Auto, or select a speed

Duplex

Keep the default setting, Auto, or select a Half or Full.

The default value: 0

Supported range: 0 through 16383

Enable the port to support power over Ethernet (PoE).

Configure a switch with VLAN Spanning Tree Protocol (VSTP) or per-VLAN Spanning Tree. VSTP helps in preventing loops in Layer 2 networks on a per-VLAN basis. One Spanning Tree per VLAN enables fine grain load balancing. Mist recommends enabling this feature for other vendor’s devices (for example, Cisco) that operate per-VLAN Spanning Tree by default.

This setting is available at the site and switch level as well.

Configure the port as a Spanning Tree Protocol (STP) edge port, if you want to enable Bridge Protocol Data Unit (BPDU) guard on a port. STP Edge is enabled on ports to which clients that do not participate in STP are connected. This setting ensures that the port is treated as an edge port and guards against the reception of BPDUs. If you plug a non-edge device into a port configured with STP Edge, the port is disabled. In addition, the Switch Insights page generates a Port BPDU Blocked event. The Front Panel on the Switch Details will also display a BPDU Error for this port.

You can clear the port of the BPDU error by selecting the port on the Front Panel and then clicking Clear BPDU Errors.

You should not enable STP Edge on the Uplink port.

You can also configure STP Edge at the switch level, from the Port Profile section on the switch details page.

STP Point-to-Point

This configuration changes the interface mode to point-to-point. Point-to-point links are dedicated links between two network nodes, or switches, that connect one port to another.

STP No Root Port

This configuration prevents the interface from becoming a root port.

Block STP BPDUs

Typically enabled on edge or access ports where BPDUs are not expected. When this option is enabled, the port is immediately shut down if a BPDU is received, helping to prevent potential loops or misconfigurations.

If STP Edge is enabled, Block STP BPDUs is automatically disabled. However, BPDU Liveliness Check can still be configured. If Block STP BPDUs is enabled, both STP Edge and BPDU Liveliness Check are automatically disabled.

Enable Quality of Service (QoS) for the port to prioritize latency-sensitive traffic, such as voice, over other traffic on a port.

You have the option to override the QoS configuration on the WLAN settings page (Site > WLANs > WLAN name). To override the QoS configuration, select the Override QoS check box and choose a wireless access class. The downstream traffic (AP > client) gets marked with the override access class value specified. The override configuration doesn't support upstream traffic (client > AP).

See also: QoS Configuration.

Enable storm control to monitor traffic levels and automatically drop broadcast, multicast, and unknown unicast packets when the traffic exceeds a traffic level (specified in percentage). This specified traffic level is known as the storm control level. This feature actively prevents packet proliferation and maintains the performance of the LAN.

When you enable Storm Control, you can also choose to exclude broadcast, multicast, and unknown unicast packets from monitoring.

You can also configure a switch to automatically shut down a port when traffic exceeds the user-defined storm control threshold, by selecting the Shutdown Port check box under Action on Threshold.

For more information, see Understanding Storm Control.

Enable Persistent (Sticky) MAC to retain MAC addresses for trusted workstations and servers learned by the interface, even after a device restart. You can configure Sticky MAC for static wired clients. Sticky MAC is not intended for use on Juniper Mist AP interfaces, nor is it supported for trunk ports or those configured with 802.1X authentication.

Used in conjunction with MAC Limits (explained above), Sticky MAC protects against Layer 2 denial-of-service (DoS) attacks, overflow attacks on the Ethernet switching table, and DHCP starvation attacks, while still allowing the interface to dynamically learn MAC addresses. In the Mist portal, the Insights page reports these events as MAC Limit Exceeded .

You configure both Sticky MAC and MAC limits as part of the Port Profile for the switch. The general procedure is demonstrated in this video:

You must explicitly enable the Persistent (Sticky) MAC Learning option, located at the bottom of the Port Profile configuration block, to include Sticky MAC as part of the Port Profile that you associate with the interface. For MAC limits, the default value is 0 (unlimited, that is, disabled) but you can enable it by setting a value of up to 16383 unique MAC addresses allowed.

To see in the Mist portal what value has been set for the MAC Limit or the MAC Count, select a switch from the Switches page and hover your mouse over a switch port. You can see which (port) Profile is applied to the interface, and by extension, know its Sticky MAC status.

Figure 2: Port Details Showing Sticky MAC

The configured MAC limit and number of MACs learned will appear after a few minutes, as dynamic learning on the interface progresses. In the Mist dashboard, only the maximum MAC address count is shown. However, you can see every MAC address a given interface has learned by opening a Remote Shell to the switch and running the following Junos CLI commands:

show ethernet-switching table persistent-learning
show ethernet-switching table persistent-learning interface

MAC count is a persistent value that remains until the MAC address is cleared (or until it is disabled in the Port Profile and then that configuration is pushed to the switch).

To clear the MAC addresses on a given interface from the Mist dashboard, you need to be logged as Network Administrator or Super User. Then just select the port you want from the switch front panel (as shown in Figure 1) and click the Clear MAC [Dynamic/Persistent] button that appears.

On the Switch Insights page, the event shows up as a MAC Limit Reset event.

For more information on the front panel, see Switch Details.

Enable this option if you want this rule to apply to all switches that have the same model. Then select the model.

Enter the subnet or site variable.