You are on page 1of 81

Low Level Design Review

Generated For: Suncor


Project Name: Suncor (Mackay River)
Generated On: August 9, 2012

Corporate and Sales Headquarters


Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Phone: 888.JUNIPER (888.586.4737)
or 408.745.2000
Fax: 408.745.2100

APAC Headquarters
Juniper Networks (Hong Kong)
26/F, Cityplaza One
1111 Kings Road
Taikoo Shing, Hong Kong
Phone: 852.2332.3636
Fax: 852.2574.7803

EMEA Headquarters
Juniper(Networks(Ireland(
Airside(Business(Park((
Swords,(County(Dublin,(Ireland(
Phone:(35.31.8903.600(
EMEA(Sales:(00800.4586.4737(
Fax:(35.31.8903.601(

Copyright(2012(Juniper(Networks,(Inc.(All(rights(reserved.(Juniper(Networks,(the(Juniper(Networks(logo,(Junos,(NetScreen,(and(ScreenOS(are(registered(trademarks(of(Juniper(
Networks,(Inc.(in(the(United(States(and(other(countries.(All(other(trademarks,(service(marks,(registered(marks,(or(registered(service(marks(are(the(property(of(their(respective(
owners.(Juniper(Networks(assumes(no(responsibility(for(any(inaccuracies(in(this(document.(Juniper(Networks(reserves(the(right(to(change,(modify,(transfer,(or(otherwise(revise(this(
publication(without(notice.(
November 2009

2012 Juniper Networks, Inc.

Page 1 of 81

Table of Contents
Tables and Figures...................................................................................................................................... 3(
Document Version Control .......................................................................................................................... 5(
Preface ........................................................................................................................................................ 6(
Who Should Read this Report ..................................................................................................................... 6(
Alphabetical Index of Terms ........................................................................................................................ 6(
Intellectual Property Rights ......................................................................................................................... 6(
1.( Introduction .......................................................................................................................................... 7(
1.1(
1.2(
1.3(
1.4(

Activities Conducted to Understand Suncors Requirements ................................................................... 8(


Documentation Received to Understand Suncors Requirements ............................................................ 8(
Suncors Contact Information.................................................................................................................... 8(
Disclaimer(s) ............................................................................................................................................. 8(

2.( Understanding Suncors Proposed High Level Design ........................................................................ 9(


2.1(
2.2(
2.3(
2.4(
2.5(
2.6(
2.7(
2.8(

Description of Services to be Supported by the Network Infrastructure ................................................... 9(


Requirements Related to Class of Service and Quality of Service ........................................................... 9(
Requirements on Routing Policies ............................................................................................................ 9(
Scaling Requirements and Constraints..................................................................................................... 9(
Network Reliability Requirements ........................................................................................................... 10(
High Availability Requirements ............................................................................................................... 10(
Performance Requirements .................................................................................................................... 10(
Current Network Limitations.................................................................................................................... 10(

3.( General Network Design .................................................................................................................... 11(


3.1(
3.2(

Device Types and Roles ......................................................................................................................... 11(


Network Architecture Overview............................................................................................................... 11(

4.( Chassis and System Configuration .................................................................................................... 14(


4.1( Overview ................................................................................................................................................. 14(
4.2( Chassis ................................................................................................................................................... 14(
4.3( JUNOS Software..................................................................................................................................... 15(
4.4( System Configurations ............................................................................................................................ 16(
4.5( DNS ........................................................................................................................................................ 16(
4.6( Naming Conventions............................................................................................................................... 16(
4.6.1( Device Naming ................................................................................................................................ 16(
4.6.2( Interface Naming ............................................................................................................................. 17(
4.7( Addressing Design and Conventions ...................................................................................................... 17(
4.7.1( Management Interface (me0) .......................................................................................................... 17(
4.7.2( Loopback Addressing ...................................................................................................................... 18(
4.7.3( CORE Addressing ........................................................................................................................... 18(
4.8( Router Management ............................................................................................................................... 19(
4.8.1( SNMP .............................................................................................................................................. 19(
4.8.2( SYSLOG .......................................................................................................................................... 20(
4.8.3( Router Access ................................................................................................................................. 22(
4.8.4( Network Time Protocol (NTP).......................................................................................................... 25(
4.8.5( Protecting the Control Plane ........................................................................................................... 25(
4.9( Interface Configuration............................................................................................................................ 29(
4.9.1( ACCESS-CORE Interfaces ............................................................................................................. 29(
4.9.2( CORE RVI Interfaces ...................................................................................................................... 30(
4.9.3( CORE-WAN Interfaces .................................................................................................................... 31(
4.10( Switching............................................................................................................................................... 32(
4.10.1( Defining VLANs ............................................................................................................................... 32(
4.10.2( Assigning Physical interfaces to VLANs .......................................................................................... 33(
4.10.3( RSTP ............................................................................................................................................... 35(
4.10.4( storm-control ................................................................................................................................... 37(
4.10.5( bpdu-block ....................................................................................................................................... 37(
4.11( Routing.................................................................................................................................................. 38(
4.11.1( Filter Based Forwarding .................................................................................................................. 38(
4.11.2( Static Routing .................................................................................................................................. 44(
4.11.3( OSPF ............................................................................................................................................... 45(

Router-IDs ................................................................................................................................................... 45(


Authentication ............................................................................................................................................. 46(
Redistribution .............................................................................................................................................. 46(
4.12( Network Services .................................................................................................................................. 50(
4.12.1( DHCP .............................................................................................................................................. 50(
4.12.2( VOIP ................................................................................................................................................ 53(

5.( Class of Service ................................................................................................................................. 54(


5.1.1(
5.1.2(
5.1.3(
5.1.4(
5.1.5(
5.1.6(
5.1.7(

Classifier .......................................................................................................................................... 54(


Policer ............................................................................................................................................. 54(
Forwarding Class ............................................................................................................................ 54(
Congestion Management ................................................................................................................ 55(
Scheduler ........................................................................................................................................ 55(
Classification Rewrite ...................................................................................................................... 56(
CoS Based Forwarding ................................................................................................................... 56(

6.( Troubleshooting Resources ............................................................................................................... 57(


7.( Annotated Configuration .................................................................................................................... 58(

Tables and Figures


Table 1 - Suncor Documentation ........................................................................................................... 8(
Table 2 - Suncor Project Contacts ......................................................................................................... 8(
Table 3 - DNS Configuration ................................................................................................................ 16(
Table 4 - Suncor Naming Conventions ................................................................................................ 16(
Table 5 - Interface Naming .................................................................................................................. 17(
Table 6 - Management Interfaces ........................................................................................................ 18(
Table 7 - Core Addressing ................................................................................................................... 19(
Table 8 - SNMP Communities ............................................................................................................. 19(
Table 9 - SNMP Configuration ............................................................................................................. 20(
Table 10 - JUNOS System Logging Facilities ...................................................................................... 21(
Table 11 - JUNOS Logging Levels ...................................................................................................... 21(
Table 12 - SYSLOG Configuration ...................................................................................................... 22(
Table 13 - SSH Configuration .............................................................................................................. 23(
Table 14 - Authentication Configuration .............................................................................................. 25(
Table 15 - NTP Configuration .............................................................................................................. 25(
Table 16 - Control Plane Filter Configuration ...................................................................................... 29(
Table 17 - Core Interface Configuration .............................................................................................. 30(
Table 18 - RVI configuration ................................................................................................................ 31(
Table 19 - WAN Interface Configuration .............................................................................................. 32(
Table 20 - VLAN Configuration ............................................................................................................ 33(
Table 21 - Access Port Configuration .................................................................................................. 34(
Table 22 - Trunk Port Configuration .................................................................................................... 35(
Table 23 - RSTP Edge Port Configuration ........................................................................................... 36(
Table 24 - storm-control Configuration ................................................................................................ 37(
Table 25 - bpdu-block configuration .................................................................................................... 38(
Table 26 - FBF Routing Instance Configuration .................................................................................. 40(
Table 27 - FBF Firewall Filter Configuration ........................................................................................ 42(
Table 28 - FBF WAN Filter Application ................................................................................................ 43(
Table 29 - FBF LAN Filter Application ................................................................................................. 44(
Table 30 - Static Route Configuration .................................................................................................. 45(
Table 31 - OSPF Configuration ........................................................................................................... 50(
Table 32 - DHCP Relay Configuration ................................................................................................. 53(
Figure 1 - Mackay River Logical Diagram ............................................................................................ 12(
Figure 2 - Core Virtual Chassis ............................................................................................................ 13(
Figure 3 - JUNOS Architecture ............................................................................................................ 14(
Figure 4 - EX4200-24F ........................................................................................................................ 15(
Figure 5 - EX4200-48PX ...................................................................................................................... 15(
Figure 6 - EX4200-24PX ...................................................................................................................... 15(
Figure 7 - Filter Based Forwarding Overview ...................................................................................... 39(

Document Version Control

Author: James Austin


Version: 1.0
Date: August 15, 2012
*several descriptions of network services/protocols were taken from Juniper Networks documentation available via
http://juniper.net
Version History:
Version
Number

Author

Date

Reason for Change

0.1

James Austin

August 15, 2012

Initial Draft

0.2

James Austin

August 23, 2012

Added RSTP Configuration Recommendations

0.3

James Austin

August 26, 2012

Added Diagrams

1.0

James Austin

Sept. 4, 2012

Clean Up

Preface
This document provides a Low Level Design for the integration of Juniper Networks products into Suncors network
environment. It is an outcome of the Low Level Design review service.
Juniper Low Level Design Review service leverages the expertise and experience of Juniper Professional Services teams to
help Suncor evaluate and utilize leading practices in their planning and design activities.

Who Should Read this Report


The primary audience for this report is Suncors network design and engineering team, network operations team and any other
service personnel directly or indirectly involved in this project. Juniper Networks personnel such as Service Managers, JTAC
engineers and other Professional Services consultants may also use this document as part of the service delivery process for
Suncor.

Alphabetical Index of Terms

Acronym

Description

AS

Advanced Services

CoS

Class of Service

HA

High Availability

HLD

High Level Design

LLD

Low Level Design

PS

Professional Services

QoS

Quality of Service

SM

Service Manager

Intellectual Property Rights


This document contains valuable trade secrets and confidential information of Juniper Networks Inc. and its suppliers, and
shall not be disclosed to any person, organization, or entity unless such disclosure is subject to the provisions of a written nondisclosure and proprietary rights agreement or intellectual property license agreement approved by Juniper Networks Inc. The
distribution of this document does not grant any license in or rights, in whole or in part, to the content, the product(s),
technology, or intellectual property described herein.

1.

Introduction

This Low Level design document is based on a review of Suncors existing high level design document as a part of Mackay
River Upgrade Project. It contains a detailed low level design for the integration of Junipers products into Suncors network.
The low level design notes and recommendations presented in this document are based on the expertise and experience of
Juniper Professional Services team in evaluating and recommending network architectures, products and technologies.
Juniper PS team leverages our current knowledge of leading practices to provide an optimum design and minimize network
disruption.
The detailed design and recommendations presented here are based on documentation provided by Suncor. Additional
information has been collected during meetings, conference calls or other forms of communication with Suncors teams.
Document Objective and Scope
The main objective of this document is to document a low level design for Suncors network referring to the Mackay River
infrastructure as defined by Suncor staff in the MacKay River Design Document.

The goals of the Network upgrade project include replacing end-of-life equipment in the
current MacKay River network while strategically addressing shortcomings and introducing a
scalable and reliable environment that will support future deployment of IS services. By
upgrading the existing Network to the newest Suncor hardware standard, it will provide
increased availability and capacity for future business growth to MacKay River business units.

Project Name

Suncor MacKay River EX Refresh

Project Number

13485

Location

MacKay River, Alberta - Canada

Project Commencement Date

May 31, 2012

1.1

Activities Conducted to Understand Suncors Requirements

Suncor has engaged Juniper Professional Services to review a low level design by reviewing their high level design document
and working with the Suncor Solution Designers assigned to the Mackay River project.
Juniper has performed the following activities to collect the requirements.

1.2

Initial scoping call with Suncor: 31-May-12


Initial SOW draft document presented to Suncor: 6-Jun-12
Revised SOW document presented to Suncor: 23-July-12
Signed SOW document received from Suncor: 24-July-12
Project kick-off meeting at Suncor: 31-July-12

Documentation Received to Understand Suncors Requirements

Juniper PS consultants have understood Suncors requirements and verified them against the documentation provided. The
following documents were referred to as part of the low level design review service delivery process:
Document
Type

File Name

Provided to Juniper consultant on


(Date)

Hardware List

MacKay River BoM with spares.xls

26-July-2012

Diagram

MacKay River Fiber Layout.vsd

26-July-2012

Design Document

MacKayRiverNetworkDesign.doc

26-July-2012

Diagram

MacKayRiverNetworkDesignAll4200s.vsd

26-July-2012

Hardware List

MacKay River Summary BoM v1.0.xlsx

26-July-2012

Table 1 - Suncor Documentation


1.3

Suncors Contact Information

The following contacts have provided the documentation and other supporting information required for this project:
Name

Email

Phone Number

Rena Hu, Solution Designer

renahu@suncor.com

403-296-6395

Nashaat Mansi, Solution Designer

nmansi@suncor.com

403-296-8555

Noel Dodd, Project Manager

ndood@suncor.com

403-296-5090

Table 2 - Suncor Project Contacts


1.4

Disclaimer(s)

Information provided in this document is limited to the scope defined as part of the Juniper low level design service. It does not
include details such as (specifically):

Network design other than for Juniper Network Elements


High level design development
JUNOS script development or troubleshooting.
Product issue impact review.
Configuration or modification for any third party devices or applications.

2.

Understanding Suncors Proposed High Level Design

Juniper and Suncor together have conducted a review of Suncors high level design and validated this design for various
factors including accurately described objectives and requirements. Based on the documentation and information provided by
Suncor, Juniper gained an understanding of the stated technical requirements for this project.
Juniper and Suncor together have approved the high level design to allow Juniper to proceed further with the low level design
review service.
This section reviews the following list of business and design requirements understood and agreed based on discussions with
Suncors project team.
Resiliency and Connectivity
Topology descriptions
Description of legacy services that need to remain
Peering and providing routing
Scaling equipment and constraints
Network reliability
High availability
2.1

Description of Services to be Supported by the Network Infrastructure

The proposed network infrastructure should support the following services.

2.2

Enterprise Network DATA Connectivity


Enterprise VOIP Telephony
HTTP/HTTPS Web Proxy Support

Requirements Related to Class of Service and Quality of Service

This section documents the understanding and analysis for requirements related to Class of Service and Quality of Service.

2.3

The network must be positioned to support CoS/QoS in the future.


CoS/QoS will not be part of the initial deployment

Requirements on Routing Policies

This section documents the understanding and analysis for requirements related to routing policies.

2.4

Single OSPF Area in the Core


Filter Based Forwarding for web traffic redirection

Scaling Requirements and Constraints

This section documents understanding and analysis for scaling requirements and constraints.

Network to be installed in remote location


Rackspace and Environment challenges
Possible near term Architectural changes

2.5

Network must support geographical changes/growth

Network Reliability Requirements

This section documents understanding and analysis for network reliability requirements.

2.6

Device stability is critical due to remote location of network


Redundancy challenges related to limited Layer 1 infrastructure

High Availability Requirements

This section provides understanding and analysis on high availability requirements.

2.7

Non-stop bridging (Virtual Chassis)


Layer 3 redundancy provided in the core (Virtual Chassis)
Redundant WAN Connectivity from location provided by upstream layer (non-juniper)

Performance Requirements

This section provides understanding and analysis on the performance requirements.

2.8

Stability/Manageability is priority
Device configuration simplicity preferred over Performance tuning
Optimum cpu/memory utilization

Current Network Limitations

Suncor is facing the following limitations in the current network:

Current network devices are at or nearing End of Life


Single Point of Failure in Core (Single Cisco 4506)

3.

General Network Design

This section provides information on general network design and outlines hardware components used in Suncors Mackay
River network.
3.1

Device Types and Roles


CORE (Devices deployed as single Virtual Chassis)
QTY
4
1

Part Number
EX4200-24F
EX4200-48PX

ACCESS
QTY
33
12

3.2

Part Number
EX4200-24PX
EX4200-48PX

Network Architecture Overview

The CORE of the Suncor Mackay River network will be composed of 5 EX4200 switches configured as a single virtual chassis.
The primary network function of the CORE will be to provide Layer 3 gateways for service access VLANS as well as provide
the uplink to the existing Suncor Mackay River WAN infrastructure. The CORE switch will be added to the existing OSPF
Backbone Area, thereby learning two default routes from the existing WAN infrastructure for uplink redundancy. The virtual
chassis core will be deployed across two buildings at the Suncor Mackay River site. The old admin building will hold 3 devices,
with the remaining two devices being physically located in the radio tower. Juniper Networks Virtual Chassis technology is a
feature of the EX4200 line of Ethernet switches allowing the interconnection and operation of switches as a unified, single, high
bandwidth device. For more detailed information about virtual chassis technology including detailed troubleshooting and
system maintenance procedures please review the Juniper Networks Virtual Chassis Technology Best Practices
implementation guide.
http://www.juniper.net/us/en/local/pdf/implementation-guides/8010018-en.pdf
The ACCESS Layer of the Suncor Mackay River network will be composed of EX4200 switches deployed in both virtual
chassis and standalone configurations depending on available Layer 1 infrastructure and port requirements. Access layer 2
devices will be directly connected to the CORE via Aggregated Ethernet (802.3ad) for redundancy purposes. Not all devices
will have multiple uplinks as available Layer 1 and business requirements for redundancy will vary by access switch location.
Traffic will be logically separated by VLAN at the access layer. The uplink to the CORE will be configured as a Layer 2 trunk.
Layer 3 gateway services will be provided for the Access vlans via RVI (Routed Virtual Interfaces) associated with each VLAN
on the CORE.

LOGICAL Overview

Legacy WAN

OSPF AREA 0
CORE - VIRTUAL CHASSIS
5 member - EX4200 managed
as single entity
L3 Gateways (RVI)

ACCESS
Layer 2 (802.1Q)

only 2 access switches


drawn for clarity

IP

IP

Figure 1 - Mackay River Logical Diagram

NETWORK
USERS

CORE - Virtual Chassis


managed as single entity
(mr-z01-vc01-01-sw-core-a)

RADIO TOWER
vcp-0

vcp-1
4

3
vcp-0

vcp-1

OLD ADMIN

vcp-1

vcp-0

vcp-1

vcp-0

vcp-0

1
vcp-1

Multi Mode Extended Virtual Chassis Link (ge-0/1/2


configured as VC link on each member)
Single Mode Extended Virtual Chassis Link (ge-0/1/2
configured as VC link on each member)
Dedicated Virtual Chassis Link
Figure 2 - Core Virtual Chassis

4.

Chassis and System Configuration

This section outlines Juniper hardware components and details system configuration of JUNOS used in the new Suncor
Mackay River network.
4.1

Overview

Three versions of Juniper Networks EX series platforms are used in the Mackay River network: All of these devices have a
common architecture in the sense that they consist of an RE (Routing Engine, running the control plane) and a PFE (packet
forwarding engine, implementing the data plane).
Some details about these platforms are provided in the below paragraphs. More information can be found at
http://www.juniper.net/us/en/products-services/switching/ex-series/

Figure 3 - JUNOS Architecture

4.2

Chassis

The EX4200 line of Ethernet switches, designed for access and aggregation deployments, deliver the best of modular,
chassis-based systems in a compact and efficient form factor.
The EX4200 line offers 24- and 48-port fixed-configuration 10/100/1000BASE-T platforms with full (all ports) and partial (eight
ports) Power over Ethernet (PoE) options. A 24-port 100BASE-FX/1000BASE-X SFP-based fiber platform, designed for
gigabit aggregation deployments requiring support for long-distance links, is also available. Optional four-port Gigabit Ethernet
(GbE) and two-port 10GbE uplink modules with pluggable optics are also available.
Dimensions
(W x H x D) 17.4 x 1.7 x 16.4 in (44.2 x 4.3 x 41.7 cm)
1 rack unit (single switch)
Backplane Speed
128 Gbps (Virtual Chassis)

Data Rate
EX4200-24P/24T/24F: 88 Gbps
EX4200-48P/48T: 136 Gbps
Resiliency
Internal, hot-swappable redundant power supply; field-replaceable fan tray with three fans; graceful
Route Engine switchover (GRES) in Virtual Chassis configuration
Power Options
AC: 320W, 600W and 930W autosensing; 100-120V / 200-240V; dual load-sharing hot-swappable

Figure 4 - EX4200-24F

Figure 5 - EX4200-48PX

Figure 6 - EX4200-24PX

4.3

JUNOS Software

JUNOS is Junipers Standards-based modular software for EX-Series devices.


Running JUNOS in a network improves the reliability, performance, and security of existing applications. It automates network
operations on a streamlined system, allowing more time to focus on deploying new applications and services. And it's scalable
both up and downproviding a consistent, reliable, stable system for developers and operators.
The initial network is deployed with JUNOS 11.4R3.7.

4.4

System Configurations

This section details system configuration of JUNOS used in the Suncor Mackay River network.
4.5

DNS

The domain associated with the Suncor Mackay River network and all of the nodes comprising it is:
pcacorp.net
Configuring DNS servers for the router to point at allows troubleshooting and maintenance commands to refer to other hosts by
their name rather than their IP. DNS servers are configured under the system name-server configuration hierarchy:
The current DNS configuration does not define DNS servers. Juniper recommends configuring name-servers.
system {
host-name mr-z01-vc01-01-sw-core-a;
domain-name pcacorp.net;
time-zone UTC;

Table 3 - DNS Configuration


4.6

Naming Conventions

4.6.1 Device Naming


The naming standard being used for the new infrastructure is an adaptation of the current standard used in
current infrastructure. A text abbreviation will denote the location of the device, followed by a device number
and a text abbreviation to denote the function of the equipment.
Table below explains the existing Suncor naming convention:

Suncor Network Naming Convention Standard (except Datacenters)


Field 1
Location

Field 2
Building
Code

Field 3
SubBuilding

3 chars

5 char
max

6 char
max

cgy,
fmm,

sec, slp,
stav, rcn,
hp

secw,
cvrl, cf,
shawcb,
slpb

Field 4

Field 5
Device
Type

Field 6
Device
Function

Field 7
# of
Units

Details
2 char
max
Examples

3 char
max

3 char
max

1 char
max

01,
02,14, 17

fw, rt,
sw, lb,
rtf, wo,
ups

pci,rsc,
dis, acc,
voi, vid,
cor, osg

a, b, c,
etc.

Floor #

Example Suncor router in Sheridan Park - mis-sp-adm-01-rt-cor-a


MKY

MacKay River

Table 4 - Suncor Naming Conventions

4.6.2 Interface Naming


The following table lists the current relevant abbreviations for juniper interfaces:

Abbreviation
ae

Description
Aggregated Ethernet interface. This is a virtual aggregated
link and has a different naming format from most PICs; for
more information, see Aggregated Ethernet Interfaces
Overview.
Gigabit Ethernet interface. Some older 10-Gigabit Ethernet
interfaces use the ge media type to identify the physical
part of the network device, but newer 10-Gigabit Ethernet
interfaces use the xe media type.
Generic routing encapsulation (GRE) tunnel interface.
10-Gigabit Ethernet interface. Some older 10-Gigabit
Ethernet interfaces use the ge media type (rather than xe)
to identify the physical part of the network device.
Table 5 - Interface Naming

ge

gr
xe

4.7

Addressing Design and Conventions

4.7.1 Management Interface (me0)


Juniper Networks recommends configuring IP addresses on the me0 interface for management purposes. The Suncor
Mackay River Network does not have an OOB IP management network. All device management is conducted via an RVI
(Routed VLAN Interface) configured on each device. This interface is configured as vlan.400. The addressing for vlan.400 is
outlined in the following table.
Hostname

mr-z01-vc01-01-sw-cor-a
mr-z01-oldadm-01-sw-acc-a
mr-z01-vc02-01-sw-srv-a
mr-z01-vc03-01-sw-acc-a
mr-z01-mcc01-01-sw-acc-a
mr-z01-mcc02-01-sw-acc-a
mr-z01-mcc03-01-sw-acc-a
mr-z01-vc04-01-sw-acc-a
mr-z01-mcc04-01-sw-acc-a
mr-z01-mcc05-01-sw-acc-a
mr-z01-mcc06-01-sw-acc-a
mr-z01-mcc07-01-sw-acc-a
mr-z01-mcc08-01-sw-acc-a
mr-z01-mcc10-01-sw-acc-a
mr-z01-vc05-01-sw-acc-a
mr-z01-vc06-01-sw-acc-a
mr-z01-vc07-01-sw-acc-a
mr-z01-pad40-01-sw-acc-a
mr-z01-vc08-01-sw-acc-a
mr-z01-vc09-01-sw-acc-a
mr-z01-vc10-01-sw-acc-a
mr-z01-vc10-01-sw-acc-a
mr-z01-whs-01-sw-acc-a

Address

10.112.36.1
10.112.36.248
10.112.36.247
10.112.36.245
10.112.36.242
10.112.36.241
10.112.36.240
10.112.36.238
10.112.36.237
10.112.36.236
10.112.36.235
10.112.36.234
10.112.36.233
10.112.36.232
10.112.36.231
10.112.36.228
10.112.36.229
10.112.36.223
10.112.36.222
10.112.36.220
10.112.36.218
10.112.36.216
10.112.36.211

mr-z01-camp-01-sw-acc-a
mr-z01-oldadm-01-sw-dmz-a
mr-z01-mcc10-01-sw-acc-a

10.112.36.210
10.112.36.135
10.112.36.204

Table 6 - Management Interfaces

4.7.2 Loopback Addressing


Juniper Networks recommends defining a network for loopback addressing of network devices.
The loopback address is used for the router ID as well and is used as the source interface for all traffic originating from the device
unless specified otherwise.
Suncor Mackay River Network was deployed without Loopback Addresses.

4.7.3 CORE Addressing


The Suncore Mackay River Network uses RVIs to provide layer 3 gateways for access VLANs.
Interface

Address

Function

vlan.1

155.44.2.1/24

vlan.400

10.112.36.1/24

vlan.402

10.112.19.1/26

vlan.403

10.112.19.65/26

vlan.414

10.112.16.97/27

vlan.415

10.112.17.1/29

vlan.451

10.112.16.33/27

vlan.500

10.112.20.1/24

vlan.501

10.112.21.1/24

vlan.502

10.112.22.1/24

vlan.503

10.112.18.1/25

vlan.504

10.112.23.1/24

vlan.700

10.112.24.1/24

vlan.701

10.112.25.1/24

VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY

vlan.702

10.112.26.1/24

vlan.704

10.112.27.1/24

vlan.900

10.112.28.1/27

ge-2/0/47
ge-4/0/23

10.112.16.1/28
10.112.16.17/29

VLAN L3
GATEWAY
VLAN L3
GATEWAY
VLAN L3
GATEWAY
WAN UPLINK
WAN UPLINK

Table 7 - Core Addressing


4.8

Router Management

4.8.1 SNMP
The Simple Network Management Protocol (SNMP) enables the monitoring of network devices from a central location. The
SNMP agent exchanges network management information with SNMP manager software running on a network management
system (NMS), or host. The agent responds to requests for information and actions from the manager. The agent also controls
access to the agents Management Information Base (MIB), the collection of objects that can be viewed or changed by the SNMP
manager.
The SNMP manager collects information on network connectivity, activity, and events by polling managed devices. SNMP
access to each device is via the following groups:
Read Only Communities

Allowed Hosts

8apuMeda4e

10.8.31.0/25 :
10.16.31.0/25 :
10.64.31.0/25

Read-Write Communities

Allowed Hosts

6pAgATRucrug

10.8.31.0/25 :
10.16.31.0/25 :
10.64.31.0/25
10.22.66.128/25

Trap-Group Communities

Allowed Hosts

8apuMeda4e

10.8.31.82/32
Table 8 - SNMP Communities

The JUNOS configuration for SNMP on each router will be:

snmp {
description <description>;
location <location>;
contact IFNSSODA;
community 8apuMeda4e {
authorization read-only;
clients {

10.8.31.0/25;
10.16.31.0/25;
10.64.31.0/25;
0.0.0.0/0 restrict;
}
}
community 6pAgATRucrug {
authorization read-write;
clients {
0.0.0.0/0 restrict;
10.8.31.0/25;
10.16.31.0/25;
10.64.31.0/25;
10.22.66.128/25;
}
}
trap-group 8apuMeda4e {
version v1;
targets {
10.8.31.82;
}
}
}
Table 9 - SNMP Configuration
4.8.2 SYSLOG
JUNOS will generate system log (syslog) messages to record events that occur on the routers. Each system log message identifies
the software process that generated the message and briefly describes the operation or error that occurred. You can direct the
messages to several collection locations simultaneously including local log files, remote server, another routing-engine, the

console port and the local terminal session of one or more specific users (or all users) when they are logged in to the local Routing
Engine. Each system log message belongs to a facility, which is a group of messages that are either generated by the same
software process or concern a similar condition or activity (such as authentication attempts). To log the messages belonging to one
or more facilities to a particular destination, specify each facility name as a separate statement within the set of statements for the
destination.
Below is a table of the facilities that you can configure in JUNOS.
Facility
any
authorization
change-log
conflict-log
daemon
dfc
firewall
ftp
interactive-commands
kernel
pfe
user

Type of Event or Error


All (messages from all facilities)
Authentication and authorization attempts
Changes to the JUNOS configuration
Configuration that is inconsistent with routing platform hardware
Actions performed or errors encountered by various system processes
Events related to dynamic flow capture
Packet filtering actions performed by a firewall filter
Actions performed or errors encountered by the FTP process
Commands issued at the JUNOS command-line interface (CLI) prompt or by a JUNOScript or
NETCONF client application
Actions performed or errors encountered by the JUNOS kernel
Actions performed or errors encountered by the Packet Forwarding Engine
Actions performed or errors encountered by various user-space processes
Table 10 - JUNOS System Logging Facilities

Each message is also pre-assigned a severity level, which indicates how seriously the triggering event affects routing platform
functions. When you configure logging for a facility and destination, you specify a severity level for each facility; messages from
the facility that are rated at that level or higher are logged to the destination.
Unlike the other severity levels, the none level disables logging of a facility instead of indicating how seriously a triggering
event affects routing functions.
Severity Level
any
none
emergency
alert
critical
error
warning
notice
info

Description
Includes all severity levels
Disables logging of the associated facility to a destination
System panic or other condition that causes the routing platform to stop functioning
Conditions that require immediate correction, such as a corrupted system database
Critical conditions, such as hard drive errors
Error conditions that generally have less serious consequences than errors in the emergency, alert, and
critical levels
Conditions that warrant monitoring
Conditions that are not errors but might warrant special handling
Events or nonerror conditions of interest
Table 11 - JUNOS Logging Levels

Based on facilities and severity levels available, the recommended syslog configuration is below. This configuration will locally
log messages to several different files depending on the facility. Users logged into the router will receive emergency level
messages from all facilities. Local log files called /var/log/messages and /var/log/access will be created. The messages files
are the main log file and will contain messages from several facilities with varying levels of severity. The file access will log
each command typed at the routers CLI prompt. User interaction will be easier to track and review.
The JUNOS Syslog configuration will be:

syslog {
archive size 10m files 10;
host 156.44.161.27 {

any info;
authorization info;
facility-override local5;
}
file messages {
any info;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
file default-log-messages {
any any;
}
console {
any critical;
}
}
Table 12 - SYSLOG Configuration
4.8.3 Router Access
Console access can be gained locally at each site by physically connecting a laptop to the routers console or aux port and utilizing
a terminal emulation program configured for 9600 baud and 8N1 (eight data bits, no parity, and one stop bit).
Juniper Networks recommends establishing console access to all deployed devices via an OOB network. This is especially critical
in the Suncor Mackay River network as physical device access is limited by several factors including the remote location of the
equipment and limited on-site technical resources.
SSH access to each router is available from Suncor management networks. SSH access is limited to ten (5) simultaneous
connections per minute at a rate of ten (10) attempts per minute:
The JUNOS SSH configuration will be:

services {
ssh {
protocol-version v2;
connection-limit 5;
rate-limit 10;
}

}
Table 13 - SSH Configuration

Telnet and FTP are disabled by default, so SCP will primarily be used to transfer software and configuration files to the Juniper
devices.
User groups are defined with varying levels of authorization. Passwords for these groups, and the root authentication password for
each router, are not maintained in this document for security reasons. Suncors primary authentication method is TACPLUS. All
users authenticating via TACPLUS are mapped to the remote user. Local accounts are maintained to facilitate login when
network connectivity to the TACPLUS server is unavailable.
authentication-order [ tacplus password ];
location building <location>;
root-authentication {
encrypted-password "$1$GB3Vs3tx$yFR8ARHepOqIgGOgIm7fr."; ## SECRET-DATA
}tacplus-server {
10.8.31.89 {
secret "$9$mPz6pu1crvO1X7Nd4oz369uO1IcevL"; ## SECRET-DATA
timeout 10;
source-address 10.112.36.1;
}
10.22.66.131 {
secret "$9$KMNvX-Y2aDHm4aQF360OX7-V24aJDqmT"; ## SECRET-DATA
timeout 10;
}
}
login {
message
"********************************************************************************\n
THIS IS A PRIVATE SYSTEM INTENDED FOR SUNCOR AUTHORIZED USE ONLY.\n UNAUTHORIZED

ACCESS WILL BE REPORTED TO SUNCOR'S INFORMATION SECURITY\n PERSONNEL AND LAW


ENFORCEMENT AGENCIES.\n USE OF SUNCOR'S SYSTEMS IS INTENDED FOR BUSINESS
PURPOSES.\n THERE IS NO RIGHT OF PRIVACY IN THIS SYSTEM. INFORMATION SYSTEMS AND
SECURITY\n PERSONNEL MAY GIVE TO LAW ENFORCEMENT OFFICIALS ANY POTENTIAL EVIDENCE
OF CRIME\n FOUND ON THIS SYSTEM. USE OF THIS SYSTEM BY ANY USER, AUTHORIZED OR\n
UNAUTHORIZED, CONSTITUTES EXPRESS CONSENT TO THIS MONITORING, WHICH MAY INCLUDE\n
INTERCEPTION, RECORDING, READING, COPYING, OR CAPTURING AND, IF REASONABLY\n
REQUIRED AND PERMITTED BY LAW, DISCLOSURE TO THE APPROPRIATE AUTHORITIES.\n IF YOU
DO NOT CONSENT, LOG OFF NOW.\n
********************************************************************************\n
CECI EST UN SYSTEME PRIVE QUI DOIT ETRE UNIQUEMENT UTILISE A DES FINS DUMENT\n
AUTORISEES PAR SUNCOR. TOUT ACCES NON AUTORISE SERA RAPPORTE AU GROUPE DE\n LA
SECURITE DE L'INFORMAITON DE SUNCOR ET AUX ORGANISMES D'APPLICATION DE\n LA LOI.\n
L'UTILISATION DE CE SYSTEME EST PREVUE A DES FINS COMMERCIALES.\n AUCUN DROIT A LA
VIE PRIVEE N'EXISTE DANS CE SYSTEME. LE PERSONNEL DES SERVICES\n INFORMATIQUES ET
DU GROUPE DE LA SECURITE DE L'INFORMAITON PEUT SOUMETTRE TOUTE\n EVIDENCE D'UN
CRIME POTENTIEL AUX RESPONSABLES DE L'APPLICATION DE LA LOI.\n L'UTILISATION DE CE
SYSTEME PAR TOUTE PERSONNE AUTORISEE OU NON, CONSTITUE UN\n CONSENTEMENT TACITE A
LA SURVEILLANCE, INCLUANT L'INTERCEPTION, L'ENREGISTREMENT,\n LA LECTURE, LA COPIE,
OU LA CAPTURE ET, SI EXIGEE ET PERMISE PAR LA LOI,\n LA DIVULGATION AUX AUTORITES
APPROPRIEES.\n SI VOUS NE CONSENTEZ PAS A CES CONDITIONS, SORTEZ DU SYSTEME
MAINTENANT.\n
********************************************************************************";
retry-options {
tries-before-disconnect 3;
backoff-threshold 3;
backoff-factor 10;
}
class admin {
idle-timeout 15;
permissions all;
}
user jtac {
uid 2001;
class admin;
authentication {
encrypted-password "$1$HfnIgbYN$qWsnNLy6RgJM87XR/FMHR1"; ## SECRETDATA
}
}
user remote {
uid 2002;

class admin;
}
user tacgen {
uid 2000;
class admin;
authentication {
encrypted-password "$1$ukGQxC.E$ajBwitbuhhGGnsWINjf080"; ## SECRETDATA
}
}
}
Table 14 - Authentication Configuration

4.8.4 Network Time Protocol (NTP)


Network Time Protocol (NTP) provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse
network. NTP uses a returnable-time design in which a distributed subnet of time servers operating in a self-organizing,
hierarchical master-slave configuration synchronizes local clocks within the subnet and to national time standards by means of
wire or radio. The servers also can redistribute reference time using local routing algorithms and time daemons.
The JUNOS NTP configuration is:
ntp {
boot-server 10.8.60.44;
server 10.8.60.44;
server 10.8.60.47;
server 156.44.208.69;
server 156.44.111.49;
}
Table 15 - NTP Configuration
4.8.5 Protecting the Control Plane
A firewall filter protecting the routing engine from accepting unauthorized information is applied to the loopback interface.
Although routing protocol authentication is recommended for OSPF, it does not prevent protocol packets from reaching the
routing process before they are rejected. As a result it is still possible to launch a denial of service attack against a routing
process by sending a massive number of unauthorized packets. CPU cycles can be used in rejecting these packets. We
therefore recommend setting a firewall filter that accepts protocol packets only from trusted sources.
The filter should examine the following packet parameters:

Addresses of trusted sources


Services and protocols that are running on the router:

o OSPF
o Management services (SSH, SNMP, NTP, etc.)
o Diagnostic and troubleshooting protocols (ICMP, traceroute, etc.)
Police the rate at which these packets are accepted.

The following firewall filter is applied on the loopback interface of all Juniper Switches in the Suncor Mackay River Network.
firewall {
family inet {
filter protect_control_plane {
term PERMIT-ESTABLISHED {
from {
tcp-established;
}
then accept;
}
term PERMIT-SSH {
from {
source-prefix-list {
mgmt-hosts;
}
destination-port ssh;
}
then accept;
}
term PERMIT-SNMP {
from {
source-prefix-list {
snmp-hosts;
}
protocol udp;
destination-port snmp;
}
then accept;

}
term PERMIT-PIM {
from {
protocol pim;
}
then accept;
}
term PERMIT-IGMP {
from {
protocol igmp;
}
then accept;
}
term PERMIT-ICMP {
from {
protocol icmp;
}
then accept;
}
term PERMIT-SOURCE-UDP {
from {
source-prefix-list {
mgmt-hosts;
}
protocol udp;
source-port [ ntp domain tacacs ];
}
}
term PERMIT-SOURCE-TCP {
from {
source-prefix-list {

mgmt-hosts;
}
protocol tcp;
source-port ntp;
}
then accept;
}
term PERMIT-TRACEROUTE {
from {
protocol udp;
destination-port 33434-33523;
}
then accept;
}
term PERMIT-NTP {
from {
destination-port ntp;
}
then accept;
}
term PERMIT-DHCP {
from {
destination-port dhcp;
}
then accept;
}
term PERMIT-OSPF {
from {
protocol ospf;
}

then accept;
}
term DEFAULT-DENY {
then {
discard;
}
}
}
}
Table 16 - Control Plane Filter Configuration

4.9

Interface Configuration

4.9.1 ACCESS-CORE Interfaces


IEEE 802.3ad link aggregation enables you to group Ethernet interfaces at the physical layer to form a single link layer
interface, also known as a link aggregation group (LAG) or bundle. For more information, see IEEE Standard 802.3ad,
Link Aggregation.
The Link Aggregation Control Protocol (LACP) is a mechanism for exchanging port and system information to create
and maintain LAG bundles. The LAG bundle distributes MAC clients across the link layer interface and collects traffic
from the links to present to the MAC clients of the LAG bundle.
To create the links in the LAG bundles, you can add one or more Ethernet physical interfaces to it. The LACP detects
Ethernet interfaces as links if they are configured on the same line module and have the same physical layer
characteristics. The LACP also assigns to the LAG bundle the same MAC address of the Ethernet link with the highest
port priority, which is the lowest value.
The LACP also controls the exchange of LACP protocol data units (PDUs) between the Ethernet links in the LAG
bundle. The PDUs contain information about each link and enable the LAG bundle to maintain them.
By default, Ethernet links do not exchange PDUs, which contain information about the state of the link. You can
configure Ethernet links to actively transmit PDUs, or passively transmit them, sending out LACP PDUs only when it
receives them from another link. The transmitting link is known as the Actor and the receiving link is known as the
Partner.
In the Suncor Mackay River network, access switches connect to the CORE via 802.3AD Aggregated Ethernet
Interfaces. LACP is configured as the control mechanism for the AE links. 802.1Q trunks are configured over the
Aggregated Ethernet Interfaces.
The following configuration template is provided for reference.

interfaces {
ge-0/0/0 {
description <description>;

ether-options {
802.3ad ae0;
}
}
ae0 {
description <description>;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
}
}
}
Table 17 - Core Interface Configuration
4.9.2 CORE RVI Interfaces
To segment traffic on a LAN into separate broadcast domains, you create separate virtual LANs (VLANs). VLANs limit
the amount of traffic flowing across the entire LAN, reducing the possible number of collisions and packet
retransmissions within the LAN. For example, you might want to create a VLAN that includes the employees in a
department and the resources that they use often, such as printers, servers, and so on.
Of course, you also want to allow these employees to communicate with people and resources in other VLANs. To
forward packets between VLANs you normally you need a router that connects the VLANs. However, you can
accomplish this forwarding on a switch without using a router by configuring a routed VLAN interface (RVI). Using this
approach reduces complexity and avoids the costs associated with purchasing, installing, managing, powering, and
cooling another device.

An RVI is a special type of Layer 3 virtual interface named vlan. Like normal Layer 3 interfaces, the vlan interface needs a
logical unit number with an IP address. In fact, to be useful an RVI needs at least two logical units and two IP addressesyou
must create units with addresses in each of the subnets associated with the VLANs between which you want traffic to be
routed. That is, if you have two VLANs (for example, VLAN red and VLAN blue) with corresponding subnets, your RVI must
have a logical unit with an address in the subnet for red and a logical unit with an address in the subnet for blue. The switch
automatically creates direct routes to these subnets and uses these routes to forward traffic between VLANs.
Layer 3 gateways are provided for the access VLANs on the CORE. These gateways are configured as Routed VLAN
Interfaces (RVIs). VLANs are associated with RVIs in the vlans hierarchy which is detailed in a later section.
RVI configuration (1 shown for clarity)

vlan {
unit 1 {
family inet {
filter {
input REDIRECT-FROM-HOST;
}
address 156.44.2.1/24 {
preferred;
}
address 156.44.104.209/29;
}
}

Table 18 - RVI configuration


4.9.3 CORE-WAN Interfaces

Ethernet links are used to connect the Core to the existing WAN infrastructure. These point-to-point links
are numbered.
Example link between the CORE and the WAN infrastructure.

ge-4/0/23 {
description mcky-adm-01-rt-wan-b;
ether-options {
no-auto-negotiation;
link-mode full-duplex;
speed {
100m;
}
}
unit 0 {
family inet {
filter {
input REDIRECT-FROM-SERVER;
}
address 10.112.16.17/29;
}
}
}
Table 19 - WAN Interface Configuration

4.10 Switching
4.10.1 Defining VLANs
EX-series switches use VLANs to make logical groupings of network nodes with their own broadcast domains. You can use
VLANs to limit the traffic flowing across the entire LAN and reduce collisions and packet retransmissions.
VLANs are defined at the vlans hierarchy. VLANs are named and it is at this level that the vlan-id is configured and routinginterfaces (RVIs) are bound to the VLAN.
A sample of the CORE VLAN configuration is provided for reference.

vlans {
VLAN0223 {
vlan-id 223;
}
default {
vlan-id 1;
l3-interface vlan.1;
}
v11_wan_outside {
vlan-id 11;
}
v400_net_mmgt {
vlan-id 400;
l3-interface vlan.400;
}
v402_serv_admin {
vlan-id 402;
l3-interface vlan.402;
}
v403_serv_ilo {
vlan-id 403;
l3-interface vlan.403;
}
v414_video_strm_srv {
vlan-id 414;
l3-interface vlan.414;
}
Table 20 - VLAN Configuration
4.10.2 Assigning Physical interfaces to VLANs
The VLAN tag is a 4 byte tag inserted into Ethernet frames and is used to consistently associate traffic with a
particular VLAN. The individual frames must be tagged as they are passed throughout a network.
When assigning a VLAN to a port on the switch, the user can assign either of the following modes:

Access mode - also known as untagged mode:


This mode is used to connect network devices, such as desktop computers, IP telephones, printer, and file
servers.
The port receives and transmits untagged Ethernet frames from the network devices.
This mode is the default mode for all ports.
Example of switch port configuration in the access mode:

ge-2/0/41 {
description <description>;
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members 1;
}

Table 21 - Access Port Configuration


Trunk mode - also known as tagged mode :
This mode is used to connect to other switches, routers, non-LLDP enabled VOIP devices
The port transmits and receives Ethernet frames with VLAN tags for multiple VLANs.
The port must be explicitly configured in the trunk mode.
Example of Switch port configured in the trunk mode:

ge-4/0/21 {
description <description>;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
Table 22 - Trunk Port Configuration
In the Suncor Mackay River Network, both modes are used. Uplinks from the Access Layer to the CORE are
configured as trunks. VOIP devices that are non-LLDP capable are also serviced via ports configured as trunks.
Devices that are not VLAN aware or participate in only a single VLAN are serviced via access mode interfaces.
4.10.3 RSTP
Juniper Networks EX Series Ethernet Switches provide Layer 2 loop prevention through Spanning Tree Protocol
(STP), Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), and VLAN Spanning Tree
Protocol (VSTP). The default factory configuration for EX Series switches uses RSTP. If your network includes 802.1D
1998 bridges, you can explicitly configure STP. Note that when doing so, the EX Series switches use the IEEE 802.1D
2004 specification, force version 0, which is an RSTP configuration that is compatible with basic STP. If you use
VLANs, we recommend that you enable MSTP unless your network requires the device compatibility provided by
VSTP.
RSTP is an evolution of the STP IEEE 802.1D protocol designed to provide faster spanning tree re-convergence after
a switch port, switch, or LAN failure. STP takes up to 50 seconds to respond to topology changes while RSTP
responds to changes within the timeframe of three hello BPDUs (Bridge Protocol Data Units), or 6 seconds. RSTP
calculates the spanning tree in the same manner as STP, but re-convergence after a connectivity failure works
differently. The key difference between STP and RSTP is that the latter does not use timers (rather a handshake) to
transition between port states and roles.
A ports state determines how it processes a frame. A ports role determines how it participates in the spanning tree.
STP places each port of a designated bridge in one of five states and assigns it a role as root, designated, or nondesignated port.RSTP assigns a port to one of three states, simplifying the process for a port to enter the forwarding
state, and establishes new port roles that serve as back-ups for a failed root or designated port on a designated
bridge.
The three port states used by RSTP are:
DiscardingThe port discards all BPDUs. This state replaces the disabled, blocking, and learning states used by
STP. A port in this state discards all frames it receives and does not learn MAC addresses.
LearningThe port prepares to forward traffic by examining received frames for location information in order to
build its MAC address table. RSTP eliminates the listening state that proceeds the learning state in STP
because the new mechanism for re-convergence (proposal-agreement handshake) does not require the
switch to spend time listening for the spanning tree to reconfigure.

ForwardingThe port filters and forwards frames. A port in the forwarding state is part of the active spanning tree.
The five port roles used by RSTP are:
Root portThe port closest to the root bridge (has the lowest path cost from a bridge) and serves as the only
port that receives frames from and forwards frames to the root bridge. The root port functions the same as in
STP.
Designated portThe port that forwards traffic away from the root bridge toward a leaf. A designated bridge
has one designated port for every link connection it serves. A root bridge forwards frames from all of its ports,
which serve as designated ports. A designated port functions the same as in STP.
Alternate portA port that provides an alternate path toward the root bridge if the root port fails and is placed
in the discarding state. This port is not part of the active spanning tree, but if the root port fails, the alternate
port immediately takes over.
Backup portA port that provides a backup path toward the leaves of the spanning tree if a designated port
fails and is placed in the discarding state. A backup port can only exist where two or more bridge ports
connect to the same LAN for which the bridge serves as the designated bridge. A backup port for a
designated port immediately takes over if the port fails.
Disabled portThe port is not part of the active spanning tree. Note that in STP, disabled is a state and not
a role.
STP and RSTP maintain the spanning tree differently. Both use BPDUs to communicate the current tree topology.
With STP, however, the root bridge initiates these messages and they propagate throughout the tree every hello time
interval. With RSTP, a non-root bridge sends a BPDU with its current information every hello time interval, regardless
of receiving BPDUs from the root bridge. If an RSTP device does not receive a configuration message from its
neighbor after an interval of three hello times, it determines it has lost a connection with that neighbor. In this way, the
RSTP BPDUs serve as a keep-alive mechanism that provides rapid failure detection. Note that EX Series switches
configured to use STP actually run RSTP force version 0, which is compatible with STP, so BPDU behavior is the
same.
When a root port or a designated port fails on an RSTP-enabled device, the alternate or backup port takes over after
an exchange of BPDUs called the proposal-agreement handshake. RSTP propagates this handshake over point-topoint links, which are dedicated links between two network nodes, or switches, that connect one port to another. If a
local port becomes a new root or designated port, it negotiates a rapid transition with the receiving port on the nearest
neighboring switch by using the proposal-agreement handshake to ensure a loop-free topology.
RSTP also defines the concept of an edge port, which is a designated port that connects to non-STP-capable
devices, such as PCs, servers, routers, or hubs that are not connected to other switches. Because edge ports connect
directly to end stations, they cannot create network loops and can transition to the forwarding state immediately,
skipping the listening and learning stages required by STP. You can manually configure edge ports, and a switch can
also detect edge ports by noting the absence of configuration BPDUs from any attached systems. If an edge port
receives a BPDU, it transitions to a regular STP port.
By taking advantage of edge ports and point-to-point links, RSTP provides rapid re-configuration of the spanning tree that can
occur in less than one second. Contrasted with the default 50-second re-convergence time based on STP timers (IEEE
802.1D), RSTP provides critical support for networks carrying delay-sensitive traffic, such as voice or video.
In the Suncor Mackay River network RSTP is enabled on all interfaces. However, RSTP edge ports are not currently explicitly
configured. Juniper recommends evaluating the RSTP configuration and explicitly setting edge ports.

[edit protocols rstp]


user@switch# set interface ge-0/0/5 edge
user@switch# set interface ge-0/0/6 edge
user@switch#

Table 23 - RSTP Edge Port Configuration

4.10.4 storm-control
A traffic storm is generated when messages are broadcast on a network and each message prompts a receiving node
to respond by broadcasting its own messages on the network. This, in turn, prompts further responses, creating a
snowball effect. The LAN is suddenly flooded with packets, creating unnecessary traffic that leads to poor network
performance or even a complete loss of network service. Storm control enables the switch to monitor traffic levels and
to drop broadcast and unknown unicast packets when a specified traffic levelcalled the storm control levelis
exceeded, thus preventing packets from proliferating and degrading the LAN. As an alternative to having the switch
drop packets, you can configure it to shut down interfaces or temporarily disable interfaces (see the actionshutdown statement or the port-error-disable statement) when the storm control level is exceeded.
The factory default configuration enables storm control on all switch interfaces, with the storm control level set to 80
percent of the combined broadcast and unknown unicast streams. You can change the storm control level for an
interface by specifying a bandwidth value for the combined broadcast and unknown unicast traffic streams. You can
also selectively disable storm control on the broadcast stream or on the unknown unicast stream.
Broadcast, multicast, and unicast packets are part of normal LAN operation, so to recognize a storm, you must be
able to identify when traffic has reached a level that is abnormal for your LAN. Suspect a storm when operations begin
timing out and network response times slow down. As more packets flood the LAN, network users might be unable to
access servers or e-mail.
Monitor the level of broadcast and unknown unicast traffic in the LAN when it is operating normally. Use this data as a
benchmark to determine when traffic levels are too high. Then configure storm control to set the level at which you want to
drop broadcast traffic, unknown unicast traffic, or both.
It is recommended that the Suncor Mackay River network team analyze traffic patterns and configure storm-control
accordingly.
The following example would disable interface ge-0/0/0.0 when unknown broadcast/unicast traffic exceeded 40% of available
link bandwidth.

user@switch# show storm-control


storm-control {
interface ge-0/0/0.0 {
level 40;
}
}
Table 24 - storm-control Configuration
4.10.5 bpdu-block
EX Series switches provide Layer 2 loop prevention through Spanning Tree Protocol (STP), Rapid Spanning Tree protocol
(RSTP), and Multiple Spanning Tree Protocol (MSTP). BPDU protection is configured on interfaces to prevent them from
receiving BPDUs that could result in STP misconfigurations, which could lead to network outages.
A loop-free network is supported through the exchange of a special type of frame called bridge protocol data unit
(BPDU). Receipt of BPDUs on certain interfaces in an STP, RSTP, or MSTP topology, however, can lead to network
outages by triggering an STP misconfiguration. To prevent such outages, enable BPDU protection on those interfaces
that should not receive BPDUs.
Enable BPDU protection on switch interfaces connected to user devices or on interfaces on which no BPDUs are expected,
such as edge ports. If a BPDU is received on a BPDU-protected interface, the interface is disabled and stops forwarding
frames.

In the Suncor Mackay River Network, it is recommended that RSTP edge ports be defined and BPDU protection be
enabled on all RSTP edge ports.
Example configuration.

[edit protocols rstp]


user@switch# set interface ge-0/0/5 edge
user@switch# set interface ge-0/0/6 edge
user@switch# set bpdu-block-on-edge

Table 25 - bpdu-block configuration


4.11 Routing
4.11.1 Filter Based Forwarding

For IPv4, IPv6, or MPLS-tagged IPv4 traffic only, you can use stateless firewall filters in conjunction with forwarding
classes and routing instances to control how packets travel in a network. This is called filter-based forwarding (FBF).
You can define a filtering term that matches incoming packets based on source address and then classifies matching
packets to a specified forwarding class. This type of filtering can be configured to grant certain types of traffic
preferential treatment or to improve load balancing. To configure a stateless firewall filter to classify packets to a
forwarding class, configure a term with the nonterminating action forwarding-class class-name.
You can also define a filtering term that directs matching packets to a specified routing instance. This type of filtering can be
configured to route specific types of traffic through a firewall or other security device before the traffic continues on its path. To
configure a stateless firewall filter to direct traffic to a routing instance, configure a term with the terminating action routinginstance routing-instance-name <topology topology-name> to specify the routing instance to which matching
packets will be forwarded.
The Suncor Mackay River network employs Filter Based Forwarding to redirect specific web traffic to an internal cache. This
is accomplished via a routing-instance that contains a static default route to the WAE device. Traffic that should be sent to the
WAE is identified and placed in the WAE routing-instance via firewall filters, which are applied to inbound traffic on the LAN
and WAN facing interfaces.
The following diagaram illustrates Filter Based Forwarding in the Suncor Mackay River network as configured on the CORE.

WAN

FILTER REDIRECT-FROMSERVER

INET.0

WAE.INET.0

WAE DEVICE

FILTER REDIRECT-FROMHOST

ACCESS LAYER

INBOUND TRAFFIC

WAE TRAFFIC
OTHER TRAFFIC
Figure 7 - Filter Based Forwarding Overview

WAE
ROUTING-INSTANCE
MAIN
ROUTING-INSTANCE

The following routing-instance configuration is used on the CORE to forward traffic to the WAE device (10.112.16.104)

routing-instances {
WAE {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop
10.112.16.104;
}
}
}
}
routing-options {
nonstop-routing;
interface-routes {
rib-group inet IMPORT-ROUTES;
}
rib-groups {
IMPORT-ROUTES {
import-rib [ inet.0 WAE.inet.0 ];
}
}
}
Table 26 - FBF Routing Instance Configuration
The following firewall filters are used on the CORE to identify traffic that should be sent to the WAE device.

filter REDIRECT-FROM-SERVER {
term REDIRECT-FROM-SERVER {
from {
source-prefix-list {
WAE-REDIRECT;
}
source-port http;
}
then {
routing-instance WAE;
}
}
term default {
then accept;
}
}
filter REDIRECT-FROM-HOST {
term REDIRECT-FROM-HOST {
from {
destination-prefix-list {
WAE-REDIRECT;
}
destination-port http;
}
then {

routing-instance WAE;
}
}
term default {
then accept;
}
}

Table 27 - FBF Firewall Filter Configuration


Application of the firewall filters on the WAN facing interfaces

ge-2/0/47 {
description WANINSIDEmcky-adm-01-3825-a:gi0/0;
unit 0 {
family inet {
filter {
input REDIRECT-FROM-SERVER;
}
address 10.112.16.1/28;
}
}
}
ge-4/0/23 {
description mcky-adm-01-rt-wan-b;
ether-options {

no-auto-negotiation;
link-mode full-duplex;
speed {
100m;
}
}
unit 0 {
family inet {
filter {
input REDIRECT-FROM-SERVER;
}
address 10.112.16.17/29;
}
}
}
Table 28 - FBF WAN Filter Application
Application of the REDIRECT-FROM-HOST firewall filter on LAN facing interfaces (only 1 shown for clarity)

vlan {
unit 1 {
family inet {
filter {
input REDIRECT-FROM-HOST;
}
address 156.44.2.1/24 {
preferred;
}
address 156.44.104.209/29;
}
}
Table 29 - FBF LAN Filter Application
4.11.2 Static Routing

The Suncor Mackay River Network also provides WAN connectivity for Suncors PCN network. Static Routes are configured
on the CORE network for the PCN networks. These static routes are redistributed into OSPF.
The CORE static route configuration is outlined below:

static {
route 10.112.16.128/25 next-hop 10.112.17.4;
route 10.112.38.0/24 next-hop 10.112.36.55;
route 10.112.39.16/28 next-hop 10.112.36.55;
route 10.112.39.224/28 next-hop 10.112.21.4;
route 156.44.3.0/25 next-hop 10.112.17.4;
route 156.44.23.0/25 next-hop 10.112.17.4;
route 156.44.55.32/27 next-hop 156.44.2.244;
route 156.44.66.0/28 next-hop 156.44.2.241;
route 156.44.70.0/24 next-hop 156.44.2.244;

route 156.44.71.16/28 next-hop 156.44.2.244;


route 156.44.71.128/25 next-hop 156.44.2.244;
route 156.44.72.96/27 next-hop 10.112.17.4;
route 156.44.79.0/27 next-hop 156.44.2.252;
route 156.44.85.8/30 next-hop 156.44.2.252;
route 156.44.85.12/30 next-hop 10.112.17.4;
route 156.44.85.32/28 next-hop 10.112.17.4;
}
protocols {
ospf {
}

export static-to-OSPF;

}
policy-options {
policy-statement static-to-OSPF {
term term1 {
from protocol static;
then accept;
}
}
Table 30 - Static Route Configuration
4.11.3 OSPF

The CORE of the Suncor Mackay River network participates in the existing backbone OSPF area. The CORE learns two
default routes that are originated by the directly connected WAN routers..
Router-IDs
Juniper Networks routers and Cisco Systems routers use the same procedure for determining the OSPF router ID:
1.
2.
3.
4.

If the RID is manually configured, use that value


If no RID is manually configured, use the IP address configured on the loopback interface
If no IP address is configured on a loopback interface, use the highest IP address configured on a physical interface
If no IP address is configured on a physical interface, a RID cannot be acquired and OSPF does not start

We recommend manually configuring all OSPF RIDs, even when the same value is configured as an IP address on the
loopback interface. Doing so insures that the RID is always deterministic.
Authentication
Authentication between all OSPF neighbors is highly recommended. Although most attacks launched against IP routing
protocols are against BGP, attacks against OSPF have occurred. Authentication prevents most attacks by causing OSPF to
drop any OSPF packets that do not contain the correct authentication parameters.
Two types of authentication are supported: Simple passwords (AuType = 1) and MD5 cryptographic checksum (AuType = 2).
Simple passwords are carried in OSPF packets as unencrypted plain text, and can therefore be sniffed. Therefore this method
is inappropriate for the network. MD5 authentication computes a checksum based on a combination of the contents of the
OSPF packet and a configured key. The result of the checksum is a cryptographic hash that is included in the transmitted
packet. The receiving router, which must be configured with the same key, calculates its own checksum and compares the
result with the hash enclosed in the packet. If the two values do not match, the packet is dropped and an authentication error is
recorded. Because the key itself is not carried in the OSPF packets, the key cannot be practically deduced from captured
packets through a reversal of the encryption algorithm.
Each configured key has a key ID, which is carried in the OSPF packet along with the cryptographic hash. This key ID allows
multiple keys to be configured, which is useful for changing keys without disrupting OSPF adjacencies. When multiple keys are
configured, OSPF sends copies of each packet matching the number of keys. It is therefore important that multiple keys are
only configured during periods of key change. When the change is complete, the old key must be deleted.
A non-decreasing sequence number is also carried in the OSPF packet, which prevents replay attacks.
Authentication must be configured for an entire area. Although different keys can be configured for each interface, we
recommend using the same key for all interfaces in the Suncor network for operational simplicity. However, this key should be
changed periodically to prevent intentional or unintentional divulgence to outside parties. We recommend changing the key at
least semi-annually as a part of regular network maintenance. Scripts can easily be written to automate network-wide key
changes.
The Suncor Mackay River Network does not authenticate OSPF neighbors.
Redistribution
Large-scale network failures due to redistribution between OSPF and some other routing protocol occurs with surprising
frequency. The most common scenario is one in which the full Internet routing table is inadvertently redistributed from BGP into
the link state IGP. In the case of OSPF, such an accident causes generation of one AS_External (type 5) LSA for each
redistributed prefix causing in turn process failure through over-taxed SPF calculations and runaway flooding.
To prevent such vulnerabilities, no redistribution should be configured between OSPF and any other dynamic IP routing
protocol. Only static routes should be redistributed, as needed, into OSPF. Such redistribution provides customer routing
information where necessary for proper network operation.
This policy not only closes the vulnerability described above of redistributing Internet routes through policy misconfiguration,
but also reduces network compromise due to misconfiguration.
The Suncor Mackay River Network WAN routers currently redistribute BGP routes into OSPF.
The CORE of the Suncor Mackay River Network redistributes static routes into OSPF.

protocols {
ospf {
inactive: traceoptions {
file ospf.txt;
flag state;
flag route;
flag general;
flag error detail;
}
export static-to-OSPF;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface vlan.1 {
passive;
}
interface vlan.400 {
passive;
}
interface vlan.401 {
interface-type p2p;
}
interface vlan.402 {

passive;
}
interface vlan.403 {
passive;
}
interface vlan.414 {
passive;
}
interface vlan.415 {
passive;
}
interface vlan.451 {
passive;
}
interface vlan.500 {
passive;
}
interface vlan.501 {
passive;
}
interface vlan.502 {
passive;
}
interface vlan.503 {
passive;
}

interface vlan.504 {
passive;
}
interface vlan.700 {
passive;
}
interface vlan.701 {
passive;
}
interface vlan.702 {
passive;
}
interface vlan.704 {
passive;
}
interface vlan.900 {
passive;
}
interface ge-4/0/23.0 {
interface-type p2p;
}
interface ge-2/0/47.0 {
interface-type p2p;
}
}

Table 31 - OSPF Configuration


4.12 Network Services
4.12.1 DHCP
You can configure extended DHCP relay options on the router and enable the router to function as a DHCP relay agent. A
DHCP relay agent forwards DHCP request and reply packets between a DHCP client and a DHCP server.
The Suncor Mackay River CORE is configured as a DHCP relay agent for all access VLANS.

forwarding-options {
helpers {
bootp {
interface {
vlan.1 {
server 10.112.19.57;
server 10.146.96.22;
}
vlan.402 {
server 10.112.19.57;
server 10.146.96.22;
}
vlan.403 {
server 10.112.19.57;
server 10.146.96.22;
}
vlan.500 {
server 10.112.19.62;

server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.501 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.502 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.504 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;

server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.700 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.701 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.702 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;

server 10.112.19.57;
server 10.146.96.22;
}
vlan.704 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.900 {
server 10.112.19.57;
server 10.146.96.22;
}
}
}
}
}
Table 32 - DHCP Relay Configuration
4.12.2 VOIP
The Suncor Mackay River network supports several different types of VOIP deployments. The configuration required to
support IP Telephony deployments is dependent upon the features the VOIP phone supports.
In cases of devices that do not support LLDP, Ethernet trunks are created to support both voice and data traffic on the same
port. LLDP-MED is recommended where supported. Please consult the following guides for detailed explanations of Juniper
EX Telephony Deployments.
http://www.juniper.net/us/en/local/pdf/app-notes/3500131-en.pdf

5.

Class of Service

The Suncor Mackay River Network does not currently use CoS. The data here is provided for reference purposes.
This section contains a discussion of the seven components of the JUNOS class of service architecture:
1.
2.
3.
4.
5.
6.
7.

Classifier
Policer
Forwarding Class
Congestion Management
Scheduler
Classification Rewrite
Forwarding

5.1.1 Classifier
A classifier associates incoming packets with a configured or default forwarding class and packet loss priority. The forwarding
class is associated with a queue while the loss priority is associated with the congestion manager. There are two types of
classifier:

Behavior Aggregate (BA) classifiers determine the forwarding class based on the packets DiffServe Code Point
(DSCP), IP Precedence, MPLS EXP, or IEEE 802.1p field values. The assumption behind these classifiers is that the marking
of at least one of these fields has already been done, so BA classifiers are normally found in core routers. These classifiers are
called Behavior Aggregates because they can aggregate multiple PHBs.

Multifield (MF) classifiers identify the forwarding class and loss priority that a packet should be assigned to based on
one or more field values of the packet. As such, MF classifiers are normally found at the network edge. Typical fields used to
classify packets are the source and destination IP addresses, IP protocol number, source and destination port, and DSCP, IP
precedence, or MPLS EXP fields. A packet can also be classified according to the interface on which it was received. JUNOS
uses firewall filters, which are designed to differentiate packets based on field values, to build MF classifers.
A single incoming interface can have both a BA and an MF classifier. BA classifiers function on the FPC, whereas MF
classifiers function on the IPII ASIC. Because the incoming FPC appears earlier in the packet forwarding path than the IPII
processing, incoming packets are acted upon by the BA classifier first and the MF classifier next. As a result, if there is a
conflict in the classifiers resolution of the packet, the MF overrides the BA classifier.
5.1.2 Policer
A policer provides rate limiting of incoming or outgoing packet traffic. Policers can be associated with an interface to police all
incoming and outgoing traffic, or they can use a firewall filter to identify specific packets to be policed. Policers can also be a
part of an MF classifier, changing the classification of a packet that is outside of the policed limits.
A token bucket mechanism is used to police traffic based on either a specified finite rate in bits per second, using the
bandwidth-limit statement, or as a percentage of interface bandwidth, using the bandwidth-percent statement.
Note that rate limiting based on bandwidth percentages cannot be configured on aggregate, tunnel, and software interfaces
and can only be used for interface specific filters (not forwarding table filters).
The policer is also configured to allow a specified burst size, using the burst-size-limit statement. The burst size limit is
specified in bytes per second, and is determined by multiplying the interface bandwidth by the amount of time traffic can burst
to that maximum bandwidth, up to a maximum configurable value of 100Mbps.
5.1.3 Forwarding Class
A forwarding class, also known as an ordered aggregate, is the set of packets that are assigned to a given queue.
The four default forwarding classes are:


Expedited Forwarding (EF) provides low loss, low latency, low jitter, assured bandwidth, end-to-end service.

Assured Forwarding (AF) provides a group of services you can define and includes four subclasses, AF1 through
AF4, each with low, medium, or high r\drop probabilities.

Best Effort (BE) is standard IP packet treatment, meaning that no preference is given in queuing or forwarding and
that drop probabilities are more aggressive during periods of congestion.

Network Control (NC) is for network control traffic such as routing protocol and VoIP signaling, The class if given high
priority, but no special treatment is needed for packet loss, delay, or delay variation (jitter).
The default queue associations for these classes are:

NC: Queue 3
AF: Queue 2
EF: Queue 1
BE: Queue 0

Note that although the AF and EF forwarding classes appear by default, the default classifier references only the NC and BE
queues; in other words, no packets are sent to queues 1 and 2 by default. If a packet is not referenced by any classifier, it is
sent to queue 0.
These defaults are changed under the [edit class-of-service] level with the forwarding-classes statement, with which a
forwarding class alias is associated with a queue. The forwarding class queue association is then assigned to a logical
interface under the [edit class-of-service interfaces interface-name unit logical-unit-number] level using the forwarding-class
statement. Note that the same forwarding class cannot be associated with more than one queue, and more queues than the
platform supports cannot be configured.
5.1.4 Congestion Management
[
JUNOS uses random early detection (RED) to manage queue congestion.
A classifier (in addition to assigning a packet to a forwarding class) assigns a packet loss priority (PLP) to a packet. This PLP
can be either low or high. For each queue, up to four drop profiles are configured for various combinations of low or high PLP
and TCP or non-TCP packets. These drop profiles define the drop probability of a queued packet at increasing levels of queue
fullness.
A drop profile is configured by specifying a set of {fill-level, drop-probability} tuples or pairs. An example of such a pair might
specify that when the queue is 50% full, the drop probability is 30%. Up to 64 of these pairs can be configured for a stair-step
drop profile or a set of fill-levels and drop probabilities can be configured as points on a smooth curve (using the interpolate
option) for a more fine-grained drop profile.
Drop profiles are configured under the [edit class-of-service drop-profiles] level.
5.1.5 Scheduler
A scheduler assigns the size of the queue (queue depth) and the transmission rate of the queue (the rate at which the queue is
serviced). The scheduler also associates one or more drop profiles with a queue and specifies what combination of low or high
PLP and TCP or non-TCP to apply.
Buffer size is specified in percentage of total buffer space for the interface. The default buffer sizes are:

Queue 0 = 95%
Queue 1 = 0%
Queue 2 = 0%
Queue 3 = 5%

Transmission rate can be specified in bits per second or as a percentage of available bandwidth. The default transmission
rates are:

Queue 0 = 95%
Queue 1 = 0%
Queue 2 = 0%
Queue 3 = 5%

The queues are serviced using a weighted round robin (WRR) algorithm. The scheduler assigns a priority (weight) to each
queue that determines how the queue is serviced in relation to the other queues. If the queue has not yet been serviced to its
maximum allotted bandwidth percentage, it has a positive credit. If the allotted bandwidth percentage is reached and there are
still packets in the queue, the queue has a negative credit. This system of priorities and credits allows an ordered servicing of
queues while at the same time allowing queues to use excess bandwidth that is not used by other queues.
5.1.6 Classification Rewrite
Rewrite rules can be configured that rewrite the DSCP, IP precedence, MPLS EXP, or IEEE 802.1p bits of a packet before it is
transmitted. Such rules are configured to override the values assigned by the incoming classifier. If no rewrite rules are
configured, the outgoing packet is marked according to the forwarding class and PLP assigned by the classifier.
5.1.7 CoS Based Forwarding
CoS-based forwarding (CBF) allows control of the next-hop selection based on a packets class of service. The next-hop can
be an IP address, and interface, or an LSP.

6.

Troubleshooting Resources

Juniper Networks maintains an extensive searchable database of documentation for all platforms. Please visit
http://support.juniper.net
Below are some examples of the documentation available which is relevant to the Suncor Mackay River network.

Resolution Guide - EX - Verify/Troubleshoot VLAN interface


http://kb.juniper.net/InfoCenter/index?page=content&id=KB22220

Resolution Guides - EX - Troubleshoot/Verify Interface


http://kb.juniper.net/InfoCenter/index?page=content&id=KB22217
Troubleshoot Extended Virtual Chassis configurations
http://www.juniper.net/techpubs/en_US/junos11.4/topics/example/virtual-chassis-ex4200-multiple-wiringclosets.html

Resolution Guide - EX - Troubleshoot Dynamic Host Configuration Protocol


http://kb.juniper.net/InfoCenter/index?page=content&id=KB23335
Resolution Guide - EX - Troubleshoot Spanning Tree Protocol (STP)
http://kb.juniper.net/InfoCenter/index?page=content&id=KB22774

JUNOS For IOS Engineers


http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/junos-for-iosengineers/

7.

Annotated Configuration

The following configuration template is commented for reference purposes.

system {
host-name mr-z01-vc01-01-sw-core-a;

<- Device Hostname

domain-name pcacorp.net;

<- Device Domain Name

time-zone UTC; <- Device Time Zone


no-redirects; <- disable support for IP redirects
authentication-order [ tacplus password ]; <- Use TACACS for primary authentication, local password file secondary
location building OldAdmin; <- Device physical location
root-authentication { <- local root password
encrypted-password "$1$GB3Vs3tx$yFR8ARHepOqIgGOgIm7fr."; ## SECRET-DATA
}
tacplus-server {
10.22.66.131 { <- ACS SERVER IP
port 1812; <-ACS SERVER PORT
secret "$9$.mQntpBhyK0BLx7-g4QFn/p0B1hlK8"; ## SECRET-DATA
timeout 2; <-Authentication timeout timer in seconds
}
10.8.31.89 {
secret "$9$8.ML-woaUkmTZUn/9AIR-VwYaZUDkfT3"; ## SECRET-DATA
timeout 2;
}
}
login { <- This is the login banner
message "********************************************************************************\n THIS IS A PRIVATE SYSTEM
INTENDED FOR SUNCOR AUTHORIZED USE ONLY.\n UNAUTHORIZED ACCESS WILL BE REPORTED TO
SUNCOR'S INFORMATION SECURITY\n PERSONNEL AND LAW ENFORCEMENT AGENCIES.\n USE OF SUNCOR'S
SYSTEMS IS INTENDED FOR BUSINESS PURPOSES.\n THERE IS NO RIGHT OF PRIVACY IN THIS SYSTEM.
INFORMATION SYSTEMS AND SECURITY\n PERSONNEL MAY GIVE TO LAW ENFORCEMENT OFFICIALS ANY
POTENTIAL EVIDENCE OF CRIME\n FOUND ON THIS SYSTEM. USE OF THIS SYSTEM BY ANY USER, AUTHORIZED
OR\n UNAUTHORIZED, CONSTITUTES EXPRESS CONSENT TO THIS MONITORING, WHICH MAY INCLUDE\n

INTERCEPTION, RECORDING, READING, COPYING, OR CAPTURING AND, IF REASONABLY\n REQUIRED AND


PERMITTED BY LAW, DISCLOSURE TO THE APPROPRIATE AUTHORITIES.\n IF YOU DO NOT CONSENT, LOG OFF
NOW.\n ********************************************************************************\n CECI EST UN SYSTEME PRIVE QUI DOIT
ETRE UNIQUEMENT UTILISE A DES FINS DUMENT\n AUTORISEES PAR SUNCOR. TOUT ACCES NON AUTORISE
SERA RAPPORTE AU GROUPE DE\n LA SECURITE DE L'INFORMAITON DE SUNCOR ET AUX ORGANISMES
D'APPLICATION DE\n LA LOI.\n L'UTILISATION DE CE SYSTEME EST PREVUE A DES FINS COMMERCIALES.\n
AUCUN DROIT A LA VIE PRIVEE N'EXISTE DANS CE SYSTEME. LE PERSONNEL DES SERVICES\n INFORMATIQUES
ET DU GROUPE DE LA SECURITE DE L'INFORMAITON PEUT SOUMETTRE TOUTE\n EVIDENCE D'UN CRIME
POTENTIEL AUX RESPONSABLES DE L'APPLICATION DE LA LOI.\n L'UTILISATION DE CE SYSTEME PAR TOUTE
PERSONNE AUTORISEE OU NON, CONSTITUE UN\n CONSENTEMENT TACITE A LA SURVEILLANCE, INCLUANT
L'INTERCEPTION, L'ENREGISTREMENT,\n LA LECTURE, LA COPIE, OU LA CAPTURE ET, SI EXIGEE ET PERMISE
PAR LA LOI,\n LA DIVULGATION AUX AUTORITES APPROPRIEES.\n SI VOUS NE CONSENTEZ PAS A CES
CONDITIONS, SORTEZ DU SYSTEME MAINTENANT.\n
********************************************************************************";
retry-options {
tries-before-disconnect 3; <- Allow three password tries before session disconnect
backoff-threshold 3; <- Threshold for the number of failed login attempts before the user experiences a delay when
attempting to reenter a password
backoff-factor 10; <- Length of delay after each failed login attempt. The length of delay increases by this value for each
subsequent login attempt after the value specified in the backoff-threshold option
}
class superuser-local {
idle-timeout 15; <- Disconnect superuser sessions after 15 minutes of idle time.
}
user jtac { <- local password file user
uid 2001;
class super-user;
authentication {
encrypted-password "$1$midgtj1A$rJkvl7tuPYP7MpL328kYG/"; ## SECRET-DATA
}
}
user remote { <- local password file user
uid 2002;
class super-user;
}
user tacgen { <- local password file user
uid 2000;

class superuser;
authentication {
encrypted-password "$1$c1jcnPmN$vMAoUZMHd6SLDgYBs5nWt1"; ## SECRET-DATA
}
}
}
services {
ssh {
protocol-version v2; <- only support ssh v2
connection-limit 5; <- only allow 5 concurrent ssh sessions
rate-limit 10; <- prevent ssh brute force attacks only allow 10 connection attempts per minute
}
}
syslog {
archive size 10m files 10; <- archive local syslog files after 10mb in size keep previous 10 files
host 156.44.161.27 { <- syslog server
any info;
authorization info;
facility-override local5; <- set syslog facility to local5
}
file messages { <- local log file
any info;
authorization info;
}
file interactive-commands { <- log all interactive commands to local file system
interactive-commands any;
}
file default-log-messages { <- for troubleshooting purporses deactivate when not in use
any any;

}
console { <- log critical messages to device console
any critical;
}
}
commit synchronize; <- synchronize configurations across routing-engines when commit is performed.
ntp { <- NTP configuration
boot-server 10.8.60.44;
server 10.8.60.44;
server 10.8.60.47;
server 156.44.208.69;
server 156.44.111.49;
}
}
chassis {
redundancy {
graceful-switchover; <-enable graceful swithover. In the event of routing-engine failover upstream WAN routers are
notified to resent OSPF LSAs.
}
aggregated-devices {
ethernet {
device-count 34; <- support 34 LAG interfaces
}
}
alarm {
management-ethernet {
link-down ignore; <-ignore me0 interface state
}
}

}
interfaces {

INTERFACE CONFIGURATION REMOVED


forwarding-options {
helpers { <- DHCP RELAY CONFIGURATION
bootp {
interface {
vlan.1 {
server 10.112.19.57;
server 10.146.96.22;
}
vlan.402 {
server 10.112.19.57;
server 10.146.96.22;
}
vlan.403 {
server 10.112.19.57;
server 10.146.96.22;
}
vlan.500 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.501 {
server 10.112.19.62;

server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.502 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.504 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.700 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;

}
vlan.701 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.702 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.704 {
server 10.112.19.62;
server 156.44.162.163;
server 10.8.65.142;
server 10.22.128.37;
server 10.112.19.57;
server 10.146.96.22;
}
vlan.900 {
server 10.112.19.57;
server 10.146.96.22;
}

}
}
}
}
snmp {
contact IFNSSODA;
community 8apuMeda4e { <- snmp community
authorization read-only; <- snmp authorization level
clients { <- configure SNMP clients
0.0.0.0/0 restrict;
10.8.31.0/25;
10.16.31.0/25;
10.64.31.0/25;
10.22.66.128/25;
}
}
community 6pAgATRucrug {
authorization read-write;
clients {
0.0.0.0/0 restrict;
10.8.31.0/25;
10.16.31.0/25;
10.64.31.0/25;
10.22.66.128/25;
}
}
trap-group 8apuMeda4e {
version v1;
targets { <-SNMP TRAP HOSTS

10.64.31.21;
10.8.31.21;
10.8.31.82;
}
}
}
routing-options {
nonstop-routing; <-keep standby routing engine route tables synchronized across routing engines
interface-routes {
rib-group inet IMPORT-ROUTES; <- This command creates a Routing Information Base consisting of all the
interface/directly connected routes.
}
static { <- static routes to PCN network assets
route 10.112.16.128/25 next-hop 156.44.2.253;
route 10.112.38.0/24 next-hop 10.112.36.55;
route 10.112.39.16/28 next-hop 10.112.36.55;
route 10.112.39.224/28 next-hop 10.112.21.4;
route 156.44.3.0/25 next-hop 156.44.2.253;
route 156.44.23.0/25 next-hop 156.44.2.253;
route 156.44.55.32/27 next-hop 156.44.2.244;
route 156.44.66.0/28 next-hop 156.44.2.241;
route 156.44.70.0/24 next-hop 156.44.2.244;
route 156.44.71.16/28 next-hop 156.44.2.244;
route 156.44.71.128/25 next-hop 156.44.2.244;
route 156.44.72.96/27 next-hop 156.44.2.253;
route 156.44.79.0/27 next-hop 156.44.2.252;
route 156.44.85.8/30 next-hop 156.44.2.252;
route 156.44.85.12/30 next-hop 156.44.2.253;
route 156.44.85.32/28 next-hop 156.44.2.253;

route 0.0.0.0/0 next-hop 10.112.36.1;


}
rib-groups {
IMPORT-ROUTES { <- This is the Routing Information Base created above which consists of directly connected/network
routes only
import-rib [ inet.0 WAE.inet.0 ]; <- This command copies directly connected/network routes into WAE routing instance
which is used for filter based forwarding.
}
}
router-id 10.112.36.253; <-This is the router-id which is used as a source for all router originating traffic unless otherwise
specified
}
protocols {
ospf { <- OSPF Protocol Configuration
inactive: traceoptions { <- Enable traceoptions for OSPF debugging
file ospf.txt;
flag state;
flag route;
flag general;
flag error detail;
}
area 0.0.0.0 { <-Defines OSPF Backbone area
interface lo0.0 {
passive; <- The passive keyword means networks on this interface will be advertised to the backbone area however
OSPF LSAs will not be forwarded out passive interfaces
}
interface vlan.1;
interface vlan.400 {
passive;
}
interface vlan.401 {

interface-type p2p;
}
interface vlan.402 {
passive;
}
interface vlan.403 {
passive;
}
interface vlan.404;
interface vlan.414 {
passive;
}
interface vlan.415 {
passive;
}
interface vlan.451 {
passive;
}
interface vlan.500 {
passive;
}
interface vlan.501 {
passive;
}
interface vlan.502 {
passive;
}
interface vlan.503 {
passive;

}
interface vlan.504 {
passive;
}
interface vlan.700 {
passive;
}
interface vlan.701 {
passive;
}
interface vlan.702 {
passive;
}
interface vlan.704 {
passive;
}
interface vlan.900 {
passive;
}
interface ge-4/0/23.0 {
interface-type p2p;
}
interface ge-2/0/47.0 {
interface-type p2p;
}
}
}
pim { <-enable Protocol Independent Multicast.
rp { <- Define the core as the multicast rendezvous point.

local {
family inet {
address 10.112.36.253;
}
}
}
interface lo0.0 {
mode sparse; <- specify PIM mode.
}
interface vlan.414 {
mode sparse;
}
interface vlan.500 {
mode sparse;
}
interface vlan.501 {
mode sparse;
}
interface vlan.502 {
mode sparse;
}
interface vlan.504 {
mode sparse;
}
interface vlan.900 {
mode sparse;
}
}
igmp-snooping { <- enable IGMP snooping

vlan all;
}
rstp {
bridge-priority 40k; <- set RSTP bridge priority
}
lldp { <- enable LLDP
interface ge-2/0/25.0;
interface ge-0/1/0.0;
}
lldp-med {<- enable LLDP-med
interface ge-2/0/25.0;
}
}
policy-options {
prefix-list mgmt-hosts { <- define management hosts used to restrict access to the router
10.8.31.0/25;
10.16.31.0/25;
10.22.66.128/25;
10.64.31.0/25;
10.112.36.0/24;
}
prefix-list snmp-hosts { <- define snmp hosts used to restrict snmp polling of the router
10.8.31.21/32;
10.8.31.24/32;
10.8.31.82/32;
}
prefix-list WAE-REDIRECT { <- define WAE hosts/clients used to forward traffic to the WAE
10.8.33.96/27;
10.16.32.64/28;

10.22.100.0/27;
10.64.10.192/26;
10.65.10.192/27;
}
}
firewall {
family inet {
filter protect_control_plane { <- define a filter to protect the router
term PERMIT-ESTABLISHED { <- allow established return traffic
from {
tcp-established;
}
then accept;
}
term PERMIT-SSH { <- allow ssh access to the device from specified hosts
from {
source-prefix-list {
mgmt-hosts;
}
destination-port ssh;
}
then accept;
}
term PERMIT-SNMP { <- allow SNMP polling
from {
source-prefix-list {
snmp-hosts;
}
protocol udp;

destination-port snmp;
}
then accept;
}
term PERMIT-PIM { <- allow PIM
from {
protocol pim;
}
then accept;
}
term PERMIT-IGMP { <- allow IGMP
from {
protocol igmp;
}
then accept;
}
term PERMIT-ICMP { <- allow ICMP
from {
protocol icmp;
}
then accept;
}
term PERMIT-SOURCE-UDP { <- allow UDP traffic from management hosts (ntp,dns,tacplus)
from {
source-prefix-list {
mgmt-hosts;
}
protocol udp;
source-port [ ntp domain tacacs ];

}
}
term PERMIT-SOURCE-TCP { <- allow NTP traffic from mgmt. hosts
from {
source-prefix-list {
mgmt-hosts;
}
protocol tcp;
source-port ntp;
}
then accept;
}
term PERMIT-TRACEROUTE { <- allow new style traceroute
from {
protocol udp;
destination-port 33434-33523;
}
then accept;
}
term PERMIT-NTP { <- allow inbound NTP traffic
from {
destination-port ntp;
}
then accept;
}
term PERMIT-DHCP { <- allow DHCP traffic
from {
destination-port dhcp;
}

then accept;
}
term PERMIT-OSPF { <- allow OSPF
from {
protocol ospf;
}
then accept;
}
term DEFAULT-DENY {
then {
discard;
}
}
}
filter REDIRECT-FROM-SERVER { <- Filter Based Forwarding filter used for WAE functionality applied on WAN
interfaces
term REDIRECT-FROM-SERVER {
from {
source-prefix-list {
WAE-REDIRECT;
}
source-port http;
}
then {
routing-instance WAE;
}
}
term default {
then accept;
}

}
filter REDIRECT-FROM-HOST { <- Filter Based Forwarding filter used for WAE functionality applied on LAN interfaces

term REDIRECT-FROM-HOST {
from {
destination-prefix-list {
WAE-REDIRECT;
}
destination-port http;
}
then {
routing-instance WAE;
}
}
term default {
then accept;
}
}
}
}
routing-instances {
WAE { <- define WAE routing instance
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.112.16.104; <- forward all traffic to WAE IP
}
}
}

}
ethernet-switching-options {
nonstop-bridging; <- maintain switching table state across all routing engines
}
vlans { <- define VLANS
VLAN0223 {
vlan-id 223;
}
default {
vlan-id 1;
l3-interface vlan.1; <- Define Layer 3 interface for VLAN
}
v11_wan_outside {
vlan-id 11;
}
v400_net_mmgt {
vlan-id 400;
l3-interface vlan.400;
}
v401_wan_inside {
vlan-id 401;
l3-interface vlan.401;
}
v402_serv_admin {
vlan-id 402;
l3-interface vlan.402;
}
v403_serv_ilo {
vlan-id 403;

l3-interface vlan.403;
}
v404_wan_wibnd {
vlan-id 404;
l3-interface vlan.404;
}
v414_video_strm_srv {
vlan-id 414;
l3-interface vlan.414;
}
v415_pcn_fw_tran {
vlan-id 415;
l3-interface vlan.415;
}
v450_dmz_security {
vlan-id 450;
}
v451_voip_srv {
vlan-id 451;
l3-interface vlan.451;
}
v452_security_inside2 {
vlan-id 452;
}
v500_admin_off_data {
vlan-id 500;
l3-interface vlan.500;
}
v501_pad_mcc_data {

vlan-id 501;
l3-interface vlan.501;
}
v502_trailer_data {
vlan-id 502;
l3-interface vlan.502;
}
v503_ctrlsys_mon {
vlan-id 503;
l3-interface vlan.503;
}
v504_trailer_cmplx_data {
vlan-id 504;
l3-interface vlan.504;
}
v700_admin_off_voice {
vlan-id 700;
l3-interface vlan.700;
}
v701_pad_mcc_voice {
vlan-id 701;
l3-interface vlan.701;
}
v702_trailer_voice {
vlan-id 702;
l3-interface vlan.702;
}
v704_trailer_cmplx_voice {
vlan-id 704;

l3-interface vlan.704;
}
v900_net_video {
vlan-id 900;
l3-interface vlan.900;
}
}
virtual-chassis { <- virtual chassis setup
preprovisioned; <- preposition virtual chassis members
no-split-detection; <- disable virtual chassis split detection
member 0 {
role routing-engine; <- allows member switch to be routing engine
serial-number BR0212231013;
location OldAdmin;
}
member 3 {
role routing-engine;
serial-number BR0212231003;
location RadioTower;
}
member 1 {
role line-card; <- member switch specified as a line-card (not eligible to become routing engine)
serial-number BR0212230957;
location OldAdmin;
}
member 2 {
role line-card;
serial-number FP0211492326;
location OldAdmin;

}
member 4 {
role line-card;
serial-number BR0212170699;
location RadioTower;
}
}

{master:0}[edit]
jtac@mr-z01-vc01-01-sw-core-a#

Corporate and Sales Headquarters


Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Phone: 888.JUNIPER (888.586.4737)
or 408.745.2000
Fax: 408.745.2100

APAC Headquarters
Juniper Networks (Hong Kong)
26/F, Cityplaza One
1111 Kings Road
Taikoo Shing, Hong Kong
Phone: 852.2332.3636
Fax: 852.2574.7803

EMEA Headquarters
Juniper(Networks(Ireland(
Airside(Business(Park((
Swords,(County(Dublin,(Ireland(
Phone:(35.31.8903.600(
EMEA(Sales:(00800.4586.4737(
Fax:(35.31.8903.601(

Copyright(2012(Juniper(Networks,(Inc.(All(rights(reserved.(Juniper(Networks,(the(Juniper(Networks(logo,(Junos,(NetScreen,(and(ScreenOS(are(registered(trademarks(of(Juniper(
Networks,(Inc.(in(the(United(States(and(other(countries.(All(other(trademarks,(service(marks,(registered(marks,(or(registered(service(marks(are(the(property(of(their(respective(
owners.(Juniper(Networks(assumes(no(responsibility(for(any(inaccuracies(in(this(document.(Juniper(Networks(reserves(the(right(to(change,(modify,(transfer,(or(otherwise(revise(this(
publication(without(notice.(