スイッチ設定オプション

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.

For more information, refer to Add or Delete a CLI Configuration.

• 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). Configuration involves defining terms, which consist of match conditions and actions to apply to matching routes.

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.

Routing policies are tied to protocols such as BGP or OSPF. A routing policy 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 appear on the Routing Policy tab.

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 the Use Site Timezone option to configure the switch to automatically align its time zone with the associated site’s configured time zone.

When this option is enabled and saved, the effective time zone is displayed on both the site and switch detail pages and is pushed to the device. If Use Site Timezone is disabled, the switch defaults to UTC. Note that the switch time zone configured via the additional CLI commands takes precedence over the time zone configured using the Use Site Timezone option. This configuration is available at the organization or site level and at the switch level.