Juniper Switch Configuration

Juniper Switch Configuration

To make changes on the switch, you need to be in CLI mode by typing:

switch%

To make changes on the switch, you need to be in CLI mode by typing:

switch% cli

And now, your prompt should look like the following:

root@switch>

Now, Juniper switched come with a default configuration. For the simplicity of the NeatRack course, we will DELETE the default configuration and add the basic configuration needed for this environment. Each section will be broken up by the main categories of Juniper configuration. With that said, let’s begin.

To Make Configuration Changes

In order to make any configuration changes, you have to be in edit mode. To be in edit mode, you simply type edit while in cli mode:

root@switch> edit

Now your prompt should look like the following:

root@switch> edit
Entering configuration mode

{master:0}[edit]
root@switch#

System

The first section that will be configured are the system settings. This will cover users, services, setting time-zone, along with other configuration needed for the switch.

root-authentication

{master:0}[edit]
root@switch# set system root-authentication plain-text-password

Now you’ll be prompted to put in the root password, which will be the following below. You’ll type this twice to verify that the password is typed correctly.

15.learner

Login

This section is where you can add users. In this example, we will add an admin user. First, let’s drop down into the [edit system login] hierarchy:

{master:0}[edit]
root@switch# edit system login

Now you can configure the user directly. First, we want to set a UID unique to the user account, in this case, we will be using 2000:

{master:0}[edit system login]
root@switch# set user admin uid 2000

Next, configure the class that the user will be assigned to. Because this is an admin user, we will add them to the super-user class, which allows complete access to view and modify configuration, along with run show commands.

You can read more on Juniper user classes using the link below.
https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/junos-os-login-class.html

{master:0}[edit system login]
root@switch# set user admin class super-user

Next, we can add the super-users account. This is mostly used for implementations that use radius for authentication. Instead of using the set commands, we’ll load the entire configuration:

{master:0}[edit system login] 
root@switch# load merge terminal relative
[Type ^D at a new line to end input]
user super-users {
    uid 2006;
    class super-user;
}
^D

The load merge terminal relatvie command is very useful when loading in chunks of configuration without setting each command. We will mostly use set commands for the remainder of the lab and the SRX lab to get you familiar with Juniper. However, to get you familar with loading configuration. We’ll practice with the next couple of sections.

You will still need to set the password for the admin user:, which will be the same as the root password:

{master:0}[edit system login]
root@switch# set user admin authentication plain-text-password

Services

Next, we’ll configure one service, SSH. We will go over additional services in a different lab. First, we need to get out of the login hierarchy and into the services hierachy by running:

{master:0}[edit system login] 
root@switch# top edit system services
{master:0}[edit system services]

The top edit command, brings us to the very top of the configuration, then by specifying system services, we drop down to the system services hierarchy. Now you can load in the following configuration:

ssh {
    root-login allow;
    protocol-version v2;
    client-alive-interval 120;
    connection-limit 5;
    rate-limit 3;
}

What exactly did we accomplish with this? Here is a breakdown of the lines of configuration you just loaded:

  1. root-login allow: This allows us to login with the root account
  2. protocol-version v2: We set that we are using SSH version 2 (which is the industry standard)
  3. client-alive-interval 120: This sets the number of seconds (120) before a null packet is sent to the client to keep the SSH session alive
  4. connection-limit 5: This sets the number of SSH connections to 5 at the same time
  5. rate-limit 3: This sets the number of SSH attempts per minute

This completes the services section and you’ll configure syslog next. You’ll need to get out of  the services hierarchy:

 

{master:0}[edit system services]
root@switch# up
{master:0}[edit system]
root@switch#

Miscellanous System Configurations

First, we want to set up auto snapshot. This allows the switch to automatically fix corrupt Junos OS files in the root partition.

set auto-snapshot

Next, we’ll set the time zone, which is EST in out case:

set time-zone EST5EDT

Now, we need to prevent redirect messages from being sent from the switch:

set no-redirects

This next command is part of the Juniper default configuration that’s generally kept. The management instance keeps the management port on the back of the Juniper in its own routing instance:

set management-instance

In order to keep the switch secure, we want to log out of the switch whenever the console port is disconnected:

set ports console log-out-on-disconnect

Juniper can keep a number of configurations on it flash between 0-49. This means that Juniper will have a copy of the configuration of the switch up to 49 times ago. For our environment, we will set it to 49:

set max-configurations-on-flash 49

We need to configure the NTP servers so that the switch can keep the correct time, as NTP stands for Network Time Protocol We will set up 3 for redundancy:

set ntp server 216.239.35.4
set ntp server 216.239.35.8
set ntp server 216.239.35.12

Lastly, we need to give the switch a name:

set system host-name s-neatrack-lab

Chassis

The chassis section is to configure options for Virtual Chassis (VC), AE device counts, and any alarms.

Redundancy

In most switch uses, the redundancy option isn’t needed because there is only one switch. However, with the use of 2 switch, you can configure a Virtual Chassis, which allows 2 switches to act as one. Thus, you would need to configure graceful swithover in the event that one of the switches in the VC were to go down. To set this up, you can run the following:

{master:0}[edit]
root@switch# set chassis redundancy graceful-switchover

Aggregated-Devices

You can configure the number of aggreagated devices on the switch. Aggregated devices are devices that utilize the use of 2 separate physical interfaces that are joined to act as one. This is called an AE (aggregated ethernet) interface in Juniper. This can also be referred to as a Port Channel or a Bond. Becuase we won’t be configuring any of these types of interface for this lab, we’ll set it to one:

{master:0}[edit]
root@switch# set chassis aggregated-devices ethernet device-count 1

Alarm

You can also set/disable alarms on the switch. We will disable the alarm on the management port since we aren’t currently using it:

{master:0}[edit]
root@switch# set chassis alarm management-ethernet link-down ignore

VLANs

Next, we need to configure vlans for our interfaces to use. We will first create our uplink vlan into the Richweb Lab network. To connect to the Richweb Lab network, we will be using vlan14. However, if you are not at Richweb, you will need to contact a NeatRack trainer with your current setup for further instruction and guidance.


Let’s start by dropping into the vlans hierarchy:

{master:0}[edit]
root@switch# edit vlans

Now we can create our vlan with a name by referencing the vlan id and the identification for the vlan:

{master:0}[edit vlans]
root@switch# set vl2_inet vlan-id 14

Now your vlan should look like this:

{master:0}[edit vlans]
root@switch# show
vl14_inet {
    vlan-id 14;
}

Now we will create our own lab network using vlan 60, which we will put an IP address on:

{master:0}[edit vlans]
root@switch# set vl60_mng vlan-id 60 l3-interface irb.60

Your vlan60 should look like the following:

{master:0}[edit vlans]
root@switch# show
vl60_mng {
    vlan-id 60;
    l3-interface irb.60;
}

We will be configuring the l3 interface in the next section.

Interfaces

Now, we’ll configure interfaces to the KVM host, our Internet Uplink into the Richweb lab network, and to our Juniper SRX.

Uplink to Richweb Lab

We will first be configuring our uplinking interface into the Richweb lab. Go to the interfaces hierarchy:

{master:0}[edit vlans]
root@switch# top edit interfaces

[edit interfaces] 
root@switch#

Now, Juniper ports start at 0 instead of 1, so a Juniper interface will look like:

ge-0/0/0

We will configure our uplink port on ge-0/0/0:

[edit interfaces] 
root@switch# edit ge-0/0/0

[edit interfaces ge-0/0/0]
root@switch#

First we want to set a description of what the port will be uplinking to or doing. We’ll add the port as well in the description for easier searching:

[edit interfaces ge-0/0/0]
root@switch# set description "Uplink to RW Lab (ge-0/0/0)"

We are going to set our port to be an trunk port that can send multiple vlans to the same device without creating multiple access ports; however, we will only be adding 1 vlan to the trunk. This is because we are connecting our switch to another switch. 

[edit interfaces ge-0/0/0]
root@switch# set unit 0 family ethernet-switching interface-mode trunk

Now we want to assign vlan 2 to our port:

[edit interfaces ge-0/0/0]
root@switch# set unit 0 family ethernet-switching vlan members 14

Lastly, we want to set storm-control to default to that if an interface exceeds 80% of the available bandwidth, the port will be disabled. This is to protect against loops, rogue devices, and maliciously places devices to create a DoS (Denial of Service) attack by taking up all available resources.

[edit interfaces ge-0/0/0]
root@switch# set unit 0 family ethernet-switching storm-control default

Your final interface should look like this:

[edit interfaces ge-0/0/0]
root@switch# show
description "Uplink to RW Lab (ge-0/0/0)";
unit 0 {
    family ethernet-switching {
        interface-mode trunk;
	vlan {
            members 14;
        }
        storm-control default;
    }

Uplink to KVM Host

Next, we can create the uplink port to our KVM host. We will be using a trunk port so that we can future vlans to the KVM host. We will be using port ge-0/0/1, which you’ll set up very similarly to ge-0/0/0 with the addition of vlan60.


Because the configuration is so similar, we will utilize the copy utility of Juniper, so let’s go back up to the interfaces level:

[edit interfaces ge-0/0/0]
root@switch# up

[edit interfaces]
root@switch#

Now we can copy ge-0/0/0 to ge-0/0/1:

[edit interfaces]
root@switch# copy ge-0/0/0 to ge-0/0/1

Now you’ll see that ge-0/0/1 is an exact copy of ge-0/0/0:

[edit interfaces]
root@switch#show
ge-0/0/0 {
    description "Uplink to RW Lab (ge-0/0/0)";
    unit 0 {
        family ethernet-switching {
	    interface-mode trunk;
	    vlan {
                members 14;
           }
           storm-control default;
        }
    }
}

ge-0/0/1 {
    description "Uplink to RW Lab (ge-0/0/0)";
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
	    vlan {
                members 14;
            }
            storm-control default;
        }
    }
}

We need to tailor this for our application so, change the description first:

[edit interfaces]
root@switch# set ge-0/0/1 description "Uplink to KVM Host (ge-0/0/1)"

Now, because we will be passing multiple vlans now and in future labs, we want to adjust the vlans that we are passing through to the KVM host:

[edit interfaces]
root@switch# delete ge-0/0/1 unit 0 family ethernet-switching vlan members 14
root@switch# set ge-0/0/1 unit 0 family ethernet-switching vlan members all

Your KVM uplink interface should now look like this:

[edit interfaces]
root@switch# show ge-0/0/1
description "Uplink to KVM Host (ge-0/0/1)"

We are allowing all vlans that we have created and will create in future labs to go to the KVM host.

IRB Interface

We’ll be creating a lab network of our own so we can set up SSH connectivity to future equipment in the NeatRack course.  We will create an IRB interface, which stands for Integrated Routing and Bridging. This means that we will be placing a Layer-3 (Routing) component, an IP address, on a Layer-2 (Packet) component, a VLAN. 

Let’s first go to the irb hierarchy:

[edit interfaces]
root@switch# edit irb

[edit interfaces irb]
root@switch#

Similar to physical interfaces, we will set a unit, however, out unit will correspond to out lab vlan60:

[edit interfaces irb]
root@switch# set unit 60 description "NeatRack Lab 172.30.60.5 (irb.60)"
root@switch# set unit 60 family inet no-redirects address 172.30.60.5/24

So our irb should look like the following:

[edit interfaces irb]
root@switch# show
unit 60 {
    description "NeatRack Lab 172.30.60.5 (irb.60)";
    family inet {
        no-redirects;
        address 172.30.60.5/24;
    }
}

Protocols

The protcols sections is where you can configure protocols options like OSPF and BGP (both are dynamic routing protocols that will be explained in future labs), RSTP, LLDP, and other Layer 2 protocols. Let’s go the the protocols hierarchy first:

[edit interfaces irb]
root@switch# top edit protocols

[edit protocols]
root@switch#

We’ll first set up the timeout interval for the switch to learn MAC (Media Access Control)addresses, which is important so that there aren’t any stale MAC addresses left. the default is 300 seconds, but in our case, we can set the interval for a longer time period:

[edit protocols]
root@switch# set l2-learning global-mac-table-aging-time 14440

Next, we want to set up LLDP (Link Layer Discovery Protocol) so that we can see devices that are connected to our switch. We want to set this on all interfaces so that we can see a device that’s plugged into our switch. We can even see what port a neighbor is plugged into and what corresponding port that we are plugged into on the neighbor. LLDP can provide descriptions that are configured on ports as well.

[edit protocols]
root@switch# set lldp interface all
root@switch# set lldp port-id-subtype interface-name
root@switch# set neighbour-port-info-display port-description

In addition to LLDP, we want to enable LLDP-MED (Link Layer Discovery Protocol-Media Endpoint Discovery) on all interfaces, which is an extension of LLDP for the discovery of devices like VoIP phones:

[edit protocols]
root@switch# set lldp-med interface all

Now we want to set up IGMP (Internet Group Management Protocol) snooping. This reduces the amount of multicast traffic being flooded on a device and only sends to multicase traffice only to devices that are expecting to receive multicast traffice. You can set only specific vlans to snoop but in most cases, you’ll set it on all interfaces:

[edit protocols]
root@switch# set igmp-snooping vlan all

Another option we can configure is the amount of time that a port can be blocked due to a BPDU error. A BPDU is a Bridge Protocol Data Unit that is used in the STP (Spanning Tree Protocol) to exchange packet information on Layer 2. We can configure what ports can be blocked verus what ports should be allowed. We are going to set the timeout to 30 seconds:

[edit protocols]
root@switch# set layer2-control bpdu-block disable-timeout 30

In tandem with the disable timeout, we need to configure RSTP (Rapid Spanning Tree Protocol) what what ports were are and aren’t blocking. We’ll start by setting the port of the KVM host that we WON’T block:

[edit protocols]
root@switch# set rstp interface ge-0/0/1 mode point-to-point

Then we can set all remaining ports as blocked as to protect the switch from malicious and rogue devices that could flood traffic and disrupt the network:

[edit protocols]
root@switch# set rstp interface all
root@switch# set rstp bpdu-block-on-edge

With the protocols section completed, it should look like the following:

[edit protocols]
root@switch# show
l2-learning {
    global-mac-table-aging-time 1440;
}
lldp {
    port-id-subtype interface-name;
    neighbour-port-info-display port-description;
    interface all;
}
lldp-med {
    interface all;
}
igmp-snooping {
    vlan all;
}
layer2-control {
    bpdu-block {
        disable-timeout 30;
    }
}
rstp {
    interface ge-0/0/1 {
        mode point-to-point;
    }
    interface all;
    bpdu-block-on-edge;
}

Forwarding Options and PoE

The last two sections are relatively short, so they’re grouped together. Forwarding options are the ways that we can forward traffic, whether that is setting up storm control profiles, or relaying DHCP requests to an external server. We will create a default storm control profile and to block all traffic that exceeds the default bandwidth of 80%:

[edit protocols]
root@switch# up

[edit]
root@switch# set forwarding-options storm-control-profiles default all

Your forwarding option should look like the following:

[edit]
root@switch# show forwarding-options
storm-control-profiles default {
    all;
}

PoE is Power over Ethernet and it allows a network device like a switch or even a router to pass power to another device like a phone of WAP (Wireless Access Point) over its Ethernet connection. We want to enable PoE on all interfaces:

[edit]
root@switch# set poe interface all

Final Check

To apply your changes, you must run the commit command:

[edit]
root@switch# commit

If there are any errors Juniper will tell you, and you will need to address them before a commit will be successful. If your commit comes back with no errors, then congratulations, you have successfully configured a Juniper switch. Now you can configure your SRX

Juniper SRX Configuration