Oesj LGD 9.a PDF

Operating Enhanced Services for
n
JUNOS Software
io
9.a
ct
du
ro
ep
Detailed Lab Guide
rR
Fo
ot
N
1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-OESJ

Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks
are the property of their respective owners.
Operating Enhanced Services for JUNOS Software Detailed Lab Guide, Revision 9.a
Copyright © 2008, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History:
Revision 9.a—March 2008
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 9.0R1. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental
or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
n
io
ct
Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice.
du
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The JUNOS software has no
known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
ro
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
ep
rR
Fo
ot
N
Contents
Lab 1: Initial System Configuration (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Load a Reset Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Establish Layer 2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Part 3: Assign IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Part 4: Establish Layer 3 Connectivity Using OSPF Routing Protocol . . . . . . . . . . . . . . . . . . . . . . 1-11
Part 5: Establish Hosts Within Each Site and Summarize the Advertisement of Their Prefixes
Across the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
n
Lab 2: Security Policies (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Part 1: Interface Assignment to Security Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
io
Part 2: Building Address Books for Each Security Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Part 3: Establishing and Configuring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
ct
Part 4: Testing and Monitoring the Functionality of Security Zones . . . . . . . . . . . . . . . . . . . . . . . 2-23
Lab 3: Network Address Translation (NAT) (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
du
Part 1: Adding Public Addresses to Address Books of Necessary Security Zones . . . . . . . . . . . . 3-2
Part 2: Define Source and Destination NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Part 3: Incorporating Source and Destination NAT into Security Policies . . . . . . . . . . . . . . . . . . . 3-9
Part 4: NAT Testing and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
ro
Lab 4: Campus Interconnectivity—IPSec VPNs (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Part 1: Configuring IKE Phase 1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
ep
Part 2: Configuring IKE Phase 2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Part 3: Configuring Route-Based IPSec VPN Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Part 4: Troubleshooting the Retail/Finance IPSec VPN Operation . . . . . . . . . . . . . . . . . . . . . . . . 4-10
rR
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Fo
ot
N
Contents • iii
iv • Contents
N
ot
Fo
rR
ep
ro
du
ct
io
n
.
Course Overview
The Operating Enhanced Services for JUNOS Software course is an instructor-led, four-day
course designed to provide enterprise network engineers with the knowledge and skills
necessary to use JUNOS software with enhanced services. It covers advanced security
features and configurations of Juniper Networks platforms, focusing specifically on the
enhanced services of JUNOS software. The course combines both lecture and labs, with
significant time allocated for hands-on experience with JUNOS software enhanced services.
Objectives
After successfully completing this course, you should be able to:
n
• Describe the requirements of routers and firewalls.
io
• Describe the architecture of JUNOS software with enhanced services.
• Describe and define zone types and their purpose.
ct
• Configure and monitor zones.
• Explain the meaning of SCREEN options.
du
• Identify advantages of using JUNOS SCREEN options.
• Configure and monitor zone-based SCREEN options.
•
•
ro
Explain security policy functionality.
Configure and monitor security policies.
ep
• Describe Network Address Translation (NAT) features.
• Configure and monitor NAT.
• Describe IPSec VPNs.
rR
• Configure and monitor policy-based and route-based IPSec VPNs.

• Describe high availability support and the JUNOS Services Redundancy Protocol
(JSRP).
Fo
• Describe JSRP operation.

• Configure and monitor JSRP.
Intended Audience
The primary audiences for this course are the following:
ot
• Enterprise network engineers; and

• Reseller support engineers.
N
Course Level
This is an advanced-level course.
. Course Overview • v
Prerequisites
The following are the prerequisites for this course:
• The Operating Juniper Networks Routers in the Enterprise course or equivalent
experience;
• Knowledge, familiarity, and comfort with the JUNOS software CLI;
• Experience managing routers (not necessarily Juniper Networks) in an enterprise
environment;
• An understanding of destination-based, hop-by-hop IP routing; and
• Experience with interior gateway protocols (IGPs).
n
io
ct
du
ro
ep
rR
Fo
ot
N
vi • Course Overview
Course Agenda
Day 1
Lab 1: Initial System Configuration (Detailed)
Day 2
Lab 2: Security Policies (Detailed)
Day 3
Lab 3: Network Address Translation (NAT) (Detailed)
n
Day 4
io
Lab 4: Campus Interconnectivity—IPSec VPNs (Detailed)
ct
du
ro
ep
rR
Fo
ot
N
Course Agenda • vii

Document Conventions
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface
(CLI) or a graphical user interface (GUI). To make the language of these documents easier to
read, we distinguish GUI and CLI text from chapter text according to the following table.
Style Description Usage Example
Franklin Normal text. Most of what you read in the Lab
n
Gothic Guide and Student Guide.
Console text:
io
Courier
New commit complete
• Screen captures
ct
• Noncommand-related Exiting configuration
syntax mode
du
Century GUI text elements: Select File>Open, and then click
Gothic Configuration.conf in the
• Menu names
Filename text box.
• Text field entry
ro
Input Text Versus Output Text
ep
You will also frequently see cases where you must enter input text yourself. Often this will be
shown in the context of where you must enter it. We use bold style to distinguish text that is
input versus text that is simply displayed.
rR
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Fo
Normal GUI View configuration history by

clicking Configuration>History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File>Save, and enter
ot
config.ini in the Filename field.

N
viii • Document Conventions

Defined and Undefined Syntax Variables
Finally, this course distinguishes between regular text and syntax variables, and it also
distinguishes between syntax variables where the value is already assigned (defined variables)
and syntax variables where you must assign the value (undefined variables). Note that these
styles can be combined with the input style as well.
CLI Text where variable value is already policy my-peers

Variable assigned.
n
GUI Click on my-peers in the dialog.
Variable
io
CLI Text where the variable’s value is Type set policy
Undefined the user’s discretion and text where policy-name.
ct
the variable’s value as shown in the
GUI ping 10.0.1.1
lab guide might differ from the
Undefined
value the user must input. Select File>Save, and enter
du
filename in the Filename field.
ro
ep
rR
Fo
ot
N
Document Conventions • ix
Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication

The Operating Enhanced Services for JUNOS Software Detailed Lab Guide was developed and
tested using software version 9.0R1. Previous and later versions of software may behave
n
differently so you should always consult the documentation and release notes for the version
of code you are running before reporting errors.
io
This document is written and maintained by the Juniper Networks Education Services
development team. Please send questions and suggestions for improvement to
ct
training@juniper.net.
Technical Publications
du
You can print technical manuals and release notes directly from the Internet in a variety of
formats:
• Go to http://www.juniper.net/techpubs/.
ro
• Locate the specific software or hardware release and title you need, and choose
the format in which you want to view or print the document.
ep
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support

rR
For technical support, contact Juniper Networks at http://www.juniper.net/customers/

support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the
United States).
Fo
ot
N
x • Additional Information
Lab 1
Initial System Configuration (Detailed)
Overview
n
io
In this first lab you will establish the baseline for all other labs. Specifically, you will establish
Layer 2 and Layer 3 connectivity between the devices within your group. There are four
ct
groups—A,B,C, and D. You will work in pairs, as defined by your instructor. Layer 2 connectivity
consists in establishing a WAN Frame Relay connection across the Internet, and virtual LAN
(VLAN) connectivity within each city of your group. Layer 3 connectivity consists of assigning IP
du
addressing, as defined in the lab guide, and configuring the OSPF routing protocol. Once all the
connections are established, you will configure three hosts within each site, and ensure that
summary routes for these hosts are propagated across the WAN links.
This lab is available in two formats: a high-level format, that is designed to make you think
ro
through each step, and a detailed format that offers step-by-step instructions complete with
sample output from most of the commands.
ep
By completing this lab, you will perform the following tasks:
• Load the reset configuration files.
• Establish Layer 2 Frame Relay and VLAN addressing.
rR
• Assign IP addresses to all the specified interfaces.

• Establish Layer 3 connectivity using the OSPF routing protocol.
• Ensure the distribution of aggregate routes across the Internet.
Fo
• Test and monitor network connectivity.

This lab requires you to use the Sydney router, which is logically segmented into several
virtual routers. XX-VR and XX-VR2 are defined as virtual routers for each site, where XX is a
two-letter abbreviation of your router. Sydney also acts as the service provider, which provides
ot
Frame Relay services between sites.

N
Initial System Configuration (Detailed) • Lab 1–1

9.a.9.0R1
Operating Enhanced Services for JUNOS Software
Key Commands
Key operational-mode commands used in this lab include the following:

configure
load override
ping
show interfaces terse
show ospf
show route table
traceroute
n
Part 1: Load a Reset Configuration File
io
In this part of the lab each team will load the reset configuration file.
ct
Step 1.1
du
Log in to the router with the username lab and the password lab123. Note that the
username and the password are case sensitive.
Tokyo (ttyd0)
login: lab
Password:
ro
--- JUNOS 9.0R1.10 built 2008-02-14 03:14:18 UTC
ep
lab@Tokyo> configure
Entering configuration mode
rR
Step 1.2
Enter configuration mode and load a reset configuration using the load override
command. The file to be loaded is located in the /var/home/lab/oesj/
lab1-reset.conf directory.
Fo
lab@Tokyo> configure
[edit]
lab@Tokyo# load override /var/home/lab/oesj/lab1-reset.conf
ot
load complete
[edit]
N
lab@Tokyo#
Step 1.3
Display the resulting configuration.
Here is the sample configuration for the Tokyo router:
[edit]
lab@Tokyo# show
## Last changed: 2008-02-22 04:02:56 UTC
version 9.0R1.10;
Lab 1–2 • Initial System Configuration (Detailed)

system {
host-name Tokyo;
root-authentication {
encrypted-password "$1$88Mjdcd5$QDURoHCb0BJHBzSOyhqly."; ## SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$MEG.LEMV$N5FAp2A5tUP6U52UiSHoB/"; ##
SECRET-DATA
n
}
}
io
}
services {
ct
ssh;
telnet;
web-management {
du
http {
interface ge-0/0/0.0;
}
} ro
}
syslog {
user * {
ep
any emergency;
}
file messages {
any any;
rR
authorization info;
}
file interactive-commands {
interactive-commands any;
}
Fo
}
}
interfaces {
ge-0/0/0 {
description "Do-not-delete-Management-Interface!";
ot
unit 0 {
family inet {
address 10.210.11.178/28;
N
}
}
}
}
security {
zones {
security-zone trust {
interfaces {
all {
host-inbound-traffic {
system-services {

all;
}
protocols {
all;
}
}
}
}
}
}
policies {
from-zone trust to-zone trust {
n
policy trust {
match {
io
source-address any;
destination-address any;
ct
application any;
}
then {
du
permit;
}
}
} ro
}
}
ep
[edit]
lab@Tokyo#
Part 2: Establish Layer 2 Addressing

rR
In this part of the lab you will configure all Layer 2 addresses for your router. Refer to the Lab 1
diagram for your group letter (A, B, C, or D).
Fo
Step 2.1
Display the status of the Internet-facing serial interface and LAN interface ge-0/0/3.
[edit]
lab@Tokyo# run show interfaces ge-0/0/3
ot
Physical interface: ge-0/0/3, Enabled, Physical link is Up

Interface index: 140, SNMP ifIndex: 36
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Loopback: Disabled,
N
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:

Enabled,
Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Current address: 00:17:cb:4e:ab:03, Hardware address: 00:17:cb:4e:ab:03
Last flapped : 2007-12-03 02:42:03 UTC (4d 23:06 ago)
Input rate : 0 bps (0 pps)

Output rate : 0 bps (0 pps)

Active alarms : None
Active defects : None
[edit]
lab@Tokyo# run show interfaces se-1/0/1
Physical interface: se-1/0/1, Enabled, Physical link is Up
Type: Serial, Link-level type: PPP, MTU: 1504, Maximum speed: 8mbps
Interface flags: Point-To-Point Internal: 0x4000
n
Link flags : Keepalives
io
ct
du
Question: What is the link-level type for the serial
interface facing the Internet?
ro
Answer: The link-level type is PPP.
Question: Based on the network diagram for your group,

ep
what are the link-level encapsulations for the serial
interface that faces the Internet and the ge-0/0/3
interface?
rR
Answer: The ge-0/0/3 interface requires VLAN-tagging

Fo
encapsulation. The serial link that faces the Internet

requires Frame Relay encapsulation.
Step 2.2
ot
Configure Layer 2 parameters, as identified in the network diagram for your group letter (A, B,
C, or D). Commit the changes.
[edit]
N
lab@Tokyo# edit interfaces
[edit interfaces]
lab@Tokyo# set ge-0/0/3 vlan-tagging
[edit interfaces]
lab@Tokyo# set ge-0/0/3 unit 100 vlan-id 100
[edit interfaces]
lab@Tokyo# set ge-0/0/3 unit 200 vlan-id 200

[edit interfaces]
lab@Tokyo# set se-1/0/1 encapsulation frame-relay
[edit interfaces]
lab@Tokyo# set se-1/0/1 unit 602 dlci 602
[edit interfaces]
lab@Tokyo# show ge-0/0/3
vlan-tagging;
unit 100 {
vlan-id 100;
n
}
unit 200 {
io
vlan-id 200;
}
ct
[edit interfaces]
lab@Tokyo# show se-1/0/1
du
encapsulation frame-relay;
unit 602 {
dlci 602;
} ro
[edit interfaces]
lab@Tokyo# commit
ep
commit complete
[edit interfaces]
lab@Tokyo#
rR
Step 2.3
Display the status of the interfaces again using show interfaces interface-name
command.
Fo
[edit]
lab@Tokyo# run show interfaces ge-0/0/3
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Link-level type: Ethernet, MTU: 1518, Speed: 100mbps, Loopback: Disabled,
ot
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:

Enabled,
Remote fault: Online
N

Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
Current address: 00:17:cb:4e:ab:03, Hardware address: 00:17:cb:4e:ab:03
Active alarms : None
Active defects : None

Logical interface ge-0/0/3.100 (Index 64) (SNMP ifIndex 43)

Flags: SNMP-Traps VLAN-Tag [ 0x8100.100 ] Encapsulation: ENET2
Input packets : 0
Output packets: 0
Security: Zone: trust
Allowed host-inbound traffic : bootp bfd bgp dlsw dns dvmrp igmp ldp msdp
nhrp ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp
ident-reset http https ike netconf ping rlogin rpm rsh snmp snmp-trap ssh
telnet traceroute xnm-clear-text xnm-ssl lsping

n
Input packets : 0
Output packets: 0
io
ct
du
Input packets : 0 ro
Output packets: 0
ep
rR
[edit]
lab@Tokyo# run show interfaces se-1/0/1
Physical interface: se-1/0/1, Enabled, Physical link is Up
Type: Serial, Link-level type: Frame-Relay, MTU: 1504, Maximum speed: 8mbps
Fo

Interface flags: Point-To-Point Internal: 0x4000
Link flags : Keepalives DTE
ANSI LMI settings: n391dte 6, n392dte 3, n393dte 4, t391dte 10 seconds
LMI: Input: 4 (00:00:02 ago), Output: 3 (00:00:02 ago)
ot
DTE statistics:
Enquiries sent : 3
Full enquiries sent : 0
N
Enquiry responses received : 3

Full enquiry responses received : 0
DCE statistics:
Enquiries received : 0
Full enquiries received : 0
Enquiry responses sent : 0
Full enquiry responses sent : 0
Common statistics:
Unknown messages received : 0
Asynchronous updates received : 1
Out-of-sequence packets received : 0

Keepalive responses timedout : 0

Logical interface se-1/0/1.602 (Index 70) (SNMP ifIndex 46)

Flags: Hardware-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
Input packets : 0
Output packets: 0
n
io
DLCI 602
ct
Flags: Down, DCE-Unconfigured
Total down time: 00:00:19 sec, Last down: 00:00:19 ago
Input packets : 0
du
Output packets: 0
DLCI statistics:
Active DLCI :0 Inactive DLCI :1
ro
Question: What is the difference between the display of
the interfaces status in this step and Step 2.1?
ep
rR
Answer: The interface status in Step 2.1 illustrated

Layer 1 parameters for LAN and WAN interfaces. Also,
the serial interface used PPP as its Layer 2 protocol.
Now the LAN interface status illustrates logical units
Fo
(VLANs), and the serial interface uses Frame Relay as

its Layer 2 protocol.
Part 3: Assign IP Addressing

ot
Step 3.1
N
Assign IP addresses to the WAN, LAN, and lo0 interfaces of your router, as illustrated in the
Lab 1 diagram for your group letter (A, B, C, or D).
[edit interfaces]
lab@Tokyo# set ge-0/0/3 unit 100 family inet address 10.222.100.1/24
[edit interfaces]
lab@Tokyo# set ge-0/0/3 unit 200 family inet address 10.222.200.1/24
[edit interfaces]

lab@Tokyo# set se-1/0/1 unit 602 family inet address 172.18.36.1/30
[edit interfaces]
lab@Tokyo# set lo0 unit 0 family inet address 192.168.24.1
[edit interfaces]
lab@Tokyo# show
ge-0/0/0 {
description "Do-not-delete-Management-Interface!";
unit 0 {
family inet {
address 10.210.11.178/28;
n
}
}
io
}
ge-0/0/3 {
ct
vlan-tagging;
unit 100 {
vlan-id 100;
du
family inet {
address 10.222.100.1/24;
}
} ro
unit 200 {
vlan-id 200;
family inet {
ep
address 10.222.200.1/24;
}
}
}
rR
se-1/0/1 {
encapsulation frame-relay;
unit 602 {
dlci 602;
family inet {
Fo
address 172.18.36.1/30;
}
}
}
lo0 {
ot
unit 0 {
family inet {
address 192.168.24.1/32;
N
}
}
}
[edit interfaces]
lab@Tokyo#
Step 3.2
Commit the configuration changes.

[edit interfaces]
lab@Tokyo# commit and-quit
commit complete
Exiting configuration mode
lab@Tokyo>
Step 3.3
Test IP connectivity by pinging the IP address of the directly attached interface of your peer
router across the Internet.
lab@Tokyo> ping 172.18.36.2
n
PING 172.18.36.2 (172.18.36.2): 56 data bytes
64 bytes from 172.18.36.2: icmp_seq=0 ttl=65 time=3.758 ms
io
64 bytes from 172.18.36.2: icmp_seq=2 ttl=65 tim^C
ct
--- 172.18.36.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.344/2.816/3.758/0.666 ms
du
lab@Tokyo>
Question: Is the ping successful?

ro
Answer: The ping should be successful.
ep
Continue testing IP connectivity by pinging the IP address of the XX-VR and XX-VR2 LAN
interfaces directly attached to your router.
rR

PING 10.222.100.2 (10.222.100.2): 56 data bytes
Fo

^C
--- 10.222.100.2 ping statistics ---
ot

PING 10.222.200.2 (10.222.200.2): 56 data bytes
N

64 bytes from 10.222.200.2: icmp_seq=4 ttl=64 ti^C
--- 10.222.200.2 ping statistics ---
lab@Tokyo>

Answer: The ping should be successful.
Now continue testing IP connectivity by pinging the IP address of the lo0 interface of your peer
router across the Internet.
PING 192.168.36.1 (192.168.36.1): 56 data bytes
ping: sendto: No route to host
n
io
^C
--- 192.168.36.1 ping statistics ---
ct
lab@Tokyo>
du
Question: Is the ping successful? Why?
ro
ep
Answer: The ping is not successful because there is no
route to the destination IP address. To learn the route, a
dynamic routing protocol or static route is required.
rR
Part 4: Establish Layer 3 Connectivity Using OSPF Routing Protocol
In this part of the lab, you will establish Layer 3 connectivity between all the routers within your
Fo
city region (which includes your router, XX-VR, and XX-VR2) and between those routers and
the routers of your peer. You are to use OSPF as the routing protocol. Refer to the network
diagram of Lab 1 for your group letter (A, B, C, or D) to determine the OSPF areas assignments.
Step 4.1
ot
From your router, use Telnet to access the XX-VR router of your city region. Recall that XX are
the first two letters of your city name. For example, TO-VR is the router name attached to
Tokyo. The login name is your router name, router-VR, where router is in lower case
N
letters, and the password is lab123.

lab@Tokyo> telnet 10.222.100.2
Trying 10.222.100.2...
Connected to 10.222.100.2.
Escape character is '^]'.
Sydney (ttyp0)
login: tokyo-VR
Password:

--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
NOTE: This router is divided into many virtual routers used by different
teams. Please only configure your own virtual router.
You must use 'configure private' to configure this router.
tokyo-VR@Sydney>
Step 4.2
n
Configure the OSPF routing protocol for routing-instance XX-VR. Use the Lab 1 diagram to
identify which OSPF area to configure. OSPF interfaces include lo0. xyz and
io
ge-0/0/3.xyz, where xyz is the corresponding VLAN ID, as defined on the lab diagram.
tokyo-VR@Sydney> configure private
ct
warning: uncommitted changes will be discarded on exit
du
[edit]
tokyo-VR@Sydney# edit routing-instances TO-VR
[edit routing-instances TO-VR]

tokyo-VR@Sydney# edit protocols
ro
[edit routing-instances TO-VR protocols]
ep
tokyo-VR@Sydney# set ospf area 1 interface ge-0/0/3.100

rR
tokyo-VR@Sydney# set ospf area 1 interface lo0.100

tokyo-VR@Sydney# up
Fo

tokyo-VR@Sydney# show
instance-type virtual-router;
interface lo0.100;
ot
protocols {
ospf {
area 0.0.0.1 {
N
interface lo0.100;
}
}
}
Step 4.3
Commit configuration file.


tokyo-VR@Sydney# top
[edit]
tokyo-VR@Sydney# commit
commit complete
[edit]
tokyo-VR@Sydney#
Step 4.4
n
Close the Telnet session with the XX-VR router. Now use Telnet to access the XX-VR2 router
of your city region. (Recall that XX are the first two letters of your city name. For example,
io
TO-VR2 is the router name attached to Tokyo. The login name is your router name,
router-VR2, where router is in lower case letters, and the password is lab123.)
ct
[edit]
tokyo-VR@Sydney# exit
du
tokyo-VR@Sydney> exit
Connection closed by foreign host.

ro
Trying 10.222.200.2...
ep
Sydney (ttyp0)
rR
login: tokyo-VR2
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC

Fo

ot
tokyo-VR2@Sydney>
Step 4.5
N
Configure the OSPF routing protocol for the routing-instance XX-VR2. Use the Lab 1 diagram
to identify which OSPF area to configure. OSPF interfaces include lo0. xyz and
ge-0/0/3.xyz, where xyz is the corresponding VLAN ID, as defined on the lab diagram.
tokyo-VR2@Sydney> configure private
[edit]
tokyo-VR2@Sydney# edit routing-instances TO-VR2

[edit routing-instances TO-VR2]

tokyo-VR2@Sydney# set protocols ospf area 11 interface ge-0/0/3.200

tokyo-VR2@Sydney# set protocols ospf area 11 interface lo0.200

tokyo-VR2@Sydney# show
instance-type virtual-router;
interface lo0.200;
n
protocols {
ospf {
io
area 0.0.0.11 {
ct
interface lo0.200;
}
}
du
}
Step 4.6
Commit the configuration file. Next, exit the Telnet session.
ro
tokyo-VR2@Sydney# top
ep
[edit]
tokyo-VR2@Sydney# commit and-quit
commit complete
rR
tokyo-VR2@Sydney> exit

Fo
lab@Tokyo>
ot
[edit]
tokyo-VR2@Sydney# commit
commit complete
N
[edit]
tokyo-VR2@Sydney# exit
lab@Tokyo>

Step 4.7
Configure the OSPF protocol on your router. Use the Lab 1 network diagram to identify which
interfaces belong to which OSPF areas. Your router is the OSPF area border router (ABR).
lab@Tokyo> edit
[edit]
lab@Tokyo# edit protocols
[edit protocols]
n
lab@Tokyo# set ospf area 0 interface se-1/0/1.602
io
[edit protocols]
lab@Tokyo# set ospf area 0 interface lo0
ct
[edit protocols]
lab@Tokyo# set ospf area 1 interface ge-0/0/3.100
du
[edit protocols]
lab@Tokyo# set ospf area 11 interface ge-0/0/3.200
[edit protocols] ro
lab@Tokyo# show
ospf {
area 0.0.0.0 {
ep
interface se-1/0/1.602;
interface lo0.0;
}
area 0.0.0.1 {
rR
}
area 0.0.0.11 {
}
Fo
[edit protocols]
lab@Tokyo#
ot
Step 4.8
Commit the configuration changes in your router.
N
[edit protocols]
commit complete
lab@Tokyo>
Step 4.9
Check OSPF neighbor status from your router. If the status of OSPF neighbors is not showing as
FULL, fix the problem.

lab@Tokyo> show ospf neighbor

Address Interface State ID Pri Dead
172.18.36.2 se-1/0/1.602 Full 192.168.36.1 128 38
10.222.100.2 ge-0/0/3.100 Full 192.168.25.1 128 38
10.222.200.2 ge-0/0/3.200 Full 192.168.125.1 128 30
Question: How many OSPF neighbors do you see?
Answer: You should see three OSPF neighbors.
n
Step 4.10
io
Check the routing table on your router.
lab@Tokyo> show route table inet.0
ct
inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
du
10.210.11.176/28 *[Direct/0] 6d 00:53:33
> via ge-0/0/0.0
10.210.11.178/32 *[Local/0] 6d 00:53:35 ro
Local via ge-0/0/0.0
10.222.100.0/24 *[Direct/0] 1d 00:58:12
> via ge-0/0/3.100
ep
10.222.100.1/32 *[Local/0] 1d 00:58:12
10.222.101.0/24 *[OSPF/10] 00:03:05, metric 13
> via se-1/0/1.602
rR
10.222.200.0/24 *[Direct/0] 1d 00:58:12

> via ge-0/0/3.200
10.222.200.1/32 *[Local/0] 1d 00:58:12
10.222.201.0/24 *[OSPF/10] 00:02:50, metric 13
Fo
> via se-1/0/1.602

172.18.36.0/30 *[Direct/0] 1d 00:55:24
> via se-1/0/1.602
[OSPF/10] 00:07:50, metric 12
> via se-1/0/1.602
ot
172.18.36.1/32 *[Local/0] 1d 00:58:12

Local via se-1/0/1.602
192.168.24.1/32 *[Direct/0] 1d 00:58:12
N
> via lo0.0

192.168.25.1/32 *[OSPF/10] 00:07:40, metric 1
> to 10.222.100.2 via ge-0/0/3.100
192.168.36.1/32 *[OSPF/10] 00:03:05, metric 12
> via se-1/0/1.602
192.168.37.1/32 *[OSPF/10] 00:02:50, metric 13
> via se-1/0/1.602
192.168.125.1/32 *[OSPF/10] 00:07:40, metric 1
> to 10.222.200.2 via ge-0/0/3.200
192.168.137.1/32 *[OSPF/10] 00:02:50, metric 13
> via se-1/0/1.602

224.0.0.5/32 *[OSPF/10] 00:07:55, metric 1

MultiRecv
Step 4.11
Test IP connectivity. Issue a ping from the lo0 interface of your router to the lo0 interface of
your peer router across the Internet.
Answer: Yes, the ping should be successful.
n
Step 4.12
io
Issue a ping from your LAN interface’s IP address to one of the LAN sites of your peer router.
ct
lab@Tokyo> ping 192.168.36.1 source 192.168.24.1
PING 192.168.36.1 (192.168.36.1): 56 data bytes
du
^C ro
--- 192.168.36.1 ping statistics ---
ep
lab@Tokyo> ping source 10.222.200.1 192.168.125.1
PING 192.168.125.1 (192.168.125.1): 56 data bytes
rR

64 bytes from 192.168.125.1: icm^C
--- 192.168.125.1 ping statistics ---
Fo
lab@Tokyo>
Part 5: Establish Hosts Within Each Site and Summarize the Advertisement of
ot
Their Prefixes Across the Internet

N
In this part of the lab you will configure local hosts within the XX-VR and XX-VR2 sites. You
will emulate the existence of these hosts by assigning additional addresses to the lo0.tyx
interface, where tyx is the lo0 logical interface belonging to either the XX-VR or XX-VR2
router. Next, you will ensure that only a /24 prefix for the hosts is advertised across the
Internet. Refer to the static routes and hosts table on the Lab 1 diagram for your group letter
(A, B, C, or D).

Step 5.1
From your router, use Telnet to access the XX-VR router of your city region. (Recall that XX are
letters, and the password is lab123.)
Trying 10.222.100.2...
n
Sydney (ttyp0)
io
login: tokyo-VR
Password:
ct
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
du
tokyo-VR@Sydney>
ro
Step 5.2
ep
Define local hosts belonging to the predefined LAN the assigning host IP addresses to the lo0
interface of your router, as identified in the table on the Lab 1 diagram for your group letter (A,
B, C, or D).
rR

[edit]
Fo
tokyo-VR@Sydney# edit interfaces lo0 unit 100
[edit interfaces lo0 unit 100]

tokyo-VR@Sydney# set family inet address 10.10.100.1
ot

N


tokyo-VR@Sydney# show
description "TO-VR loopback";
family inet {
address 192.168.25.1/32;
address 10.10.100.1/32;
address 10.10.100.2/32;
address 10.10.100.3/32;


tokyo-VR@Sydney#
Step 5.3
Commit the changes.
tokyo-VR@Sydney# top
[edit]
n
tokyo-VR@Sydney# commit
commit complete
io
ct
[edit]
tokyo-VR@Sydney#
Step 5.4
du
Close the Telnet session with XX-VR router. Now use Telnet to access the XX-VR2 router of
your city region. (Recall that XX are the first two letters of your city name. For example,
TO-VR2 is the router name attached to Tokyo. The login name is your router name,
ro
router-VR2, where router is in lower case letters, and the password is lab123.)
[edit]
ep
tokyo-VR@Sydney# exit
rR

Trying 10.222.200.2...
Fo
Sydney (ttyp0)
ot
login: tokyo-VR2
Password:
N
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
tokyo-VR2@Sydney>

Step 5.5
Define local hosts belonging to the predefined LAN by assigning host IP addresses to the lo0
interface of your router, as identified in the table on the Lab 1 diagram for your group letter (A,
B, C, or D).
[edit]
tokyo-VR@Sydney# edit interfaces lo0 unit 200
n
io
tokyo-VR2@Sydney# set family inet address 10.10.200.1
ct
du

tokyo-VR2@Sydney# show ro
description "TO-VR2 loopback";
family inet {
address 192.168.125.1/32;
ep
address 10.10.200.1/32;
address 10.10.200.2/32;
address 10.10.200.3/32;
}
rR

tokyo-VR2@Sydney#
Step 5.6
Fo
Commit the changes and log out from the XX-VR2 router.
ot
[edit]
tokyo-VR2@Sydney# commit
commit complete
N
[edit]
tokyo-VR2@Sydney# exit
lab@Tokyo>

Step 5.7
Check the routing tables in your router. Specifically, ensure that your router is receiving all the
host routes that you just defined.
lab@Tokyo> show route 10.10/16

10.10.100.1/32 *[OSPF/10] 17:22:31, metric 1

> to 10.222.100.2 via ge-0/0/3.100
n
10.10.100.2/32 *[OSPF/10] 17:22:31, metric 1
> to 10.222.100.2 via ge-0/0/3.100
io
10.10.100.3/32 *[OSPF/10] 17:22:31, metric 1
> to 10.222.100.2 via ge-0/0/3.100
10.10.101.1/32 *[OSPF/10] 17:22:37, metric 13
ct
> via se-1/0/1.602
10.10.101.2/32 *[OSPF/10] 17:22:37, metric 13
> via se-1/0/1.602
du
10.10.101.3/32 *[OSPF/10] 17:22:37, metric 13
> via se-1/0/1.602
10.10.200.1/32 *[OSPF/10] 17:22:26, metric 1
> to 10.222.200.2 via ge-0/0/3.200
ro
10.10.200.2/32 *[OSPF/10] 17:22:26, metric 1
> to 10.222.200.2 via ge-0/0/3.200
10.10.200.3/32 *[OSPF/10] 17:22:26, metric 1
ep
> to 10.222.200.2 via ge-0/0/3.200
10.10.201.1/32 *[OSPF/10] 17:22:37, metric 13
> via se-1/0/1.602
10.10.201.2/32 *[OSPF/10] 17:22:37, metric 13
rR
> via se-1/0/1.602

10.10.201.3/32 *[OSPF/10] 17:22:37, metric 13
> via se-1/0/1.602
lab@Tokyo>
Fo
Question: How many route belonging to the prefix

10.10/16 exist?
ot
N
Answer: There are 12 routes that belong to the prefix

10.10/16: three host routes for each of the four routers
in the group.
Step 5.8
Summarize host routes, ensuring that only /24 prefixes are advertised across the Internet for
each of the sites.

Question: What router(s) must perform the summary

function required in this step?
Answer: The route summarization must be defined at

the ABR routers.
lab@Tokyo> edit
n
[edit]
io
lab@Tokyo# edit protocols ospf
[edit protocols ospf]
ct
lab@Tokyo# set area 1 area-range 10.10.100/24
du
lab@Tokyo# set area 11 area-range 10.10.200/24

lab@Tokyo# show ro
area 0.0.0.0 {
interface lo0.0;
ep
}
area 0.0.0.1 {
area-range 10.10.100.0/24;
rR
}
area 0.0.0.11 {
area-range 10.10.200.0/24;
Fo

lab@Tokyo#
Step 5.9
ot
Commit the changes.

N
lab@Tokyo# commit
commit complete

lab@Tokyo# exit
[edit]
lab@Tokyo# exit
lab@Tokyo>

Step 5.10
Check the routing table of your router.
lab@Tokyo> show route 10.10/16

10.10.100.0/24 *[OSPF/10] 00:00:25, metric 16777215

Discard
10.10.100.1/32 *[OSPF/10] 17:26:25, metric 1
n
> to 10.222.100.2 via ge-0/0/3.100
10.10.100.2/32 *[OSPF/10] 17:26:25, metric 1
io
> to 10.222.100.2 via ge-0/0/3.100
10.10.100.3/32 *[OSPF/10] 17:26:25, metric 1
> to 10.222.100.2 via ge-0/0/3.100
ct
10.10.101.0/24 *[OSPF/10] 00:01:07, metric 13
> via se-1/0/1.602
10.10.200.0/24 *[OSPF/10] 00:00:25, metric 16777215
du
Discard
10.10.200.1/32 *[OSPF/10] 17:26:20, metric 1
> to 10.222.200.2 via ge-0/0/3.200
10.10.200.2/32 *[OSPF/10] 17:26:20, metric 1
ro
> to 10.222.200.2 via ge-0/0/3.200
10.10.200.3/32 *[OSPF/10] 17:26:20, metric 1
> to 10.222.200.2 via ge-0/0/3.200
ep
10.10.201.0/24 *[OSPF/10] 00:01:07, metric 13
> via se-1/0/1.602
lab@Tokyo>
rR
Question: How many routes of 10.10/16 prefix are you

seeing from your peer router?
Fo
Answer: In total there are ten 10.10/16 prefixes—six for

ot
local sites, two summaries of /24 from the peer router,

and two summary routes generated internally.
N
Step 5.11
Check connectivity by logging in to the XX-VR or XX-VR2 router and initiating a ping from one
of the local host IP addresses, which was configured during this lab, to another local host IP
address of the peer site across the Internet. If there is a problem, troubleshoot the problem
with the help of traceroute and various show commands.
Trying 10.222.100.2...

Sydney (ttyp0)
login: tokyo-VR
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
n
tokyo-VR@Sydney> ping routing-instance TO-VR source 10.10.100.1 10.10.201.3
io
PING 10.10.201.3 (10.10.201.3): 56 data bytes
ct
du
^C
ro
tokyo-VR@Sydney> traceroute routing-instance TO-VR source 10.10.100.1
10.10.201.3
ep
traceroute to 10.10.201.3 (10.10.201.3) from 10.10.100.1, 30 hops max, 40 byte
packets
1 10.222.100.1 (10.222.100.1) 1.643 ms 1.306 ms 1.863 ms
2 172.18.36.2 (172.18.36.2) 4.709 ms 3.592 ms 3.971 ms
rR
3 10.10.201.3 (10.10.201.3) 4.704 ms 4.614 ms 4.721 ms
tokyo-VR@Sydney>
Fo
STOP Tell your instructor that you have completed Lab 1.

ot
N

Lab 2
Security Policies (Detailed)
Overview
n
io
In this lab you will establish security zones and security policies as identified in the network
diagram for Lab 2. Within the security policies you will enable specific services and necessary
ct
protocols to maintain IP connectivity established in Lab 1. You will test and monitor the
functionality of your configuration using the JUNOS command-line interface (CLI).
The lab is available in two formats: a high-level format that is designed to make you think
du
through each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
ro
• Configure security zones for your network.
• Implement security policies to enable communications between the security
ep
zones.
• Monitor security zone operation.
Similar to the previous lab, this lab requires the use of the Sydney router, which is logically
rR
segmented into several virtual routers. Each student router connects to two virtual routers in
the form of XX-VR and XX-VR2, where XX is a two-letter abbreviation for the directly
connected student router. Sydney also acts as the service provider, which provides Frame
Relay services between sites.
Fo
ot
N
Security Policies (Detailed) • Lab 2–1

9.a.9.0R1
Key Commands

configure
ping
show interfaces terse
show route table
show security flow
show security policies
show security zones
n
traceroute
io
Part 1: Interface Assignment to Security Zones
ct
In this part each team will assign the router’s interfaces to the appropriate security zones, as
identified in the Lab 2 network diagram for your group letter (A, B, C, or D).
du
Step 1.1
Log in to the router with the username lab and the password lab123. Note that the
username and the password are case sensitive.
ro
Tokyo (ttyd0)
login: lab
Password:
ep
--- JUNOS 9.0R1.10 built 2008-02-14 03:14:18 UTC

lab@Tokyo>
rR
Step 1.2
Delete the security zone called trust and the security policies. Note that the trust zone
was preconfigured in the initial setup. Now that you have established Layer 3 connectivity, you
Fo
must eliminate the trust zone and establish other security zones, as defined in this lab.
lab@Tokyo> edit
[edit]
ot
lab@Tokyo# show security

zones {
security-zone trust {
N
interfaces {
all {
system-services {
all;
}
protocols {
all;
}
}
Lab 2–2 • Security Policies (Detailed)

}
}
}
}
policies {
from-zone trust to-zone trust {
policy trust {
match {
source-address any;
destination-address any;
application any;
}
n
then {
permit;
io
}
}
ct
}
}
du
[edit]
lab@Tokyo# delete security
[edit] ro
lab@Tokyo# show security
[edit]
ep
lab@Tokyo#
Step 1.3
Configure the functional management zone and assign the interface ge-0/0/0.0 to it.
rR
Ensure that all system services and protocols are allowed for the ge-0/0/0.0 interface.
[edit]
lab@Tokyo# edit security zones functional-zone management
Fo
[edit security zones functional-zone management]

lab@Tokyo# set interfaces ge-0/0/0.0 host-inbound-traffic system-services all

lab@Tokyo# set interfaces ge-0/0/0.0 host-inbound-traffic protocols all
ot

lab@Tokyo# show
N
interfaces {
ge-0/0/0.0 {
system-services {
all;
}
protocols {
all;
}
}
}


lab@Tokyo# top
Step 1.4
Assign interfaces to the security zones, as identified in the Lab 2 network diagram for your
group letter (A, B, C, or D). In total, there are the following five security zones:
• Public zone: Across the Internet between the two peer routers;
• Retail and Admin zones: Local to the left peer router; and
n
• HR and Finance zones: Local to the right peer router.
io
Note
ct
Zones names are case sensitive.
Use the following table to ensure correct assignment of interfaces and zones on your router.
du
Zone Assignment
ro
Group Router name Interface Security Zone
A Tokyo lo0 Public

ep
se-1/0/1.602 Public
ge-0/0/3.100 Retail
rR
ge-0/0/3.200 Admin
London lo0 Public

se-1/0/0.603 Public
Fo
ge-0/0/3.101 HR
ge-0/0/3.201 Finance
B San Jose lo0 Public

se-1/0/1.606 Public
ot
ge-0/0/3.105 Retail
ge-0/0/3.205 Admin
N
Hong Kong lo0 Public

se-1/0/0.601 Public
ge-0/0/3.102 HR

Zone Assignment
Group Router name Interface Security Zone
C Denver lo0 Public

se-1/0/1.607 Public
ge-0/0/3.106 Retail
ge-0/0/3.206 Admin
Sao Paulo lo0 Public
n
se-1/0/0.608 Public
ge-0/0/3.103 HR
io
ct
Montreal lo0 Public
se-1/0/1.605 Public
du
ge-0/0/3.107 Retail
ge-0/0/3.207 Admin
Admsterdam ro lo0 Public
se-1/0/0.604 Public
ge-0/0/3.104 HR
ep
[edit]
rR
lab@Tokyo# edit security zones
[edit security zones]

lab@Tokyo# set security-zone Public interfaces lo0
Fo

lab@Tokyo# set security-zone Public interfaces se-1/0/1.602

lab@Tokyo# set security-zone Retail interfaces ge-0/0/3.100
ot

lab@Tokyo# set security-zone Admin interfaces ge-0/0/3.200
N

lab@Tokyo# show
functional-zone management {
interfaces {
ge-0/0/0.0 {
system-services {
all;
}
protocols {

all;
}
}
}
}
}
security-zone Public {
interfaces {
lo0.0;
se-1/0/1.602;
}
}
n
security-zone Retail {
interfaces {
io
ge-0/0/3.100;
}
ct
}
security-zone Admin {
interfaces {
du
ge-0/0/3.200;
}
}

lab@Tokyo#
ro
Step 1.5
ep
Commit the changes.
rR
lab@Tokyo# commit
commit complete

lab@Tokyo# exit
Fo
[edit]
lab@Tokyo# exit
lab@Tokyo>
ot
Step 1.6
Check IP connectivity on your router. You can test the connectivity by pinging the lo0 interface
N
of your peer router.

PING 192.168.36.1 (192.168.36.1): 56 data bytes
^C
--- 192.168.36.1 ping statistics ---
lab@Tokyo>

Question: Is the ping successful? Why or why not?
Answer: The ping is not successful because there is no

route to the destination address.
Step 1.7
Check the OSPF neighbors from your router’s perspective.
n
lab@Tokyo> show ospf neighbor
io
lab@Tokyo> show ospf interface
Interface State Area DR ID BDR ID Nbrs
lo0.0 DR 0.0.0.0 192.168.24.1 0.0.0.0 0
ct
se-1/0/1.602 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/3.100 DR 0.0.0.1 192.168.24.1 0.0.0.0 0
du
ge-0/0/3.200 DR 0.0.0.11 192.168.24.1 0.0.0.0 0
lab@Tokyo>
ro
Question: Does your router see the OSPF neighbors?
Why?
ep
Answer: The router does not see any OSPF neighbors

rR
because the newly configured security zones are not

permitting any traffic into the router, including OSPF
traffic.
Step 1.8
Fo
Permit the OSPF routing protocol into all security zones of your router.
lab@Tokyo> edit
ot
[edit]
N

lab@Tokyo# set security-zone Public host-inbound-traffic protocols ospf

lab@Tokyo# set security-zone Retail host-inbound-traffic protocols ospf

lab@Tokyo# set security-zone Admin host-inbound-traffic protocols ospf

lab@Tokyo# show
functional-zone management {
interfaces {
ge-0/0/0.0 {
system-services {
all;
}
protocols {
all;
}
}
n
}
}
io
}
security-zone Public {
ct
protocols {
ospf;
du
}
}
interfaces {
lo0.0; ro
se-1/0/1.602;
}
}
ep
security-zone Retail {
protocols {
ospf;
rR
}
}
interfaces {
ge-0/0/3.100;
}
Fo
}
security-zone Admin {
protocols {
ospf;
ot
}
}
interfaces {
N
ge-0/0/3.200;
}
}

lab@Tokyo#
Step 1.9
Commit the configuration. Then check the status of OSPF on your router.


lab@Tokyo# commit
commit complete

lab@Tokyo# run show ospf interface
lo0.0 DR 0.0.0.0 192.168.24.1 0.0.0.0 0
se-1/0/1.602 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/3.100 DR 0.0.0.1 192.168.24.1 10.10.100.1 1
ge-0/0/3.200 DR 0.0.0.11 192.168.24.1 10.10.200.1 1
n
lab@Tokyo# run show ospf neighbor
io
172.18.36.2 se-1/0/1.602 Full 192.168.36.1 128 34
ct
10.222.100.2 ge-0/0/3.100 Full 10.10.100.1 128 37
10.222.200.2 ge-0/0/3.200 Full 10.10.200.1 128 36
du
lab@Tokyo#
Question: Does OSPF on your router see the neighbors?

ro
Why or why not?
ep
Answer: Now the router sees the OSPF neighbors

because their packets are allowed into the router.
rR
Step 1.10
Check the status of the 10.10/16 networks in the routing table of your router.
Fo

lab@Tokyo# run show route 10.10/16

ot
10.10.100.0/24 *[OSPF/10] 00:17:37, metric 16777215

Discard
N
10.10.100.1/32 *[OSPF/10] 00:17:37, metric 1

> to 10.222.100.2 via ge-0/0/3.100
10.10.100.2/32 *[OSPF/10] 00:17:37, metric 1
> to 10.222.100.2 via ge-0/0/3.100
10.10.100.3/32 *[OSPF/10] 00:17:37, metric 1
> to 10.222.100.2 via ge-0/0/3.100
10.10.101.0/24 *[OSPF/10] 00:17:38, metric 13
> via se-1/0/1.602
10.10.200.0/24 *[OSPF/10] 00:17:32, metric 16777215
Discard
10.10.200.1/32 *[OSPF/10] 00:17:32, metric 1

> to 10.222.200.2 via ge-0/0/3.200

10.10.200.2/32 *[OSPF/10] 00:17:32, metric 1
> to 10.222.200.2 via ge-0/0/3.200
10.10.200.3/32 *[OSPF/10] 00:17:32, metric 1
> to 10.222.200.2 via ge-0/0/3.200
10.10.201.0/24 *[OSPF/10] 00:17:31, metric 13
> via se-1/0/1.602

lab@Tokyo#
Question: How many routes with the 10.10/16 prefix
n
are in the routing table? Is this correct?
io
ct
du
Answer: There are ten prefixes belonging to the
10.10/10 address space, which is the correct number
of routes.
Part 2: Building Address Books for Each Security Zone

ro
ep
In this part of the lab you will build the address books for the security zones on the LAN side of
your router. The address books must include the IP addresses of the hosts in each security
zone, as defined in the Lab 2 network diagram for your group letter (A, B, C, or D).
rR
Step 2.1
Using the table of hosts defined on the network diagram for Lab 2, configure the address book
for Retail, Admin, HR, and Finance security zones. Use the following naming convention
for the address sets: XX-VRhosts and XX-VR2hosts, where XX is the two-letter
Fo
abbreviation for your city name. For example, the address set names for Tokyo are
TO-VRhosts and TO-VR2hosts.
Note
ot
Address and address set names are case sensitive.

N
The following example illustrates the configuration for the Tokyo router, which includes the
address book configurations for the Retail and Admin security zones.
lab@Tokyo# edit security-zone Retail
[edit security zones security-zone Retail]

lab@Tokyo# set address-book address TO-VRhost1 10.10.100.1




lab@Tokyo#set set address-book address-set TO-VRhosts address TO-VRhost1

lab@Tokyo# set address-book address-set TO-VRhosts address TO-VRhost2

n
lab@Tokyo# show address-book
io
address TO-VRhost1 10.10.100.1/32;
ct
address-set TO-VRhosts {
address TO-VRhost1;
du
address TO-VRhost2;
address TO-VRhost3;
}
ro
lab@Tokyo# lab@Tokyo# up
ep
lab@Tokyo# edit security-zone Admin
[edit security zones security-zone Admin]

rR
lab@Tokyo# set address-book address TO-VR2host1 10.10.200.1

Fo


lab@Tokyo#set address-book address-set TO-VR2hosts address TO-VR2host1
ot

lab@Tokyo# set address-book address-set TO-VR2hosts address TO-VR2host2
N


address TO-VR2host1 10.10.200.1/32;
address-set TO-VR2hosts {
address TO-VR2host1;

}

lab@Tokyo#
Step 2.2
Configure the address book for the Public zone. Ensure that it contains four address sets,
including the Retail, Admin, HR, and Finance zones.
n
lab@Tokyo# up
io
lab@Tokyo# edit security-zone Public
ct
[edit security zones security-zone Public]
lab@Tokyo#set address-book address TO-VRhost1 10.10.100.1
du

ro
ep

rR

Fo


ot

N




lab@Tokyo# set address-book address LO-VRhost1 10.10.101.1



lab@Tokyo# set address-book address-set LO-VRhosts address LO-VRhost1
n
io
ct
lab@Tokyo# set address-book address LO-VR2host1 10.10.201.1
du
ro
ep
lab@Tokyo# set address-book address-set LO-VR2hosts address LO-VR2host1

rR

Fo

ot

N
address LO-VRhost1 10.10.101.1/32;

address LO-VR2host1 10.10.201.1/32;
address TO-VRhost1;
address TO-VRhost2;
address TO-VRhost3;
}

}
address-set LO-VRhosts {
address LO-VRhost1;
address LO-VRhost2;
address LO-VRhost3;
}
address-set LO-VR2hosts {
address LO-VR2host1;
n
io
}
ct
lab@Tokyo#
Step 2.3
du
Commit the changes.
commit complete
ro
ep
lab@Tokyo>
Part 3: Establishing and Configuring Security Policies

rR
In this part of the lab you will establish and configure security policies that enable the
necessary traffic flow between the security zones.
Fo
Step 3.1
Issue a ping from your router to one of the hosts connected to your router via the LAN.
PING 10.10.100.1 (10.10.100.1): 56 data bytes
ot

N
^C
lab@Tokyo>

Answer: Yes, the ping is successful. The source and the

destination addresses of the ping belong to the
interfaces of the same security zone. Although JUNOS
software with enhanced services requires intrazone
security policies for any intrazone traffic, the ping’s
echo request packets resulted in session creation,
allowing echo-reply packets to come back to the router.
n
Step 3.2
io
Now, issue another ping across the Internet. For example, if you are in Group A, issue a ping
from the Tokyo router to one of the host addresses behind the London router—for instance,
10.10.101.1.
ct
PING 10.10.101.1 (10.10.101.1): 56 data bytes
du
^C
ro
lab@Tokyo>
ep
rR
Answer: The ping is not successful. The source address

of the ping belongs to the interface of the Public
zone. The destination address of the ping belongs to
another security zone. Because the echo-request
packet of the ping must traverse the peer router, the
Fo
security policy is required to enable this type of traffic.
Step 3.3
Configure an application set called my-apps. You will specify the applications that will be
ot
permitted by the security policies, which you will define later in this lab. The applications
include junos-http, junos-telnet, junos-ftp, and junos-ping.
lab@Tokyo> edit
N
[edit]
lab@Tokyo# edit applications
[edit applications]
lab@Tokyo# set application-set my-apps application junos-http
[edit applications]
lab@Tokyo# set application-set my-apps application junos-telnet

[edit applications]
lab@Tokyo# set application-set my-apps application junos-ftp
[edit applications]
lab@Tokyo# set application-set my-apps application junos-ping
[edit applications]
lab@Tokyo# show
application-set my-apps {
application junos-http;
application junos-telnet;
application junos-ftp;
n
application junos-ping;
}
io
[edit applications]
ct
lab@Tokyo#
Step 3.4
du
Configure security policies that permit the my-apps applications between the Retail and
Admin security zones of your router. Ensure the ability of traffic to originate in both security
zones. Name the policies RetailToAdmin and AdminToRetail.
[edit applications]
lab@Tokyo# top
ro
ep
[edit]
lab@Tokyo# edit security policies
[edit security policies]

rR
lab@Tokyo# edit from-zone Retail to-zone Admin
[edit security policies from-zone Retail to-zone Admin]

lab@Tokyo# set policy RetailToAdmin match source-address TO-VRhosts
Fo

lab@Tokyo# set policy RetailToAdmin match destination-address TO-VR2hosts

lab@Tokyo# set policy RetailToAdmin match application my-apps
ot

lab@Tokyo# set policy RetailToAdmin then permit
N

lab@Tokyo# show
policy RetailToAdmin {
match {
source-address TO-VRhosts;
destination-address TO-VR2hosts;
application my-apps;
}
then {
permit;

}
}

lab@Tokyo# up

lab@Tokyo# edit from-zone Admin to-zone Retail
[edit security policies from-zone Admin to-zone Retail]

lab@Tokyo# set policy AdminToRetail match source-address TO-VR2hosts
n
lab@Tokyo# set policy AdminToRetail match destination-address TO-VRhosts
io
ct
lab@Tokyo# set policy AdminToRetail match application my-apps
du
lab@Tokyo# set policy AdminToRetail then permit

lab@Tokyo# show ro
policy AdminToRetail {
match {
source-address TO-VR2hosts;
ep
destination-address TO-VRhosts;
}
then {
rR
permit;
}
}

Fo
lab@Tokyo#
Question: On which router must you perform the

configuration?
ot
Answer: You must perform the configuration on the

N
router that is directly attached to the Retail and

Admin security zones (Tokyo, San Jose, Denver, or
Montreal).
Step 3.5
Configure security policies that permit the my-apps applications between the Retail and
Finance security zones of your router. Because the Retail and Finance zones are
separated by the Internet, you must reference the Public zone as either the source or the
destination zone when configuring the security policies. Name the policies
RetailToFinance and FinanceToRetail.


lab@Tokyo# up

lab@Tokyo# edit from-zone Retail to-zone Public
[edit security policies from-zone Retail to-zone Public]

lab@Tokyo# set policy RetailToFinance match source-address TO-VRhosts
n
lab@Tokyo# set policy RetailtoFinance match destination-address LO-VR2hosts
io
lab@Tokyo# set policy RetailToFinance match application my-apps
ct
lab@Tokyo# set policy RetailToFinance then permit
du
lab@Tokyo# show
policy RetailToFinance {
match {
destination-address LO-VR2hosts;
ro
ep
}
then {
permit;
}
rR

lab@Tokyo# up
Fo

lab@Tokyo# edit from-zone Public to-zone Retail
[edit security policies from-zone Public to-zone Retail]

ot
lab@Tokyo# set policy FinanceToRetail match source-address LO-VR2hosts

N
lab@Tokyo# set policy FinancetoRetail match destination-address TO-VRhosts

lab@Tokyo# set policy FinanceToRetail match application my-apps

lab@Tokyo# set policy FinanceToRetail then permit

lab@Tokyo# show
policy FinanceToRetail {

match {
source-address LO-VR2hosts;
}
then {
permit;
}
}

lab@Tokyo#
n
Here it the sample configuration for the London router:
io
[edit]
lab@London# edit security policies
ct
lab@London# edit from-zone Finance to-zone Public
du
[edit security policies from-zone Finance to-zone Public]
lab@London# set policy FinanceToRetail match source-address LO-VR2hosts
ro
lab@London# set policy FinanceToRetail match destination-address TO-VRhosts
ep
lab@London# set policy FinanceToRetail match application my-apps

rR
lab@London# set policy FinanceToRetail then permit

lab@London# show
Fo
match {
}
ot
then {
permit;
}
N

lab@London# up

lab@London# edit from-zone Public to-zone Finance
[edit security policies from-zone Public to-zone Finance]

lab@London# set policy RetailToFinance match source-address TO-VRhosts


lab@London# set policy RetailToFinance match destination-address LO-VR2hosts

lab@London# set policy RetailToFinance match application my-apps

lab@London# set policy RetailToFinance then permit

lab@London# show
n
match {
io
ct
}
then {
permit;
du
}
}

ro
lab@London#
Step 3.6
ep
Configure security policies that permit the my-apps applications between the Admin and HR
security zones of your router. Because the Admin and HR zones are separated by the Internet,
you must reference the Public zone as either the source or destination zone when
configuring the security policies. Name the policies AdminToHR and HRtoAdmin.
rR
Here is the sample configuration for the Tokyo router.

lab@Tokyo# up
Fo

lab@Tokyo# edit from-zone Admin to-zone Public
[edit security policies from-zone Admin to-zone Public]

lab@Tokyo# set policy AdminToHR match source-address TO-VR2hosts
ot

lab@Tokyo# set policy AdminToHR match destination-address LO-VRhosts
N

lab@Tokyo# set policy AdminToHR match application my-apps

lab@Tokyo# set policy AdminToHR then permit

lab@Tokyo# show
policy AdminToHR {

match {
destination-address LO-VRhosts;
}
then {
permit;
}
}

lab@Tokyo# lab@Tokyo# up
n
io
lab@Tokyo# edit from-zone Public to-zone Admin
ct
[edit security policies from-zone Public to-zone Admin]
lab@Tokyo# set policy HRtoAdmin match source-address LO-VRhosts
du
lab@Tokyo# set policy HRtoAdmin match destination-address TO-VR2hosts

ro
lab@Tokyo# set policy HRtoAdmin match application my-apps

ep
lab@Tokyo# set policy HRtoAdmin then permit

lab@Tokyo# show
rR
policy HRtoAdmin {
match {
source-address LO-VRhosts;
Fo
}
then {
permit;
}
}
ot

lab@Tokyo#
N
Here is the sample configuration for the London router.

lab@London# up

lab@London# edit from-zone Public to-zone HR
[edit security policies from-zone Public to-zone HR]

lab@London# set policy AdminToHR match source-address TO-VR2hosts


lab@London# set policy AdminToHR match destination-address LO-VRhosts

lab@London# set policy AdminToHR match application my-apps

lab@London# set policy AdminToHR then permit

lab@London# show
policy AdminToHR {
n
match {
io
ct
}
then {
permit;
du
}
}

ro
lab@London# up

ep
lab@London# edit from-zone HR to-zone Public
[edit security policies from-zone HR to-zone Public]

lab@London# set policy HRtoAdmin match source-address LO-VRhosts
rR

lab@London# set policy HRtoAdmin match destination-address TO-VR2hosts

Fo
lab@London# set policy HRtoAdmin match application my-apps

lab@London# set policy HRtoAdmin then permit
ot

lab@London# show
policy HRtoAdmin {
N
match {
}
then {
permit;
}
}


lab@London#
Step 3.7
Commit the changes.
commit complete
lab@Tokyo>
n
io
Part 4: Testing and Monitoring the Functionality of Security Zones
ct
In this part of the lab you will test and monitor the functionality of the security zones.
Step 4.1
du
Configure traceoptions within the security flow stanza, flagging basic-datapath
and session. Use the file name lab2debug.
lab@Tokyo> edit ro
[edit]
ep
lab@Tokyo# edit security flow
[edit security flow]

lab@Tokyo# set traceoptions flag session
rR

lab@Tokyo# set traceoptions flag basic-datapath
lab@Tokyo# set traceoptions file lab2debug
Fo

lab@Tokyo# show
traceoptions {
file lab2debug;
ot
flag basic-datapath;
flag session;
}
N

lab@Tokyo#
Step 4.2
Commit the changes.


commit complete
lab@Tokyo>
Step 4.3
Note
This step should be performed by only one of the
members of the group because the other member
n
of the group will be observing the results of flow
debugging.
io
From your router use Telnet to access the XX-VR router of your city region. (Recall that XX are
ct
du
Trying 10.222.100.2...
Escape character is '^]'. ro
Sydney (ttyp0)
ep
login: tokyo-VR
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC

rR
Fo
tokyo-VR@Sydney>
Step 4.4
ot
From the XX-VR router issue a ping from one of the hosts located in the Retail zone to
another host located in the Finance zone.
tokyo-VR@Sydney> ping source 10.10.100.1 10.10.201.3 routing-instance TO-VR
N
PING 10.10.201.3 (10.10.201.3): 56 data bytes

^C


tokyo-VR@Sydney>
Question: Is ping successful? Why or why not?
Answer: The ping should be successful because the

security policies are permitting pings from the Retail
n
to the Finance zones through the Public zone.
io
Step 4.5
Now issue a ping from one of the hosts located in the Admin zone to another host located in
ct
the Finance zone.
tokyo-VR@Sydney> ping source 10.10.200.3 10.10.201.1 routing-instance TO-VR2
du
PING 10.10.201.1 (10.10.201.1): 56 data bytes
^C
ro
tokyo-VR@Sydney>
ep
Question: Is ping successful? Why or why not?
rR
Answer: The ping should not be successful because no

security policy permits pings from the Admin to the
Finance zones. Recall that the default policy is to
discard all traffic.
Fo
Step 4.6
Using the management interface ge-0/0/0.0, use Telnet to access the router that is
performing the tests identified in Steps 4.4 and 4.5.
lab@London> telnet 10.210.11.178
ot
Trying 10.210.11.178...
N
Tokyo (ttyp0)
login: lab
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:14:18 UTC

lab@Tokyo>

Step 4.7
Examine the sessions in progress.
lab@Tokyo> show security flow session
Session ID: 7, Policy name: self-traffic-policy/1, Timeout: 58
In: 10.222.100.2/1 --> 224.0.0.5/1;ospf, If: ge-0/0/3.100
Out: 224.0.0.5/1 --> 10.222.100.2/1;ospf, If: .local..0

In: 10.222.200.2/1 --> 224.0.0.5/1;ospf, If: ge-0/0/3.200
Out: 224.0.0.5/1 --> 10.222.200.2/1;ospf, If: .local..0
n
io
In: 172.18.36.2/1 --> 224.0.0.5/1;ospf, If: se-1/0/1.602
Out: 224.0.0.5/1 --> 172.18.36.2/1;ospf, If: .local..0
ct
In: 10.222.100.1/58230 --> 10.222.100.2/23;tcp, If: .local..0
Out: 10.222.100.2/23 --> 10.222.100.1/58230;tcp, If: ge-0/0/3.100
du
In: 10.210.11.179/62114 --> 10.210.11.178/23;tcp, If: ge-0/0/0.0
Out: 10.210.11.178/23 --> 10.210.11.179/62114;tcp, If: .local..0
ro
5 sessions displayed
ep
lab@Tokyo>
Question: What command must you issue to view the

sessions in progress?
rR
Fo
Answer: Use the show security flow session

command to view the sessions in progress.
Question: How many sessions exist?

ot
Answer: There are five active sessions.

N

Question: What command must you issue to obtain the

information on the maximum number of sessions that
the router can handle?
Answer: Use the show security flow session

summary command. Here is the sample output taken
from the Tokyo router:
n
io
lab@Tokyo> show security flow session summary
Session summary:
Unicast-sessions: 5
ct
Multicast-sessions: 0
Failed-sessions: 0
Sessions-in-use: 5
du
Maximum-sessions: 262144
lab@Tokyo>
Step 4.8
ro
From the XX-VR router, open a Telnet session from one of the hosts in the Retail zone to a
host within a Finance zone through the Public zone.
ep
tokyo-VR@Sydney> telnet 10.10.201.2 source 10.10.100.3 routing-instance TO-VR
Trying 10.10.201.2...
rR
Sydney (ttyp1)
login: london-VR
Fo
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
ot

N
london-VR@Sydney>
On your router, turn on monitoring of the lab2debug file to observe the results of session
forming debugging.
lab@Tokyo> monitor start lab2debug
lab@Tokyo>
*** lab2debug ***
Feb 25 02:42:49 02:42:49.803547:CID-0:RT:<10.210.11.179/62114->10.210.11.178/
23;6> : <management/ge-0/0/0.0>

Feb 25 02:42:49 02:42:49.803564:CID-0:RT:packet [53] ipid = 54862, @4a0b20ee

******
Feb 25 02:42:49 02:42:49.803575:CID-0:RT: find flow: table 0x4b5f7104, hash

205865(0x3ffff), sa 10.210.11.179, da 10.210.11.178, sp 62114, dp 23, proto 6,
tok 16
Feb 25 02:42:49 02:42:49.803592:CID-0:RT: flow fast tcp/udp session id 32
Feb 25 02:42:49 02:42:49.803601:CID-0:RT: post addr xlation:

10.210.11.179->10.210.11.178.
n
Feb 25 02:42:49 02:42:49.803611:CID-0:RT:mbuf 0x4a0b1f40, exit nh 0xfffb0006
io
Feb 25 02:42:49 02:42:49.804583:CID-0:RT:Using in_ifp from pfe_tag with index
0
ct
Feb 25 02:42:49 02:42:49.804591:CID-0:RT:Using vr id from pfe_tag with value= 0
du
Feb 25 02:42:49 02:42:49.804596:CID-0:RT:Changing lpak->in_ifp from:.local..0
-> to:.local..0
Feb 25 02:42:49 02:42:49.804601:CID-0:RT:Over-riding lpak->vsys with 0

ro
Feb 25 02:42:49 02:42:49.804608:CID-0:RT:<10.210.11.178/23->10.210.11.179/
62114;6> : <junos-self/.local..0>
ep
Feb 25 02:42:49 02:42:49.804623:CID-0:RT:packet [53] ipid = 55876, @48aaa292
******
rR

tok 4

Fo

10.210.11.178->10.210.11.179.
Feb 25 02:42:49 02:42:49.804667:CID-0:RT:mbuf 0x48aaa0e0, exit nh 0x90010

ot
Feb 25 02:42:49 02:42:49.905335:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
N
Feb 25 02:42:49 02:42:49.905354:CID-0:RT:packet [52] ipid = 54863, @4a1ed7ce

******

tok 16


10.210.11.179->10.210.11.178.
Feb 25 02:42:49 02:42:49.905404:CID-0:RT:mbuf 0x4a1ed640, exit nh 0xfffb0006
Feb 25 02:42:49 02:42:49.945224:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:49 02:42:49.945241:CID-0:RT:packet [54] ipid = 54864, @49f5eb8e

******
n
tok 16
io
ct
10.210.11.179->10.210.11.178.
du
Feb 25 02:42:49 02:42:49.945286:CID-0:RT:mbuf 0x49f5ea00, exit nh 0xfffb0006

ro
0

ep
-> to:.local..0
rR
Feb 25 02:42:49 02:42:49.948612:CID-0:RT:<10.210.11.178/23->10.210.11.179/

Fo

******

ot
tok 4

N

10.210.11.178->10.210.11.179.
Feb 25 02:42:50 02:42:49.1050360:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:50 02:42:49.1050379:CID-0:RT:packet [52] ipid = 54865, @4a067f8e

******


tok 16

10.210.11.179->10.210.11.178.
Feb 25 02:42:50 02:42:49.1050427:CID-0:RT:mbuf 0x4a067e00, exit nh 0xfffb0006
n
0
io
Feb 25 02:42:50 02:42:49.1053191:CID-0:RT:Using vr id from pfe_tag with value=
ct
0
du
-> to:.local..0

ro
Feb 25 02:42:50 02:42:49.1053208:CID-0:RT:<10.210.11.178/23->10.210.11.179/
ep
******

rR

tok 4

Fo

10.210.11.178->10.210.11.179.

ot
Feb 25 02:42:50 02:42:49.1153951:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
N
Feb 25 02:42:50 02:42:49.1153967:CID-0:RT:packet [52] ipid = 54866, @49fe6eee

******

tok 16

10.210.11.179->10.210.11.178.

Feb 25 02:42:50 02:42:49.1154011:CID-0:RT:mbuf 0x49fe6d60, exit nh 0xfffb0006
Feb 25 02:42:50 02:42:49.1303541:CID-0:RT:<10.222.200.2/513->224.0.0.5/48;89>

: <Admin/ge-0/0/3.200>
Feb 25 02:42:50 02:42:49.1303559:CID-0:RT:packet [68] ipid = 54026, @4a0a1532

******
Feb 25 02:42:50 02:42:49.1303571:CID-0:RT: ge-0/0/

3.200:10.222.200.2->224.0.0.5, 89
n
17001(0x3ffff), sa 10.222.200.2, da 224.0.0.5, sp 1, dp 1, proto 89, tok 20
io
Feb 25 02:42:50 02:42:49.1303595:CID-0:RT: flow session id 9
ct
Feb 25 02:42:50 02:42:49.1303600:CID-0:RT: refreshing session
du
10.222.200.2->224.0.0.5.
Feb 25 02:42:50 02:42:49.1303616:CID-0:RT:mbuf 0x4a0a13a0, exit nh 0xfff80006

ro
0
ep

rR
-> to:.local..0
Feb 25 02:42:50 02:42:50.950867:CID-0:RT:<10.210.11.178/23->10.210.11.179/

Fo
Feb 25 02:42:50 02:42:50.950883:CID-0:RT:packet [1075] ipid = 55880, @48eca7f2

******
ot

tok 4
N

10.210.11.178->10.210.11.179.
Feb 25 02:42:50 02:42:50.950934:CID-0:RT:mbuf 0x48eca640, exit nh 0x90010

Feb 25 02:42:51 02:42:50.1054149:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:51 02:42:50.1054167:CID-0:RT:packet [52] ipid = 54867, @4a04684e

******

tok 16
n
10.210.11.179->10.210.11.178.
io
Feb 25 02:42:51 02:42:50.1054213:CID-0:RT:mbuf 0x4a0466c0, exit nh 0xfffb0006
ct
0
du
0
ro
-> to:.local..0
ep
Feb 25 02:42:51 02:42:50.1055202:CID-0:RT:<10.210.11.178/23->10.210.11.179/

rR

******

Fo

tok 4

ot

10.210.11.178->10.210.11.179.
N
Feb 25 02:42:51 02:42:50.1156170:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:51 02:42:50.1156186:CID-0:RT:packet [52] ipid = 54868, @4a1efe0e

******

tok 16


10.210.11.179->10.210.11.178.
Feb 25 02:42:51 02:42:50.1156230:CID-0:RT:mbuf 0x4a1efc60, exit nh 0xfffb0006

0
n
io
-> to:.local..0
ct
Feb 25 02:42:51 02:42:51.951879:CID-0:RT:<10.210.11.178/23->10.210.11.179/
du
Feb 25 02:42:51 02:42:51.951895:CID-0:RT:packet [1075] ipid = 55883, @48eca7f2

****** ro
ep
tok 4

rR

10.210.11.178->10.210.11.179.

Fo
Feb 25 02:42:52 02:42:51.1052847:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:53 02:42:51.1052865:CID-0:RT:packet [52] ipid = 54870, @4a06a5ce

******
ot

N
tok 16

10.210.11.179->10.210.11.178.
Feb 25 02:42:53 02:42:51.1052913:CID-0:RT:mbuf 0x4a06a440, exit nh 0xfffb0006

0


0

-> to:.local..0
Feb 25 02:42:53 02:42:51.1055950:CID-0:RT:<10.210.11.178/23->10.210.11.179/

n
******
io
ct
tok 4
du

10.210.11.178->10.210.11.179. ro
ep
Feb 25 02:42:53 02:42:51.1156926:CID-0:RT:<10.210.11.179/62114->10.210.11.178/
23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:53 02:42:51.1156943:CID-0:RT:packet [52] ipid = 54871, @49f95aee

rR
******

tok 16
Fo

10.210.11.179->10.210.11.178.
ot
Feb 25 02:42:53 02:42:51.1156988:CID-0:RT:mbuf 0x49f95960, exit nh 0xfffb0006

N

0

0

-> to:.local..0

Feb 25 02:42:53 02:42:52.1346954:CID-0:RT:<10.210.11.178/23->10.210.11.179/

Feb 25 02:42:53 02:42:52.1346970:CID-0:RT:packet [1075] ipid = 55885,

@48eca7f2 ******

tok 4
n
io
10.210.11.178->10.210.11.179.
ct
du
Feb 25 02:42:53 02:42:52.1448947:CID-0:RT:<10.210.11.179/62114->10.210.11.178/
23;6> : <management/ge-0/0/0.0>
Feb 25 02:42:53 02:42:52.1448965:CID-0:RT:packet [52] ipid = 54872, @4a1034ce

ro
******

ep
tok 16

rR

10.210.11.179->10.210.11.178.
Feb 25 02:42:53 02:42:52.1449011:CID-0:RT:mbuf 0x4a103340, exit nh 0xfffb0006

Fo

0

ot

N
-> to:.local..0
Feb 25 02:42:53 02:42:52.1449750:CID-0:RT:<10.210.11.178/23->10.210.11.179/


******


tok 4

10.210.11.178->10.210.11.179.
Feb 25 02:42:53 02:42:52.1515955:CID-0:RT:<10.222.100.2/513->224.0.0.5/48;89>
n
: <Retail/ge-0/0/3.100>
io
Feb 25 02:42:53 02:42:52.1515971:CID-0:RT:packet [68] ipid = 54028, @4a060cf2
******
ct
Feb 25 02:42:53 02:42:52.1515982:CID-0:RT: ge-0/0/
3.100:10.222.100.2->224.0.0.5, 89
du
143045(0x3ffff), sa 10.222.100.2, da 224.0.0.5, sp 1, dp 1, proto 89, tok 18
Feb 25 02:42:53 02:42:52.1516007:CID-0:RT:

ro
flow session id 7

ep
10.222.100.2->224.0.0.5.
rR
Feb 25 02:42:53 02:42:52.1516028:CID-0:RT:mbuf 0x4a060b40, exit nh 0xfff80006
Feb 25 02:42:53 02:42:52.1550478:CID-0:RT:<10.210.11.179/62114->10.210.11.178/

23;6> : <management/ge-0/0/0.0>
Fo
Feb 25 02:42:53 02:42:52.1550496:CID-0:RT:packet [52] ipid = 54873, @4a07fdee

******

ot
tok 16

N

10.210.11.179->10.210.11.178.
Feb 25 02:42:53 02:42:52.1550542:CID-0:RT:mbuf 0x4a07fc60, exit nh 0xfffb0006

0

0


-> to:.local..0
Feb 25 02:42:54 02:42:53.1347447:CID-0:RT:<10.210.11.178/23->10.210.11.179/

Feb 25 02:42:54 02:42:53.1347463:CID-0:RT:packet [1075] ipid = 55888,

@48eca7f2 ******
n
io
tomonitor stop
ct
lab@Tokyo>
Step 4.9
du
Close all the Telnet sessions and return to your router.
london-VR@Sydney> exit

ro
ep
lab@Tokyo>
rR
Shown here is the step for the other router:

lab@Tokyo> exit

Fo
lab@London>
Tell your instructor that you have completed Lab 2.

ot
STOP
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

Lab 3
Network Address Translation (NAT) (Detailed)
Overview
n
io
Now that you have established full connectivity and defined all the security zones, ensure that
private addresses do not enter the Internet by using destination and source Network Address
ct
Translation (NAT) and Port Address Translation (PAT).
You will deploy policy-based destination NAT using IP address translation to a range of IP
addresses. You will also accomplish the source address NAT using a source pool with PAT. The
du
Lab 3 network diagram provides the public address space for each group. Upon establishing
NAT, you will monitor the functionality of your configuration.
This lab is available in two formats: a high-level format that is designed to make you think
ro
ep
• Configure policy-based destination NAT.
• Configure source NAT using a source pool with PAT.
rR
• Ensure that full connectivity is maintained.

• Test and monitor NAT operation.
Similar to the previous lab, this lab requires you to use the Sydney router, which is logically
Fo
Relay services between the sites.
ot
N
Network Address Translation (NAT) (Detailed) • Lab 3–1

9.a.9.0R1
Key Commands

configure
ping
show route table
show security flow
show security nat
show security zones
n
traceroute
io
Part 1: Adding Public Addresses to Address Books of Necessary Security Zones
ct
In this part of the lab you will add public addresses corresponding to hosts in the Retail,
Admin, HR, and Finance security zones. Refer to the network diagram for Lab 3 for your
group letter (A, B, C, or D).
du
The public address space is identified in the following table.
ro
Public Address Assignment
Security Zone Name Name of the Address Public Address Space
ep
Retail PublicAddressRetail 200.10.10/24
Admin PublicAddressAdmin 200.10.11/24

rR
HR PublicAddressHR 136.10.10/24
Finance PublicAddressFinance 136.10.11/24
Step 1.1
Fo
Log in to the router with the username lab and the password lab123.
Note
ot
The username and the password are case sensitive.

N
Tokyo (ttyd0)
login: lab
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:14:18 UTC

lab@Tokyo>
Step 1.2
Add public addresses, identified in the Public Address Assignment table, to the Public zone
address book. Use the names for public addresses as identified in the table.
Lab 3–2 • Network Address Translation (NAT) (Detailed)

lab@Tokyo> edit
[edit]
lab@Tokyo# edit security zones security-zone Public

lab@Tokyo# set address-book address PublicAddressRetail 200.10.10/24

lab@Tokyo# set address-book address PublicAddressAdmin 200.10.11/24
n
lab@Tokyo# set address-book address PublicAddressHR 136.10.10/24
io
ct
lab@Tokyo# set address-book address PublicAddressFinance 136.10.11/24
du
ro
ep
rR

address PublicAddressRetail 200.10.10.0/24;
address PublicAddressAdmin 200.10.11.0/24;
address PublicAddressHR 136.10.10.0/24;
address PublicAddressFinance 136.10.11.0/24;
Fo
address TO-VRhost1;
address TO-VRhost2;
address TO-VRhost3;
}
ot
N
}
address LO-VRhost1;
address LO-VRhost2;
address LO-VRhost3;
}


lab@Tokyo#
Step 1.3
Add the defined public addresses to the address books of other security zones of your router.
Again, use the variable name for the addresses as identified in the table Public Address
Assignment table.
Note
n
Add only the addresses that are necessary for a
io
corresponding security zone.
Question: What are the public addresses that you
ct
should add to address books of your local security
zones?
du
Retail security zone:
Admin security zone:

HR security zone: ro
Finance security zone:
ep
Answer: You should be adding
PublicAddressRetail address to the Retail
zone, PublicAddressAdmin address to the Admin
zone, PublicAddressHR address to the HR zone,
rR
and PublicAddressFinance address to the

Finance zone.
The following configuration is for the Tokyo router:

Fo

lab@Tokyo# up
lab@Tokyo# set security-zone Retail address-book address PublicAddressRetail
200.10.10/24
ot

lab@Tokyo# set security-zone Admin address-book address PublicAddressAdmin
N
200.10.11/24

lab@Tokyo# show security-zone Retail address-book
address TO-VRhost1;
address TO-VRhost2;

address TO-VRhost3;
}

lab@Tokyo# show security-zone Admin address-book
n
}
io
ct
lab@Tokyo#
The following configuration is for the London router:
du
lab@London# up
[edit security zones] ro

lab@London# set security-zone address-book address PublicAddressHR 136.10.10/
24
ep
lab@London# set security-zone address-book address PublicAddressFinance
136.10.11/24
rR

lab@London# show security-zone HR address-book
Fo

address LO-VRhost1;
address LO-VRhost2;
address LO-VRhost3;
ot

N
lab@London# show security-zone Finance address-book

}


lab@London#
Step 1.4
Commit the changes.
lab@Tokyo# commit
commit complete

lab@Tokyo#
n
io
Part 2: Define Source and Destination NAT
ct
In this part of the lab you will configure source and destination NAT. Recall that you are to
deploy policy-based destination NAT using IP address translation to a range of IP addresses
and source NAT using a source pool with PAT.
du
You must work with your partner to ensure that proper addresses are applied to source and
destination NAT. Let’s take Tokyo and London as an example. For traffic originating from the
Retail to Finance security zones (through the Public zone), you will require source NAT
ro
to take place on the Tokyo router and destination NAT to take place on the London router.
Likewise, for traffic originating from the Finance to Retail security zones (through Public
zone), you will require source NAT to take place on the London router and destination NAT to
take place on the Tokyo router.
ep
The following table provides a summary of the NAT types to be deployed in every router of the
network.
rR
Deployment of NAT Types

Source Zone Destination Zone Source NAT Destination NAT Group
Fo
applied in: applied in:
Retail Finance through Tokyo London A

Public
San Jose Hong Kong B
Denver Sao Paulo C
ot
Montreal Amsterdam D
Retail through A
N
Finance London Tokyo

Public
Hong Kong San Jose B
Sao Paulo Denver C
Amsterdam Montreal D

Deployment of NAT Types

Source Zone Destination Zone Source NAT Destination NAT Group
applied in: applied in:
Admin HR through Public Tokyo London A

San Jose Hong Kong B
Denver Sao Paulo C
Montreal Amsterdam D
HR Admin through London Tokyo A
n
Public
Hong Kong San Jose B
io
Sao Paulo Denver C
Amsterdam Montreal D
ct
Step 2.1
du
Using the Deployment of NAT Types table, configure the appropriate source NAT on your router.
Use the first host of the corresponding public address space to assign to the source pool. For
example, you will use the source pool address 200.10.10.1 (which is the first host of the
200.10.10/24 address space) when configuring the Tokyo source pool to be used for source
ro
NAT from the Retail zone.
Use the following convention for source pool naming: ZoneNameSourcePool. For example,
Tokyo’s source pool for traffic originating from the Retail zone should be named
ep
RetailSourcePool.
lab@Tokyo# up
rR
[edit security]
lab@Tokyo# edit nat
[edit security nat]

Fo
lab@Tokyo# edit interface se-1/0/1.602
[edit security nat interface se-1/0/1.602]

lab@Tokyo# set source-nat pool RetailSourcePool address 200.10.10.1
ot

lab@Tokyo# set source-nat pool AdminSourcePool address 200.10.11.1
N

lab@Tokyo# show
source-nat {
pool RetailSourcePool {
address {
200.10.10.1;
}
}
pool AdminSourcePool {
address {

200.10.11.1;
}
}
}

lab@Tokyo#
The following configuration is for Tokyo’s peer of London:
[edit security nat]
lab@London# edit interface se-1/0/0.603
n
lab@London# show
io
source-nat {
pool FinanceSourcePool {
ct
address {
136.10.11.1;
}
du
}
pool HRsourcePool {
address {
136.10.10.1; ro
}
}
}
ep
lab@London#
Step 2.2
rR
Using the Deployment of NAT Types table, configure the appropriate destination NAT on your
router. The destination address range should be from the lowest to the highest private host
address in the corresponding zone. For example, destination NAT for the Retail zone applied
on Tokyo should range from 10.10.100.1 to 10.10.100.3. Name the destination NAT
Fo
ZoneNameDestNat. For example, the destination NAT’s name on Tokyo for the Retail
zone is RetailDestNAT.
lab@Tokyo# up
ot
[edit security nat]

lab@Tokyo# set destination-nat RetailDestNAT address-range low 10.10.100.1
N
high 10.10.100.3
[edit security nat]

lab@Tokyo# set destination-nat AdminDestNAT address-range low 10.10.200.1 high
10.10.200.3
[edit security nat]

lab@Tokyo# show destination-nat RetailDestNAT
address-range low 10.10.100.1 high 10.10.100.3;
[edit security nat]

lab@Tokyo# show destination-nat AdminDestNAT

[edit security nat]

lab@Tokyo#
The following configuration is for Tokyo’s peer of London:
[edit security nat]
lab@London# show destination-nat HRdestNAT
[edit security nat]
n
lab@London# show destination-nat FinanceDestNAT
io
[edit security nat]
ct
lab@London#
Part 3: Incorporating Source and Destination NAT into Security Policies
du
In this part of the lab you will adjust source and destination addresses in the security policies
of your router. Furthermore, you will refer to source NAT, destination NAT, or both from within
ro
the action statements of the corresponding security policies.
Step 3.1
ep
Using the Deployment of NAT Types table, fill in the following table for your group and router.
NAT Deployment in Security Policies

rR
City from-zone to-zone Source Destination Source NAT Destination

Address Address NAT
Fo
ot
The answers for all groups are found in the NAT Deployment table. You defined in Lab 2 the
source and destination address sets, and the named XX-VRhosts or XX-VR2hosts. Those
address sets contain private addresses (remember that XX is the corresponding city
N
abbreviation).

NAT Deployment
City from-zone to-zone Source Destination Source NAT Destination NAT
Address Address
Tokyo, Retail Public XX-VRhosts PublicAddress RetailSourceP n/a
Finance ool
San Jose,
Denver,
Montreal
n
Public Retail PublicAddr PublicAddress n/a RetailDestNAT
io
essFinance Retail
Admin Public XX-VR2hosts PublicAddress AdminSourcePo n/a
ct
HR ol
du
Public Admin PublicAddr PublicAddress n/a AdminDestNAT
essHR Admin
London, Public HR PublicAddr PublicAddress n/a HRDestNAT

Hong Kong,
Sao Paulo,
essAdmin ro HR
Amsterdam
ep
HR Public XX-VRhosts PublicAddress HRSourcePool n/a
Admin
Public Finance PublicAddr PublicAddress n/a FinanceDestNAT

rR
essRetail Finance
Finance Public XX-VR2hosts PublicAddress FinanceSource n/a

Fo
Retail Pool
Step 3.2
ot
Display the configuration of security policies to be altered.

[edit security nat]
N
lab@Tokyo# up
[edit security]
lab@Tokyo# edit policies

lab@Tokyo# show from-zone Retail to-zone Public
match {

}
then {
permit;
}
}

lab@Tokyo# show from-zone Public to-zone Retail
match {
n
io
}
then {
ct
permit;
}
}
du
lab@Tokyo# show from-zone Admin to-zone Public
policy AdminToHR { ro
match {
ep
}
then {
permit;
rR
}
}

lab@Tokyo# show from-zone Public to-zone Admin
Fo
policy HRtoAdmin {
match {
ot
}
then {
permit;
N
}
}

lab@Tokyo#

Step 3.3
Using the table that you filled out in Step 3.1, adjust the security policies configurations,
reflecting all the necessary changes in the source and destination addresses. Also, make
appropriate changes to the permit statements of security policies, ensuring that the
corresponding source NAT, destination NAT, or both take place as a result of policy execution.
lab@Tokyo# edit from-zone Retail to-zone Public

lab@Tokyo# delete policy RetailToFinance match destination-address
n
io
lab@Tokyo# set policy RetailToFinance match destination-address
PublicAddressFinance
ct
lab@Tokyo# set policy RetailToFinance then permit source-nat pool
RetailSourcePool
du
lab@Tokyo# show
policy RetailToFinance { ro
match {
destination-address PublicAddressFinance;
ep
}
then {
permit {
rR
source-nat {
pool RetailSourcePool;
}
}
}
Fo

lab@Tokyo# up
ot

lab@Tokyo# edit from-zone Public to-zone Retail
N

lab@Tokyo# delete policy FinanceToRetail match source-address

lab@Tokyo# delete policy FinanceToRetail match destination-address

lab@Tokyo# set policy FinanceToRetail match source-address
PublicAddressFinance


lab@Tokyo# set policy FinanceToRetail match destination-address
PublicAddressRetail

lab@Tokyo# set policy FinanceToRetail then permit destination-nat
RetailDestNAT

lab@Tokyo# show
match {
n
source-address PublicAddressFinance;
destination-address PublicAddressRetail;
io
}
ct
then {
permit {
destination-nat {
du
RetailDestNAT;
}
}
} ro
}

ep
lab@Tokyo# up

lab@Tokyo# edit from-zone Admin to-zone Public
rR

lab@Tokyo# delete policy AdminToHR match destination-address

Fo
lab@Tokyo# set policy AdminToHR match destination-address PublicAddressHR

lab@Tokyo# set policy AdminToHR then permit source-nat pool AdminSourcePool
ot

lab@Tokyo# show
policy AdminToHR {
N
match {
destination-address PublicAddressHR;
}
then {
permit {
source-nat {
pool AdminSourcePool;
}
}

}
}

lab@Tokyo# up

lab@Tokyo# edit from-zone Public to-zone Admin

lab@Tokyo# delete policy HRtoAdmin match source-address
n
lab@Tokyo# delete policy HRtoAdmin match destination-address
io
ct
lab@Tokyo# set policy HRtoAdmin match source-address PublicAddressHR
du
lab@Tokyo# set policy HRtoAdmin match destination-address PublicAddressAdmin

lab@Tokyo# set policy HRtoAdmin then permit destination-nat AdminDestNAT
ro
lab@Tokyo# show
ep
policy HRtoAdmin {
match {
source-address PublicAddressHR;
destination-address PublicAddressAdmin;
rR
}
then {
permit {
destination-nat {
Fo
AdminDestNAT;
}
}
}
}
ot

lab@Tokyo#
N
The following is the resulting configuration from the Tokyo’s peer, London:
lab@London# show
from-zone Public to-zone HR {
policy AdminToHR {
match {
source-address PublicAddressAdmin;
destination-address PublicAddressHR;
}

then {
permit {
destination-nat {
HRdestNAT;
}
}
}
}
}
from-zone Public to-zone Finance {
policy RetailtoFinance {
match {
n
source-address PublicAddressRetail;
destination-address PublicAddressFinance;
io
application any;
}
ct
then {
permit {
destination-nat {
du
FinanceDestNAT;
}
}
} ro
}
}
from-zone Finance to-zone Public {
ep
match {
destination-address PublicAddressRetail;
rR
}
then {
permit {
source-nat {
Fo
pool FinanceSourcePool;
}
}
}
}
ot
}
from-zone HR to-zone Public {
policy HRtoPublic {
N
match {
destination-address PublicAddressAdmin;
}
then {
permit {
source-nat {
pool HRsourcePool;
}
}

}
}
}

lab@London#
Step 3.4
Commit the configuration file.
n
commit complete
io
lab@Tokyo>
ct
Part 4: NAT Testing and Troubleshooting
du
In this part of the lab you will test source and destination NAT.
Step 4.1 ro
ep
Trying 10.222.100.2...
rR
Sydney (ttyp0)
Fo
login: tokyo-VR
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC

ot
N
tokyo-VR@Sydney>
Step 4.2
From the XX-VR router initiate a Telnet session from one of the hosts located in the Retail
or Admin zone to another host, located in the Finance or HR zone.

Question: If you are initiating a Telnet session from the

Retail zone, what destination address must you use?
To which security zone does it belong? Why?
Answer: You will initiate a Telnet session from a host in

the Retail zone with the destination address of the
n
public address space belonging to the Finance zone.
The reason is that other traffic will not be (should not
io
be) permitted by security policies.
tokyo-VR@Sydney> telnet source 10.10.200.1 136.10.10.1 routing-instance TO-VR2
ct
Trying 136.10.10.1...
telnet: connect to address 136.10.10.1: No route to host
telnet: Unable to connect to remote host
du
tokyo-VR@Sydney>
Question: Is the Telnet session successful? Why or why

ro
not?
ep
rR
Answer: The Telnet session is not successful because

no route to the public addresses exists.
Step 4.3
Fo
Fix the routing issue identified in the Step 4.2.

Exit the Telnet session into XX-VR router of your city region.
ot

N
lab@Tokyo>
Configure static routes to the prefixes of public addresses for the hosts belonging to the local
security zones of your router. For example, the Tokyo router will have static routes for
200.10.10/24 and 200.10.11/24 prefixes, as they represent prefixes of public addresses for
the Retail and Admin security zones, which are local to Tokyo. The London router, on the
other hand, will have static routes for 136.10.10/24 and 136.10.11/24 prefixes, as they
represent prefixes of public addresses for the HR and Finance security zones, which are local
to London.

The next-hop addresses, to be used in the static routes definitions, are the 10.222.x.y
addresses, leading to the respective hosts in the corresponding security zones. For example,
the 200.10.10/24 static route, because it represents public address prefix for hosts in
Retail zone, will use 10.222.100.2 as its next-hop address. The Lab 3 network diagrams
provide all the necessary information.
The following Public Address Assignment table provides the reference between the public
address prefixes and the corresponding security zones.
Public Address Assignment
n
Security Zone Name Public Address Space
io
Retail 200.10.10/24
Admin 200.10.11/24
ct
HR 136.10.10/24
Finance 136.10.11/24
du
lab@Tokyo> edit
[edit]
lab@Tokyo# edit routing-options static
ro
ep
[edit routing-options static]
lab@Tokyo# set route 200.10.10/24 next-hop 10.222.100.2
rR

lab@Tokyo# set route 200.10.11/24 next-hop 10.222.200.2

lab@Tokyo# show
Fo
route 200.10.10.0/24 next-hop 10.222.100.2;

route 200.10.11.0/24 next-hop 10.222.200.2;

lab@Tokyo#
ot
Here is the sample configuration for Tokyo’s peer router of London:

[edit]
N
lab@London# show routing-options

static {
route 136.10.10.0/24 next-hop 10.222.101.2;
route 136.10.11.0/24 next-hop 10.222.201.2;
}
[edit]
lab@London

Step 4.4
Ensure that the configured static routes are propagated to routers across the Internet and your
local LANs.
Question: What technique in JUNOS software do you

use to propagate static routes to other routers?
n
Answer: To propagate static routes to other routers, use
OSPF and routing policies. First, configure routing
io
policies. Next, export the configured policy under OSPF
protocol.
ct
lab@Tokyo# top
du
[edit]
lab@Tokyo# edit policy-options
[edit policy-options] ro
lab@Tokyo# set policy-statement staticToOSPF term 10 from protocol static
[edit policy-options]
ep
lab@Tokyo# set policy-statement staticToOSPF term 10 then accept
lab@Tokyo# show
rR
policy-statement staticToOSPF {
term 10 {
from protocol static;
then accept;
Fo
}
}
lab@Tokyo# top
ot
[edit]
lab@Tokyo# edit protocols ospf
N

lab@Tokyo# set export staticToOSPF

lab@Tokyo# show
export staticToOSPF;
area 0.0.0.0 {
interface lo0.0;
}

area 0.0.0.1 {
area-range 10.10.100.0/24;
}
area 0.0.0.11 {
area-range 10.10.200.0/24;
}

lab@Tokyo#
n
Step 4.5
io
Commit the changes.
ct
commit complete
du
lab@Tokyo>
Step 4.6
ro
Note
This step should be performed only by one of the
members of the group because the other member
ep
of the group will be observing the results of NAT.
rR
Fo
Trying 10.222.100.2...
Sydney (ttyp0)
ot
login: tokyo-VR
Password:
N
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
tokyo-VR@Sydney>

Step 4.7
From the XX-VR router, initiate a Telnet session from one of the hosts located in the Retail
or Admin zone to another host, located in the Finance or HR zone.
tokyo-VR@Sydney> telnet source 10.10.100.1 136.10.11.1 routing-instance TO-VR
Trying 136.10.11.1...
Sydney (ttyp0)
n
login:
Question: Is the Telnet session successful?
io
ct
Answer: Yes, the Telnet session should be successful.
du
Step 4.8
Using the management interface ge-0/0/0.0, use Telnet to access the router that is
performing the tests identified in the Step 4.7.
lab@London> telnet 10.210.11.178
Trying 10.210.11.178...
ro
ep
Tokyo (ttyp0)
rR
login: lab
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:14:18 UTC

Fo
lab@Tokyo>
Step 4.9
Use show commands to observe NAT functionality.
lab@Tokyo> show security flow session
ot

In: 10.222.200.2/1 --> 224.0.0.5/1;ospf, If: ge-0/0/3.200
Out: 224.0.0.5/1 --> 10.222.200.2/1;ospf, If: .local..0
N

In: 10.222.100.2/1 --> 224.0.0.5/1;ospf, If: ge-0/0/3.100
Out: 224.0.0.5/1 --> 10.222.100.2/1;ospf, If: .local..0

In: 10.222.100.1/49463 --> 10.222.100.2/23;tcp, If: .local..0
Out: 10.222.100.2/23 --> 10.222.100.1/49463;tcp, If: ge-0/0/3.100

In: 172.18.36.2/1 --> 224.0.0.5/1;ospf, If: se-1/0/1.602

Out: 224.0.0.5/1 --> 172.18.36.2/1;ospf, If: .local..0
Session ID: 8, Policy name: RetailToFinance/6, Timeout: 1782

In: 10.10.100.1/60088 --> 136.10.11.1/23;tcp, If: ge-0/0/3.100
Out: 136.10.11.1/23 --> 200.10.10.1/1025;tcp, If: se-1/0/1.602

In: 10.210.11.179/56534 --> 10.210.11.178/23;tcp, If: ge-0/0/0.0
Out: 10.210.11.178/23 --> 10.210.11.179/56534;tcp, If: .local..0
6 sessions displayed
n
lab@Tokyo>
io
Question: How many sessions exist? Explain.
ct
du
ro
Answer: The Tokyo router has six sessions. Three
sessions in each router are OSPF sessions. The other
ep
sessions are Telnet sessions.
Step 4.10
rR
Use the show security nat command to view source and destination NAT details.
lab@Tokyo> show security nat destination-nat summary
Pool name Address range Port
RetailDestNAT 10.10.100.1 - 10.10.100.3
Fo
AdminDestNAT 10.10.200.1 - 10.10.200.3
lab@Tokyo> show security nat source-nat summary

Pool name Address low Address high Interface PAT
RetailSourcePool 200.10.10.1 200.10.10.1 se-1/0/1.602 yes
ot
AdminSourcePool 200.10.11.1 200.10.11.1 se-1/0/1.602 yes
lab@London> show security nat destination-nat summary

N
Pool name Address range Port

FinanceDestNAT 10.10.201.1 - 10.10.201.3
HRdestNAT 10.10.101.1 - 10.10.101.3
lab@London> show security nat source-nat summary

FinanceSourcePool 136.10.11.1 136.10.11.1 se-1/0/0.603 yes
HRsourcePool 136.10.10.1 136.10.10.1 se-1/0/0.603 yes

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

Lab 4
Campus Interconnectivity—IPSec VPNs (Detailed)
Overview
n
io
In this lab, you will implement secure tunnels using route-based IPSec VPNs.
This lab is available in two formats: a high-level format that is designed to make you think
ct
du
Specifically, by completing this lab, you will perform the following tasks:
• Configure a route-based IPSec VPN between the two sites across the Internet.
• Troubleshoot and monitor IPSec VPNs.
ro
Similar to the previous lab, this lab requires you to use the Sydney router, which is logically
ep
Relay services between sites.
rR
Fo
ot
N
Campus Interconnectivity—IPSec VPNs (Detailed) • Lab 4–1

9.a.9.0R1
Key Commands
Key operational mode commands used in this lab include the following:
?
clear security ike security-associations
clear security ipsec security-associations
clear security ipsec statistics
configure
monitor start
monitor stop
n
ping
show log
io
show ospf neighbor
show route
show security ike security-associations
ct
show security ipsec security-associations
show security ipsec statistics
du
show security zones
Part 1: Configuring IKE Phase 1 Parameters ro

In this part of the lab, you will configure IKE Phase 1 parameters for the Retail/Finance
ep
IPSec VPN Tunnel. Specifically, you will configure the IKE proposal, the IKE policy, and the IKE
gateway.
Step 1.1
rR
Log in to the router with the username lab and the password lab123.
Note
Fo
The username and the password are case sensitive.
Tokyo (ttyd0)
login: lab
Password:
ot
--- JUNOS 9.0R1.10 built 2008-02-14 03:14:18 UTC

N
lab@Tokyo>
Lab 4–2 • Campus Interconnectivity—IPSec VPNs (Detailed)

Step 1.2
Define the IKE Phase 1 proposal, named IkeProposal, using the following parameters:
• Authentication method: Preshared keys;
• DH group: Group 5;
• Authentication algorithm: MD5;
• Encryption algorithm: 3DES-CBC; and
• Proposal lifetime value: 1200 seconds.
n
lab@Tokyo> edit
io
[edit]
ct
lab@Tokyo# edit security ike
[edit security ike]
lab@Tokyo# show proposal IkeProposal
du
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm md5;
encryption-algorithm 3des-cbc; ro
lifetime-seconds 1200;
[edit security ike]

ep
lab@Tokyo#
Step 1.3
Define the IKE Phase 1 policy, called IkePolicy. Use main mode and a preshared key called
rR
vpn123.
[edit security ike]
Fo
lab@Tokyo# set policy IkePolicy mode main
[edit security ike]

lab@Tokyo# set policy IkePolicy pre-shared-key ascii-text vpn123
ot
[edit security ike]

lab@Tokyo# set policy IkePolicy proposals IkeProposal
N
[edit security ike]

lab@Tokyo# show policy IkePolicy
mode main;
proposals IkeProposal;
pre-shared-key ascii-text "$9$0z2e1SeKMXbs48LGDkqf5"; ## SECRET-DATA
[edit security ike]

lab@Tokyo#
Step 1.4
Define the IKE Phase 1 gateway, named IkeGateway.

Question: What address must you specify for the

gateway?
Answer: The address of the gateway is the IP address of

the serial link across the Internet. For example, for
Tokyo’s specification of the gateway, the address is
172.18.36.2, which is the IP address of London’s
serial interface that faces Tokyo via the Internet.
n
[edit security ike]
io
lab@Tokyo# show gateway IkeGateway
ike-policy IkePolicy;
address 172.18.36.2;
ct
external-interface se-1/0/1.602;
du
[edit security ike]
lab@Tokyo# up
[edit security]
lab@Tokyo#
Part 2: Configuring IKE Phase 2 Parameters

ro
ep
In this part of the lab you will configure Phase 2 IKE parameters for the IPSec VPN tunnel.
Specifically, you will configure the IPSec proposal, the IPSec policy, and the IPSec VPN.
Step 2.1
rR
Configure the IPSec proposal, named ProposalIke2, using the following parameters:
• The protocol is ESP;
• The authentication algorithm is HMAC-MD5-96;
Fo
• The encryption algorithm is 3DES-CBC; and

• The lifetime of the proposal is 4800 seconds.
ot
[edit security]
lab@Tokyo# edit ipsec
N
[edit security ipsec]

lab@Tokyo# show proposal ProposalIke2
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 4800;

lab@Tokyo#

Step 2.2
Define the IPSec policy, called IPSecPolicy, to use the Group 5 perfect-forward-secrecy key.
lab@Tokyo# show policy IPSecPolicy
perfect-forward-secrecy {
keys group5;
}
n
lab@Tokyo#
Step 2.3
io
Assign the proposal, named ProposalIke2, to the policy defined in Step 2.2.
ct
lab@Tokyo# set policy IPSecPolicy proposals ProposalIke2
du
Step 2.4
Define the IPSec VPN, called IPSecVPN. Ensure that the IPSec tunnel is established only
when there is traffic that needs to go through the tunnel.
ro
Question: How do you ensure that an IPSec tunnel is
established without waiting for any traffic?
ep
Answer: To ensure that an IPSec tunnel is established

without waiting for any traffic, use the
rR
establish-tunnels immediately knob.

lab@Tokyo# show vpn IPSecVPN
Fo
ike {
gateway IkeGateway;
ipsec-policy IPSecPolicy;
}
establish-tunnels on-traffic;
ot

lab@Tokyo#
N
Step 2.5
Bind the configured IPSec VPN to the st0.0 interface.
lab@Tokyo# set vpn IPSecVPN bind-interface st0.0

lab@Tokyo#

Part 3: Configuring Route-Based IPSec VPN Elements
In this part of the lab you will configure distinguishing parameters for route-based IPSec VPNs.
Step 3.1
Configure the st0.0 interface on your router. Use the Lab 4 network diagram for IP address
assignment for your group.
lab@Tokyo# top
n
[edit]
lab@Tokyo# edit interfaces
io
[edit interfaces]
lab@Tokyo# set st0 unit 0 family inet address 172.18.38.1/30
ct
[edit interfaces]
du
lab@Tokyo# up
[edit]
lab@Tokyo#
Step 3.2
ro
Ensure that routing between the two sites across the Internet is performed across the st0.0
ep
interface.
Question: To what OSPF area should interface st0.0
belong on your router?
rR
Answer: The st0.0 interface should belong to Area 0.
[edit]
Fo
lab@Tokyo# show protocols

ospf {
area 0.0.0.0 {
ot
interface lo0.0;
}
area 0.0.0.1 {
N
area-range 10.10.100.0/24;
}
area 0.0.0.11 {
area-range 10.10.200.0/24;
}
}
[edit]

lab@Tokyo# delete protocols ospf area 0 interface se-1/0/1.602
[edit]
lab@Tokyo# set protocols ospf area 0 interface st0.0
[edit]
lab@Tokyo# show protocols
ospf {
area 0.0.0.0 {
interface lo0.0;
interface st0.0;
}
n
area 0.0.0.1 {
area-range 10.10.100.0/24;
io
}
ct
area 0.0.0.11 {
area-range 10.10.200.0/24;
du
}
}
Step 3.3
Commit the configuration.
ro
[edit]
ep
lab@Tokyo# commit
commit complete
Step 3.4
rR
Check the status of the OSPF routing protocol.

Question: Do you see any neighbors across the st0.0
interface? Why or why not?
Fo
Answer: There are no neighbors across the st0.0

interface because the st0.0 interface has not been
ot
assigned to a security zone and, as such, it belongs to

the Null zone by default.
N
[edit]
10.222.100.2 ge-0/0/3.100 Full 10.10.100.1 128 35
10.222.200.2 ge-0/0/3.200 Full 10.10.200.1 128 34
[edit]
lab@Tokyo# run show ospf interface
lo0.0 DR 0.0.0.0 192.168.24.1 0.0.0.0 0

st0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0

ge-0/0/3.100 BDR 0.0.0.1 10.10.100.1 192.168.24.1 1
ge-0/0/3.200 BDR 0.0.0.11 10.10.200.1 192.168.24.1 1
[edit]
lab@Tokyo#
Step 3.5
Ensure that the problem identified in Step 3.4 is fixed.
[edit]
n
io
lab@Tokyo# edit security-zone Public
ct
lab@Tokyo# show
address-book {
du
ro
ep
rR

Fo
address TO-VRhost1;
address TO-VRhost2;
address TO-VRhost3;
}
ot
address LO-VRhost1;
address LO-VRhost2;
N
address LO-VRhost3;
}
}

}
}
protocols {
ospf;
}
}
interfaces {
lo0.0;
se-1/0/1.602;
}
n
lab@Tokyo# set interfaces st0.0
io
ct
lab@Tokyo# show interfaces
lo0.0;
se-1/0/1.602;
du
st0.0;

lab@Tokyo# ro
Step 3.6
Commit configuration changes.
ep
lab@Tokyo# commit
commit complete
rR

lab@Tokyo#
Step 3.7
Fo
Check the OSPF neighbors.

Question: Do you see any neighbors across the st0.0
interface?
ot
N
Answer: You should see one OSPF neighbor across the

st0.0 interface.

172.18.38.2 st0.0 Full 192.168.36.1 128 38
10.222.100.2 ge-0/0/3.100 Full 10.10.100.1 128 38
10.222.200.2 ge-0/0/3.200 Full 10.10.200.1 128 31


lab@Tokyo# exit

lab@Tokyo# exit
[edit]
lab@Tokyo# exit
lab@Tokyo>
n
Part 4: Troubleshooting the Retail/Finance IPSec VPN Operation
io
Step 4.1
ct
Confirm that IKE Phase 1 security associations (SAs) are formed.
du
Question: In what state is the IKE Phase 1 SA? Why?
ro
ep
Answer: IKE Phase 1 SAs are formed because IPSec
VPN tunnels are established on the condition of
receiving the traffic that must be sent. In our case, it is
OSPF traffic that causes IKE Phase 1 SAs to be formed.
rR
lab@Tokyo> show security ike security-associations

Index Remote Address State Initiator cookie Responder cookie Mode
1 172.18.36.2 UP 1e830b1e240dc921 acc980e867ae1723 Main
Fo
Step 4.2
Confirm that IKE Phase 2 SAs are formed.
lab@Tokyo> show security ipsec security-associations
ot
total configured sa: 2

ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 172.18.36.2 500 ESP:3des/md5 7583bb6e 4029/ unlim - 0
N
>131073 172.18.36.2 500 ESP:3des/md5 17f14138 4029/ unlim - 0
lab@Tokyo>
Step 4.3
From your router, use Telnet to access the XX-VR router of your city region. (Recall that XX are


Trying 10.222.100.2...
Sydney (ttyp0)
login: tokyo-VR
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
n
io
ct
tokyo-VR@Sydney>
Step 4.4
du
From the XX-VR router, initiate a Telnet session from one of the hosts located in the Retail
zone to another host located in the Finance zone.
ro
Trying 136.10.11.1...
^C
ep
tokyo-VR@Sydney>

rR
Answer: The Telnet is not successful.
Step 4.5
Fo
Log out from the XX-VR router.


ot
lab@Tokyo>
Step 4.6
N
Recall that your router and your partner’s router is performing NAT. Check the source NAT
assignments.
Question: With which interfaces are the source NAT
addresses associated?
Answer: The source NAT addresses are associated with

the serial interfaces.

Question: With which interfaces should the source NAT

addresses be associated now?
Answer: The source NAT addresses should be

associated with the tunnel interface, st0.0.
lab@Tokyo> show security nat source-nat summary

RetailSourcePool 200.10.10.1 200.10.10.1 se-1/0/1.602 yes
AdminSourcePool 200.10.11.1 200.10.11.1 se-1/0/1.602 yes
n
lab@Tokyo>
io
lab@London> show security nat source-nat summary
ct
FinanceSourcePool 136.10.11.1 136.10.11.1 se-1/0/0.603 yes
HRsourcePool 136.10.10.1 136.10.10.1 se-1/0/0.603 yes
du
lab@London>
Step 4.7
lab@Tokyo> edit
Fix the problem identified in Step 4.6.
ro
ep
[edit]
lab@Tokyo# edit security nat
rR
[edit security nat]

lab@Tokyo# show
destination-nat RetailDestNAT address-range low 10.10.100.1 high 10.10.100.3;
destination-nat AdminDestNAT address-range low 10.10.200.1 high 10.10.200.3;
Fo
interface se-1/0/1.602 {
source-nat {
address {
200.10.10.1;
ot
}
}
N
address {
200.10.11.1;
}
}
}
}
[edit security nat]

lab@Tokyo# rename interface se-1/0/1.602 to interface st0.0
[edit security nat]

lab@Tokyo# show
destination-nat RetailDestNAT address-range low 10.10.100.1 high 10.10.100.3;
destination-nat AdminDestNAT address-range low 10.10.200.1 high 10.10.200.3;
interface st0.0 {
source-nat {
address {
200.10.10.1;
}
}
n
address {
200.10.11.1;
io
}
}
}
ct
}
[edit security nat]
du
lab@Tokyo#
Step 4.8
Commit the configuration changes.
ro
[edit security nat]
lab@Tokyo# commit
ep
commit complete
[edit security nat]

lab@Tokyo# exit
rR
[edit]
lab@Tokyo# exit
Fo
lab@Tokyo>
Step 4.9
Repeat Steps 4.3 and 4.4.
ot

N
Answer: The Telnet should now be successful.

Trying 10.222.100.2...
Sydney (ttyp0)

login: tokyo-VR
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC
tokyo-VR@Sydney>
n
Trying 136.10.11.1...
io
ct
Sydney (ttyp1)
login: ^CClient aborted login
du
tokyo-VR@Sydney>
Step 4.10 ro
Exit the Telnet session.
ep

rR
lab@Tokyo>
Step 4.11
From your router, use Telnet to access the XX-VR2 router of your city region. (Recall that XX
are the first two letters of your city name. For example, TO-VR2 is the router name attached to
Fo
Tokyo. The login name is your router name, router-VR2, where router is in lower case
Trying 10.222.200.2...
ot
N
Sydney (ttyp0)
login: tokyo-VR2
Password:
--- JUNOS 9.0R1.10 built 2008-02-14 03:13:25 UTC

tokyo-VR2@Sydney>
Step 4.12
Ensure that the established IPSec tunnel works for Admin/HR zones connection as well,
which you can do by establishing a Telnet session originating from a host located in Admin
zone to a host located in HR zone.
tokyo-VR2@Sydney> telnet 136.10.10.1 source 10.10.200.1 routing-instance
TO-VR2
Trying 136.10.10.1...
n
io
Sydney (ttyp1)
ct
login:
du
Answer: The Telnet should be successful.

ro
Step 4.13
ep
Observe the statistics of the IPSec tunnel on another router of your pod.
lab@London> show security ipsec statistics
ESP Statistics:
rR
Encrypted bytes: 51648

Decrypted bytes: 29816
Encrypted packets: 414
Decrypted packets: 421
AH Statistics:
Fo
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
ot
AH authentication failures: 0, Replay errors: 0

ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
N
lab@London> show security ipsec statistics

ESP Statistics:
Encrypted bytes: 51648
Decrypted bytes: 29868
Encrypted packets: 414
Decrypted packets: 422
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0

Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
lab@London>
n
io
ct
du
ro
ep
rR
Fo
ot
N

Operating Enhanced Services for
JUNOS Software
n
io
Appendix A: Lab Diagrams
ct
du
ro
ep
rR
Fo
ot
N
n
io
ct
du
ro
ep
rR
Fo
ot
N
A–2 • Lab Diagrams

n
io
ct
du
ro
ep
rR
Fo
ot
N
Lab Diagrams • A–3

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

n
io
ct
du
ro
ep
rR
Fo
ot
N

Oesj LGD 9.a PDF

Uploaded by

Document Information

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

Oesj LGD 9.a PDF

Uploaded by

Copyright:

Available Formats

Operating Enhanced Services for

1194 North Mathilda Avenue

Course Number: EDU-JUN-OESJ

Lab 3: Network Address Translation (NAT) (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

• Configure and monitor policy-based and route-based IPSec VPNs.

• Describe JSRP operation.

• Enterprise network engineers; and

Course Agenda • vii

CLI and GUI Text

Style Description Usage Example

Franklin Normal text. Most of what you read in the Lab

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Normal GUI View configuration history by

config.ini in the Filename field.

viii • Document Conventions

Style Description Usage Example

CLI Text where variable value is already policy my-peers

Education Services Offerings

About This Publication

Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.net/customers/

• Assign IP addresses to all the specified interfaces.

• Test and monitor network connectivity.

Frame Relay services between sites.

Initial System Configuration (Detailed) • Lab 1–1

Key operational-mode commands used in this lab include the following:

Lab 1–2 • Initial System Configuration (Detailed)

Initial System Configuration (Detailed) • Lab 1–3

Part 2: Establish Layer 2 Addressing

Physical interface: ge-0/0/3, Enabled, Physical link is Up

Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:

Lab 1–4 • Initial System Configuration (Detailed)

Output rate : 0 bps (0 pps)

Question: Based on the network diagram for your group,

Answer: The ge-0/0/3 interface requires VLAN-tagging

encapsulation. The serial link that faces the Internet

lab@Tokyo# edit interfaces

Initial System Configuration (Detailed) • Lab 1–5

Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:

Device flags : Present Running

Lab 1–6 • Initial System Configuration (Detailed)

Logical interface ge-0/0/3.100 (Index 64) (SNMP ifIndex 43)

Logical interface ge-0/0/3.200 (Index 67) (SNMP ifIndex 47)

Device flags : Present Running

Enquiry responses received : 3

Initial System Configuration (Detailed) • Lab 1–7

Keepalive responses timedout : 0

Logical interface se-1/0/1.602 (Index 70) (SNMP ifIndex 46)

Answer: The interface status in Step 2.1 illustrated

(VLANs), and the serial interface uses Frame Relay as

Part 3: Assign IP Addressing

Lab 1–8 • Initial System Configuration (Detailed)

lab@Tokyo# set se-1/0/1 unit 602 family inet address 172.18.36.1/30

Initial System Configuration (Detailed) • Lab 1–9

Question: Is the ping successful?

lab@Tokyo> ping 10.222.100.2

64 bytes from 10.222.100.2: icmp_seq=4 ttl=64 time=4.187 ms

lab@Tokyo> ping 10.222.200.2

64 bytes from 10.222.200.2: icmp_seq=1 ttl=64 time=2.390 ms

Lab 1–10 • Initial System Configuration (Detailed)

Question: Is the ping successful?