Juniper JNCIA-Junos - Class of Service

For this last chapter, you are going to mark some traffic.

Exercise – Marking packets

Your goal is to create a filter that you will apply on JUNOS1′s em4 interface (input). This filter will mark all packets from 10.3.3.0/24 with expedited-forwarding (EF) DSCP.

Solution

firewall {
    family inet {
        filter apply-cos {
            term from-JUNOS3 {
                from {
                    source-address {
                        10.3.3.0/24;
                    }
                }
                then {
                    forwarding-class expedited-forwarding;
                    accept;
                }
            }
            term default {
                then accept;
            }
        }
    }

em4 {
     unit 0 {
         family inet {
             filter {
                 input apply-cos;
             }
             address 172.30.25.9/30;
         }
     }
 }

This is the end of our hands-on exercises, you should now be ready to seat for the

JNCIA-Junos certification. Don’t forget you can obtain 50% off the exam cost by passing the pre-assessment exam on Juniper’s website.

Juniper JNCIA-Junos - Routing Policy and Firewall Filters

We assume you have read chapter 2 of Juniper’s second PDF so that you can practice routing policy and firewall filters. First we are going to start with a simple route redistribution followed by a firewall filter to restrict telnet access.

Exercise 1 – Default route redistribution into OSPF

Create a policy to redistribute the existing default route (0.0.0.0/0) on JunOS1 into OSPF so that other routers can use it.

Solution

[edit]
root@JUNOS1# edit policy-options

[edit policy-options]
root@JUNOS1# set policy-statement default-static term accept-default-static from protocol static

[edit policy-options]
root@JUNOS1# set policy-statement default-static term accept-default-static from route-filter 0.0.0.0/0 exact

[edit policy-options]
root@JUNOS1# set policy-statement default-static term accept-default-static then accept

[edit policy-options]
root@JUNOS1# show
policy-statement default-static {
    term accept-default-static {
        from {
              protocol static;
              route-filter 0.0.0.0/0 exact;
             }
    then accept;
    }
}

[edit policy-options]
root@JUNOS1# top edit protocols ospf

[edit protocols ospf]
root@JUNOS1# set export default-static

[edit]
root@JUNOS1# commit

JUNOS1 advertises the default route in OSPF, check that JUNOS3 can actually see it.

root@JUNOS3# run show route protocol ospf
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/150] 00:00:05, metric 0, tag 0
> to 172.30.25.9 via em4.0

Exercise 2 – Firewall filtering

To complete this exercise, we have to activate telnet service on JUNOS1.

[edit]
root@JUNOS1# set system services telnet

[edit]
root@JUNOS1# set system login user junuser class super-user authentication plain-text-password

[edit]
root@JUNOS1# commit
commit complete

Test the service from JUNOS3 using the loopback0 as the source interface.

[edit]
root@JUNOS3# run telnet 10.1.1.1 interface lo0
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.

JUNOS1 (ttyp0)
login: junuser
Password:

--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC

junuser@JUNOS1> exit
Connection closed by foreign host.

Now add a firewall filter to allow telnet access to JUNOS3 loopback0 interface (10.3.3.3) only. You have to define the firewall filter, a prefix list and apply the filter on JUNOS1′s loopback0.

Solution

[edit]
root@JUNOS1# edit firewall filter limit-telnet-access

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-accept from source-prefix-list trusted

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-accept from protocol tcp

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-accept from destination-port telnet

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-accept then accept

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-reject from protocol tcp

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-reject from destination-port telnet

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-reject then discard

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term telnet-reject then log

[edit firewall filter limit-telnet-access]
root@JUNOS1# set term else-accept then accept

[edit firewall filter limit-telnet-access]
root@JUNOS1# show
term telnet-accept {
    from {
        source-prefix-list {
        trusted; ## 'trusted' is not defined
             }
        protocol tcp;
        destination-port telnet;
        }
    then accept;
   }
term telnet-reject {
    from {
         protocol tcp;
         destination-port telnet;
         }
    then {
         discard;
    }
}
term else-accept {
    then accept;
}

[edit firewall filter limit-telnet-access]
root@JUNOS1# top edit policy-options

[edit policy-options]
root@JUNOS1# set prefix-list trusted 10.3.3.3

[edit policy-options]
root@JUNOS1# top set interfaces lo0 unit 0 family inet filter input limit-telnet-access

Let check we can only connect only from JUNOS3′s loopback0 interface. Also have a look at the firewall log on JUNOS1.

root@JUNOS2# run telnet 10.1.1.1 interface lo0
Trying 10.1.1.1...

^C

[edit]
root@JUNOS3# run telnet 10.1.1.1 interface lo0
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.

JUNOS1 (ttyp0)

login:

root@JUNOS1# run show firewall log
Log :
Time      Filter    Action Interface     Protocol        Src Addr                         Dest Addr
01:42:37  limit-telnet-access D em1.0    TCP             10.2.2.2                         10.1.1.1
01:42:33  limit-telnet-access D em1.0    TCP             10.2.2.2                         10.1.1.1
01:42:29  limit-telnet-access D em1.0    TCP             10.2.2.2                         10.1.1.1
01:42:25  limit-telnet-access D em1.0    TCP             10.2.2.2                         10.1.1.1

Juniper JNCIA-Junos - Routing Fundamentals

Starting with Juniper’s second PDF, we can make a new practice lab for the next 3 chapters. This lab is a bit more advanced than the previous one in order to test the OSPF routing protocol. You will need 3 Juniper routers, here are the connections:

• JUNOS1, interface em0 <-> JUNOS2, interface em0
• JUNOS1, interface em1 <-> JUNOS2, interface em1
• JUNOS1, interface em4 <-> JUNOS3, interface em4
• JUNOS2, interface em3 <-> JUNOS3, interface em3

Make sure the routers have a factory default configuration (use the load factory-default command if you need to). Then set the host-name, root password and IP addresses for each router, to save time you can copy and paste the following commands (don’t forget to commit):

JUNOS1

set system host-name JUNOS1
set interfaces em0 unit 0 family inet address 172.30.25.2/30
set interfaces em1 unit 0 family inet address 172.30.25.6/30
set interfaces em3 unit 0 family inet address 192.168.1.1/24
set interfaces em4 unit 0 family inet address 172.30.25.9/30
set interfaces lo0 unit 0 family inet address 10.1.1.1/24
set system root-authentication plain-text-password

JUNOS2

set system host-name JUNOS2
set interfaces em0 unit 0 family inet address 172.30.25.1/30
set interfaces em1 unit 0 family inet address 172.30.25.5/30
set interfaces em3 unit 0 family inet address 172.30.25.13/30
set interfaces lo0 unit 0 family inet address 10.2.2.2/24
set system root-authentication plain-text-password

JUNOS3

set system host-name JUNOS3
set interfaces lo0 unit 0 family inet address 10.3.3.3/24
set interfaces em3 unit 0 family inet address 172.30.25.14/30
set interfaces em4 unit 0 family inet address 172.30.25.10/30
set system root-authentication plain-text-password

If everything went fine, the topology for your new lab should be like in the following image. Please read chapter one of Juniper’s second PDF before continuing.

Exercise 1 – Static routing

On JUNOS1, configure a default static route (0.0.0.0/0) to next-hop 172.30.25.1.

Solution

Add a second default static route with a preference of 7 to next-hop 172.30.25.5 that should be used as a backup (floating static route) and commit.

Solution

Let’s check that everything is working as expected:

root@JUNOS1# run show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 00:01:54
> to 172.30.25.1 via em0.0
                    [Static/7] 00:00:13
> to 172.30.25.5 via em1.0
...

[edit]
root@JUNOS1# run ping 10.2.2.2
PING 10.2.2.2 (10.2.2.2): 56 data bytes
64 bytes from 10.2.2.2: icmp_seq=0 ttl=64 time=1.650 ms
64 bytes from 10.2.2.2: icmp_seq=1 ttl=64 time=1.272 ms

root@JUNOS2# run monitor traffic interface em0
...
19:33:03.526742 172.30.25.2 > 10.2.2.2: ICMP echo request, id 16648, seq 0, length 64

[edit]
root@JUNOS1# deactivate interfaces em0

[edit]
root@JUNOS1# commit
commit complete

[edit]
root@JUNOS1# run ping 10.2.2.2
PING 10.2.2.2 (10.2.2.2): 56 data bytes
64 bytes from 10.2.2.2: icmp_seq=0 ttl=64 time=3.247 ms
64 bytes from 10.2.2.2: icmp_seq=1 ttl=64 time=0.658 ms

[edit]
root@JUNOS2# run monitor traffic interface em1
...
19:35:30.376370 172.30.25.6 > 10.2.2.2: ICMP echo request, id 14090, seq 7, length 64

Exercise 2 – OSPF routing

Configure OSPF routing on all interfaces connecting routers and their loopbacks but no adjacency should be formed on interfaces connecting to the 172.30.25.0/30 subnet (172.30.25.1 and 172.30.25.2).

Solution

JUNOS1

set protocols ospf area 0.0.0.0 interface em0.0 passive
set protocols ospf area 0.0.0.0 interface em1.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface em3.0
set protocols ospf area 0.0.0.0 interface em4.0

JUNOS2

set protocols ospf area 0.0.0.0 interface em0.0 passive
set protocols ospf area 0.0.0.0 interface em1.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface em3.0

JUNOS3

set protocols ospf area 0.0.0.0 interface em3.0
set protocols ospf area 0.0.0.0 interface em4.0
set protocols ospf area 0.0.0.0 interface lo0.0

Let’s check that everything is working as expected:

[edit]
root@JUNOS1# run show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.30.25.5      em1.0                  Full      10.2.2.2         128    34
172.30.25.10     em4.0                  Full      10.3.3.3         128    32

[edit]
root@JUNOS2# run show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.30.25.6      em1.0                  Full      10.1.1.1         128    36
172.30.25.14     em3.0                  Full      10.3.3.3         128    38

[edit]
root@JUNOS3# run show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.30.25.13     em3.0                  Full      10.2.2.2         128    36
172.30.25.9      em4.0                  Full      10.1.1.1         128    35

root@JUNOS3# run show route protocol ospf
...
10.1.1.1/32        *[OSPF/10] 00:04:11, metric 1
...
10.2.2.2/32        *[OSPF/10] 00:04:11, metric 1
...
192.168.1.0/24     *[OSPF/10] 00:00:02, metric 2
> to 172.30.25.9 via em4.0

root@JUNOS3# run traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 40 byte packets
1  192.168.1.1 (192.168.1.1)  1.611 ms  0.588 ms  1.362 ms

[edit]
root@JUNOS3# deactivate interfaces em4

[edit]
root@JUNOS3# commit
commit complete

[edit]
root@JUNOS3# run traceroute 192.168.1.1

traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 40 byte packets
1  172.30.25.13 (172.30.25.13)  2.316 ms  1.479 ms  0.882 ms
2  192.168.1.1 (192.168.1.1)  1.283 ms  1.300 ms  1.129 ms

Finally, don’t forget to reactivate interface em4 and commit:

[edit]
root@JUNOS3# activate interfaces em4

[edit]
root@JUNOS3# commit
commit complete

Juniper JNCIA-Junos - Operational Monitoring and Maintenance

For the last chapter of Juniper’s first PDF, we are going to have a closer look how to get more information about JunOS and also practice the password recovery procedure that will sooner and later be useful for you.

Exercise 1 – boot messages

Do you remember the booting process in chapter 1? Well you have a command to see the messages again (hint: use the show system command).

Solution

root@JUNOS1# run show system boot-messages
Copyright (c) 1996-2010, Juniper Networks, Inc.
...
ad1: 1024MB <QEMU HARDDISK 0.11.0> at ata0-slave WDMA2
Trying to mount root from ufs:/dev/ad0s1a
vn_read_compressed_block: invalid block index 550

Exercise 2 – JunOS packages

Still about the booting process, we have seen that JunOS packages are loaded on virtual memory disks (you can still see that using the show system storage command). Find the command which list all these packages including their versions.

Solution

root@JUNOS1> show version
Hostname: JUNOS1
Model: olive
JUNOS Base OS boot [10.1R1.8]
JUNOS Base OS Software Suite [10.1R1.8]
JUNOS AppId Services [10.1R1.8]
JUNOS IDP Services [10.1R1.8]
JUNOS Routing Software Suite [10.1R1.8]

Exercise 3 – network interfaces

Now show all interfaces configured on JUNOS1 (equivalent to show ip interface brief on Cisco IOS) and then use a command to show a maximum of details for interface em0.

Solution

root@JUNOS1> show interfaces terse
Interface               Admin Link Proto    Local                 Remote
em0                     up    up
em0.0                   up    up   inet     192.168.1.1/24
192.168.1.3/24
...

root@JUNOS1> show interfaces em0 extensive
Physical interface: em0, Enabled, Physical link is Up
Interface index: 8, SNMP ifIndex: 17, Generation: 134
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Clocking:
...

Exercise 4 – monitor

Let’s play a bit more with the monitor command. On JUNOS2, monitor all interface traffic (statistics) in real time. From JUNOS1 ping JUNOS2 (192.168.1.2) and check the counters incrementing.

Solution

root@JUNOS2> monitor interface traffic
Interface    Link  Input packets        (pps)     Output packets        (pps)
...
em0           Up           1476                            1302
...

Exercise 5 – password recovery

Now assume you have forgotten the root password for JUNOS2 or maybe you really have, don’t panic, you are going to do a password recovery. First reboot you system and be ready to hit space to get to the kernel command prompt. Then follow the procedure as explained in the documentation.

root@JUNOS2> request system reboot
Reboot the system ? [yes,no] (no) yes
...

Solution

Hit [Enter] to boot immediately, or space bar for command prompt.
<space>
Type '?' for a list of commands, 'help' for more detailed help.
OK boot –s
...
Enter full pathname of shell or 'recovery' for root password recovery or RETURN for /bin/sh: recovery
...
NOTE: Once in the CLI, you will need to enter configuration mode using
NOTE: the 'configure' command to make any required changes. For example,
NOTE: to reset the root password, type:
NOTE:    configure
NOTE:    set system root-authentication plain-text-password
NOTE:    (enter the new password when asked)
NOTE:    commit
NOTE:    exit
NOTE:    exit
NOTE: When you exit the CLI, you will be asked if you want to reboot
NOTE: the system

Starting CLI ...
root> configure
Entering configuration mode

[edit]
root# set system root-authentication plain-text-password
New password:
Retype new password:

[edit]
root# commit
error: could not open database: /var/run/db/juniper.data: No such file or directory
error: Database open failed for file '/var/run/db/juniper.data': No such file or directory
commit complete

[edit]
root@JUNOS2# exit
Exiting configuration mode

root@JUNOS2> exit
Reboot the system? [y/n] y

Well done, you completed all exercises for Juniper’s first PDF, now it is time to go into more serious stuff with the second PDF and Routing Fundamentals

Juniper JNCIA-Junos - Secondary System Configuration

Before diving deeper into JunOS configuration you should have read chapter 4 of Juniper’s first PDF. Let’s continue with the same lab as before.

Exercise 1 – Syslog

On JUNOS2, set up a syslog file to record any config changes (hint: system syslog). Commit and quit.

Solution

[edit]
root@JUNOS2# set system syslog file config-changes change-log info

[edit]
root@JUNOS2# commit and-quit
commit complete
Exiting configuration mode

Now go back to configuration mode and change junuser to give operator permissions instead of super-user. Again, commit and-quit. Using the show command, display the log related to your previous commit.

Solution

[edit]
 root@JUNOS2# set system login user junuser class operator

[edit]
root@JUNOS2# commit and-quit
commit complete
Exiting configuration mode

root@JUNOS2> show log config-changes
 Dec 16 05:06:24  JUNOS2 mgd[1392]: UI_CFG_AUDIT_SET: User 'root' set:
[system login user junuser class] "super-user -> "operator"

Use the help syslog command to learn more about the message code (UI_CFG_AUDIT_SET).

Solution

root@JUNOS2> help syslog UI_CFG_AUDIT_SET
 Name:          UI_CFG_AUDIT_SET
 Message:       User '<username>' <action>: <pathname> <delimiter><data> ->
 "<value>"
 Help:          Value has been set for configuration object
 Description:   The indicated user set a value for a configuration object, as
 indicated.
 Type:          Event: This message reports an event, not an error
 Severity:      info

From JUNOS1, telnet to JUNOS2 (192.168.1.2), log in and start monitoring the change-log file in real time.

Solution

root@JUNOS1> telnet 192.168.1.2
 Trying 192.168.1.2...
 Connected to 192.168.1.2.
 Escape character is '^]'.

JUNOS2 (ttyp0)

login: junuser
 Password:

--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC
 junuser@JUNOS2> monitor start config-changes

Using the console (logged with root) on JUNOS2, delete em1 configuration and cancel your current candidate configuration using the rollback command. The operator connected via telnet should have been informed of what just happened. Stop all monitoring and exit.

Solution

[edit]
root@JUNOS2# delete interfaces em1

[edit]
 root@JUNOS2# rollback 0
 load complete

junuser@JUNOS2>
 *** config-changes ***
 Dec 16 05:16:53  JUNOS2 mgd[1392]: UI_CFG_AUDIT_OTHER: User 'root' delete: [interfaces em1]
 Dec 16 05:17:12  JUNOS2 mgd[1392]: UI_CFG_AUDIT_OTHER: User 'root' rollback: /config/juniper.conf
...

junuser@JUNOS2> monitor list
 monitor start "config-changes" (Last changed Dec 16 05:17:13)

junuser@JUNOS2> monitor stop
 junuser@JUNOS2> exit

Exercise 2 – FTP and automated configuration backup

On JUNOS2, activate FTP and commit (hint: use set system services).

Solution

[edit]
 root@JUNOS2# set system services ftp

[edit]
 root@JUNOS2# commit
 commit complete

Back to JUNOS1, configure it to backup any new configuration that becomes active on JUNOS2 (192.168.1.2) using FTP to ftp://junuser@192.168.1.2 (hint: configuration is done in system archival configuration level). Commit once to apply your candidate configuration, delete interface em3 and commit again. After a few seconds your new configuration should be backed up on JUNOS2 (use the file list /var/home/junuser command to check).

Solution

[edit]
 root@JUNOS1# edit system archival configuration

[edit system archival configuration]
 root@JUNOS1# set transfer-on-commit
 root@JUNOS1# set archive-sites ftp://junuser@192.168.1.2 password mypassword

[edit system archival configuration]
 root@JUNOS1# commit
 commit complete

[edit system archival configuration]
 root@JUNOS1# top delete interfaces em3

[edit system archival configuration]
 root@JUNOS1# commit
 commit complete

[edit]
 root@JUNOS1# run show log messages | match juniper.conf
 Dec 16 07:06:20  JUNOS1 logger: transfer-file: Transferred
/var/transfer/config/JUNOS1_juniper.conf.gz_20111216_070529

root@JUNOS2> file list /var/home/junuser
/var/home/junuser:
 .ssh/
 JUNOS1_juniper.conf.gz_20111216_070459

Juniper JNCIA-Junos - User Interface Options & Initial Configuration

This page is to practice what you learned in Juniper’s PDF (part 1), chapter 2 and 3.  So now it is time to get active and log in as root without any password.

First thing you should notice is that Amnesiac is the default host-name. This indicates that our JunOS is running with the factory-default configuration (you can use the load factory-default command in configuration mode to have a JunOS in this state).

You are logged in as root, you should see the UNIX shell prompt root@% where you can type UNIX commands like ls or ps but this is beyond our scope. What we want is the operational mode prompt root> that is started with the cli command.

Amnesiac (ttyd0)
 login: root

--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC
 root@% cli
 root>

Type show configuration to display the current factory-default configuration.

root> show configuration
## Last commit: 2011-02-17 00:34:21 UTC by root
version 10.1R1.8;
system {
    syslog {
        user * {
            any emergency;
        }
        file messages {
            any notice;
            authorization info;
        }
        file interactive-commands {
            interactive-commands any;
        }
    }
    ## Warning: missing mandatory statement(s): 'root-authentication'
}

Note the missing mandatory statement warning, this means you will not be able to commit your changes until you set up a password for root.

Exercise 1 – root password

Go to configuration mode using the configure command and try to commit the current candidate configuration, then set a password for root and commit again.

Solution

Now your JunOS route is ready for new commits! Let’s see if you can apply the same configuration on your second router without looking at the solution above. Remember, you must first login, then go to operational mode and then to configuration mode. The command to set up the root password starts with set system, use ? to find the complete command. Finally, don’t forget to commit or your configuration will not be active!

root# set system ?
 Possible completions:
 > accounting           System accounting configuration
 + apply-groups         Groups from which to inherit configuration data
 ...
 > tracing              System wide option for remote tracing

Also try out the help topic command to display usage guidelines (if you want the all story), the help reference command to display summary information (the most useful when you want to know about all command options) and the help apropos command which displays the contexts (typically set commands) relevant to the configuration hierarchy level at which you are currently positioned (if you want help only for your current hierarchy level and nothing else).

[edit]
 root# help topic system root-authentication
 root# help reference system root-authentication
 root# help apropos root-authentication

Exercise 2 – host-name

Have you noticed? We have exactly the same prompt on both routers; this is annoying as we want to know which is which. Let’s add a host-name for both routers. We’ll let you find the right command (hint: use set system ?)

Solution

Now compare the candidate configuration with the active configuration using show | compare. The + are lines that are going to be added to the active configuration when you commit and – lines are going to be removed.  This is very useful to know exactly what is about to be changed. Do it on both routers and commit.

root# show | compare
 [edit system]
 +  host-name JUNOS1;

[edit]
 root# commit
 commit complete

Exercise 3 – rollback

On JUNOS2, configure a wrong hostname, anything. Commit your configuration and rollback to the one containing the right hostname.

Solution

Exercise 4 – edit

Let’s configure an IP address for the first interface on our JUNOS1 router using the edit command. Place yourself at the following level:interfaces em0 unit 0 family inet. em0 is the name for our first interface, give it this IP address and mask: 192.168.1.1/24

Solution

Exercise 5 – up

Go back up 3 levels and edit em1 in the same way as em0. Configure the following IP address and mask: 10.1.1.1/8

Solution

Exercise 6 – top & commit check

Go to the top level, check your configuration and commit.

Solution

Exercise 7 – set vs. edit & set

Configure the em0 (logical unit 0, IPv4 family) interface on JUNOS2 router with 192.168.1.2/24 IP address using the set command from the top level (remember ? is your friend).

Solution

Configure IP address 10.1.1.2/8 on em1 by placing yourself to the last level using edit.

Solution

Exercise 8 – telnet

Now we would like to configure telnet (SSH would be a better choice as it is secured) to remotely configure JUNOS2 from JUNOS1. First check that nothing is configured under system services level while staying at your current level (hint: use top). Then edit that level without going back to the top level. Configure telnet with the set command, exit to the top level, check what you are about to change and finally commit.

Solution

Add a user account to access this device using telnet and commit again.

Solution

Exercise 9 – run

Back to JUNOS1, without leaving configuration mode, ping and telnet to JUNOS2 (IP address: 192.168.1.2). Use Ctrl + C to stop pinging. Use the username and password you previously created to authenticate with JUNOS2.

Solution

Exercise 10 – automatic rollback

From your telnet session on JUNOS2, delete the telnet statement under system services level and commit in a way that if you lose your connection to JUNOS2, the configuration is automatically rolled back after 1 minute. Exit both configuration and operational modes to go back to JUNOS1. Try to telnet again to 192.168.1.2; this should not work. Wait about 2 minutes (take a coffee break) and try again. This time it should work as your previous commit should have been rolled back.

Solution

Exercise 11 – copy & rename

Copy em1 configuration to em2 and rename em2 to em3. Deactivate em3. Go to interfaces level and display the candidate configuration. Note the inactive: em3. Finally commit.

Solution

Change em3 IP address from 10.1.1.1/8 to 10.1.1.3/8 (hint: use the rename command). Maybe you would like to see what commands produced this candidate configuration? Use show and a pipe to find out.

Solution

Exercise 12 – annotate

Add an annotation saying that em3 is inactive. Using only one command, commit with a comment describing what you just did and return to operational mode.

Solution

Compare the active configuration with the previous one using the show configuration command.

Solution

Exercise 13 – rescue

You know your configuration works well (basic connectivity is established for instance). Therefore you want to make it the rescue configuration in case of problem; this will speed up a recovery. Create the rescue configuration and restore it.

Solution

Exercise 14 – preferred IP address

Configure an additional IP address (192.168.1.3/24) for em0 and configure your router so that it uses this IP as the source when sending pings to JUNOS2. Commit, exit to operational mode and check with the show interfaces command that em0 has 2 IP addresses.

Solution

Let’s check that JUNOS1 can actually send packets using source IP address 192.168.1.3. On JUNOS2, in operational mode, use the following command to monitor the traffic to and from the router:  monitor traffic interface em0 (Ctrl + C to exit). Then ping from JUNOS1 to 192.168.1.2. You should see that you are receiving packets from 192.168.1.3 (192.168.1.3 > 192.168.1.2)

root@JUNOS1> ping 192.168.1.2
 PING 192.168.1.2 (192.168.1.2): 56 data bytes
 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=12.510 ms
 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.665 ms

root@JUNOS2> monitor traffic interface em0
 verbose output suppressed, use <detail> or <extensive> for full protocol decode
 Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
 Address resolution timeout is 4s.
 Listening on em0, capture size 96 bytes
 04:37:18.543830 192.168.1.3 > 192.168.1.2: ICMP echo request, id 40718, seq 12, length 64
 04:37:18.544023 192.168.1.2 > 192.168.1.3: ICMP echo reply, id 40718, seq 12, length 64

Congratulations, you completed this page! If you are ready to have some more, please go to Secondary System Configuration

Juniper JNCIA-Junos - Operating System Fundamentals

This part is mainly theory and reading chapter 1 of Juniper’s PDF (part 1). It is only what you need for the exam; however, it is interesting to have an overview of how JunOS actually boots up.

First, make your lab in GNS3 by connecting 2 routers back to back using their em0 interface. Keep this lab for all your exercises for chapters of part 1.

Start your Juniper routers in GNS3 and console to them. As you learned in Juniper’s PDF, JunOS is based on FreeBSD, an open source UNIX Operating System. This OS is very reliable and you also get extra tools that you cannot find on Cisco IOS for instance.

The first thing you should see after starting JunOS, are the kernel modules being loaded. The kernel is the core component of the operating system.

/boot/modules/if_bge.ko text=0xa98c data=0x364+0xc syms=[0x4+0xd50+0x4+0xd18]
...
/boot/modules/mac_runasnonroot.ko text=0x7b4 data=0x4d0 syms=[0x4+0x310+0x4+0x39d]

Then, you have a chance to give parameters to the kernel in order to change the default booting process. This can be useful to recover the root password for example, but that’s not the only use. Root is the name given to the super administrator on UNIX.

Here you can just wait a few seconds or hit enter to boot immediately; the kernel is then being loaded. There is a lot of information, most of it is really not relevant, but some might be interesting, like how much memory has been detected or other CPU information.

Hit [Enter] to boot immediately, or space bar for command prompt.
Booting [/kernel]...
platform_early_bootinit: M/T Series Early Boot Initialization
Olive CPU
...
Copyright (c) 1996-2010, Juniper Networks, Inc. All rights reserved.
Copyright (c) 1992-2006 The FreeBSD Project.
...
JUNOS 10.1R1.8 #0: 2010-02-12 17:15:05 UTC
    builder@queth.juniper.net:/volume/build/junos/10.1/release/10.1R1.8/obj-i386/bsd/sys/compile/JUNIPER
...
real memory  = 268369920 (255 MB)
avail memory = 248840192 (237 MB)
...

Now, it’s time for the drivers to be loaded, these are what the OS needs to interface with hardware components.  Here you can see that our 6 network interface cards (em0 to em5) have been detected and have correct Ethernet MAC addresses, which is good! What is a router useful for if you don’t have network interfaces?

Setting up M/T interface operations and attributes
platform_mastership_init: Unknown product_type 0x00000001
em5: bus=0, device=8, func=0, Ethernet address 00:ab:ae:99:e3:05
em4: bus=0, device=7, func=0, Ethernet address 00:ab:ae:99:e3:04
em3: bus=0, device=6, func=0, Ethernet address 00:ab:ae:99:e3:03
em2: bus=0, device=5, func=0, Ethernet address 00:ab:ae:99:e3:02
em1: bus=0, device=4, func=0, Ethernet address 00:ab:ae:99:e3:01
em0: bus=0, device=3, func=0, Ethernet address 00:aa:00:ca:a4:00
...

Next is JunOS itself, bundled in different packages, to be loaded into memory via virtual disks (md0, md1 etc.). These packages begin with the letter j and we can guess their function, like jkernel, jroute or jpfe (PFE) which – if you remember chapter one – stands for Packet Forwarding Engine and is an important part of JunOS.

Mounted jbase package on /dev/md0...
Verified manifest signed by PackageProduction_10_1_0
Verified jboot signed by PackageProduction_10_1_0
Verified jbase-10.1R1.8 signed by PackageProduction_10_1_0
Mounted jkernel package on /dev/md1...
Verified manifest signed by PackageProduction_10_1_0
Verified jkernel-10.1R1.8 signed by PackageProduction_10_1_0
Mounted jpfe package on /dev/md2...
Mounted jdocs package on /dev/md3...
Verified manifest signed by PackageProduction_10_1_0
Verified jdocs-10.1R1.8 signed by PackageProduction_10_1_0
Mounted jroute package on /dev/md4...
Verified manifest signed by PackageProduction_10_1_0
Verified jroute-10.1R1.8 signed by PackageProduction_10_1_0
Mounted jcrypto package on /dev/md5...
Verified manifest signed by PackageProduction_10_1_0
Verified jcrypto-10.1R1.8 signed by PackageProduction_10_1_0
Mounted jpfe-common package on /dev/md6
...

Now that JunOS is in memory, it is executed and its modules/drivers loaded as well.

...
ifpfed_ds1e1Loading E1/T1/J1 driver
ifpfed_ds3e3Loading the NETPFE DS3 module
ifpfed_eia530 ifpfed_ethLoading the NETPFE ethernet module
...
Loading Multilink Services PICs module.
Loading the M&T Platform NETPFE module
...

Your FreeBSD/JunOS is ready. If everything went fine, you should see a login prompt.

See you on User Interface Options & Initial Configuration to start playing with your new lab.

Malware attack on Apple employees by hackers who targeted Facebook

 The same ring of hackers that are responsible for hacking into at least 40 companies including Facebook and Twitter are reportedly also infected the computers of some Apple employees, the company acknowledged Tuesday.

The purpose of hack considered an effort to steal company secrets, research and intellectual property that they can sell. Investigators tracked at least one server being used by the hacker ring to a hosting company in the Ukraine.

"Apple has identified malware which infected a limited number of Mac systems through a vulnerability in the Java plug-in for browsers," the company said in its statement. "The malware was employed in an attack against Apple and other companies, and was spread through a website for software developers. We identified a small number of systems within Apple that were infected and isolated them from our network."

Apple isolated the infected systems from its network and said there was no indication that any data had been taken. Apple is releasing a tool that scans Macs and removes the Java malware. Oracle has also released an update to Java that fixes the vulnerability. 

In addition to the Java update, Apple has rolled out version 11.0.2 of iTunes via Software Update. 

Facebook acknowledged that it was attacked and said no user data had been compromised, but that many other companies had been targeted in the same attack, whereas in the attack on Twitter resulted in the breach of as many as 250,000 users' data.

Apple said it was working closely with law enforcement to find the culprits, but the spokesman would not elaborate further. The Federal Bureau of Investigation declined to comment.

Patch released for critical Adobe vulnerabilities

 Today Adobe released a patch for two critical vulnerabilities (CVE-2013-0640 and CVE-2013-0641) that are already being exploited by attackers. Adobe released version 11.0.02 of its Adobe Reader and Adobe Acrobat Pro applications. 

Vulnerabilities affect Adobe Reader and Acrobat XI (11.0.01 and earlier), X (10.1.5 and earlier) and 9.5.3 and earlier for Windows and Mac OS X systems.

"These updates address vulnerabilities that could cause a crash and potentially allow an attacker to take control of the affected system." security advisory reads.

Exploits were discovered by security company FireEye and researchers with antivirus provider Kaspersky Lab have confirmed the exploit can successfully escape the Adobe sandbox.

Users can update the software through the built-in updater or by downloading a copy of the Windows, Mac, or Linux installer directly from Adobe's website. 

New Mac malware opens secure connection for a remote hacker

A new malware threat for the Mac has been discovered that attempting to set up a secure connection for a remote hacker to connect through and grab private information.

Dubbed "Pintsized" that uses a modified version of OpenSSH to potentially set up a remote connection into Mac accounts.

This backdoor Trojan can be used to conduct distributed denial of service (DDoS) attacks, or it can be used to install additional Trojans or other forms of malicious software.

Since the connection between the hacker and the machine is encrypted, it becomes very hard for the Trojan to be detected or traced. The threat has the potential to become serious, as it uses an exploit in OS X to bypass Gatekeeper and establish a reverse shell that creates a secure connection. 

Trojan stays hidden by disguising itself as a file that is used for networked printers in Mac OS X. The location of the malware has been traced to this particular directory. This tactic conceals the Trojan and makes a monitor think that a printer is seeking access to the network.

Pintsized hasn't been seen in the wild yet, according to security software maker Intego, since the malware looks to still be in a proof of concept stage.

LivingSocial: Employees' and Founders' Common Stock Now Worthless

PrivCo EXCLUSIVE): LIVINGSOCIAL Receives Emergency $110M Debt Infusion From Existing Investors With Oppressive Terms, JUST DAYS FROM BANKRUPTCY, Effectively Handing Over Distressed Co. to Today's Financing Participants...Implied Valuation: JUST $330M, DOWN 94% FROM $5.7 BILLION In Dec. 2011 V.C. Round...Equity Was NOT Issued Today (As Has Been Widely Misreported)...Instead, A Desperate LIVINGSOCIAL Accepted A COMPLEX Series of Secured-Convertible-Debt Securities With Onerous Terms (PrivCo Has Confirmed Exclusively) Including: (1) Liquidation Preferences of SEVERAL TIMES the $110M In Debt (2) Double-Digit Cash Dividends (3) "Super-Warrants" On Stock, (4) Secured Against Co. Assets and Stock, and (5) Re-Pricing of Participating Investors Earlier Rounds...Employees' and Founders' Common Stock Now Worthless

• Today's Participating Investors Effectively Now Own The Entire Company
• Common Stock and Shares of Company's Employees Now WORTHLESS 
• LivingSocial senior company insider tells PrivCo: "We scrambled for cash quickly....we did receive one other funding offer, but the current investors' terms were the least bad of two terrible proposals....which we had no choice but to take it or file for Chapter 11."
• LivingSocial ended year with just $76 Million in cash & current assets, against a stunning $338 Million in short-term liabilities
• "The company threw itself at the mercy of its investors - who, having already sunk $823,624,695 before the emergency funding, were in a position to dictate the terms - to avoid a total collapse of the company within days...though this will likely be LivingSocial's final gasp." - PrivCo CEO Sam Hamadeh
• LivingSocial Insider Tells PrivCo: "It was a take-it-or-leave it deal"

February 20, 2013 8:15 PM EST - LivingSocial (PrivCo Private Company Ticker: LIVSOCP) has just received $110 million in emergency financing from some of its existing investors today, in a last ditch attempt to save the privately-held daily deals company from imminent financial ruin, PrivCo has confirmed exclusively, until the company can be sold by year's end to recoup whatever is still possible.
PrivCo today exclusively confirmed the terms of the distressed financing (which was NOT a "new VC round" as has been widely misreported) with both a senior executive at LivingSocial familiar with the transaction, as well as a current LivingSocial venture capital investor participating in the new emergency debt financing:
Distressed Financing Including The Following Onerous Terms (PrivCo Exclusive):

• LIVINGSOCIAL Issued A New Complex Class of Convertible Debt Securities, Convertible Into a Still New Class of Preferred Stock With Still More New Preferences - EQUITY or stock was NOT issued today as widely misreported today
• "Super liquidation preferences" of several times the $110 Million in debt (e.g., at 4x, a debt liquidation preference of up to $440 Million)
• A large issuance of "Super-Warrants" for still more shares in LivingSocial attached to the Secured Convertible Debt
• Double-digit annual cash dividends to be paid by LivingSocial
• Re-pricing of participating investors' previous rounds

According to PrivCo sources, the financing effort was led by LivingSocial's largest outside shareholder, Amazon.com, with participation from some of its major venture capital investors (who had already invested $823,624,695 in equity in LivingSocial before today's emergency debt financing) in the hopes of salvaging what they can, with strict terms in place to ensure they are first to be paid upon a sale or bankruptcy. (Prior investors in LivingSocial include: Lightspeed Venture Partners, Grotech Ventures, Revolution Ventures, and U.S. Venture Partners; the VC firm confirming today's deal terms preferred not be to named)
Implied valuation of LivingSocial in today's financing is $330 million, a 94% decrease from December 2011's $5.7 Billion valuation, although with the complex sets of rights/re-pricings of earlier rounds/cash dividends, etc. the implied valuation could be as little as $165 million. ("There really is no valuation anymore," said one source familiar with the transaction terms.)
Ramifications of LivingSocial's Acceptance of The Oppressive Terms of Emergency Funding:

• 4,000 employees' stock is rendered worthless
• Employees' stock options are worthless
• Founder stock is worthless
• Emergency funding terms means LivingSocial handed over the company to today's funders
• Nearly a billion dollars of investor money has been lost, as all early rounds (Series A, B etc.) are worthless
• Sources said LivingSocial's Board made clear this was the final lifeline, that the company must break even by the end of the year including closing dozens of unprofitable offices and laying off thousands of employees
• PrivCo expects Chapter 11 by year end, with secured convertible debt holders ahead of merchants in liquidation preferences
• Despite company's attempt to say this funding was a vote of confidence by investors, virtually no risk to investors because primary spot in line in a bankruptcy liquidation
• LivingSocial's merchants owed money stand behind today's funders in the event of a bankruptcy, as unlike today's funders they are unsecured creditors
• PrivCo's sources indicate that investors are forcing the company to break even in an attempt to sell the company by year's end
• Needless to say, there will not be a LivingSocial IPO

LivingSocial's Commentary:
When reached by PrivCo today, a senior LivingSocial communications executive - who would only speak off the record stated: "I will try to put my best possible positive spin on what you have pieced together is a negative situation":

• "Shareholders extended a lifeline to the company which is a major vote of confidence"
• "Yes most of our Current Liabilities are Merchant Payables, which are local merchants' share of the dailydeals we sell and yes we collect that cash in advance, and we do owe them for all that - and yes it's now hundreds of millions of dollars more than our cash on hand. But despite our Current Liabilities being high, they at least are not as frightening as Groupon's Merchant Payables gap, as Groupon pays out usually in 1/3rds (30 days, 60 days, then 90 days), while at LivingSocial, we usually pay 80% of the total daily deal's sales to a merchant within 10 days of the offer ending, and then we owe them the other 20% months later.  So yes we owe local merchants a lot of money, more than our Cash, and these Merchant Payables are most of our Current Liabilities as PrivCo surmised, but I will point out thta at least it's not as as great a portion of our Current Liabilities as Groupon's."
• "Our CEO said we do now plan to break even and become profitable by year end. I'm not sure exactly how, but that is our goal."
• "Hopefully the announcement today of new financing helps alleviate concerns of LivingSocial's solvency...and we know they are out there....especially concerns from our merchants we owed money to."
• "We also did get a second offer to finance us, so we were able to choose between two offers. And that's a great position to be in, and shows we had a second offer and they were also interested. And the current investors' offer was the better of the two so that's the Financing deal we took." ("As a corporate lawyer who has seen thousands of funding term sheets," said PrivCo CEO Sam Hamadeh, Esq.,"given the oppressive terms of the offer they accepted, I can't imagine how ugly the other financing offer looked.")

PrivCo's Hamadeh concluded:"LivingSocial's issuance of this onerous emergency debt financing effectively means that its most recent investors entirely control the equity of the company. LivingSocial essentially threw itself at the mercy of its investors - who had already sunk over $823 Million in the company before today's $110 Million additional lifeline - to avoid a total collapse of the company that would have occurred within days.  Regardless, this will likely be LivingSocial's - and the daily deals bubble's - final gasp."

UNIX Tutorial Seven

7.1 Compiling UNIX software packages  

We have many public domain and commercial software packages installed on our systems, which are available to all users. However, students are allowed to download and install small software packages in their own home directory, software usually only useful to them personally.

There are a number of steps needed to install the software.

• Locate and download the source code (which is usually compressed)
• Unpack the source code
• Compile the code
• Install the resulting executable
• Set paths to the installation directory

Of the above steps, probably the most difficult is the compilation stage.

Compiling Source Code

All high-level language code must be converted into a form the computer understands. For example, C language source code is converted into a lower-level language called assembly language. The assembly language code made by the previous stage is then converted into object code which are fragments of code which the computer understands directly. The final stage in compiling a program involves linking the object code to code libraries which contain certain built-in functions. This final stage produces an executable program.

To do all these steps by hand is complicated and beyond the capability of the ordinary user. A number of utilities and tools have been developed for programmers and end-users to simplify these steps.

make and the Makefile

The make command allows programmers to manage large programs or groups of programs. It aids in developing large programs by keeping track of which portions of the entire program have been changed, compiling only those parts of the program which have changed since the last compile.

The make program gets its set of compile rules from a text file called Makefile which resides in the same directory as the source files. It contains information on how to compile the software, e.g. the optimisation level, whether to include debugging info in the executable. It also contains information on where to install the finished compiled binaries (executables), manual pages, data files, dependent library files, configuration files, etc.

Some packages require you to edit the Makefile by hand to set the final installation directory and any other parameters. However, many packages are now being distributed with the GNU configure utility.

configure

As the number of UNIX variants increased, it became harder to write programs which could run on all variants. Developers frequently did not have access to every system, and the characteristics of some systems changed from version to version. The GNU configure and build system simplifies the building of programs distributed as source code. All programs are built using a simple, standardised, two step process. The program builder need not install any special tools in order to build the program.

The configure shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a Makefile in each directory of the package.

The simplest way to compile a package is:

1. cd to the directory containing the package's source code.
2. Type ./configure to configure the package for your system.
3. Type make to compile the package.
4. Optionally, type make check to run any self-tests that come with the package.
5. Type make install to install the programs and any data files and documentation.
6. Optionally, type make clean to remove the program binaries and object files from the source code directory  

The configure utility supports a wide variety of options. You can usually use the --help option to get a list of interesting options for a particular configure script.

The only generic options you are likely to use are the --prefix and --exec-prefix options. These options are used to specify the installation directories.  

The directory named by the --prefix option will hold machine independent files such as documentation, data and configuration files.

The directory named by the --exec-prefix option, (which is normally a subdirectory of the --prefix directory), will hold machine dependent files such as executables.

7.2 Downloading source code

For this example, we will download a piece of free software that converts between different units of measurements.

First create a download directory 

% mkdir download

Download the software here and save it to your new download directory.

7.3 Extracting the source code  

Go into your download directory and list the contents. 

% cd download 
% ls -l

As you can see, the filename ends in tar.gz. The tar command turns several files and directories into one single tar file. This is then compressed using the gzip command (to create a tar.gz file).

First unzip the file using the gunzip command. This will create a .tar file. 

% gunzip units-1.74.tar.gz

Then extract the contents of the tar file.  

% tar -xvf units-1.74.tar

Again, list the contents of the download directory, then go to the units-1.74 sub-directory. 

% cd units-1.74

7.4 Configuring and creating the Makefile  

The first thing to do is carefully read the README and INSTALL text files (use the less command). These contain important information on how to compile and run the software.

The units package uses the GNU configure system to compile the source code. We will need to specify the installation directory, since the default will be the main system area which you will not have write permissions for. We need to create an install directory in your home directory.  

% mkdir ~/units174

Then run the configure utility setting the installation path to this. 

% ./configure --prefix=$HOME/units174

NOTE: The $HOME variable is an example of an environment variable. The value of $HOME is the path to your home directory. Just type

% echo $HOME 

to show the contents of this variable. We will learn more about environment variables in a later chapter.

If configure has run correctly, it will have created a Makefile with all necessary options. You can view the Makefile if you wish (use theless command), but do not edit the contents of this.

7.5 Building the package 

Now you can go ahead and build the package by running the make command. 

% make

After a minute or two (depending on the speed of the computer), the executables will be created. You can check to see everything compiled successfully by typing

% make check

If everything is okay, you can now install the package.  

% make install

This will install the files into the ~/units174 directory you created earlier.

7.6 Running the software

You are now ready to run the software (assuming everything worked). 

% cd ~/units174

If you list the contents of the units directory, you will see a number of subdirectories.

bin	The binary executables
info	GNU info formatted documentation
man	Man pages
share	Shared data files

To run the program, change to the bin directory and type 

% ./units

As an example, convert 6 feet to metres. 

You have: 6 feet
You want: metres 

* 1.8288

If you get the answer 1.8288, congratulations, it worked.

To view what units it can convert between, view the data file in the share directory (the list is quite comprehensive).

To read the full documentation, change into the info directory and type 

% info --file=units.info

7.7 Stripping unnecessary code

When a piece of software is being developed, it is useful for the programmer to include debugging information into the resulting executable. This way, if there are problems encountered when running the executable, the programmer can load the executable into a debugging software package and track down any software bugs.

This is useful for the programmer, but unnecessary for the user. We can assume that the package, once finished and available for download has already been tested and debugged. However, when we compiled the software above, debugging information was still compiled into the final executable. Since it is unlikey that we are going to need this debugging information, we can strip it out of the final executable. One of the advantages of this is a much smaller executable, which should run slightly faster.

What we are going to do is look at the before and after size of the binary file. First change into the bin directory of the units installation directory. 

% cd ~/units174/bin
% ls -l

As you can see, the file is over 100 kbytes in size. You can get more information on the type of file by using the file command. 

% file units

units: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped

To strip all the debug and line numbering information out of the binary file, use the strip command 

% strip units
% ls -l

As you can see, the file is now 36 kbytes - a third of its original size. Two thirds of the binary file was debug code!!!

Check the file information again. 

% file units

units: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped

Sometimes you can use the make command to install pre-stripped copies of all the binary files when you install the package. Instead of typing make install, simply type make install-strip