Authentication and Access Control (AJEX) - 12a

<Course Title> and Access Control
Authentication
LY
N
O
SE
U
AL
N
R
TE
IN
Authentication and Access Control
LY
N
O
SE
U
AL
Understanding the Defaults

N
By default, all installed interfaces in an EX Series switch are configured for Layer 2 operations. These
Layer 2 interfaces do not enforce any end-user authentication. In some environments, this default
R
implementation can be problematic and prone to security risks. Once an end user receives a physical
connection, that user can, if proactive measures are not taken, connect a rogue switch or wireless
device to the network allowing access for unauthorized devices to the network and its resources.
TE
We discuss several authentication and access control features throughout this material that combat
the potential security risks that are inherent with the default configuration settings. Note that not all
features are currently supported on all EX Series devices. For details about your specific device, refer
to the features overview found in the technical publications.
IN
2 www.juniper.net
LY
N
O
SE
U
AL
Potential Risks
N
This slide is designed to get you thinking about potential issues that can arise from the illustrated
scenarios.
R
Among other things, you could see Layer 2 topology changes that affect network performance or
cause complete outages, unauthorized access to your network and its resources, or a network
TE
outage caused by resource overload through a denial of service (DoS) attack. In reality many
potential issues can arise if you do not protect your network and its resources. The authentication
and access control features covered in this material can help mitigate some of these potential
issues.
IN
www.juniper.net 3
LY
N
O
SE
U
AL
Controlling Network Access

N
This slide introduces a number of features that can help control network access. We cover the
features listed on the slide in detail in subsequent sections.
R
Note that each of the highlighted features authenticates users using RADIUS. One of the biggest
advantages of a RADIUS implementation is that it offers a single, centralized database of end-user
TE
accounts. Each network device can then query the RADIUS server when a given user attempts
access. If the account is available and the parameters (user name, password, and so forth) are
correct, the RADIUS server lets the network device know that the user should be granted access.
Using RADIUS to authenticate users greatly simplifies account management because you maintain
IN
and manage only a single database of users, rather than dozens or hundreds. We provide more
details about RADIUS authentication on subsequent slides in this section.
4 www.juniper.net
LY
N
O
SE
U
AL
RADIUS Overview
N
RADIUS provides authentication, authorization, and accounting (AAA) services in network

environments. When users attempt to access a network device, a RADIUS server verifies that the
R
user is legitimate (authentication). The RADIUS server can then assign certain levels of access to
network resources (authorization). Finally, the RADIUS server keeps track of how long that user
stayed connected and how much data the user sent or received (accounting).
TE
A RADIUS client is a network device, such as an EX Series switch, that makes access requests on
behalf of end users. Although RADIUS is similar in many respects to other client/server database
models, RADIUS can only provide information regarding users as a part of the authentication
process. In other words, you can not use a RADIUS database to look up information on a user or
IN
collection of users as you might with a Structured Query Language (SQL) or Lightweight Directory
Access Protocol (LDAP) database. RADIUS servers will offer up the information they contain only
within the context of the RADIUS process.
www.juniper.net 5
LY
N
O
SE
U
AL
RADIUS Traffic Flow

N
The simple traffic flow on the slide illustrates the general steps that occur when an end user
attempts to gain access to a network device (an EX Series switch in our example), as follows:
R
1. The end user makes an initial connection to the network device;

2. The network device creates and sends the RADIUS server an access-request packet,
TE
which includes the user’s account name and password (or an encrypted variant of the
password);
3. The RADIUS server consults its account database to determine if the user credentials
are legitimate;
IN
4. Assuming the information in the access-request packet is valid, the RADIUS server
returns an access-accept packet to the network device, informing it that the user should
be given access; and
5. The network device accepts the user’s connection.
If the user’s credentials are not legitimate, the RADIUS server sends the network device an
access-reject packet, instructing it to deny access to the user.
Note that in this example we show how RADIUS authenticates user access to a network device.
RADIUS can also be used to authenticate user access to an entire network. We illustrate how RADIUS
is used to authenticate network access in the next section.
6 www.juniper.net
LY
N
O
SE
U
AL
802.1X
N
802.1X is an Institute of Electrical and Electronics Engineers (IEEE) standard used for port-level access
control and authentication. 802.1X does not replace other security technologies; rather, it works
R
together with port security features, such as Dynamic Host Configuration Protocol (DHCP) snooping,
Dynamic ARP Inspection (DAI), and media access control (MAC) limiting, to guard against DoS attacks
TE
and spoofing.
The 802.1X standard is based on the Extensible Authentication Protocol (EAP), a universal
authentication framework. EAP is not an authentication mechanism by itself. Instead, EAP provides
some common functions and a negotiation method to determine the authentication mechanism (EAP
IN
method) used between hosts and the authentication server. As individual hosts are authenticated, they
can be associated with a specific profile and virtual LAN (VLAN).
A LAN configured for 802.1X authentication contains three basic components:
• Supplicant: The device being authenticated. This device is typically a user’s PC or an IP
phone.
• Authenticator: The device that prevents a supplicant’s access until it is authenticated. This
device is a switch.
• Authentication server: The authenticating device. EX Series switches support RADIUS
authentication servers for 802.1X.
To authenticate through 802.1X, supplicants require 802.1X client software. Some operating systems,
such as Windows XP, include an 802.1X client by default.
www.juniper.net 7
LY
N
O
SE
U
AL
Controlling Access
N
802.1X works in conjunction with the Extensible Authentication Protocol (EAP) standard to provide
port-based network access control. Defined by the Internet Engineering Task Force (IETF), EAP is an
R
authentication framework that ensures the secure passing and validation of network credentials. EAP
also allows for the creation of a variety of extensible access protocols, such as tunneled EAP for more
TE
flexible, expandable network access and authorization.

802.1X authenticators, such as EX Series switches, control network access by blocking all traffic to and
from unauthorized supplicants. Authenticators open access only when supplicants are authenticated.
Supplicants request network access through their attached authenticator by sending and responding to
IN
EAP over LAN (EAPOL) messages. If an authenticated supplicant no longer requires access to the
network, it notifies the authenticator, at which time the authenticator once again blocks network access
through the associated network port.
Relaying Information
When an authenticator receives authentication requests from a supplicant, those requests are received
as EAPOL messages. The authenticator extracts and relays the identity information, found within the
EAPOL message, to the authentication server as a RADIUS access request. The authenticator does not
evaluate the supplicant’s credentials but simply relays that information to the authenticating server in
an understandable format.
8 www.juniper.net
LY
N
O
SE
U
AL
Authentication Process
N
This slide shows the individual steps for the 802.1X authentication process.
R
TE
IN
www.juniper.net 9
LY
N
O
SE
U
AL
Authenticating Supplicants
N
Although the authentication server performs the actual authentication process, it is up to the
authenticator to facilitate network access for individual supplicants through the switch ports.
R
Supplicants are authenticated in either single mode, single-secure mode, or multiple mode:
• single: Authenticates only the first supplicant. All other supplicants who connect later to
TE
the port are allowed full access without any further authentication. The subsequent
supplicants utilize the first supplicant’s authentication. This setting is the default
supplicant mode on EX Series switches. It is also the recommended mode when a user’s
PC and IP telephone use the same switch port and one of the supplicants does not support
802.1X.
IN
• single-secure: Allows only one supplicant to connect to the port. No other supplicant is
allowed to connect until the first supplicant logs out.
• multiple: Allows multiple supplicants to connect to the port. Each supplicant is
authenticated individually.
10 www.juniper.net
LY
N
O
SE
U
AL
Single Supplicant Mode

N
This slide illustrates the single supplicant mode, which is the default supplicant mode for EX Series
switches.
R
TE
IN
www.juniper.net 11
LY
N
O
SE
U
AL
Single-Secure Supplicant Mode

N
This slide highlights the single-secure supplicant mode.

R
TE
IN
12 www.juniper.net
LY
N
O
SE
U
AL
Multiple Supplicant Mode

N
This slide highlights the multiple supplicant mode. The multiple supplicant mode overcomes
the security concerns of the single supplicant mode while providing more flexibility than the
R
single-secure mode. The multiple supplicant mode allows multiple supplicants to connect to
the port. Each supplicant is authenticated individually.
TE
IN
www.juniper.net 13
LY
N
O
SE
U
AL
Periodic Reauthentication
N
By default, EX Series switches functioning as 802.1X authenticators force all authenticated

supplicants to periodically reauthenticate. The default reauthentication interval is 3600 seconds
R
(1 hour). You can disable reauthentication or modify the reauthentication interval for individual ports
at the [edit protocols dot1x authenticator interface interface-name]
TE
configuration hierarchy level. The reauthentication interval range is from 1 to 65535 seconds. We
provide a configuration example on a subsequent slide.
IN
14 www.juniper.net
LY
N
O
SE
U
AL
802.1X and Mixed Environments

N
The slide addresses two common scenarios in which either the supplicant (client) or the authenticator
(switch) is not enabled for 802.1X, whereas the other component is enabled for 802.1X.
R
In the first scenario, the supplicant does not support 802.1X, but the authenticator does support
802.1X. In this case, the authenticator sends an EAP frame requesting the supplicant’s identity.
TE
Because the supplicant has no 802.1X support, it does not respond. The authenticator keeps the port in
an unauthorized state, blocking normal traffic from being switched.
In the second scenario, the authenticator does not support 802.1X, but the supplicant does support
802.1X. In this case, the supplicant sends an EAP start frame to initiate authentication. Because the
IN
authenticator is not configured for 802.1X, or does not support 802.1X, it does not respond. The
supplicant continues sending EAP start frames until it reaches the predefined limit of attempts. The
number of start attempts might vary depending on the supplicant client software. Once the predefined
limit is reached, the supplicant assumes that the link is authenticated and begins forwarding traffic.
In scenarios where the supplicant does not support 802.1X, you can permit some level of access
using the guest VLAN feature or the static MAC bypass feature. We discuss both of these features on
subsequent slides in this section.
www.juniper.net 15
LY
N
O
SE
U
AL
Dynamic VLAN Assignment

N
802.1X provides the ability to dynamically associate supplicants with a designated VLAN during the
authentication process. You can configure the RADIUS server to return VLAN attributes as part of the
R
access-accept message. For proper operation, the same VLAN assigned to the supplicant’s port by the
RADIUS server must also be configured on the switch.
TE
In addition to dynamically assigning VLANs, you can also dynamically apply firewall filters. EX Series
switches support the configuration of RADIUS server attributes specific to Juniper Networks. These
attributes are known as vendor-specific attributes (VSAs) and are described in RFC 2138. Through
VSAs, you can configure port-filtering attributes on the RADIUS server. VSAs are clear text fields sent
IN
from the RADIUS server to the switch as a result of the 802.1X authentication success or failure. The
802.1X authentication prevents unauthorized user access by blocking a supplicant at the port until
the supplicant is authenticated by the RADIUS server. The VSA attributes are interpreted by the
switch during authentication, and the switch takes appropriate actions. Implementing port-filtering
attributes with 802.1X authentication on the RADIUS server provides a central location for controlling
LAN access for supplicants.
These port-filtering attributes specific to Juniper Networks are encapsulated in a RADIUS server VSA
with the vendor ID set to the Juniper Networks ID number, 2636.
Continued on next page.
16 www.juniper.net
Dynamic VLAN Assignment (contd.)
In addition to configuring port-filtering attributes through VSAs, you can apply a port firewall filter that
has already been configured on the switch directly to the RADIUS server. Like port-filtering attributes,
the filter is applied during the 802.1X authentication process, and its actions are applied at the
switch port. Adding a port firewall filter to a RADIUS server eliminates the need to add the filter to
multiple ports and switches.
VSAs are only supported for 802.1X single-supplicant and multiple-supplicant configurations.
LY
N
O
SE
U
AL
N
R
TE
IN
www.juniper.net 17
LY
N
O
SE
U
AL
Guest VLAN
N
Guest VLANs, in conjunction with 802.1X, MAC RADIUS, and captive portal authentication, provide
secure access to the LAN for corporate guests and for end devices that fail the authentication
R
process.
When a corporate visitor attempts to authenticate on the LAN and authentication fails, the visitor is
TE
moved to a guest VLAN. A guest VLAN typically provides access only to the Internet.
A guest VLAN can also provide limited access to the LAN in cases when authentication fails for end
devices that are not visitors. When authentication fails, the switch receives an access-reject
message for the end device and determines whether a guest VLAN is configured on that port. If so, it
IN
moves that end device alone to the guest VLAN. If the access-reject message contains optional
VLAN information, then the end device is moved to the VLAN specified by the RADIUS server and not
to the locally configured guest VLAN.
Authentication can fail for many reasons. One example is when the end device does not have
supplicant software on it (for example, the end device is a device type that cannot be enabled for
802.1X, such as a printer). Another example is when the end device provides invalid credentials—a
username or password that were not authenticated by the RADIUS server.
For end devices that are not 802.1X-enabled, a guest VLAN can allow limited access to a server from
which the non-802.1X-enabled end device can download the supplicant software and attempt
authentication again.
18 www.juniper.net
LY
N
O
SE
U
AL
Server Fail Fallback

N
The server fail fallback option allows you to specify how end devices connected to the switch are
supported if the RADIUS authentication server becomes unavailable.
R
EX Series switches use authentication to implement access control in an enterprise network. If

802.1X, MAC RADIUS, or captive portal authentication are configured on the interface, end devices
TE
are evaluated at the initial connection by a RADIUS server. If the end device is configured on the
RADIUS server, the device is granted access to the LAN and the EX Series switch permits access
through the interface.
A RADIUS server timeout occurs when RADIUS authentication servers are not available to
IN
authenticate LAN access requests. The server fail fallback option allows you to specify one of the
four actions listed on the slide to be taken toward end devices awaiting authentication when a server
timeout occurs.
Server fail fallback is triggered most often during reauthentication attempts made when the RADIUS
server is no longer accessible. However, server fail fallback can also be triggered by an end device’s
first attempt at authentication through the RADIUS server. Server fail fallback allows you to specify
that an end device be moved to a specified VLAN if the switch receives an access-reject message.
The configured VLAN name overrides any attributes sent by the server.
Note that the server fail fallback options are applicable to 802.1X, MAC RADIUS, and captive portal.
We cover the MAC RADIUS and captive portal features in subsequent sections in this material.
www.juniper.net 19
LY
N
O
SE
U
AL
Static MAC Bypass

N
You can allow end devices to access the LAN without authentication through a RADIUS server by
including their MAC addresses in the static MAC bypass list. You might choose to include a device in
R
the bypass list to allow non-802.1X-enabled devices access to the LAN or to eliminate the delay that
occurs while the switch determines that a connected device is a non-802.1X-enabled host.
TE
When you configure static MAC bypass on the switch, the MAC address of the end device is first
checked in a local database (a user-configured list of MAC addresses). If a match is found, the end
device is successfully authenticated and the interface is opened up for it. No further authentication
is done for that end device. If a match is not found and 802.1X authentication is enabled on the
switch, the switch attempts to authenticate the end device through the RADIUS server or grants
IN
access through the guest VLAN, if configured. The MAC addresses can be bound to a specific
network port or associated with any network port to facilitate user mobility. We provide a
configuration example on a subsequent slide. If you bind a static MAC address to a specific port, you
must use the multiple supplicant mode:
[edit protocols dot1x]
user@switch# commit
[edit protocols dot1x authenticator static 00:26:88:02:6b:87/48 interface]
'interface ge-0/0/7.0'
Static MAC cannot be configured on interface in single or single-secure mode
error: commit failed: (statements constraint check failed)
20 www.juniper.net
LY
N
O
SE
U
AL
Configuring 802.1X: Part 1

N
In the sample configuration, we see the definition of a RADIUS server and an authentication profile. As
illustrated on the slide, the RADIUS server and authentication profile configuration is defined under the
R
[edit access] configuration hierarchy.

TE
IN
www.juniper.net 21
LY
N
O
SE
U
AL

N
This slide shows the next portion of the 802.1X configuration example. The configuration takes place
under the [edit protocols dot1x] configuration hierarchy level.
R
Note that when authenticating end-user devices through the static MAC bypass method you can specify
an individual MAC address or a prefix-range of MAC addresses as shown in the following example:
TE

user@switch# show
authenticator {
static {
IN
50:c5:8d:ba:62:05/48;
00:26:88:00:00:00/24;
}
}
...
In the preceding example the MAC address 50:c5:8d:ba:62:05/48 will be accepted along with
any MAC address in the 00:26:88:00:00:00/24 prefix range. Using a prefix range can come in
handy when you need to permit access to several devices that do not support 802.1X using the
static MAC bypass method.
22 www.juniper.net
LY
N
O
SE
U
AL

N
This slide shows the server fail fallback configuration syntax. Note that the server fail fallback options
are applicable to 802.1X, MAC RADIUS, and captive portal. We cover the MAC RADIUS and captive portal
R
features in subsequent sections in this material.

TE
IN
www.juniper.net 23
LY
N
O
SE
U
AL
Monitoring 802.1X
N
This slide displays some common operational mode commands used to monitor 802.1X.
R
TE
IN
24 www.juniper.net
LY
N
O
SE
U
AL
MAC RADIUS
N
Like 802.1X, MAC RADIUS authentication uses a centralized RADIUS server and database to
authenticate end-user devices. You can configure MAC RADIUS authentication on interfaces that are
R
connected to end-user devices that are not 802.1X-enabled but that you want to allow access to the
LAN.
TE
Because MAC RADIUS uses a centralized authentication server and database, it is more scalable
than manually defining an exclusion list (in the form of the static MAC bypass list) on individual
switches.
IN
www.juniper.net 25
LY
N
O
SE
U
AL
MAC RADIUS and 802.1X

N
You can enable multiple authentication methods on the same switch port. For example, if both
802.1X-enabled end devices and end devices that are not 802.1X-enabled connect to an interface,
R
you can configure both 802.1X and MAC RADIUS authentication methods on the interface. In this
case, the switch first attempts to authenticate using 802.1X, and if that method fails, it attempts to
authenticate the end device using MAC RADIUS authentication.
TE
When 802.1X and MAC RADIUS authentication are enabled on the same port on an EX Series switch,
the switch uses Extensible Authentication Protocol-Message Digest 5 (EAP-MD5) as its EAP method
when attempting to authenticate 802.1X-enabled devices.
IN
If you know that only non-802.1X-enabled end devices will connect to a given interface, you can
eliminate the delay that occurs while the switch determines that the end device is
non-802.1X-enabled by configuring the mac-radius restrict option. Note that the delay when
determining whether a device is 802.1X enabled can take up to 90 seconds. We highlight the use of
the restrict option on a subsequent slide.
26 www.juniper.net
LY
N
O
SE
U
AL
Configuring MAC RADIUS: Part 1

N
illustrated on the slide, the RADIUS server and authentication profile are defined under the [edit
R
access] configuration hierarchy. Note that this configuration is the same configuration required for
802.1X.
TE
IN
www.juniper.net 27
LY
N
O
SE
U
AL

N
This slide shows the next portion of the MAC RADIUS configuration example. Similar to 802.1X, the MAC
RADIUS configuration also takes place under the [edit protocols dot1x] configuration
R
hierarchy.
The illustrated example highlights the use of the restrict option. When using the MAC RADIUS
TE
restrict option, all 802.1X packets received on the associated port are dropped. In other words, a
device attempting to authenticate through that port using 802.1X will never be authenticated regardless
of the defined supplicant mode. In other words, when the restrict option is used no mix and match
of 802.1X and MAC authentication occurs on the port, even if it is configured for multi-supplicant mode.
IN
Note that the dynamic VLAN and other RADIUS attributes continue to work the same even with the
restrict option enabled.
28 www.juniper.net
LY
N
O
SE
U
AL
Monitoring MAC RADIUS

N
This slide highlights the show dot1x interface detail command which is used to verify
status information of interfaces participating in 802.1X and MAC RADIUS. The output shows that
R
MAC RADIUS is enabled and that the restrict option is set for ge-0/0/15.0.
TE
IN
www.juniper.net 29
LY
N
O
SE
U
AL
Captive Portal
N
Captive Portal is a network access control mechanism that authenticates users and permits access
to the network based on username and password. You have a couple options for implementing
R
captive portal. You can implement captive portal where the processing is handled locally on the
EX Series device except for the user authentication which is handled by a RADIUS server. The second
method utilizes a remote Junos Pulse Access Control Service device to off-load both the captive
TE
portal processing and user authentication. With this combination of products, the switch serves as
an Infranet Enforcer, that is, a policy enforcement point for the Access Control Service.
Regardless of which method you choose the functionality and configuration of captive portal are
basically the same. You enable captive portal on an individual interface. When an end-user device
IN
opens a Web browser and points to a remote website, the connected switch, with the captive portal
feature enabled, intercepts the request and presents the user with the captive portal login HTML
page. The captive portal login HTML page requests the user's username and password. If the user is
authenticated, the user's original Web-page request and subsequent access to the network is
permitted. If the user is not authenticated, the switch denies the user’s original Web-page request
along with all other network access.
This authentication process includes a number of implied requirements. For example, an end-user
device connected to a port enabled for captive portal authentication requires an IP address, gateway
services, and most likely Domain Name System (DNS) services to initiate and request HTTP services
from a remote Web server. The switch port achieves this task by allowing DHCP and DNS traffic to
flow through the port even when the end user is not authenticated.
30 www.juniper.net
LY
N
O
SE
U
AL
Authentication Exclusion List

N
In some situations, and specifically for some devices, you might need to define an authentication
exclusion list. Captive portal provides such a mechanism and it is called the authentication whitelist.
R
The authentication whitelist option is especially helpful when working with devices that do not have
HTTP capabilities, such as printers and IP phones. The captive portal authentication whitelist is
TE
similar in function to the static MAC bypass option in 802.1X. We provide a configuration example on
a subsequent slide.
IN
www.juniper.net 31
LY
N
O
SE
U
AL
Configuring Captive Portal: Part 1

N
A number of small steps are involved in ensuring captive portal is set up properly. The first step is to
ensure that the Web service on the EX Series switch is enabled. You can use HTTP or HTTPS with the
R
captive portal feature. Because of its increased security, HTTPS is recommended. Note that if HTTPS
is used you will need to generate and load a security certificate and its corresponding key on the
EX Series switch. There are currently three methods for implementing a security certificate on the EX
TE
Series switches. The fastest and easiest method is to use the default system generated certificate
which is an automatically generated self-signed certificate. After the switch is initialized, it checks for
the presence of an automatically generated self-signed certificate. If it does not find one, the switch
generates one and saves it in the file system. use the following command at the [edit system
IN
services web-management] hierarchy to enable HTTPS to use the system generated

certificate:
[edit system services web-management]
user@switch# set https system-generated-certificate
The second method is to manually generate a self signed certificate using the Junos CLI. This
method is a little more time consuming than using the automatically generated certificate but this
method allows you to determine the parameters the system will use to generate the certificate.
32 www.juniper.net
Configuring Captive Portal: Part 1 (contd.)
Generating a digital certificate is a two step process. The first step is to generate a cryptographic key
pair:
user@switch> request security pki generate-key-pair size 1024 type rsa certificate-id
my-cert
Generated key pair my-cert, key size 1024 bits
The second step is to generate the self-signed certificate. To generate the self-signed certificate
manually, include the certificate ID name, the subject of the distinguished name (DN), the domain
name, the IP address of the switch, and the e-mail address of the certificate holder:
user@switch> request security pki local-certificate generate-self-signed
certificate-id my-cert domain-name juniper.net email user@juniper.net ip-address
LY
10.210.14.131 subject "CN=BM0208124277,CN=system generated,CN=self-signed"
Self-signed certificate generated and loaded successfully
For a full list of parameters and variables you can use to generate a certificate please refer to the
documentation for your specific device and Junos version.
N
In oder to use your certificate with HTTPS you must apply the certificate to the HTTPS service. The
certificate ID you specified while generating the certificate is a unique identifier that is used to
O
enable the HTTPS service.
user@switch# set https pki-local-certificate my-cert SE
The third option for generating a security certificate and key is to utilize a separate device such as a
server running OpenSSL. An example of the command used on the server to generate a security
certificate and key follows. (Note that the name of the associated .pem file is user-defined):
user@server$openssl req -x509 -nodes -newkey rsa:1024 -keyout name-of-cert.pem -out
U
name-of-cert.pem
...
After entering this command you will be asked a number of generic questions about your locality and
AL
company. Once you answer those questions (or press Enter to skip answering those questions), the
process of generating the security certificate and key is complete. You can view the contents as
shown in the following output:
user@server$cat name-of-cert.pem
N
-----BEGIN RSA PRIVATE KEY-----

MIICXAIBAAKBgQCu5hAiBag2iezCVGE5dWoj4w1iJo1VdQNZvzMdCrmKHNrO8wnC
...
R
vETZ/wtb8wL6kFskmoEC1mP3Vnz0tnhKo+sUmwDnXT1XgBYd3dgAdHfq8Y2Spmg=
-----END RSA PRIVATE KEY-----
TE
-----BEGIN CERTIFICATE-----
MIICsDCCAhmgAwIBAgIJAJHTcY0ugTjqMA0GCSqGSIb3DQEBBAUAMEUxCzAJBgNV
...
w5WoUn9IbiCpdzOeq53oCgIz01joCQpr6hFkTz1Kpz/mS4QX+Tgx4Qq7GNMUFL4=
-----END CERTIFICATE-----
IN
Once the certificate and key are generated, you must copy the associated .pem file from the server
to your EX Series switch and associate that file with the configuration using the following command:
[edit]
user@switch# set security certificates local name-of-cert load-key-file
name-of-cert.pem
The final step is to configure the HTTPS service to use this certificate.
user@switch# set https local-certificate name-of-cert
www.juniper.net 33
LY
N
O
SE
U
AL

N
R
802.1X and MAC RADIUS.
TE
If you are implementing captive portal using a remote Junos Pulse Access Control Service device, the
configuration demonstrated on the slide is the same. The only exception is that instead of specifying a
RADIUS server’s IP address you must specify the IP address of the Junos Pulse Access Control device. In
addition to setting up the RADIUS server and authentication profile configuration you must also
configure the switch with the details for connecting to the Junos Pulse Access Control device.
IN
34 www.juniper.net
To configure the switch to work with the Access Control Service:
1. Configure the switch to use the Access Control Service for authentication and
authorization:
[edit ethernet-switching-options]
user@switch# show
uac-policy;
2. Configure the parameters used to connect to the Access Control Service MAG Series or
the IC Series NAC device including the device’s hostname, IP address, interface and
password. The IP address used should be the same IP address that you used for
specifying the authentication server. The password specified should be the password
required to connect through its administrative interface. In addition to the previously
LY
outlined mandatory infranet controller configuration parameters, you can globally
define the amount of time (in seconds) that the switch waits to receive a response from
the Access Control Service (default is 300 seconds). You can also specify the time (in
seconds) between continuity-check messages for the switch’s connection with the
N
Access Control Service (default is 30 seconds). You can specify an action for the switch
to take if a timeout occurs for the connection between the switch and the Access
Control Service. The default action is to close the session and block access to
O
resources.
[edit services unified-access-control]
user@switch# show
infranet-controller hostname {
SE
address ip-address;
interface interface-name;
password UAC-password;
}
U
timeout seconds;
interval seconds;
timeout-action action;
AL
The steps required to set up the actual Access Control Service device are outside the scope this
material. You can refer to technical documentation for the platform you are using or attend our Junos
Pulse Access Control (JPAC) course.
N
R
TE
IN
www.juniper.net 35
LY
N
O
SE
U
AL

N
The slide illustrates a sample configuration that enables the captive portal authentication feature
using HTTPS for ge-0/0/0.0. Some considerations when enabling captive portal include the
R
following:
• Captive portal can be configured only on L2 interfaces.
TE
• Captive portal does not support dynamic VLAN assignments through the RADIUS server.
• Captive portal is a supported fallback option for 802.1X.
• By default captive portal uses the single supplicant mode. You can change this default
IN
setting and instead use the single-secure or multiple supplicant mode. Note that when
an authentication whitelist is defined, you must use multiple supplicant mode for the
associated interface.
• Captive portal limits the number of user authentication attempts. The default number of
authentication attempts is three but this number can be changed using the retries
configuration option. After the specified number of retries, captive portal places the
authentication request in a holding state for a period of time (60 seconds by default).
• Upon expiry of re-authentication timer, captive portal tears down the connection. When
this tear-down occurs, the end-user device must reauthenticate. Sessions, by default,
are 3600 seconds (1 hour). You can change the default re-authentication timer using
the session-expiry configuration option for specific interfaces or for all interfaces.
36 www.juniper.net
LY
N
O
SE
U
AL

N
You have the flexibility to modify the captive portal login page and add detailed instructions or terms
and conditions related to the use of the network. This slide provides the syntax and command
R
options used to customize the captive portal login page for your environment. We illustrate a login
page with the default parameters on a subsequent slide.
TE
IN
www.juniper.net 37
LY
N
O
SE
U
AL

N
Depending on your environment, you might need to create an authentication whitelist. This slide
illustrates a sample configuration that includes an authentication whitelist. By default, captive portal
R
operates in single supplicant mode. When an authentication whitelist is defined, you must use the
multiple supplicant mode for the associated interface as illustrated on the slide for ge-0/0/1.0.
TE
IN
38 www.juniper.net
LY
N
O
SE
U
AL
Monitoring Captive Portal: Part 1

N
As with many network implementations, the true test of successful configuration is determining
whether things work from the end-user’s perspective. If the end-user attempts to open a Web page
R
associated with a remote Web server and that user is presented with the Terms and Conditions of
Use and the User Authentication pages, as shown on the slide, and, after entering the required user
name and password, is directed to the original Web page, then you know the captive portal feature is
TE
working as desired. If the user does not see the expected captive portal authentication pages or is
never redirected to the original Web page, then you will need to verify connectivity and configurations
on all participating devices including the end-user host, the switch, the RADIUS server, and possibly
even the remote Web server.
IN
www.juniper.net 39
LY
N
O
SE
U
AL

N
In addition to the verification steps highlighted on the preceding slide, you can also use various
operational commands to monitor captive portal operations. The slide highlights several show and
R
clear commands that can be useful when working with the captive portal feature.
TE
IN
40 www.juniper.net
LY
N
O
SE
U
AL
Authentication Processing
N
You can enable multiple authentication methods on EX Series switches including those illustrated on
the slide. When multiple authentication methods are enabled the switch uses a decision tree to
R
determine which method to use when authenticating a user. The next slide provides an illustration of
how this decision is made.
TE
IN
www.juniper.net 41
LY
N
O
SE
U
AL
Authentication Process Flow

N
This slide illustrates the authentication process. The authentication process resembles the following:
1. Authentication is initiated by an end device sending an EAP request or a data packet.
R
2. If the MAC address of the end device is in the static MAC bypass list or the
authentication whitelist, the switch accepts the end device without querying the
TE
authentication server and allows the end device to access the LAN.
3. If the MAC address is not in the static MAC bypass list or the authentication whitelist,
the switch checks whether an authenticator statement is configured on the interface. If
an authenticator is not configured, the switch checks for captive portal configuration. If
IN
captive portal configuration exists for the interface, skip to Step 6. If an authenticator is
configured:
a. The switch checks whether the mac-radius restrict statement is
configured on the interface. If mac-radius restrict is configured, the
switch does not attempt 802.1X authentication and skips to Step 5. If it is
configured, the switch moves to Step b.
42 www.juniper.net
Authentication Process Flow (contd.)
b. The switch sends either an EAP request (if the end device initiated contact with a
data packet) or an EAP response (if the end device initiated contact with an
EAPOL-start message).
c. If the switch receives no response, it tries sending an EAP request two more
times (a total of three attempts by default).
d. If the end device does not respond to the EAP messages sent by the switch, the
switch checks for MAC RADIUS configuration. If MAC RADIUS configuration exists,
the switch skips to Step 4. If the end device responds to the EAP messages, the
switch proceeds to step 5.
e. When an EAP request is received from the end device, the switch sends an
LY
authentication request message to the authentication server. If the
authentication server does not respond, the switch checks whether a server fail
VLAN is configured. If a server fail VLAN exists, the switch performs the
configured server fail fallback operation. If no server fail VLAN is available, the
switch skips to Step 6.
N
f. The authentication server sends an access-accept or access-reject message. If
the authentication server sends an access-reject message, the switch skips to
O
Step 8.
4. If the end device does not respond to the EAP messages, the switch checks whether
MAC RADIUS authentication is configured on the interface. If it is not configured, the
SE
5. If MAC RADIUS authentication is configured on the interface:
a. The switch sends a MAC RADIUS authentication request to the authentication
server. The switch sends only one such request. If the authentication server does
U
not respond, the switch checks whether a server fail VLAN is configured on the
switch. If a server fail VLAN is available, the switch performs the configured
server fail fallback operation. If no server fail VLAN is available, the switch skips
AL
to Step 8.
b. The authentication server sends an access-accept or access-reject message. If
the authentication server sends an access-reject message, the switch proceeds
to Step 6.
N
6. If MAC RADIUS authentication is not configured on the interface or if the authentication

server responds with an access-reject message for MAC RADIUS authentication, the
R
switch checks whether captive portal is configured on the interface. If captive portal is
not configured on the interface, the switch skips to Step 8.
7. If captive portal authentication is configured on the interface:
TE
a. The switch sends a request to the user on the end device for captive portal
authentication information.
b. The switch sends the captive portal authentication information to the
IN
authentication server.
c. The authentication server sends an access-accept or access-reject message. If
the server sends an access-reject message, the switch proceeds to Step 8.
8. The switch checks whether a guest VLAN is configured. If a guest VLAN is configured,
the switch allows the end device limited access to the LAN.
www.juniper.net 43
<Course Title>
Advanced Spanning Tree
LY
N
O
SE
U
AL
N
R
TE
IN
LY
N
O
SE
U
AL
What If...?
N
Switches flood broadcast frames and frames for unknown media access control (MAC) addresses
out all ports except the port on which those frames were received. In Layer 2 networks with
R
redundant paths, such as the one illustrated on the slide, switches will continuously flood these
types of frames throughout the network. When a frame is continuously flooded throughout a Layer 2
network, a Layer 2 loop exists. Layer 2 loops can be extremely harmful to a network’s operation and
TE
should be avoided. To avoid Layer 2 loops, you must implement a Layer 2 loop-prevention
mechanism such as the Spanning Tree Protocol (STP) or Rapid Spanning Tree Protocol (RSTP). We
discuss some alternatives to STP and RSTP in subsequent sections in this material.
IN
2 www.juniper.net
LY
N
O
SE
U
AL
Factory Default Configuration and RSTP

N
RSTP is enabled by default on EX Series switches. RSTP helps ensure a loop-free Layer 2 topology in
environments where redundant paths exist. To establish a loop-free path, RSTP elects one of the
R
participating switches as the root bridge. Based on the election results, each switch determines the
role and state of its switch ports. As illustrated on the slide, the root bridge election and
determination of every switch port’s role and state provide a loop-free path throughout the network.
TE
IN
www.juniper.net 3
LY
N
O
SE
U
AL
Test Your Knowledge: Part 1

N
This slide is designed to test your understanding of the various configuration options and how they
relate to the root bridge election process. As shown in the following output, you can use the show
R
spanning-tree bridge command to verify root bridge information:

user@DS-1> show spanning-tree bridge
TE
STP bridge parameters

Context ID : 0
Enabled protocol : RSTP
Root ID : 4096.00:26:88:02:74:90
Hello time : 2 seconds
IN
Maximum age : 20 seconds

Forward delay : 15 seconds
Message age : 0
Number of topology changes : 1
Time since last topology change : 2114 seconds
Topology change initiator : ge-0/0/1.0
Topology change last recvd. from : 00:26:88:02:6b:81
Local parameters
Bridge ID : 4096.00:26:88:02:74:90
Extended system ID : 0
Internal instance ID : 0
4 www.juniper.net
LY
N
O
SE
U
AL

N
relate to port role and state determination. As shown in the following output, you can use the show
R
spanning-tree interface command to verify spanning tree interface information:

user@DS-2> show spanning-tree interface
TE
Spanning tree interface parameters for instance 0

Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/1.0 16:514 128:514 4096.002688027490 20000 BLK ALT
ge-0/0/8.0 16:521 16:521 8192.002688026b90 20000 FWD DESG
IN
ge-0/0/10.0 128:523 16:523 32768.0019e2516580 1 FWD ROOT
user@AS-1> show spanning-tree interface

ge-0/0/8.0 16:521 128:521 4096.002688027490 2000 FWD ROOT
ge-0/0/10.0 16:523 16:523 32768.0019e2516580 2000 FWD DESG
ge-0/0/12.0 16:525 16:525 32768.0019e2516580 2000 FWD DESG
www.juniper.net 5
LY
N
O
SE
U
AL

N
relate to port role and state determination. As shown in the following output, you can use the show
R
spanning-tree interface command to verify spanning tree interface information:

user@AS-2> show spanning-tree interface
TE

ge-0/0/8.0 32:521 16:521 32768.002688026b90 20000 BLK ALT
ge-0/0/12.0 16:525 16:525 32768.0019e2516580 20000 FWD ROOT
IN
6 www.juniper.net
LY
N
O
SE
U
AL
A Limitation of STP and RSTP

N
While RSTP provides several advantages over STP neither of these protocols allow for load balancing,
which in some environments is a requirement. In environments where RSTP or STP is used, all VLANs
R
within a LAN share the same spanning tree, which limits the number of forwarding paths for data
traffic.
TE
To address this limitation, we recommend you enable the Multiple Spanning Tree Protocol (MSTP) to
provide load balancing for the configured VLANs. In environments that require interoperability with
Cisco's Per-VLAN Spanning Tree Plus (PVST+) or rapid-PVST+ (RPVST+), you should consider using
the Juniper Networks VLAN Spanning Tree Protocol (VSTP). We discuss MSTP and VSTP in
subsequent sections in this material.
IN
www.juniper.net 7
LY
N
O
SE
U
AL
MSTP
N
MSTP extends STP and RSTP functionality by mapping multiple independent spanning-tree instances
onto one physical topology. Each spanning-tree instance (STI) includes one or more VLANs. Each
R
multiple spanning tree instance (MSTI) creates a separate topology tree and you can administratively
map it to one or more VLANs. Allowing users to administratively map VLANs to MSTIs facilitates
better load sharing across redundant links within a Layer 2 switching environment.
TE
Unlike in STP and RSTP configurations, a port can belong to multiple VLANs and be dynamically
blocked in one spanning-tree instance but forwarding in another. This behavior significantly improves
network resource utilization by load-balancing across the network and maintaining switch CPU loads
at moderate levels. MSTP also leverages the fast re-convergence time of RSTP when a network,
IN
switch, or port failure occurs within a spanning-tree instance.

MSTP was originally defined in the IEEE 802.1s draft and later incorporated into the IEEE 802.1Q-2003
specification.
8 www.juniper.net
LY
N
O
SE
U
AL
MST Region
N
MSTP allows switches to be logically grouped into manageable clusters, known as multiple spanning
R
tree (MST) regions. An MST region is a group of switches that share the same region name, revision
level, and VLAN-to-instance mapping parameters.
Each MST region supports up to 64 MSTIs. MSTP greatly reduces the number of bridge protocol data
TE
units (BPDUs) on a LAN by including the spanning tree information for all MSTIs in a single BPDU. MSTP
encodes region information after the standard RSTP BPDU along with individual MSTI messages. The
MSTI configuration messages convey spanning tree information for each instance.
MSTP elects a regional root bridge for each MSTI. The regional root bridge is elected based on the
IN
configured bridge priority and calculates the spanning tree within its designated instance.
www.juniper.net 9
LY
N
O
SE
U
AL
Common Spanning Tree: Part 1

N
The common spanning tree (CST), which interconnects all MST regions as well as STP devices not bound
R
to a particular region, facilitates end-to-end paths within an MSTP environment. The CST facilitates
backward compatibility with RSTP and STP.
TE
IN
10 www.juniper.net
LY
N
O
SE
U
AL
Common Spanning Tree: Part 2

N
Because MSTP encodes region information after the standard RSTP BPDU, a switch running RSTP
R
interprets MSTP BPDUs as RSTP BPDUs. This behavior facilitates full compatibility between devices
running MSTP and devices running STP or RSTP. MSTP uses the same Ethernet frame as STP and RSTP.
However, the BPDU information in the data field is different.
TE
The first 13 fields in the MST BPDU contain similar information to what you would find in an RSTP BPDU.
In fact, an RSTP-speaking switch evaluates these fields in the same manner as it would any other RSTP
BPDU. To the outside world (other MSTI regions or standalone RSTP devices), these fields are a
representation of the virtual bridge that is an individual MSTP region. This information is used to build
IN
the CST.
www.juniper.net 11
LY
N
O
SE
U
AL
Common and Internal Spanning Tree

N
All MSTP environments contain a CST, which is used to interconnect individual MST regions and
independent STP devices. All bridges in the CST elect a single root bridge. The root bridge is responsible
R
for the path calculation for the CST. As illustrated on the slide, bridges outside of the MST region treat
each MST region as a virtual bridge, regardless of the actual number of devices participating in each
MST region.
TE
The common and internal spanning tree (CIST) is a single topology that connects all switches (RSTP
and MSTP devices) through an active topology. The CIST includes a single spanning tree as
calculated by RSTP together with the logical continuation of connectivity through MST regions. MSTP
calculates the CIST and the CIST ensures connectivity between LANs and devices within a bridged
IN
network.
Each MSTP region builds a spanning tree for the region, referred to as an internal spanning tree, based
upon the remaining BPDU fields. For a switch to participate in a region’s internal spanning tree and use
the information in this portion of the BPDU, it must be configured with the same configuration ID.
Therefore, all switches in the same region must be configured with the same configuration ID. This
approach to configuration ensures that when MSTP switches outside of the local MSTP region receive
MSTP BPDUs, those switches will evaluate only the CST-related information (illustrated on the previous
slide). Once the internal spanning tree is built, by default, all traffic on all VLANs will follow it.
12 www.juniper.net
Common and Internal Spanning Tree (contd.)
Without the use of MSTI configuration methods, traffic for all VLANs within a region flows along the
path of the internal spanning tree. To override this behavior and allow some VLANs to take one path
through the region and let others take other paths (64 paths are possible for each region), you must
configure MSTIs as part of the router MSTI configuration. The information carried in the MSTI
configuration messages allows each switch to elect root bridges, root ports, designated ports,
designated bridges, and so forth for each MSTI. Each MSTI will have one or more VLANs associated
with them. One VLAN cannot be in more than one MSTI. Notice that the MSTI messages do not carry
VLAN ID information. The VLAN-to-MSTI mappings are configured locally on each switch and each
switch configuration should use the same mappings. We evaluate MSTP configuration on EX Series
switches on a subsequent slides.
LY
N
O
SE
U
AL
N
R
TE
IN
www.juniper.net 13
LY
N
O
SE
U
AL
MSTP Configuration
N
This slide illustrates the configuration structure for MSTP along with some of the key configuration
parameters and considerations. Note that some of the MSTP configuration values must match on all
R
devices participating in the same MSTP region. The MSTP configuration values that must match
include:
TE
• Configuration name: A user-defined value used to represent the region. Note that this
value can be left blank but must match on all devices in a common region.
• Revision level: A user-defined value that represents the MSTP configuration version
number. By default this value is 0.
IN
• MSTI-to-VLAN mapping: A mapping between a specific MSTI and the VLANs that MSTI
will service. This value must match on all devices in a common MSTP region. All VLANs
not specifically mapped to a user-defined MSTI are automatically associated with
MSTI 0 (the common spanning tree instance).
14 www.juniper.net
LY
N
O
SE
U
AL
Topology and Objectives

N
This slide introduces the topology and objectives used throughout this case study.
R
TE
IN
www.juniper.net 15
LY
N
O
SE
U
AL
Configuring MSTP
N
This slide provides the configuration required on DS-1 and DS-2 to accomplish the objectives
outlined on the previous slide. Note that the configuration on AS-1, AS-2, and AS-3 is very similar to
R
that shown on the slide with the exception of the configured bridge priority values (AS-1, AS-2, and
AS-3 all use the default bridge priority of 32K).
TE
IN
16 www.juniper.net
LY
N
O
SE
U
AL
Monitoring MSTP: Part 1

N
This slide illustrates the operational-mode commands used to monitor MSTP along with a sample
output from the show spanning-tree mstp configuration command.
R
TE
IN
www.juniper.net 17
LY
N
O
SE
U
AL

N
The slide highlights the use of the show spanning-tree interface command, which you use to
verify the MSTP interface status and role assignment along with various other details.
R
TE
IN
18 www.juniper.net
LY
N
O
SE
U
AL

N
The slide highlights the show spanning-tree bridge command, which you use to display STP
bridge parameters for the CIST and individual MSTIs.
R
TE
IN
www.juniper.net 19
LY
N
O
SE
U
AL
VSTP
N
VSTP allows for spanning trees to be calculated for each VLAN. VSTP is a nonstandard protocol, yet it is
compatible with Cisco’s PVST+ and RPVST+ protocols.
R
TE
IN
20 www.juniper.net
LY
N
O
SE
U
AL
VSTP Considerations: Part 1

N
When using VSTP on EX Series switches, you can selectively configure up to 253 VLANs which map to
distinct spanning tree topologies. You can enable RSTP for all VLANs not participating in VSTP. VSTP
R
and RSTP are the only spanning-tree protocols that can be configured concurrently on an EX Series
switch. Any other combination will result in a commit error as shown below:
TE
[edit protocols]
user@switch# commit
[edit protocols]
'mstp'
Another xSTP protocol is enabled
IN
error: Another xSTP protocol is enabled

error: configuration check-out failed
Note that if your network includes 802.1D 1998 bridges, you can explicitly configure STP on those
devices. When you explicitly configure STP, the EX Series switch uses the IEEE 802.1D 2004
specification, force version 0, which is an RSTP configuration that is compatible with basic STP.
www.juniper.net 21
LY
N
O
SE
U
AL
VSTP Considerations: Part 2

N
Switches configured to run VSTP automatically assign each VLAN to one spanning-tree instance that
runs RSTP. While this approach is useful to optimize network usage in small networks with a limited
R
number of VLANs, a VSTP configuration in networks with several hundred VLANs can overload switch
CPUs. For this and other reasons, we recommend you use MSTP when possible. MSTP ensures that
your network does not slow down from the increased network traffic caused by hundreds of VLANs,
TE
each with its own spanning-tree instance. Unlike VSTP, MSTP sends a single BPDU regardless of the
number of instances used.
IN
22 www.juniper.net
LY
N
O
SE
U
AL
VSTP Configuration
N
This slide illustrates the configuration structure for VSTP along with some of the key configuration
parameters and considerations. VSTP is most similar to RSTP and uses the same terminology and
R
many of the same configuration parameters. Note that VSTP also provides for the ability to force the
version to STP. In its default form, VSTP is roughly equivalent to Cisco’s Rapid PVST+. If the version is
forced to STP, as shown on the slide, VSTP is then more similar to Cisco’s PVST+.
TE
As shown on the slide, you can configure parameters for individual or all VLANs using the vlan
option. You can also use the vlan-group option to simplify your configuration tasks when groups
of VLANs use the same parameters. When using the vlan all option, the first 253 VLANs will
participate in VSTP. All VLANs beyond the first 253 will not be supported by VSTP, but may be
IN
supported by RSTP if it is enabled.

Note that VSTP will not work correctly if VLAN information is propagated over trunk ports using MVRP.
Because MVRP does not currently support VSTP on EX Series switches, you must statically define
VLAN membership on trunk ports when VSTP is enabled.
www.juniper.net 23
LY
N
O
SE
U
AL
Topology and Objectives

N
This slide introduces the topology and objectives used throughout this case study.
R
TE
IN
24 www.juniper.net
LY
N
O
SE
U
AL
Configuring VSTP
N
This slide provides the configuration required on DS-1 and DS-2 to accomplish the objectives
outlined on the previous slide. Note that the configuration on AS-1, AS-2, and AS-3 does not need to
R
include two distinct groups, as is shown for DS-1 and DS-2, since AS-1, AS-2, and AS-3 are all using
the default bridge priority of 32K.
TE
IN
www.juniper.net 25
LY
N
O
SE
U
AL
Monitoring VSTP: Part 1

N
The slide highlights the use of the show spanning-tree interface command, which you use to
verify the VSTP interface status and role assignment along with various other details. Note that the
R
spanning tree interface information is organized by VLAN.

TE
IN
26 www.juniper.net
LY
N
O
SE
U
AL
Monitoring VSTP: Part 2

N
The slide highlights the show spanning-tree bridge command, which you use to display STP
bridge parameters for each VLAN.
R
TE
IN
www.juniper.net 27
<Course Title> and Access Control
Authentication
LY
N
O
SE
U
AL
N
R
TE
IN
LY
N
O
SE
U
AL
Understanding the Defaults

N
By default, all installed interfaces in an EX Series switch are configured for Layer 2 operations. These
Layer 2 interfaces do not enforce any end-user authentication. In some environments, this default
R
implementation can be problematic and prone to security risks. Once an end user receives a physical
connection, that user can, if proactive measures are not taken, connect a rogue switch or wireless
device to the network allowing access for unauthorized devices to the network and its resources.
TE
We discuss several authentication and access control features throughout this material that combat
the potential security risks that are inherent with the default configuration settings. Note that not all
features are currently supported on all EX Series devices. For details about your specific device, refer
to the features overview found in the technical publications.
IN
2 www.juniper.net
LY
N
O
SE
U
AL
Potential Risks
N
This slide is designed to get you thinking about potential issues that can arise from the illustrated
scenarios.
R
Among other things, you could see Layer 2 topology changes that affect network performance or
cause complete outages, unauthorized access to your network and its resources, or a network
TE
outage caused by resource overload through a denial of service (DoS) attack. In reality many
potential issues can arise if you do not protect your network and its resources. The authentication
and access control features covered in this material can help mitigate some of these potential
issues.
IN
www.juniper.net 3
LY
N
O
SE
U
AL
Controlling Network Access

N
This slide introduces a number of features that can help control network access. We cover the
features listed on the slide in detail in subsequent sections.
R
Note that each of the highlighted features authenticates users using RADIUS. One of the biggest
advantages of a RADIUS implementation is that it offers a single, centralized database of end-user
TE
accounts. Each network device can then query the RADIUS server when a given user attempts
access. If the account is available and the parameters (user name, password, and so forth) are
correct, the RADIUS server lets the network device know that the user should be granted access.
Using RADIUS to authenticate users greatly simplifies account management because you maintain
IN
and manage only a single database of users, rather than dozens or hundreds. We provide more
details about RADIUS authentication on subsequent slides in this section.
4 www.juniper.net
LY
N
O
SE
U
AL
RADIUS Overview
N
RADIUS provides authentication, authorization, and accounting (AAA) services in network

environments. When users attempt to access a network device, a RADIUS server verifies that the
R
user is legitimate (authentication). The RADIUS server can then assign certain levels of access to
network resources (authorization). Finally, the RADIUS server keeps track of how long that user
stayed connected and how much data the user sent or received (accounting).
TE
A RADIUS client is a network device, such as an EX Series switch, that makes access requests on
behalf of end users. Although RADIUS is similar in many respects to other client/server database
models, RADIUS can only provide information regarding users as a part of the authentication
process. In other words, you can not use a RADIUS database to look up information on a user or
IN
collection of users as you might with a Structured Query Language (SQL) or Lightweight Directory
Access Protocol (LDAP) database. RADIUS servers will offer up the information they contain only
within the context of the RADIUS process.
www.juniper.net 5
LY
N
O
SE
U
AL
RADIUS Traffic Flow

N
The simple traffic flow on the slide illustrates the general steps that occur when an end user
attempts to gain access to a network device (an EX Series switch in our example), as follows:
R
1. The end user makes an initial connection to the network device;

2. The network device creates and sends the RADIUS server an access-request packet,
TE
which includes the user’s account name and password (or an encrypted variant of the
password);
3. The RADIUS server consults its account database to determine if the user credentials
are legitimate;
IN
4. Assuming the information in the access-request packet is valid, the RADIUS server
returns an access-accept packet to the network device, informing it that the user should
be given access; and
5. The network device accepts the user’s connection.
If the user’s credentials are not legitimate, the RADIUS server sends the network device an
access-reject packet, instructing it to deny access to the user.
Note that in this example we show how RADIUS authenticates user access to a network device.
RADIUS can also be used to authenticate user access to an entire network. We illustrate how RADIUS
is used to authenticate network access in the next section.
6 www.juniper.net
LY
N
O
SE
U
AL
802.1X
N
802.1X is an Institute of Electrical and Electronics Engineers (IEEE) standard used for port-level access
control and authentication. 802.1X does not replace other security technologies; rather, it works
R
together with port security features, such as Dynamic Host Configuration Protocol (DHCP) snooping,
Dynamic ARP Inspection (DAI), and media access control (MAC) limiting, to guard against DoS attacks
TE
and spoofing.
The 802.1X standard is based on the Extensible Authentication Protocol (EAP), a universal
authentication framework. EAP is not an authentication mechanism by itself. Instead, EAP provides
some common functions and a negotiation method to determine the authentication mechanism (EAP
IN
method) used between hosts and the authentication server. As individual hosts are authenticated, they
can be associated with a specific profile and virtual LAN (VLAN).
A LAN configured for 802.1X authentication contains three basic components:
• Supplicant: The device being authenticated. This device is typically a user’s PC or an IP
phone.
• Authenticator: The device that prevents a supplicant’s access until it is authenticated. This
device is a switch.
• Authentication server: The authenticating device. EX Series switches support RADIUS
authentication servers for 802.1X.
To authenticate through 802.1X, supplicants require 802.1X client software. Some operating systems,
such as Windows XP, include an 802.1X client by default.
www.juniper.net 7
LY
N
O
SE
U
AL
Controlling Access
N
802.1X works in conjunction with the Extensible Authentication Protocol (EAP) standard to provide
port-based network access control. Defined by the Internet Engineering Task Force (IETF), EAP is an
R
authentication framework that ensures the secure passing and validation of network credentials. EAP
also allows for the creation of a variety of extensible access protocols, such as tunneled EAP for more
TE
flexible, expandable network access and authorization.

802.1X authenticators, such as EX Series switches, control network access by blocking all traffic to and
from unauthorized supplicants. Authenticators open access only when supplicants are authenticated.
Supplicants request network access through their attached authenticator by sending and responding to
IN
EAP over LAN (EAPOL) messages. If an authenticated supplicant no longer requires access to the
network, it notifies the authenticator, at which time the authenticator once again blocks network access
through the associated network port.
Relaying Information
When an authenticator receives authentication requests from a supplicant, those requests are received
as EAPOL messages. The authenticator extracts and relays the identity information, found within the
EAPOL message, to the authentication server as a RADIUS access request. The authenticator does not
evaluate the supplicant’s credentials but simply relays that information to the authenticating server in
an understandable format.
8 www.juniper.net
LY
N
O
SE
U
AL
Authentication Process
N
This slide shows the individual steps for the 802.1X authentication process.
R
TE
IN
www.juniper.net 9
LY
N
O
SE
U
AL
Authenticating Supplicants
N
Although the authentication server performs the actual authentication process, it is up to the
authenticator to facilitate network access for individual supplicants through the switch ports.
R
Supplicants are authenticated in either single mode, single-secure mode, or multiple mode:
• single: Authenticates only the first supplicant. All other supplicants who connect later to
TE
the port are allowed full access without any further authentication. The subsequent
supplicants utilize the first supplicant’s authentication. This setting is the default
supplicant mode on EX Series switches. It is also the recommended mode when a user’s
PC and IP telephone use the same switch port and one of the supplicants does not support
802.1X.
IN
• single-secure: Allows only one supplicant to connect to the port. No other supplicant is
allowed to connect until the first supplicant logs out.
• multiple: Allows multiple supplicants to connect to the port. Each supplicant is
authenticated individually.
10 www.juniper.net
LY
N
O
SE
U
AL
Single Supplicant Mode

N
This slide illustrates the single supplicant mode, which is the default supplicant mode for EX Series
switches.
R
TE
IN
www.juniper.net 11
LY
N
O
SE
U
AL
Single-Secure Supplicant Mode

N
This slide highlights the single-secure supplicant mode.

R
TE
IN
12 www.juniper.net
LY
N
O
SE
U
AL
Multiple Supplicant Mode

N
This slide highlights the multiple supplicant mode. The multiple supplicant mode overcomes
the security concerns of the single supplicant mode while providing more flexibility than the
R
single-secure mode. The multiple supplicant mode allows multiple supplicants to connect to
the port. Each supplicant is authenticated individually.
TE
IN
www.juniper.net 13
LY
N
O
SE
U
AL
Periodic Reauthentication
N
By default, EX Series switches functioning as 802.1X authenticators force all authenticated

supplicants to periodically reauthenticate. The default reauthentication interval is 3600 seconds
R
(1 hour). You can disable reauthentication or modify the reauthentication interval for individual ports
at the [edit protocols dot1x authenticator interface interface-name]
TE
configuration hierarchy level. The reauthentication interval range is from 1 to 65535 seconds. We
provide a configuration example on a subsequent slide.
IN
14 www.juniper.net
LY
N
O
SE
U
AL
802.1X and Mixed Environments

N
The slide addresses two common scenarios in which either the supplicant (client) or the authenticator
(switch) is not enabled for 802.1X, whereas the other component is enabled for 802.1X.
R
In the first scenario, the supplicant does not support 802.1X, but the authenticator does support
802.1X. In this case, the authenticator sends an EAP frame requesting the supplicant’s identity.
TE
Because the supplicant has no 802.1X support, it does not respond. The authenticator keeps the port in
an unauthorized state, blocking normal traffic from being switched.
In the second scenario, the authenticator does not support 802.1X, but the supplicant does support
802.1X. In this case, the supplicant sends an EAP start frame to initiate authentication. Because the
IN
authenticator is not configured for 802.1X, or does not support 802.1X, it does not respond. The
supplicant continues sending EAP start frames until it reaches the predefined limit of attempts. The
number of start attempts might vary depending on the supplicant client software. Once the predefined
limit is reached, the supplicant assumes that the link is authenticated and begins forwarding traffic.
In scenarios where the supplicant does not support 802.1X, you can permit some level of access
using the guest VLAN feature or the static MAC bypass feature. We discuss both of these features on
subsequent slides in this section.
www.juniper.net 15
LY
N
O
SE
U
AL
Dynamic VLAN Assignment

N
802.1X provides the ability to dynamically associate supplicants with a designated VLAN during the
authentication process. You can configure the RADIUS server to return VLAN attributes as part of the
R
access-accept message. For proper operation, the same VLAN assigned to the supplicant’s port by the
RADIUS server must also be configured on the switch.
TE
In addition to dynamically assigning VLANs, you can also dynamically apply firewall filters. EX Series
switches support the configuration of RADIUS server attributes specific to Juniper Networks. These
attributes are known as vendor-specific attributes (VSAs) and are described in RFC 2138. Through
VSAs, you can configure port-filtering attributes on the RADIUS server. VSAs are clear text fields sent
IN
from the RADIUS server to the switch as a result of the 802.1X authentication success or failure. The
802.1X authentication prevents unauthorized user access by blocking a supplicant at the port until
the supplicant is authenticated by the RADIUS server. The VSA attributes are interpreted by the
switch during authentication, and the switch takes appropriate actions. Implementing port-filtering
attributes with 802.1X authentication on the RADIUS server provides a central location for controlling
LAN access for supplicants.
These port-filtering attributes specific to Juniper Networks are encapsulated in a RADIUS server VSA
with the vendor ID set to the Juniper Networks ID number, 2636.
16 www.juniper.net
Dynamic VLAN Assignment (contd.)
In addition to configuring port-filtering attributes through VSAs, you can apply a port firewall filter that
has already been configured on the switch directly to the RADIUS server. Like port-filtering attributes,
the filter is applied during the 802.1X authentication process, and its actions are applied at the
switch port. Adding a port firewall filter to a RADIUS server eliminates the need to add the filter to
multiple ports and switches.
VSAs are only supported for 802.1X single-supplicant and multiple-supplicant configurations.
LY
N
O
SE
U
AL
N
R
TE
IN
www.juniper.net 17
LY
N
O
SE
U
AL
Guest VLAN
N
Guest VLANs, in conjunction with 802.1X, MAC RADIUS, and captive portal authentication, provide
secure access to the LAN for corporate guests and for end devices that fail the authentication
R
process.
When a corporate visitor attempts to authenticate on the LAN and authentication fails, the visitor is
TE
moved to a guest VLAN. A guest VLAN typically provides access only to the Internet.
A guest VLAN can also provide limited access to the LAN in cases when authentication fails for end
devices that are not visitors. When authentication fails, the switch receives an access-reject
message for the end device and determines whether a guest VLAN is configured on that port. If so, it
IN
moves that end device alone to the guest VLAN. If the access-reject message contains optional
VLAN information, then the end device is moved to the VLAN specified by the RADIUS server and not
to the locally configured guest VLAN.
Authentication can fail for many reasons. One example is when the end device does not have
supplicant software on it (for example, the end device is a device type that cannot be enabled for
802.1X, such as a printer). Another example is when the end device provides invalid credentials—a
username or password that were not authenticated by the RADIUS server.
For end devices that are not 802.1X-enabled, a guest VLAN can allow limited access to a server from
which the non-802.1X-enabled end device can download the supplicant software and attempt
authentication again.
18 www.juniper.net
LY
N
O
SE
U
AL
Server Fail Fallback

N
The server fail fallback option allows you to specify how end devices connected to the switch are
supported if the RADIUS authentication server becomes unavailable.
R
EX Series switches use authentication to implement access control in an enterprise network. If

802.1X, MAC RADIUS, or captive portal authentication are configured on the interface, end devices
TE
are evaluated at the initial connection by a RADIUS server. If the end device is configured on the
RADIUS server, the device is granted access to the LAN and the EX Series switch permits access
through the interface.
A RADIUS server timeout occurs when RADIUS authentication servers are not available to
IN
authenticate LAN access requests. The server fail fallback option allows you to specify one of the
four actions listed on the slide to be taken toward end devices awaiting authentication when a server
timeout occurs.
Server fail fallback is triggered most often during reauthentication attempts made when the RADIUS
server is no longer accessible. However, server fail fallback can also be triggered by an end device’s
first attempt at authentication through the RADIUS server. Server fail fallback allows you to specify
that an end device be moved to a specified VLAN if the switch receives an access-reject message.
The configured VLAN name overrides any attributes sent by the server.
Note that the server fail fallback options are applicable to 802.1X, MAC RADIUS, and captive portal.
We cover the MAC RADIUS and captive portal features in subsequent sections in this material.
www.juniper.net 19
LY
N
O
SE
U
AL
Static MAC Bypass

N
You can allow end devices to access the LAN without authentication through a RADIUS server by
including their MAC addresses in the static MAC bypass list. You might choose to include a device in
R
the bypass list to allow non-802.1X-enabled devices access to the LAN or to eliminate the delay that
occurs while the switch determines that a connected device is a non-802.1X-enabled host.
TE
When you configure static MAC bypass on the switch, the MAC address of the end device is first
checked in a local database (a user-configured list of MAC addresses). If a match is found, the end
device is successfully authenticated and the interface is opened up for it. No further authentication
is done for that end device. If a match is not found and 802.1X authentication is enabled on the
switch, the switch attempts to authenticate the end device through the RADIUS server or grants
IN
access through the guest VLAN, if configured. The MAC addresses can be bound to a specific
network port or associated with any network port to facilitate user mobility. We provide a
configuration example on a subsequent slide. If you bind a static MAC address to a specific port, you
must use the multiple supplicant mode:
user@switch# commit
[edit protocols dot1x authenticator static 00:26:88:02:6b:87/48 interface]
'interface ge-0/0/7.0'
Static MAC cannot be configured on interface in single or single-secure mode
error: commit failed: (statements constraint check failed)
20 www.juniper.net
LY
N
O
SE
U
AL

N
illustrated on the slide, the RADIUS server and authentication profile configuration is defined under the
R
[edit access] configuration hierarchy.

TE
IN
www.juniper.net 21
LY
N
O
SE
U
AL

N
This slide shows the next portion of the 802.1X configuration example. The configuration takes place
under the [edit protocols dot1x] configuration hierarchy level.
R
Note that when authenticating end-user devices through the static MAC bypass method you can specify
an individual MAC address or a prefix-range of MAC addresses as shown in the following example:
TE

user@switch# show
authenticator {
static {
IN
50:c5:8d:ba:62:05/48;
00:26:88:00:00:00/24;
}
}
...
In the preceding example the MAC address 50:c5:8d:ba:62:05/48 will be accepted along with
any MAC address in the 00:26:88:00:00:00/24 prefix range. Using a prefix range can come in
handy when you need to permit access to several devices that do not support 802.1X using the
static MAC bypass method.
22 www.juniper.net
LY
N
O
SE
U
AL

N
This slide shows the server fail fallback configuration syntax. Note that the server fail fallback options
are applicable to 802.1X, MAC RADIUS, and captive portal. We cover the MAC RADIUS and captive portal
R
features in subsequent sections in this material.

TE
IN
www.juniper.net 23
LY
N
O
SE
U
AL
Monitoring 802.1X
N
This slide displays some common operational mode commands used to monitor 802.1X.
R
TE
IN
24 www.juniper.net
LY
N
O
SE
U
AL
MAC RADIUS
N
Like 802.1X, MAC RADIUS authentication uses a centralized RADIUS server and database to
authenticate end-user devices. You can configure MAC RADIUS authentication on interfaces that are
R
connected to end-user devices that are not 802.1X-enabled but that you want to allow access to the
LAN.
TE
Because MAC RADIUS uses a centralized authentication server and database, it is more scalable
than manually defining an exclusion list (in the form of the static MAC bypass list) on individual
switches.
IN
www.juniper.net 25
LY
N
O
SE
U
AL
MAC RADIUS and 802.1X

N
You can enable multiple authentication methods on the same switch port. For example, if both
802.1X-enabled end devices and end devices that are not 802.1X-enabled connect to an interface,
R
you can configure both 802.1X and MAC RADIUS authentication methods on the interface. In this
case, the switch first attempts to authenticate using 802.1X, and if that method fails, it attempts to
authenticate the end device using MAC RADIUS authentication.
TE
When 802.1X and MAC RADIUS authentication are enabled on the same port on an EX Series switch,
the switch uses Extensible Authentication Protocol-Message Digest 5 (EAP-MD5) as its EAP method
when attempting to authenticate 802.1X-enabled devices.
IN
If you know that only non-802.1X-enabled end devices will connect to a given interface, you can
eliminate the delay that occurs while the switch determines that the end device is
non-802.1X-enabled by configuring the mac-radius restrict option. Note that the delay when
determining whether a device is 802.1X enabled can take up to 90 seconds. We highlight the use of
the restrict option on a subsequent slide.
26 www.juniper.net
LY
N
O
SE
U
AL

N
R
802.1X.
TE
IN
www.juniper.net 27
LY
N
O
SE
U
AL

N
This slide shows the next portion of the MAC RADIUS configuration example. Similar to 802.1X, the MAC
RADIUS configuration also takes place under the [edit protocols dot1x] configuration
R
hierarchy.
The illustrated example highlights the use of the restrict option. When using the MAC RADIUS
TE
restrict option, all 802.1X packets received on the associated port are dropped. In other words, a
device attempting to authenticate through that port using 802.1X will never be authenticated regardless
of the defined supplicant mode. In other words, when the restrict option is used no mix and match
of 802.1X and MAC authentication occurs on the port, even if it is configured for multi-supplicant mode.
IN
Note that the dynamic VLAN and other RADIUS attributes continue to work the same even with the
restrict option enabled.
28 www.juniper.net
LY
N
O
SE
U
AL
Monitoring MAC RADIUS

N
This slide highlights the show dot1x interface detail command which is used to verify
status information of interfaces participating in 802.1X and MAC RADIUS. The output shows that
R
MAC RADIUS is enabled and that the restrict option is set for ge-0/0/15.0.
TE
IN
www.juniper.net 29
LY
N
O
SE
U
AL
Captive Portal
N
Captive Portal is a network access control mechanism that authenticates users and permits access
to the network based on username and password. You have a couple options for implementing
R
captive portal. You can implement captive portal where the processing is handled locally on the
EX Series device except for the user authentication which is handled by a RADIUS server. The second
method utilizes a remote Junos Pulse Access Control Service device to off-load both the captive
TE
portal processing and user authentication. With this combination of products, the switch serves as
an Infranet Enforcer, that is, a policy enforcement point for the Access Control Service.
Regardless of which method you choose the functionality and configuration of captive portal are
basically the same. You enable captive portal on an individual interface. When an end-user device
IN
opens a Web browser and points to a remote website, the connected switch, with the captive portal
feature enabled, intercepts the request and presents the user with the captive portal login HTML
page. The captive portal login HTML page requests the user's username and password. If the user is
authenticated, the user's original Web-page request and subsequent access to the network is
permitted. If the user is not authenticated, the switch denies the user’s original Web-page request
along with all other network access.
This authentication process includes a number of implied requirements. For example, an end-user
device connected to a port enabled for captive portal authentication requires an IP address, gateway
services, and most likely Domain Name System (DNS) services to initiate and request HTTP services
from a remote Web server. The switch port achieves this task by allowing DHCP and DNS traffic to
flow through the port even when the end user is not authenticated.
30 www.juniper.net
LY
N
O
SE
U
AL
Authentication Exclusion List

N
In some situations, and specifically for some devices, you might need to define an authentication
exclusion list. Captive portal provides such a mechanism and it is called the authentication whitelist.
R
The authentication whitelist option is especially helpful when working with devices that do not have
HTTP capabilities, such as printers and IP phones. The captive portal authentication whitelist is
TE
similar in function to the static MAC bypass option in 802.1X. We provide a configuration example on
a subsequent slide.
IN
www.juniper.net 31
LY
N
O
SE
U
AL

N
A number of small steps are involved in ensuring captive portal is set up properly. The first step is to
ensure that the Web service on the EX Series switch is enabled. You can use HTTP or HTTPS with the
R
captive portal feature. Because of its increased security, HTTPS is recommended. Note that if HTTPS
is used you will need to generate and load a security certificate and its corresponding key on the
EX Series switch. There are currently three methods for implementing a security certificate on the EX
TE
Series switches. The fastest and easiest method is to use the default system generated certificate
which is an automatically generated self-signed certificate. After the switch is initialized, it checks for
the presence of an automatically generated self-signed certificate. If it does not find one, the switch
generates one and saves it in the file system. use the following command at the [edit system
IN
services web-management] hierarchy to enable HTTPS to use the system generated

certificate:
user@switch# set https system-generated-certificate
The second method is to manually generate a self signed certificate using the Junos CLI. This
method is a little more time consuming than using the automatically generated certificate but this
method allows you to determine the parameters the system will use to generate the certificate.
32 www.juniper.net
Generating a digital certificate is a two step process. The first step is to generate a cryptographic key
pair:
user@switch> request security pki generate-key-pair size 1024 type rsa certificate-id
my-cert
Generated key pair my-cert, key size 1024 bits
The second step is to generate the self-signed certificate. To generate the self-signed certificate
manually, include the certificate ID name, the subject of the distinguished name (DN), the domain
name, the IP address of the switch, and the e-mail address of the certificate holder:
user@switch> request security pki local-certificate generate-self-signed
certificate-id my-cert domain-name juniper.net email user@juniper.net ip-address
LY
10.210.14.131 subject "CN=BM0208124277,CN=system generated,CN=self-signed"
Self-signed certificate generated and loaded successfully
For a full list of parameters and variables you can use to generate a certificate please refer to the
documentation for your specific device and Junos version.
N
In oder to use your certificate with HTTPS you must apply the certificate to the HTTPS service. The
certificate ID you specified while generating the certificate is a unique identifier that is used to
O
enable the HTTPS service.
user@switch# set https pki-local-certificate my-cert SE
The third option for generating a security certificate and key is to utilize a separate device such as a
server running OpenSSL. An example of the command used on the server to generate a security
certificate and key follows. (Note that the name of the associated .pem file is user-defined):
user@server$openssl req -x509 -nodes -newkey rsa:1024 -keyout name-of-cert.pem -out
U
name-of-cert.pem
...
After entering this command you will be asked a number of generic questions about your locality and
AL
company. Once you answer those questions (or press Enter to skip answering those questions), the
process of generating the security certificate and key is complete. You can view the contents as
shown in the following output:
user@server$cat name-of-cert.pem
N
-----BEGIN RSA PRIVATE KEY-----

MIICXAIBAAKBgQCu5hAiBag2iezCVGE5dWoj4w1iJo1VdQNZvzMdCrmKHNrO8wnC
...
R
vETZ/wtb8wL6kFskmoEC1mP3Vnz0tnhKo+sUmwDnXT1XgBYd3dgAdHfq8Y2Spmg=
-----END RSA PRIVATE KEY-----
TE
-----BEGIN CERTIFICATE-----
MIICsDCCAhmgAwIBAgIJAJHTcY0ugTjqMA0GCSqGSIb3DQEBBAUAMEUxCzAJBgNV
...
w5WoUn9IbiCpdzOeq53oCgIz01joCQpr6hFkTz1Kpz/mS4QX+Tgx4Qq7GNMUFL4=
-----END CERTIFICATE-----
IN
Once the certificate and key are generated, you must copy the associated .pem file from the server
to your EX Series switch and associate that file with the configuration using the following command:
[edit]
user@switch# set security certificates local name-of-cert load-key-file
name-of-cert.pem
The final step is to configure the HTTPS service to use this certificate.
user@switch# set https local-certificate name-of-cert
www.juniper.net 33
LY
N
O
SE
U
AL

N
R
802.1X and MAC RADIUS.
TE
If you are implementing captive portal using a remote Junos Pulse Access Control Service device, the
configuration demonstrated on the slide is the same. The only exception is that instead of specifying a
RADIUS server’s IP address you must specify the IP address of the Junos Pulse Access Control device. In
addition to setting up the RADIUS server and authentication profile configuration you must also
configure the switch with the details for connecting to the Junos Pulse Access Control device.
IN
34 www.juniper.net
To configure the switch to work with the Access Control Service:
1. Configure the switch to use the Access Control Service for authentication and
authorization:
[edit ethernet-switching-options]
user@switch# show
uac-policy;
2. Configure the parameters used to connect to the Access Control Service MAG Series or
the IC Series NAC device including the device’s hostname, IP address, interface and
password. The IP address used should be the same IP address that you used for
specifying the authentication server. The password specified should be the password
required to connect through its administrative interface. In addition to the previously
LY
outlined mandatory infranet controller configuration parameters, you can globally
define the amount of time (in seconds) that the switch waits to receive a response from
the Access Control Service (default is 300 seconds). You can also specify the time (in
seconds) between continuity-check messages for the switch’s connection with the
N
Access Control Service (default is 30 seconds). You can specify an action for the switch
to take if a timeout occurs for the connection between the switch and the Access
Control Service. The default action is to close the session and block access to
O
resources.
[edit services unified-access-control]
user@switch# show
infranet-controller hostname {
SE
address ip-address;
interface interface-name;
password UAC-password;
}
U
timeout seconds;
interval seconds;
timeout-action action;
AL
The steps required to set up the actual Access Control Service device are outside the scope this
material. You can refer to technical documentation for the platform you are using or attend our Junos
Pulse Access Control (JPAC) course.
N
R
TE
IN
www.juniper.net 35
LY
N
O
SE
U
AL

N
The slide illustrates a sample configuration that enables the captive portal authentication feature
using HTTPS for ge-0/0/0.0. Some considerations when enabling captive portal include the
R
following:
• Captive portal can be configured only on L2 interfaces.
TE
• Captive portal does not support dynamic VLAN assignments through the RADIUS server.
• Captive portal is a supported fallback option for 802.1X.
• By default captive portal uses the single supplicant mode. You can change this default
IN
setting and instead use the single-secure or multiple supplicant mode. Note that when
an authentication whitelist is defined, you must use multiple supplicant mode for the
associated interface.
• Captive portal limits the number of user authentication attempts. The default number of
authentication attempts is three but this number can be changed using the retries
configuration option. After the specified number of retries, captive portal places the
authentication request in a holding state for a period of time (60 seconds by default).
• Upon expiry of re-authentication timer, captive portal tears down the connection. When
this tear-down occurs, the end-user device must reauthenticate. Sessions, by default,
are 3600 seconds (1 hour). You can change the default re-authentication timer using
the session-expiry configuration option for specific interfaces or for all interfaces.
36 www.juniper.net
LY
N
O
SE
U
AL

N
You have the flexibility to modify the captive portal login page and add detailed instructions or terms
and conditions related to the use of the network. This slide provides the syntax and command
R
options used to customize the captive portal login page for your environment. We illustrate a login
page with the default parameters on a subsequent slide.
TE
IN
www.juniper.net 37
LY
N
O
SE
U
AL

N
Depending on your environment, you might need to create an authentication whitelist. This slide
illustrates a sample configuration that includes an authentication whitelist. By default, captive portal
R
operates in single supplicant mode. When an authentication whitelist is defined, you must use the
multiple supplicant mode for the associated interface as illustrated on the slide for ge-0/0/1.0.
TE
IN
38 www.juniper.net
LY
N
O
SE
U
AL

N
As with many network implementations, the true test of successful configuration is determining
whether things work from the end-user’s perspective. If the end-user attempts to open a Web page
R
associated with a remote Web server and that user is presented with the Terms and Conditions of
Use and the User Authentication pages, as shown on the slide, and, after entering the required user
name and password, is directed to the original Web page, then you know the captive portal feature is
TE
working as desired. If the user does not see the expected captive portal authentication pages or is
never redirected to the original Web page, then you will need to verify connectivity and configurations
on all participating devices including the end-user host, the switch, the RADIUS server, and possibly
even the remote Web server.
IN
www.juniper.net 39
LY
N
O
SE
U
AL

N
In addition to the verification steps highlighted on the preceding slide, you can also use various
operational commands to monitor captive portal operations. The slide highlights several show and
R
clear commands that can be useful when working with the captive portal feature.
TE
IN
40 www.juniper.net
LY
N
O
SE
U
AL
Authentication Processing
N
You can enable multiple authentication methods on EX Series switches including those illustrated on
the slide. When multiple authentication methods are enabled the switch uses a decision tree to
R
determine which method to use when authenticating a user. The next slide provides an illustration of
how this decision is made.
TE
IN
www.juniper.net 41
LY
N
O
SE
U
AL
Authentication Process Flow

N
This slide illustrates the authentication process. The authentication process resembles the following:
1. Authentication is initiated by an end device sending an EAP request or a data packet.
R
2. If the MAC address of the end device is in the static MAC bypass list or the
authentication whitelist, the switch accepts the end device without querying the
TE
authentication server and allows the end device to access the LAN.
3. If the MAC address is not in the static MAC bypass list or the authentication whitelist,
the switch checks whether an authenticator statement is configured on the interface. If
an authenticator is not configured, the switch checks for captive portal configuration. If
IN
captive portal configuration exists for the interface, skip to Step 6. If an authenticator is
configured:
a. The switch checks whether the mac-radius restrict statement is
configured on the interface. If mac-radius restrict is configured, the
switch does not attempt 802.1X authentication and skips to Step 5. If it is
configured, the switch moves to Step b.
42 www.juniper.net
Authentication Process Flow (contd.)
b. The switch sends either an EAP request (if the end device initiated contact with a
data packet) or an EAP response (if the end device initiated contact with an
EAPOL-start message).
c. If the switch receives no response, it tries sending an EAP request two more
times (a total of three attempts by default).
d. If the end device does not respond to the EAP messages sent by the switch, the
switch checks for MAC RADIUS configuration. If MAC RADIUS configuration exists,
the switch skips to Step 4. If the end device responds to the EAP messages, the
switch proceeds to step 5.
e. When an EAP request is received from the end device, the switch sends an
LY
authentication request message to the authentication server. If the
authentication server does not respond, the switch checks whether a server fail
VLAN is configured. If a server fail VLAN exists, the switch performs the
configured server fail fallback operation. If no server fail VLAN is available, the
N
f. The authentication server sends an access-accept or access-reject message. If
the authentication server sends an access-reject message, the switch skips to
O
Step 8.
4. If the end device does not respond to the EAP messages, the switch checks whether
MAC RADIUS authentication is configured on the interface. If it is not configured, the
SE
5. If MAC RADIUS authentication is configured on the interface:
a. The switch sends a MAC RADIUS authentication request to the authentication
server. The switch sends only one such request. If the authentication server does
U
not respond, the switch checks whether a server fail VLAN is configured on the
switch. If a server fail VLAN is available, the switch performs the configured
server fail fallback operation. If no server fail VLAN is available, the switch skips
AL
to Step 8.
b. The authentication server sends an access-accept or access-reject message. If
the authentication server sends an access-reject message, the switch proceeds
to Step 6.
N
6. If MAC RADIUS authentication is not configured on the interface or if the authentication

server responds with an access-reject message for MAC RADIUS authentication, the
R
switch checks whether captive portal is configured on the interface. If captive portal is
not configured on the interface, the switch skips to Step 8.
7. If captive portal authentication is configured on the interface:
TE
a. The switch sends a request to the user on the end device for captive portal
authentication information.
b. The switch sends the captive portal authentication information to the
IN
authentication server.
c. The authentication server sends an access-accept or access-reject message. If
the server sends an access-reject message, the switch proceeds to Step 8.
8. The switch checks whether a guest VLAN is configured. If a guest VLAN is configured,
the switch allows the end device limited access to the LAN.
www.juniper.net 43
<Course Title>
Deploying IP Telephony Features
LY
N
O
SE
U
AL
N
R
TE
IN
LY
N
O
SE
U
AL
Common Deployment Scenarios

N
This slide illustrates two common IP telephony deployment scenarios. In the first deployment
scenario, a single switch port is used to connect the end-user’s IP phone and computer. In the
R
second deployment scenario, two switch ports are used: one switch port for the user’s IP phone and
the second switch port for the same user’s computer. Each deployment scenario has its own set of
advantages and disadvantages, but scenario one is the clear winner for reasons explained on the
TE
next page.
IN
2 www.juniper.net
LY
N
O
SE
U
AL
Most Common Deployment Scenario

N
The most common enterprise IP telephony deployment consists of IP phones and end-host devices
connected in series and attached to a single switch port. This design reduces switch port
R
requirements by allowing multiple end-user devices to share a single connection rather than occupy
their own individual switch ports. This approach reduces the total number of required switch ports
and switches as well as capital and operational expenses.
TE
When IP phones and end-host devices share a common switch port, the sound quality on IP phone
calls might suffer when large bursts of data traffic consume the available bandwidth. When there is
not enough bandwidth for voice traffic, the resulting congestion leads to packet loss or delay. While
packet loss and delay might be acceptable for data traffic it is not typically acceptable for voice
IN
traffic because of its quality requirements. To overcome this problem, EX Series switches support a
number of features that allow you to treat voice traffic with a higher level of service. These features
include Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED), voice virtual LAN
(VLAN), and class of service (CoS). Although not strictly required for all IP telephony deployments,
Power over Ethernet (PoE) is also another commonly used feature in environments that include IP
telephony services. We cover PoE in the next section.
www.juniper.net 3
LY
N
O
SE
U
AL
Power over Ethernet

N
PoE is defined in the Institute of Electrical and Electronics Engineers (IEEE) 802.3af specification. PoE
allows both data and electric power to pass over a copper Ethernet LAN cable. This technology allows
R
voice over IP (VoIP) telephones, wireless access points, video cameras, and point-of-sale devices to
safely receive power from the same access ports through which network access is provided. EX Series
TE
Ethernet Switches provide either 8, 24, or 48 PoE ports.

A PoE deployment consists of two primary components: the power sourcing equipment (PSE) and the
powered device (PD). The PSE is any device that provides power in a PoE implementation. EX Series
switches are considered PSE devices because they include PoE ports that distribute power. A PD is a
IN
device powered by a PSE. These devices might include VoIP telephones, wireless access points, video
cameras, and point-of-sale devices.
4 www.juniper.net
LY
N
O
SE
U
AL
PoE and PoE+

N
PoE and Power over Ethernet Plus (PoE+) permit electric power, along with data, to be passed over a
copper Ethernet LAN cable. Powered devices that support PoE or PoE+ can receive power safely from
R
the same access ports that are used to connect personal computers to the network.
PoE was first defined in the IEEE 802.3af standard. In this standard, the amount of power that can
TE
be supplied to a powered device is limited to 15.4 W. PoE+, which was defined in the later IEEE
802.3at standard, increases the amount of power to 30 W. The PoE+ standard provides support for
legacy PoE devices—an IEEE 802.3af (PoE) powered device can operate normally when connected to
IEEE 802.3at (PoE+) power sourcing equipment.
IN
Whether an EX Series switch supports PoE, PoE+, or neither depends on the switch model. Consult
your product-specific documentation for PoE support information.
www.juniper.net 5
LY
N
O
SE
U
AL
PoE Power Budget

N
EX Series switches include a control mechanism for managing PoE operations. This control
mechanism is known as the PoE controller. The PoE controller allocates power to the PoE ports from
R
a set PoE power budget (pool of power that can be allocated). The PoE power budget varies
depending on the switch model and, for switches that support power supplies of different capacities,
the capacity of the installed power supply. For example, an EX Series switch with a 320 W power
TE
supply has a PoE power budget of 130 W, while with a 600 W power supply it has a PoE power
budget of 410 W.
In switches that support power supplies of different capacities, if you change your existing power
supply to a lower-capacity power supply, the PoE power budget might no longer be sufficient to power
IN
all the PoE ports on the switch. If your switch supports redundant power supplies and you have
installed power supplies of different capacities, the PoE power budget is based on the wattage of the
lower-capacity power supply. The number of PoE ports on the switch cannot be increased by
installing a larger power supply.
6 www.juniper.net
LY
N
O
SE
U
AL
Power Management Modes

N
EX Series switches support the static and class power management modes. The mode used
determines how the maximum power for a PoE interface is derived and how power is allocated to the
R
PoE interfaces.
With the static mode, you specify the maximum power for each PoE interface. The PoE controller
TE
then allocates this amount of power to the interface from its total budget. For example, if you specify
a maximum value of 8.0 W for ge-0/0/3, the PoE controller allocates 8.0 W out of its total power
budget for the interface. This amount is allocated to the interface whether a powered device is
connected to the interface or whether the connected powered device uses less power than 8.0 W.
IN
With the class power management mode the maximum power for an interface is determined by the
class of the connected powered device. The table on the slide lists the classes of powered devices
and their associated power levels. When a powered device connects to power sourcing equipment
(EX Series switch) it communicates its class information to the PoE controller on the switch. The PoE
controller then allocates the maximum power required by the class to the PoE interface. It does not
allocate power to an interface until a powered device is connected. Class 0 is the default class for
powered devices that do not provide class information. Class 4 powered devices are supported only
by switches that support IEEE 802.3at (PoE+). Check your product-specific documentation for
support information.
www.juniper.net 7
Power Management Modes (contd.)
For switches that support IEEE 802.3af (PoE), the maximum power permitted on any interface is
15.4 W. This wattage guarantees that, after line loss, the powered device receives 12.95 W, which is
the maximum required by 802.3af-compliant powered devices. For switches that support IEEE
802.3at (PoE+), the maximum power permitted on any interface is 30.0 W. This wattage guarantees
that, after line loss, the powered device receives 25.5 W, which is the maximum required by
802.3at-compliant powered devices.
LY
N
O
SE
U
AL
N
R
TE
IN
8 www.juniper.net
LY
N
O
SE
U
AL
Configuring PoE
N
The slide illustrates the basic hierarchy and configuration options for PoE. The management option
designates the way that the switch's PoE controller allocates power to the PoE interfaces. EX Series
R
switches support the class and static management modes. The guard-band option reserves a
specified amount of power (in watts) out of the PoE power budget in case of a spike in PoE consumption.
TE
IN
www.juniper.net 9
LY
N
O
SE
U
AL
Monitoring PoE: Part 1

N
This slide and the next highlight some key operational-mode commands used to monitor PoE. Use the
show chassis hardware command to determine the PoE capabilities of an EX Series switch. Use
R
the show poe controller command to view PoE power usage and availability details.
TE
IN
10 www.juniper.net
LY
N
O
SE
U
AL
Monitoring PoE: Part 2

N
This slide illustrates the show poe interface command, which you use to verify the operational
state of PoE interfaces. The output of this command also displays the power consumption details for
R
PDs attached to the PoE interfaces. As shown on the slide, you can choose to add the interface name to
the show poe interface command to limit the generated output and display PoE details for only
TE
the specified interface.

IN
www.juniper.net 11
LY
N
O
SE
U
AL
LLDP Defined
N
The Link Layer Discovery Protocol (LLDP) is a Layer 2 protocol that facilitates network and neighbor
discovery. Neighbor discovery is made possible through advertisements sent by each network device
R
participating in LLDP. Advertisements are sent by LLDP-enabled devices to identify themselves and to
announce their capabilities to neighboring devices. LLDP is somewhat comparable in purpose to the
TE
Cisco Discovery Protocol (CDP). LLDP operates on both Layer 2 and Layer 3 interfaces. Also, for
operability of the protocol, it does not matter whether the port is a trunk port or an access port because
the LLDP frames are untagged. This behavior helps the protocol build the network topology, regardless
of specific configuration parameters assigned to the port. LLDP is defined in IEEE 802.1ab.
IN
Any LLDP-enabled device is known as an LLDP agent. LLDP agents exchange LLDP data units (LLDPDUs)
with neighboring LLDP agents. LLDP agents store their local information as well as the information
learned from neighbors in a local database. LLDP periodically refreshes the local database to maintain
accurate information for neighboring LLDP agents.
12 www.juniper.net
LY
N
O
SE
U
AL
LLDPDU Frames
N
LLDP-capable devices, such as EX Series switches, transmit information in type/length/value messages

(TLVs) to neighbor devices. Device information can include specifics such as chassis and port
R
identification, system name, and system capabilities.

LLDP defines some TLVs as mandatory, whereas others are listed as optional. The TLVs leverage this
TE
information from parameters that are already configured in the Junos operating system. LLDP frames
are constrained to the local link, which means LLDP frames are never relayed or passed beyond a
directly connected neighbor.
The slide illustrates the format of an LLDPDU frame. This illustration highlights the LLDP multicast
IN
address as well as the TLVs that are required in all LLDPDUs. A basic description of the mandatory TLVs
follows:
• Chassis ID: This TLV identifies the MAC address associated with the local system.
• Port ID: This TLV identifies the port from which the LLDPDU is transmitted.
• Time to live (TTL): This TLV identifies how long the device’s information is valid. A nonzero
value indicates that the information is to be updated. A value of 0 indicates that the
information is no longer valid and should be removed from the receiver’s database.
• End of LLDPDU: This TLV identifies the end of TLVs in the LLDPDU.
www.juniper.net 13
LLDPDU Frames (contd.)
In addition to the mandatory TLVs, EX Series switches support the following set of basic TLVs:
• Port description: This TLV provides the user-configured port description. The port
description can be a maximum of 256 characters.
• System name: This TLV identifies the user-configured name of the local system. The system
name can be a maximum of 256 characters.
• System description: This TLV provides the system description containing information about
the software and current image running on the system. This information is not configurable
but taken from the software.
• System capabilities: This TLV identifies the primary function performed by the system. The
capabilities that the system supports are defined—for example, bridge or router. This
LY
information is not configurable but based on the model of the product. An EX Series switch
is capable of both switch and router operations.
• Management address: This TLV identifies the IPv4 management address of the local
system.
N
O
SE
U
AL
N
R
TE
IN
14 www.juniper.net
LY
N
O
SE
U
AL
LLDP Updates
N
LLDP agents send periodic LLDP updates to neighboring devices. These updates are advertised every
30 seconds by default. You can adjust the interval at which updates are sent through the LLDP-related
R
configuration.
LLDP agents also send LLDP updates as needed based on local changes. These updates are often
TE
referred to as triggered updates because a value or state change triggers the update, as opposed to the
regularly scheduled updates. Triggered updates cannot occur more than once per second.
LLDP updates are always sent as unsecured, one-way advertisements. Because LLDP is a stateless
protocol, there is no verification or guarantee that the neighboring devices are actually receiving the
IN
transmitted advertisements. LLDP does not offer any authentication mechanism; therefore, all LLDP
advertisements are unsecured. If a switch port connects to an untrusted boundary, such as a
customer’s network, we highly suggest that LLDP be disabled on that port. We provide a configuration
example on a subsequent slide in this material.
www.juniper.net 15
LY
N
O
SE
U
AL
Transmit Agent Role

N
Typically a device configured for LLDP (an LLDP agent) functions as both a transmit and receiver
agent. The LLDP transmit agent’s role is to send periodic and triggered updates to its neighboring
R
devices. The TTL TLV mechanism is used to ensure that only valid information is stored on the
receiver agent. The TTL value is determined by multiplying the msgTXInterval value with the
msgTXHold value. These values are defined on the transmit agent using the
TE
advertisement-interval and hold-multiplier configuration options.

As shown on the slide, the default transmit interface (msgTXInterval) is 30 seconds and the default
hold value (msgTXHold) is 4 intervals. These default values produce a default TTL value of 120
seconds. Thus, if a receiver agent does not receive an update from a given neighbor (transmit agent)
IN
within 120 seconds, the information associated with that neighbor is removed from the receiver
agent’s database.
LLDP transmit agents notify their neighbors when an interface is about to become nonoperational or
when LLDP is disabled on that interface. A final shutdown LLDPDU is sent with the chassis ID, port
ID, TTL TLV fields set to zero (0), and the end-of-LLDPDU TLV set. If a transmit agent fails to send a
shutdown TLV for an interface before it actually goes down, the receiver agent maintains the learned
information on that interface until the TTL age timer expires (default of 120 seconds).
16 www.juniper.net
Receiver Agent Role
The LLDP receiver agent stores information received from all neighboring LLDP-enabled devices (LLDP
transmit agents) in its neighbor database. The information found within the neighbor database is
accessible through SNMP. With the help of the TTL TLV mechanism, the contents within the neighbor
database are refreshed or purged regularly to ensure that only accurate data is maintained.
The LLDP receiver agent maintains detailed statistic counters for all LLDP-enabled interfaces. The
statistic counters include frames received, frames with errors, and unknown TLVs for a given interface.
LY
N
O
SE
U
AL
N
R
TE
IN
www.juniper.net 17
LY
N
O
SE
U
AL
LLDP-MED
N
LLDP-MED is an extension to LLDP (IEEE 802.1ab) and was developed to support interoperability and
enhance discovery capabilities between VoIP endpoint devices, such as IP phones, and other
R
networking devices, such as EX Series switches.

LLDP-MED exchanges TLV messages between switches and IP phones (at least those that support
TE
LLDP-MED) to help facilitate the deployment of IP telephony services in a network. Some of the key TLVs
supported on EX Series switches include the following:
• Network Policy: This TLV advertises the port VLAN configuration and associated Layer 2
and Layer 3 attributes. Attributes include the policy identifier, application types, such as
IN
voice or streaming video, 802.1Q VLAN tagging, and CoS values.

• Endpoint Location: This TLV advertises the physical location of the endpoint and is used
for emergency location services.
• Extended Power through MDI: This TLV advertises the power type, power source, power
priority, and power value of the port. It is the responsibility of the PSE device to
advertise the power priority on a port.
These TLV messages provide detailed information about how voice traffic gets tagged and prioritized.
For example, CoS and 802.1Q tag information can be sent from the switch to the IP telephone through
these TLV messages.
LLDP-MED was developed by the Telecommunications Industry Association (TIA) and is defined in the
American National Standards Institute (ANSI)/TIA-1057 standard.
18 www.juniper.net
LY
N
O
SE
U
AL
LLDP-MED Classification
N
To help determine a device’s capabilities, LLDP-MED uses classification to group devices and map
capabilities to each group. LLDP-MED distributes device classification information through TLVs. The
R
LLDP-MED device class values in use today are shown in the table on the slide. Class 0 is not yet
defined and classes 5 through 255 are currently reserved.
TE
IN
www.juniper.net 19
LY
N
O
SE
U
AL
LLDP and LLDP-MED Interaction

N
The slide illustrates the basic LLDP and LLDP-MED message exchange sequence when an
LLDP-MED-enabled IP phone is initially connected to an EX Series switch. Here you can see that the
R
EX Series switch initially advertises a base LLDP message. This initial advertisement includes all
mandatory TLVs. Once the EX Series switch receives an LLDP-MED message from the IP phone, it
begins sending LLDP-MED messages.
TE
Note that both LLDP and LLDP-MED are enabled by default for all interfaces in the factory-default
configuration. We provide a configuration example on a subsequent slide.
IN
20 www.juniper.net
LY
N
O
SE
U
AL
LLDP and 802.1X

N
When 802.1X is used on an interface, LLDP and LLDP-MED frames are advertised and processed only
when a secure port is authenticated. In other words, when 802.1x is enabled on a given switch port,
R
LLDP and LLDP-MED frames are not transmitted or received until that port becomes authenticated.
In the case where an IP phone and a user’s PC are connected to the same switch port, both devices can
TE
be authenticated separately when the multiple supplicant mode is enabled on that port. Using multiple
supplicant mode allows both devices to receive their appropriate VLAN assignments and individual
policies for voice and data traffic. Voice traffic is commonly associated with a voice VLAN, which can be
treated with a higher priority than data traffic using CoS.
IN
If an IP phone and a user’s PC are connected to the same switch port and only one of the two devices is
802.1X capable, use single supplicant mode. Single supplicant mode authenticates the 802.1X-capable
device and freely permits traffic from other devices without further authentication. In this situation, both
devices are permitted network access, and LLDP or LLDP-MED messages can be exchanged.
www.juniper.net 21
LY
N
O
SE
U
AL
Configuring LLDP and LLDP-MED

N
The slide illustrates the basic hierarchy and configuration options for LLDP and LLDP-MED.
R
TE
IN
22 www.juniper.net
LY
N
O
SE
U
AL
Monitoring LLDP and LLDP-MED

N
This slide highlights some key operational-mode commands used to monitor LLDP and LLDP-MED.
We provide a sample output for some of these commands in the case study later in this material.
R
TE
IN
www.juniper.net 23
LY
N
O
SE
U
AL
Voice VLAN Review

N
Typically, network administrators choose to treat VoIP traffic differently from user data traffic. To
treat these types of traffic differently, you must be able to separate common user data traffic from
R
voice traffic. The voice VLAN feature is used for this purpose. The voice VLAN enables a single access
port to accept untagged data traffic as well as tagged voice traffic and associate each type of traffic
with distinct and separate VLANs. By doing this, a network’s CoS implementation is used to treat
TE
voice traffic differently, generally with a higher priority than common user data traffic.
As previously mentioned you can use LLDP-MED on EX Series switches to dynamically provide the
voice VLAN ID and 802.1p CoS values to the attached IP phones. This dynamic method associates
each IP phone with the appropriate voice VLAN and assigns the necessary 802.1p values, which are
IN
used by CoS, to differentiate service for voice traffic within a network. Note that LLDP-MED is not
strictly necessary to associate the voice VLAN ID and 802.1p values with an IP phone. With most
vendors, you can manually assign these values to the IP phone directly without the use of LLDP-MED.
24 www.juniper.net
LY
N
O
SE
U
AL
Voice VLAN Configuration: Part 1

N
This slide illustrates the basic hierarchy structure along with the available configuration options
associated with the voice VLAN feature.
R
TE
IN
www.juniper.net 25
LY
N
O
SE
U
AL
Voice VLAN Configuration: Part 2

N
This slide provides a configuration example based on the sample topology shown on the slide.
R
TE
IN
26 www.juniper.net
LY
N
O
SE
U
AL
Monitoring the Voice VLAN

N
This slide illustrates the expected output based on our sample configuration shown on the previous
slide. Here you can see that the access port (ge-0/0/6.0) is associated with the data and voice
R
VLANs.
TE
IN
www.juniper.net 27
LY
N
O
SE
U
AL
Case Study: Objectives and Topology

N
The slide displays the objectives and topology for our case study.
R
TE
IN
28 www.juniper.net
LY
N
O
SE
U
AL
Configuring LLDP, LLDP-MED, and PoE

N
This slide shows the required configuration for LLDP, LLDP-MED, and PoE. Note that these features
are enabled in the factory-default configuration on most EX Series switches. We show the syntax
R
here as a review and for clarification purposes.

TE
IN
www.juniper.net 29
LY
N
O
SE
U
AL
Configuring the Voice VLAN Feature

N
This slide shows the required configuration to enable the voice VLAN feature on ge-0/0/0.0. Note
that you can use the access-ports configuration option rather than specifying each access port
R
individually. Similarly, you could simplify the configuration for the interfaces and use an interface
range instead of defining the access ports individually.
TE
In this example we specify the expedited-forwarding forwarding class for the voice VLAN. The
configured forwarding class can be communicated to the IP phone through LLDP-MED. Note that the
forwarding class must be configured on the switch along with the desired scheduling parameters.
IN
30 www.juniper.net
LY
N
O
SE
U
AL
Verifying LLDP
N
Although there are several other commands useful in determining the status of LLDP and
LLDP-MED, none are more helpful when focusing on a specific interface or neighbor than the show
R
lldp neighbors interface <interface-name> command.

Notice that sample output provides Layer 2 and Layer 3 information as well as manufacturing details
TE
for the connected neighbor. Much of this information can be useful when troubleshooting network
and connectivity issues.
IN
www.juniper.net 31
LY
N
O
SE
U
AL
Verifying PoE
N
This slide shows the output from the show poe interface ge-0/0/0 command and a capture
from an LLDP frame exchanged between the switch and IP phone. Here you can see that ge-0/0/0 is
R
enabled for PoE and that the connected powered device (the IP phone) is successfully drawing power
from that PoE interface. You can also see in both the sample output as well as the capture from the
LLDP frame that the IP phone is registered as a power class 2 device.
TE
IN
32 www.juniper.net
LY
N
O
SE
U
AL
Verifying the Voice VLAN: Part 1

N
This slide illustrates the expected output from the show vlans <vlan-name> extensive
commands. Here you can see that the access port (ge-0/0/0.0) is associated with the data and
R
voice VLANs and that it is functioning as an untagged interface for the data VLAN and a tagged
interface for the voice VLAN.
TE
IN
www.juniper.net 33
LY
N
O
SE
U
AL
Verifying the Voice VLAN: Part 2

N
This slide provides a sample capture of an LLDP-MED frame exchanged between the switch and IP
phone. Here you can see the expected VLAN details being sent from the switch to the IP phone.
R
TE
IN
34 www.juniper.net
<Course
Class of Service
Title>
LY
N
O
SE
U
AL
N
R
TE
IN
Class of Service
LY
N
O
SE
U
AL
Challenges in the LAN: Part 1

N
Many of today’s Layer 2 networks consist of multiple layers. In these environments, the aggregate
bandwidth at the Access Layer is typically much higher than the aggregate bandwidth at the higher
R
layers. Although there are typically no issues with this design, oversubscription and the resulting
congestion between layers are possible. While you can add additional links between the layers to
increase the aggregate throughput, this is not always possible or the best solution.
TE
IN
2 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Challenges in the LAN: Part 2

N
Today's enterprise network has evolved into a multi-services infrastructure carrying business-critical
applications, voice and video streams, and traffic from building automation and other control
R
systems. A well designed enterprise network can increase the likelihood of meeting the performance
demands of these applications in these networks, but there is no guarantee!
TE
Even in networks that are not fully utilizing the capacity on all their network links, instantaneous
contention for transmission to the wire can occur. If two packets arrive at an output interface at the
same time, the system transmits one packet and adds the other to a queue. The delay in the queue
might be minimal in a generally uncongested network; however, even a brief delay can be significant
for latency-sensitive traffic—such as voice over IP (VoIP).
IN
www.juniper.net 3
Class of Service
LY
N
O
SE
U
AL
Addressing the Challenges

N
You can use CoS to address the challenges mentioned on the previous slides and to help meet
performance requirements in today’s networks.
R
CoS allows you to treat traffic differently by providing a minimum bandwidth guarantee, low latency,
low packet loss, or a combination of these things for categories of traffic. Consequently, deploying
TE
CoS can make some applications perform better. CoS cannot increase the total bandwidth of a link
or decrease latency beyond the minimum limits imposed by the speed of light. CoS cannot eliminate
congestion within a network. CoS can, however, help you control how this congestion affects
different types of traffic.
IN
You can configure devices running the Junos operating system to guarantee certain levels of
bandwidth to traffic classes. This configuration ensures that the device meets minimum bandwidth
guarantees during periods of congestion. In this way, it is possible to ensure that certain types of
traffic receive a guaranteed minimum level of bandwidth on each link.
To treat the traffic within the defined service groups consistently throughout the network, all devices
must have a similar CoS configuration. We provide configuration examples later in this material.
4 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Prioritizing Traffic
N
As traffic enters a switch port, CoS examines the CoS settings found in the frame or packet headers.
The switch uses these CoS settings to determine how that traffic should be classified. Based on the
R
resulting classification, the traffic is associated with a forwarding class and corresponding output
queue. The configuration associated with the output queue determines which packets are
transmitted first when congestion exists. We examine this process in more detail on subsequent
TE
slides.
IN
www.juniper.net 5
Class of Service
LY
N
O
SE
U
AL
Traffic Classification
N
As traffic enters an incoming port, the switch examines the traffic and then associates that traffic
with a forwarding class and loss priority and assign the traffic to output queues based on the
R
associated forwarding class. This process is known as traffic classification. Note that EX Series
switches can match traffic based on existing CoS values using behavior aggregate (BA)
classification, or it can match on a variety of fields in a packet’s header (IP address, protocol, port,
TE
and so forth) using multifield classification. Classifiers associate traffic with a forwarding class.
You can configure both a BA classifier and an multifield (MF) classifier on an interface. If you do this,
the BA classification is performed first and then the MF classification. If the two classification results
conflict, the MF classification result overrides the BA classification result. Note that when a source
IN
media access control (MAC) address is learned, the frame that contains the source MAC address is
always sent out queue 0 on egress interfaces regardless of the classifier applied to the ingress
interface.
BA classification is often used in the core of enterprise networks. BA classifiers are based on
fixed-length fields, which makes them computationally more efficient than MF classifiers. Therefore
core devices, which handle high traffic volumes, are normally configured to perform BA
classification. As shown on the slide there are three types of BA classifiers supported on EX Series
switches:
• DiffServ code point (DSCP) for IP DiffServ,
• IP precedence bits, and
• Institute of Electrical and Electronics Engineers (IEEE) 802.1p CoS bits.
6 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Code Point Aliases

N
Code-point aliases assign names to specific patterns of CoS bits. When you configure certain CoS
components such as classifiers, drop-profile maps, and rewrite rules, you can use the code-point
R
alias instead of the corresponding bit pattern. The bit patterns represented by the code-point aliases
are used to associate incoming traffic with its designated service level.
TE
Code-point aliases are available for various CoS values including DSCP, IP precedence, and IEEE
802.1 bits. An example of a code-point alias found in enterprise environments is ef (expedited
forwarding) which maps to the DSCP pattern 101110. This alias is often used to classify VoIP traffic.
EX Series switches are aware of common code-point aliases and their corresponding bit patterns.
IN
You can view the known aliases using the command shown on the slide. Note that you can also
define custom mappings as shown in the following example:
[edit class-of-service]
user@switch# set code-point-aliases dscp custom-ef 101110
user@switch# commit
configuration check succeedscommit complete
user@switch# run show class-of-service code-point-aliases dscp | match ef
custom-ef 101110
ef 101110
www.juniper.net 7
Class of Service
LY
N
O
SE
U
AL
Forwarding Classes
N
A forwarding class is a grouping mechanism switches and other network devices use to identify
traffic that should receive common treatment. The network device associates traffic with a
R
forwarding class during the classification process described earlier. During output, the network
device assigns traffic to a particular output queue based on forwarding class. If a rewrite rule is
enabled for the egress interface, the CoS bits are rewritten based on forwarding class. We discuss
TE
rewrite rules in more detail later in this material.

Thinking of forwarding classes as output queues is tempting (and sometimes helpful) because a
one-to-one mapping of forwarding classes and output queues usually exists. However, that definition
is not necessarily true, because network devices, including EX Series switches, support more
IN
forwarding classes than queues. In these cases, combining the concepts of forwarding classes and
output queues can be confusing.
8 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Controlling Congestion
N
The ability to manage queues during congestion before congestion gets unmanageable can help
maintain desired performance levels in a network. There are a number of mechanisms that can help
R
manage congestion. Depending on the platform, EX Series switches support either weighted tail drop
(WTD) or weighted random early detection (WRED).
TE
• WTD: When the queue reaches a certain buffer capacity (fill level), the Junos OS no
longer allows and begins dropping packets. By default, the level is 100% of the queue.
WTD is only supported on the EX2200, EX3200, and EX4200 switches.
• WRED: Once the queue reaches a certain buffer capacity (fill level), the Junos OS
IN
gradually and randomly drops packets with a packet loss priority (PLP) of “low” or
“high”. Packets with a PLP of high are more likely to be dropped than packets with a PLP
of low. This point is illustrated on the next slide. The Junos OS supports two WRED
implementations—segmented and interpolated. From a high level, segmented is a
stair-step like drop profile, whereas interpolated is a smother (curve) drop profile.
Regardless of the implementation, a profile is a graph where the x axis represents
current buffer utilization (fill level) and the y axis is the drop probability. Depending on
where the traffic is plotted against the graph, the packet will either be dropped or
buffered. WRED is only supported on the EX8200 line of Ethernet switches.
In addition to the drop profiles, you can also implement shapers and policiers to rate-limit and drop
traffic that exceeds a specified rate. We cover shapers and policers on subsequent slides.
www.juniper.net 9
Class of Service
LY
N
O
SE
U
AL
Loss Priority and Drop Profiles

N
Drop profiles allow you to define a drop level (fill level) that notifies a queue when to start dropping
packets. How a switch determines what packets to drop and when to drop those packets depends on
R
the switch model. As previously mentioned some EX Series switches support WRED while others only
support WTD. On switch models that support WRED, you can define custom drop profiles that
proactively drop packets with the PLP high value thus providing more flexibility.
TE
On EX Series switches that support WTD, all packets are dropped when the drop level is reached,
regardless of the PLP value. By default, when the fill level is 0 percent, the drop probability is
0 percent. When the fill level is 100 percent, the drop probability is 100 percent. You can create
custom drop profiles. In the following example, the fill level is set at 75 percent which means that
IN
when the queue is 75 percent full packets destined for the associated output queue will be dropped.
user@switch# show
drop-profiles {
fill-to-75 {
fill-level 75;
}
}
Note that drop profiles are mapped to individual queues through the queues’ scheduler
configuration. We discuss schedulers later in this material.
10 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Rate Limiting Traffic

N
EX Series switches support two types of token-based rate limiting—policing and shaping. Rate
limiters are based on actual packets (preamble and inter-frame gap are excluded).
R
Policing can drop or modify the PLP for packets above a specified rate. Policing is supported for
incoming traffic only and is configured under the [edit firewall] hierarchy and applied directly
TE
to interfaces defined under the [edit interfaces] hierarchy.

Port shaping enables you to shape the aggregate traffic through an egress port to a rate that is less
than the line or port rate. Port shaping defines the maximum bandwidth allocated to a port, while
queue shaping defines a limit at which queues transmit packets. For example, using queue shaping,
IN
you can rate-limit a strict-priority queue so that the strict-priority queue does not lock out (or starve)
low-priority queues. All configuration for port and queue shaping is defined under the [edit
class-of-service] hierarchy.
www.juniper.net 11
Class of Service
LY
N
O
SE
U
AL
Allocating Resources Using Schedulers

N
You control how a switch services queues by configuring schedulers and scheduler maps. A
scheduler contains parameters that describe how a queue should be serviced. A scheduler is
R
associated with a particular queue and forwarding class through a scheduler map.
You define the order in which packets should transmit by defining a priority and a transmission rate
TE
for a forwarding class. You can configure a transmission rate for each forwarding class. The
transmission rate controls how much bandwidth the traffic associated with a given forwarding class
can consume. By default on EX Series switches, the software assigns 95 percent of the bandwidth to
queue 0 (the best-effort forwarding class) and 5 percent of the bandwidth to queue 7 (the
network-control forwarding class). The software assigns all other queues a 0 transmission rate. By
IN
default, all queues can exceed their assigned transmission rate if other queues are not fully utilizing
their assigned rates.
The configured buffer size determines the size of each queue. By default, the software assigns
95 percent of the available buffer space to queue 0 and the remaining 5 percent to queue 7. By
default, all other queues have 0 percent of the available buffer space; therefore, if you use queues
other than 0 and 7, you should assign buffers to those queues. As the buffer fills, the likelihood of
packet drops increases.
12 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Queue Priority
N
Priority scheduling determines the order in which an output interface transmits traffic from the
queues, thus ensuring that queues containing important traffic are provided better access to the
R
outgoing interface. Priority scheduling is accomplished through a procedure in which the scheduler
examines the priority of the queue. EX Series switches support two queue priority levels:
TE
• Low: When a queue is associated with the low priority, the scheduler determines if that
queue is within its defined bandwidth profile. This binary decision, which is reevaluated
on a regular time cycle, compares the amount of data transmitted by the queue against
the amount of bandwidth allocated to it by the scheduler. When the transmitted amount
is less than the allocated amount, the queue is considered to be in profile. When the
IN
transmitted amount is more than the allocated amount, the queue is considered to be
out of profile. An out-of-profile queue can only transmit if bandwidth is available.
Otherwise, the traffic associated with that queue will be buffered.
• Strict-high: When a queue is associated with the strict-high priority it receives
preferential treatment over all low priority queues. Unlimited bandwidth is assigned to
strict-high priority queues. Queues are scheduled according to the queue number,
starting with the highest queue 7, with decreasing priority down through queue 0.
Traffic in higher queue numbers is always scheduled prior to traffic in lower queue
numbers. In other words, in case of two strict-high priority queues, the queue with
higher queue number is processed first. Note that packets in low priority queues are
transmitted only when strict-high priority queues are empty.
www.juniper.net 13
Class of Service
LY
N
O
SE
U
AL
Understanding the Defaults: Part 1

N
This and the next slides illustrate some of the default configuration for various CoS components. This
slide specifically illustrates the default classifier configuration details associated with access and
R
trunk ports.
TE
IN
14 www.juniper.net
Class of Service
LY
N
O
SE
U
AL

N
This slide illustrates the default scheduler configuration details associated with EX Series switches.
R
TE
IN
www.juniper.net 15
Class of Service
LY
N
O
SE
U
AL

N
This slide illustrates the default rewrite behavior on EX Series switches.

R
TE
IN
16 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Test Your Knowledge

N
This slide is designed to test your understanding of how the default configuration components work
on EX Series switches. In this example, switch-1 receives traffic from its attached IP phone with the
R
DSCP CoS bits 101110 (code-point alias ef). Based on the default classifier applied to access ports,
all traffic received is classified as best-effort traffic (queue 0). As previously illustrated, the CoS bits
for traffic leaving queue 0 on an egress interface are rewritten to 000000. To maintain the CoS bit
TE
pattern set by the IP phone, you would need to apply a custom classifier to ge-0/0/6.0 that matches
the DSCP ef bits and associates the related traffic with queue 5 (expedited forwarding class). Note
that you would also need to associate scheduling resources with this queue to ensure the traffic is
serviced properly.
IN
www.juniper.net 17
Class of Service
LY
N
O
SE
U
AL
Changing the Default Configuration

N
This slide introduces the next several slides which cover configuration examples that override the
default CoS implementation on EX Series switches. Note that all CoS configuration covered in the
R
remainder of this section is performed at the [edit class-of-service] hierarchy.

TE
IN
18 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Enabling BA Classification
N
This slide provides a sample configuration used to enable BA classification with some custom
definitions. This custom DSCP classifier uses the import defaults statement which imports all
R
default classification assignments that are not specified. This example also illustrates how
classifiers are associated with logical interfaces. In our example, the custom DSCP classifier is
associated with all logical Gigabit Ethernet interfaces using the asterisk (*) wildcard option.
TE
Once a classifier is associated with an interface, you can verify the association using the show
class-of-service interface <interface-name> command as shown in the sample
capture that follows:
IN
user@switch> show class-of-service interface ge-0/0/6

Physical interface: ge-0/0/6, Index: 136
Queues supported: 8, Queues in use: 4
Scheduler map: <default>, Index: 2
Congestion-notification: Disabled
Logical interface: ge-0/0/6.0, Index: 2147404772

Object Name Type Index
Classifier my-classifier dscp 13741
www.juniper.net 19
Class of Service
LY
N
O
SE
U
AL
Defining Schedulers
N
This slide illustrates a sample scheduler configuration using the four system-defined forwarding
classes. In this example we allocate the desired queue transmission priority level along with the
R
transmit rate and buffer size percentages.

Note that the queues with the strict-high transmission priority do not have a defined transmit rate
TE
percentage because those queues are provided as much bandwidth as they require. Because of
their intrinsic behavior, strict-high priority queues can potentially consume all of the bandwidth and
starve the other queues. As a safe-guard, you can implement queue shaping to prevent the
starvation of low priority queues.
IN
20 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Configuring Scheduler Maps

N
Scheduler maps associate schedulers with particular forwarding classes and their respective
queues. The Junos OS references queues by their associated forwarding class. You configure
R
scheduler maps under the [edit class-of-service scheduler-maps] hierarchy.

In the example on the slide, we associate four schedulers with the four default queues.
TE
IN
www.juniper.net 21
Class of Service
LY
N
O
SE
U
AL
Using the EZQoS Template

N
This slide illustrates the use of the EZQoS configuration template which is an optional method for
implementing some of the basic CoS components. This template was specifically designed for VoIP
R
deployments and can simplify basic CoS implementations significantly.

TE
IN
22 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
The Resulting Configuration: Part 1

N
This slide shows a portion of the resulting configuration after the EZQoS template has been applied.
R
TE
IN
www.juniper.net 23
Class of Service
LY
N
O
SE
U
AL
The Resulting Configuration: Part 2

N
This slide shows the remainder of the resulting configuration after the EZQoS template has been
applied. Note that the EZQoS template does not include any rewrite rules. To ensure a consistent CoS
R
implementation throughout the network and to allow downstream devices to perform proper BA
classification, you should include rewrite rules on all core facing interfaces at a minimum. We
covered rewrite rules earlier in this section and will illustrate how they are implemented with the
TE
EZQoS template in the next section.

IN
24 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Objectives and Topology

N
This slide provides the objectives and topology information used for this case study.
R
TE
IN
www.juniper.net 25
Class of Service
LY
N
O
SE
U
AL
Implementing the EZQoS Template

N
This slide illustrates the basic steps used to implement the EZQoS template on an EX Series switch.
Note that although the configuration and monitoring steps for this case study are from AS-1’s
R
perspective, similar configuration and verification should be done on all devices within the network.
TE
IN
26 www.juniper.net
Class of Service
LY
N
O
SE
U
AL
Adding a Rewrite Rule

N
As mentioned earlier, to ensure a consistent CoS implementation throughout the network and to
allow downstream devices to perform proper BA classification, you should include rewrite rules on all
R
core facing interfaces at a minimum. In this example we associate the default DSCP rewrite rule with
all logical Gigabit Ethernet interfaces.
TE
IN
www.juniper.net 27
Class of Service
LY
N
O
SE
U
AL
Monitoring the Results: Part 1

N
This slide shows some initial verification tasks. Here you can see that the new forwarding classes
have been added. Note that there are now five forwarding classes and queues defined on AS-1; the
R
four forwarding classes from the EZQoS template and one remaining default forwarding class,
assured-forwarding, which is associated with queue 1.
TE
IN
28 www.juniper.net
Class of Service
LY
N
O
SE
U
AL

N
This slide shows some commands and outputs used to further verify the correct application of the
EZQoS template and the default DSCP rewrite rule.
R
TE
IN
www.juniper.net 29
Class of Service
LY
N
O
SE
U
AL

N
This slide shows some commands and outputs used to verify scheduling parameters and statistics
on AS-1’s egress interface.
R
TE
IN
30 www.juniper.net
<Course Title>
Monitoring and Troubleshooting
LY
N
O
SE
U
AL
N
R
TE
IN
LY
N
O
SE
U
AL
The Situation
N
You might have found yourself in a similar situation to the one highlighted on the slide. In these types
of situations, you may ask yourself a number of questions such as: What is broken?, What has
R
changed recently?, Is there really an issue or is it working as designed?, and Where do I begin?
These are all relevant questions and there are a number of correct ways to approach these types of
TE
situations. We discuss a basic troubleshooting method throughout this section that can be applied to
situations like the one illustrated on the slide.
IN
2 www.juniper.net
LY
N
O
SE
U
AL
A Basic Method for Troubleshooting

N
When beginning your troubleshooting, it is important to take a structured approach. In this material,
we will be using the troubleshooting method outlined on the slide. Each step in this troubleshooting
R
method is highlighted in detail on subsequent slides in this material.

TE
IN
www.juniper.net 3
LY
N
O
SE
U
AL
Knowing Your Environment

N
To effectively troubleshoot a network you must be familiar with the network and know what is normal
for your environment. There are many tools that allow you to get familiar with your environment. You
R
can use tools, such as sFlow and SNMP, to monitor your network environment and even establish a
baseline for that network environment. Note that we discuss sFlow and SNMP in further detail in a
subsequent section in this material.
TE
In addition to the physical components in your network, you should also have a detailed
understanding of the logical components and protocols in your environment. Without a detailed
understanding your entire environment, troubleshooting issues can be a significant challenge and
you may actually end up causing more problems by troubleshooting something that is operating as
IN
expected.
4 www.juniper.net
LY
N
O
SE
U
AL
Gathering Information
N
Before attempting to fix a problem that may or may not exist, you should gather as much information
as possible. When gathering information it is helpful to get answers to key questions relevant to the
R
situation. The answers to these key questions should provide detailed information about the
symptoms related to the issue.
TE
While talking to end users can provide some valuable information, it is also important to understand
what other resources and tools you have available and use those additional resources to help gather
relevant information. Ultimately it is the information gathered that will lead you to the problem and
help you identify a solution. Typically the sooner you gather the relevant information for a given issue,
the sooner you will be able to solve that issue and be able to get back to your video game or favorite
IN
YouTube video.
www.juniper.net 5
LY
N
O
SE
U
AL
Understanding Symptoms and Layers

N
Recall that EX Series switches maintain a strict separation between the control plane and the data
plane. When you characterize a problem, certain types of symptoms indicate the control plane as the
R
most probable cause, whereas other symptoms indicate that the root cause ultimately lies in the
data plane. In an established operating environment, it is extremely rare to find a fault in both planes
simultaneously because of the different role that each plays.
TE
The control plane is responsible for installing routes and media access control (MAC) address entries
into the forwarding table. This function relies on configuration, protocols, connection to peers and so
on. The most common symptom of a control plane problem is incorrect or missing forwarding paths
at Layer 2 and Layer 3. When in doubt, it is generally beneficial to determine whether the control
IN
plane is functioning properly before moving on to the data plane.

The data plane uses the forwarding path information provided by the control plane to perform packet
forwarding. The most common symptoms of a data plane issue are physical errors, intermittent
connectivity and dropped packets. Problems in the data plane can result from faulty hardware or
configuration-based issues such as firewall filters, policers, and so forth. Note that intermittent
issues and bottlenecks almost always trace back to the data plane.
Understanding how symptoms relate to the various layers in a modeled structure, such as the Open
Systems Interconnection (OSI) and TCP models, and the control and data planes on EX Series
switches can speed-up your troubleshooting efforts in many cases.
6 www.juniper.net
LY
N
O
SE
U
AL
Hardware Troubleshooting Flowchart

N
The artistic aspect of troubleshooting and the various ways in which a modern communications
device might malfunction combine to make a definitive set of troubleshooting steps and procedures
R
an unobtainable goal. The purpose of the hardware troubleshooting flowchart shown on the slide is
simply to provide a set of high-level steps designed to get you started with hardware fault analysis.
Note that reasonable people might disagree on the exact ordering of the steps or the particular
TE
command-line interface (CLI) commands used to help isolate a hardware failure (for example, some
might prefer the extensive option to the show interfaces command, whereas the sample
chart calls out the terse and detail options).
IN
www.juniper.net 7
LY
N
O
SE
U
AL
Software Troubleshooting Flowchart

N
The purpose of the software troubleshooting flowchart shown on the slide is simply to provide a set
of high-level steps designed to get you started on the path of software-related troubleshooting. Note
R
that as with the hardware flowchart, reasonable people might disagree on the exact ordering of the
steps or on the particulars of the CLI commands used to help isolate a software failure. Note that it is
sometimes necessary to execute the same command multiple times over a brief period of time to
TE
see patterns or indications of problems.

In some situations, configuration errors can appear as a software issue. The commands used to
investigate configuration errors depends on the reported symptoms. As an example, the commands
you use to troubleshoot symptoms related to 802.1X will not be the same commands you use to
IN
troubleshoot symptoms related to MSTP. Because of the number of possible scenarios that could involve
configuration errors, we do not provide the related CLI commands.
Some software issues may be related to a malfunctioning process. The slide also outlines some of
the key Junos processes used on EX Series switches. These processes are responsible for individual
functions including chassis and interface control as well as operations related to routing and
switching. These process can be restarted using the CLI, but this should only be used as a last
resort. Restarting a process might resolve an issue, but it makes determining the root cause very
difficult. Restarting a process can also have a cascading and adverse effect on other process that
may impact the switch or even the network as a whole.
8 www.juniper.net
LY
N
O
SE
U
AL
System Logging and Traceoptions

N
You can use the system logging and traceoptions features on EX Series switches to gather
useful information when troubleshooting hardware and software issues. This slide provides a
R
basic review of each of these features along with configuration examples.

System logging (syslog) uses a UNIX syslog-style mechanism to record system-wide, high-level
TE
operations and events, such as interfaces going up or down or users logging in to or out of the
device. The Junos OS places the resulting log messages in files stored in the /var/log directory
or can send the log messages to a remote server. The primary syslog file, which is included in
all factory-default configurations, is the /var/log/messages file.
IN
When using traceoptions, you create a trace file that is used to store decoded protocol
information received or sent by the Routing Engine (RE). As shown in the configuration example
on the slide, you identify the types of messages you want logged to the trace file using
traceoption flags. The Junos OS sends the tracing results to a specified file stored in the /var/log
directory or to a remote syslog server. You can enable traceoptions at various hierarchies to
capture detailed information pertaining to a specific protocol or feature.
www.juniper.net 9
LY
N
O
SE
U
AL
Routing Engine Information

N
The overall health of a networking device often has a lot to do with the stability of its control plane
and its dedicated resources. On EX Series switches, the RE is responsible for all control plane
R
functions. The RE has dedicated memory and a CPU to support the various control plane functions.
As with any resource, the REs memory and CPU cycles may become consumed beyond a sustainable
point.
TE
If the REs memory and CPU become overwhelmed, the stability of the system, and potentially the
entire network, may be in jeopardy. Although this is not typical, high memory and CPU utilization can
impact the performance and overall operations of the running processes and can potentially cause
those processes to fail. Note that in environments that are well designed and implemented correctly,
IN
RE CPU and memory utilization are typically maintained at a sustainable level. The utilization levels
vary and are dependant on the device’s configuration and processing load.
10 www.juniper.net
LY
N
O
SE
U
AL
Process Failures
N
The software used on today’s networking devices can be exceedingly complex. As a result, equally
complex bugs that result from unforeseen circumstances can result in a fatal error within a software
R
process. Most of these software faults relate to illegal memory operations caused by the process
attempting to read or write data from a memory area outside the boundaries allocated for that
process. In some cases, faulty hardware, such as failing memory, can cause stack or register
TE
corruption that leads to a fatal error in a software process. Core and log file analysis are used to
determine whether hardware errors have led to a software panic. A core file represents the set of
memory locations and stack data that was in place at the time of the fault. The core file that is
generated is stored in the /var/tmp file system directory and is named in the
IN
process-name.core-tarball.core-number.tgz format. Secondary core files might be

generated in the /var/crash/kernel directory as well depending on what process was involved
in the core. You can easily verify if your device has core files stored on it by executing the show
system core-dumps command from operational mode.
If your system has generated a core file, you can contact the Juniper Networks Technical Assistance
Center (JTAC) support team to assist with decoding the core file and to identify the root cause.
www.juniper.net 11
LY
N
O
SE
U
AL
Creating an Action Plan

N
It is important to outline possible causes that correlate with the known symptoms identified in the
previous step. Many common network issues fall into the following three categories:
R
• Physical: Physical issues can include, but are not limited to, faulty hardware as well as
faulty cabling or fiber.
TE
• Software: Software issues are often referred to as bugs and are problems in the
software coding.
• Configuration: Configuration issues could be as simple as a missed virtual LAN (VLAN)
tag or more complicated like a spanning tree setting that affects the entire network.
IN
After narrowing down the problem, you can create a plan to prove or disprove the possible cause.
Each plan should include the steps to prove or disprove the possible cause and how success is
defined. It is also a good idea to have a contingency plan just in case the changes associated with a
test make the situation worse. A good action plan allows you to revert back to the previous state in a
short amount of time.
12 www.juniper.net
LY
N
O
SE
U
AL
Testing Possible Solutions

N
The final step in this basic troubleshooting method is to execute the proposed test that you outlined
in the previous step. If a given test does not resolve the issue, it is recommended that you remove
R
any changes associated with that test and move on to the next test from the original starting point.
This process will help keep your configuration clean and may help you avoid any unexpected issues
later on.
TE
If none of your tests resolve the issue, you should return to step one and gather additional
information. You might need to go through this entire troubleshooting process multiple times before
identifying the resolution to the problem. If you have exhausted all of your local resources, you may
consider working with JTAC. We discuss some key considerations when working with JTAC on the next
IN
slides.
www.juniper.net 13
LY
N
O
SE
U
AL
Working with JTAC: Part 1

N
In some cases, you may need help identifying and resolving issues. You can open a support case
with JTAC to get help from Juniper Networks’ support engineers. For non critical issues it is
R
recommended that you open the case using the web portal located at www.juniper.net/cm.
Alternatively, for critical issues it is recommended you call JTAC directly to open a new case.
TE
You should provide as much detail as you can about the issue and what steps have already been
carried out. It is also a very good time to attach any relevant outputs from the affected devices. By
providing as much detail about the issue and supplying the relevant outputs up front, JTAC should
have a better understanding of the issue initially and be able to provide a resolution more quickly.
IN
14 www.juniper.net
LY
N
O
SE
U
AL
Working with JTAC: Part 2

N
When working with JTAC, you can avoid unnecessary delay by providing as much relevant information
as possible when you open a support case. In addition to the outputs and details you feel are
R
relevant to the problem, there are some standard outputs that JTAC typically request. The commands
used to capture the standard outputs requested by JTAC are outlined on the slide.
TE
JTAC may request that you gather the same output several times to illustrate historical values, like
incrementing traffic statistics, dropped packet counters, and incrementing errors. To help illustrate
the time between each instance of a specific command, you can use the set cli timestamp
command in operational mode to generate a timestamp at the beginning of each CLI output. A
sample capture showing the generated timestamp is illustrated on the slide.
IN
www.juniper.net 15
LY
N
O
SE
U
AL
Troubleshooting Tools
N
The Junos OS offers several tools that can be used when troubleshooting. We highlighted various CLI
commands that can be used to monitor system operations as well as the system logging and
R
traceoptions features in the preceding section. We cover the remaining tools listed on the slide in
this section.
TE
IN
16 www.juniper.net
LY
N
O
SE
U
AL
SNMP
N
The Junos OS supports Simple Network Management Protocol (SNMP) which can be used with a
wide variety of network management systems (NMSs) to collect information and establish a
R
meaningful baseline.
SNMP defines a set of standards for network management including a protocol, a database
TE
structure specification, and a set of data objects that facilitate communications between an SNMP
agent running on a managed device (like an EX Series switch) and an NMS. SNMP can be used to
monitor various parameters such as CPU utilization, memory utilization, CPU temperature, interface
throughput, and so on. SNMP gathers this system information by sending a GetRequest to the
agent device. The agent device can send a variety of different SNMP trap message to the NMS
IN
indicating that there has been an unexpected event on the local system.
You can also configure the local system to monitor the health of key components. When a threshold
is exceeded, the system reports this information using trap messages to the NMS. When configuring
health-monitor on a device, you can define the interval that the system checks the current
values against thresholds. These thresholds can also be explicitly defined or you can use the default
values. Additional information regarding the health-monitor feature can be found in KB16450,
by entering this number in the KB field at http://kb.juniper.net.
www.juniper.net 17
LY
N
O
SE
U
AL
sFlow Monitoring: Part 1

N
The sFlow (RFC 3176) technology is designed for monitoring high-speed switched or routed networks
and provides visibility into the types of traffic in those networks. sFlow is a statistical sampling-based
R
network monitoring technology that samples network packets and sends those samples to a
monitoring station, known as a collector. Once the samples are received by the collector, the network
administrator can determine network behaviors, traffic patterns, and detect anomalies in traffic
TE
flows.
The sFlow agent is typically embedded in a switch’s application-specific integrated circuit (ASIC)
hardware, where it collects different samples at regular intervals. The datagrams are sent at regular
intervals to the sFlow collector whose address is configured as an IP address and UDP port pair. The
IN
collector reads the datagram, estimates the traffic pattern, and generates a traffic report. The sFlow
technology provides Layer 2-7 visibility.
The sFlow agent does sampling in two phases, packet flow sampling, which consists of statistical
data gathered from individual flows, and counter sampling, which involves the periodic polling of
counters to gather interface data. Flow samples are then bundled into a datagram and the
datagrams are sent out to the collector using the default UDP port 6343. Counter sampling is done
at regular intervals to provide details about the interfaces, backplane, and so on. Communication
between the agent and the collector is bidirectional; the agent sends datagrams to the collector,
while the collector might configure some SNMP variables on the sFlow agent or might read some of
the SNMP Management Information Base (MIB) using UDP packets, as they work efficiently in times
of congestion.
18 www.juniper.net
sFlow Monitoring: Part 1 (contd.)
Up to four collectors can be configured on each EX Series switch, and each collector can receive the
same set of sFlow data record samples. As mentioned earlier, the sFlow data record samples are
sent as UDP packets. You can change the UDP port being used by modifying the configuration. The
polling interval is also configurable and is defined as the interval between each port statistic polling
update message, which can range from 0 to 3600 seconds. The sample rate means one out of every
n packets in the traffic stream will be sampled. The range of sample rate is from 100 to 1 million.
Only network Gigabit Ethernet or 10-Gigabit Ethernet ports able to accommodate routed traffic can
be used for exporting sFlow data records from an EX Series switch towards the collector. Currently
EX Series switches cannot export sFlow data records out the management Ethernet interface (me0)
or virtual management interface (vme0).
LY
N
O
SE
U
AL
N
R
TE
IN
www.juniper.net 19
LY
N
O
SE
U
AL
sFlow Monitoring: Part 2

N
This slide provides an example scenario for configuring sFlow monitoring. The objective is to sample
traffic entering switch-1’s ge-0/0/1 interface and export the sFlow data records to the collector,
R
which has the IP address 10.10.10.254. The default configuration values have been used for the
polling interval, sample rate, and UDP port in this configuration example. Although not illustrated,
switch-1 requires routing information for the 10.10.10.254 destination which in this case would be
TE
reachable through ge-0/0/10.

IN
20 www.juniper.net
LY
N
O
SE
U
AL
Port Mirroring: Part 1

N
The port mirroring feature allows you to analyze traffic passing through an EX Series switch. You can
use port mirroring to monitor traffic for such purposes as network usage policy enforcement and to
R
identify the source of problems on your network by locating abnormal or heavy bandwidth usage
from particular stations or applications. Port mirroring is needed for traffic analysis on a switch
because a switch, unlike a hub, does not broadcast packets to every port on the device. The switch
TE
mirrors and sends packets only out designated ports that you define. The mirrored packets are sent
to and analyzed on a connected device using a protocol analyzer application. The protocol analyzer
application can run either on a computer connected to the analyzer output interface or on a remote
monitoring station. You can configure port mirroring to send copies of unicast traffic to either a local
IN
analyzer port or an analyzer VLAN. A configuration example is provided on a subsequent slide.

We recommend that you disable port mirroring when you are finished troubleshooting and that you
define specific interfaces to mirror the traffic on instead of using the all keyword option. You can
also limit the amount of mirrored traffic by using statistical sampling, setting a ratio to select a
statistical sample, or using a firewall filter to mirror only packets matching certain criteria. Mirroring
only the necessary packets reduces any potential performance impact.
www.juniper.net 21
Port Mirroring (contd.)
You can use port mirroring on a switch to mirror any of the following:
• Packets entering or exiting a port: You can mirror the packets in any combination (on up
to 256 ports). For example, you can send copies of the packets entering some ports
and the packets exiting other ports to the same local analyzer port or analyzer VLAN.
• Packets entering a VLAN on an EX2200, EX3200, EX4200, or EX4500 switch: You can
mirror the packets entering a VLAN on these switches to either a local analyzer port or
to an analyzer VLAN. (On EX3200, EX4200, and EX4500 switches, you can configure
multiple VLANs (up to 256 VLANs), including a VLAN range and Private VLANs (PVLANs),
as ingress input to an analyzer.)
• Packets exiting a VLAN on an EX8200 switch: You can mirror the packets exiting a VLAN
LY
on an EX8200 switch to either a local analyzer port or to an analyzer VLAN. You can
configure multiple VLANs (up to 256 VLANs), including a VLAN range and PVLANs, as
egress input to an analyzer.
N
O
SE
U
AL
N
R
TE
IN
22 www.juniper.net
LY
N
O
SE
U
AL
Port Mirroring: Part 2

N
This slide provides an example scenario for configuring port mirroring. The objective is to mirror all
incoming packets from both employee A and employee B. You begin by creating an analyzer profile,
R
in the example the profile name is employee-monitor. Next, you define the interfaces to be
monitored and add them as the input source for the analyzer profile. Note that the ingress keyword is
used to indicate that incoming packets are to be mirrored. Finally, the output interface needs to be
TE
specified. This interface is where the mirrored packets will be sent out to the packet analyzing
device.
Note that this is a basic configuration example and you can find additional examples of port
mirroring in more complex situation by reviewing the technical documentation for your particular
IN
version and device.
www.juniper.net 23
LY
N
O
SE
U
AL
Topology, Symptoms, and Relevant Information

N
This slide outlines the network topology, reported symptoms, and other helpful information. In this
case study, end users have reported reachability issues to a remote file server. One of the end users,
R
Employee A, is able to communicate with the gateway router, but not the remote router or file server.
It has been verified that R1 and R2 both have the required routes in place to the remote subnets but
they cannot communicate with destination devices in those remote subnets or each other for that
TE
matter. The switch, connecting R1 and R2, has been configured with port mirroring to capture all
incoming packets on ge-0/0/6 and ge-0/0/10 and to send those packets out ge-0/0/15 to the
analyzer (Laptop running packet capturing software).
IN
24 www.juniper.net
LY
N
O
SE
U
AL
Interface Status
N
Start by verifying that the interfaces are up and functioning. This can easily be verified using the
show interfaces terse command. As illustrated on the slide the relevant interfaces are
R
Admin up and Link up. The interfaces are also configured for ethernet-switching which
indicates that it is operating at layer 2.
TE
IN
www.juniper.net 25
LY
N
O
SE
U
AL
Mirrored Packets
N
Next, a continuous ping is started on the Employee A device with the file server as the destination.
The slide displays the traffic captured and indicates that:
R
• The packets are all ICMP Echo requests sourced from 10.10.10.2 (Employee A device)
and destined to 12.12.12.2 (remote file server). Note that there is no return traffic.
TE
• All packets are being sent from R1 with a VLAN tag value of 105.
IN
26 www.juniper.net
LY
N
O
SE
U
AL
Verify VLAN Assignments and Port Mode

N
Using the commands and generated output illustrated on the slide, you can see that ge-0/0/6.0 and
ge-0/0/10.0 are both associated with VLAN v105 which is assigned a VLAN tag of 105. You can also
R
tell from this output that both of these interfaces are active because of the inclusion of the asterisk
(*) next to both interfaces in the output from the show vlans command. One additional piece of
information that may not be so obvious is that only ge-0/0/10.0 is a tagged interface. This value is
TE
characteristic of interfaces configured for access mode (the default port mode). To allow ge-0/0/6.0
to receive tagged frames, it must be configured for trunk mode. We verify if changing the port mode
on ge-0/0/6.0 to trunk mode resolves the issue on the next slide.
IN
www.juniper.net 27
LY
N
O
SE
U
AL
Test Possible Solutions

N
The next step is to test the possible solution. The slide shows the port is now configured for trunk
mode. The packet capture from the analyzer verifies that traffic from the Employee A device is now
R
reaching the file server. The capture displays packets being sourced from the employee as well as
return traffic which is sourced from the server.
TE
IN
28 www.juniper.net
LY
N
O
SE
U
AL
Topology, Symptoms, and Relevant Information

N
This slide outlines the network topology, reported symptoms, and other helpful information. In this
case study, users connected to AS-1 and AS-2 have been complaining for some time now about
R
latency and congestion when accessing resources through the network. You and your team have
recently implemented MSTP to load balance traffic from the various user groups (VLANs). The recent
change should distribute the traffic from the various user groups between two separate paths in the
TE
network. One path should use DS-1 as the root bridge while the other path should use DS-2 as the
root bridge. The end users have observed no difference in performance since the configuration was
changed and continue to complain about congestion. You have been asked to investigate the
situation and ensure load balancing is in effect.
IN
www.juniper.net 29
LY
N
O
SE
U
AL
Verify Root Bridge Elections

N
One approach when troubleshooting this type of an issue would be to start from a point close to the
end users and work outward from that point. In this example we do just that and start by verifying
R
which devices are being elected as the root bridge for the different MSTI instances from AS-1’s
perspective. As shown in the sample output on the slide that is taken from AS-1, the root bridge for
the user-defined instances is DS-2 (note that AS-1 connects to DS-2 using ge-0/0/10.0).
TE
IN
30 www.juniper.net
LY
N
O
SE
U
AL
Review the MSTP Configuration

N
To effectively troubleshoot this issue you must be familiar the protocol operations and requirements
for MSTP. The focusing on MSTP should provide you with the required knowledge to
R
troubleshoot and resolve the issue presented in this case study.

A quick look at the show spanning-tree mstp configuration output on AS-1 and DS-1
TE
helps identify a potential issue. As shown on the slide, the configuration digests on AS-1 and DS-1 do
not match. Remember from the MSTP that this digest must be the same across all
device in the same region. The configuration digest is comprised of the region name, revision level,
and MSTI to VLAN-ID mappings. If you pay special attention to the output, you can see that there is a
VLAN member mismatch between the two devices, which may be the cause of our current problem.
IN
We verify if changing the VLAN members associated with MSTI 1 fixes the issue on the next slide.
www.juniper.net 31
LY
N
O
SE
U
AL
Testing the Possible Solution

N
This slide shows the updated configuration used to test the theory identified on the last slide. Once
the illustrated configuration is in place on DS-1 all four switches illustrated in the diagram should
R
participate in the same MSTP region. Once all four switches are participating in the same MSTP
region, we should see DS-1 elected as root bridge for MSTI 1 which services VLAN-IDs 10 through 19.
We verify the results of this configuration change on the next slide.
TE
IN
32 www.juniper.net
LY
N
O
SE
U
AL
Verify Results
N
Now that the four switches are configured to participate in the same MSTP region, we verify the root
bridge elections for the defined MSTIs using the show spanning-tree interface command.
R
The sample output shown on the slide now shows that AS-1 considers DS-1 as root bridge for MSTI1
(AS-1 connects to DS-1 using ge-0/0/8.0) and considers DS-2 as root bridge for MSTI2 (AS-1
connects to DS-2 using ge-0/0/10.0). Now that DS-1 and DS-2 are functioning as root bridges for
TE
their respective MSTIs, you should see end-user traffic distributed between the available paths and
the complaints about congestion should subside (at least for now).
IN
www.juniper.net 33

Authentication and Access Control (AJEX) - 12a

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authentication and Access Control (AJEX) - 12a

Uploaded by

Copyright:

Available Formats

<Course Title> and Access Control

Understanding the Defaults

Controlling Network Access

RADIUS provides authentication, authorization, and accounting (AAA) services in network

RADIUS Traffic Flow

1. The end user makes an initial connection to the network device;

flexible, expandable network access and authorization.

Single Supplicant Mode

Single-Secure Supplicant Mode

This slide highlights the single-secure supplicant mode.

Multiple Supplicant Mode

By default, EX Series switches functioning as 802.1X authenticators force all authenticated

802.1X and Mixed Environments

Dynamic VLAN Assignment

Server Fail Fallback

EX Series switches use authentication to implement access control in an enterprise network. If

Static MAC Bypass

Configuring 802.1X: Part 1

[edit access] configuration hierarchy.

Configuring 802.1X: Part 2

[edit protocols dot1x]

Configuring 802.1X: Part 3

features in subsequent sections in this material.

MAC RADIUS and 802.1X

Configuring MAC RADIUS: Part 1

Configuring MAC RADIUS: Part 2

Monitoring MAC RADIUS

Authentication Exclusion List

Configuring Captive Portal: Part 1

services web-management] hierarchy to enable HTTPS to use the system generated

-----BEGIN RSA PRIVATE KEY-----

Configuring Captive Portal: Part 2

Continued on next page.

Configuring Captive Portal: Part 3

Configuring Captive Portal: Part 4

Configuring Captive Portal: Part 5

Monitoring Captive Portal: Part 1

Monitoring Captive Portal: Part 2

Authentication Process Flow

6. If MAC RADIUS authentication is not configured on the interface or if the authentication

Factory Default Configuration and RSTP

Test Your Knowledge: Part 1

spanning-tree bridge command to verify root bridge information:

STP bridge parameters

Maximum age : 20 seconds

Test Your Knowledge: Part 2

spanning-tree interface command to verify spanning tree interface information:

Spanning tree interface parameters for instance 0

ge-0/0/10.0 128:523 16:523 32768.0019e2516580 1 FWD ROOT

user@AS-1> show spanning-tree interface

Test Your Knowledge: Part 3

spanning-tree interface command to verify spanning tree interface information:

Spanning tree interface parameters for instance 0

A Limitation of STP and RSTP

switch, or port failure occurs within a spanning-tree instance.

Common Spanning Tree: Part 1

Common Spanning Tree: Part 2

Common and Internal Spanning Tree

Topology and Objectives

Monitoring MSTP: Part 1

Monitoring MSTP: Part 2

Monitoring MSTP: Part 3