Low Level Design Review: Generated For: Suncor Project Name: Suncor (Mackay River) Generated On: August 9, 2012

Low Level Design Review
Generated For: Suncor

Project Name: Suncor (Mackay River)
Generated On: August 9, 2012
Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters

Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper(Networks(Ireland(
1194 North Mathilda Avenue 26/F, Cityplaza One Airside(Business(Park((
Sunnyvale, CA 94089 USA 1111 Kings Road Swords,(County(Dublin,(Ireland(
Phone: 888.JUNIPER (888.586.4737) Taikoo Shing, Hong Kong Phone:(35.31.8903.600(
or 408.745.2000 Phone: 852.2332.3636 EMEA(Sales:(00800.4586.4737(
Fax: 408.745.2100 Fax: 852.2574.7803 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( Activities Conducted to Understand Suncors Requirements ................................................................... 8(
1.2( Documentation Received to Understand Suncors Requirements ............................................................ 8(
1.3( Suncors Contact Information.................................................................................................................... 8(
1.4( Disclaimer(s) ............................................................................................................................................. 8(
2.( Understanding Suncors Proposed High Level Design ........................................................................ 9(
2.1( Description of Services to be Supported by the Network Infrastructure ................................................... 9(
2.2( Requirements Related to Class of Service and Quality of Service ........................................................... 9(
2.3( Requirements on Routing Policies ............................................................................................................ 9(
2.4( Scaling Requirements and Constraints..................................................................................................... 9(
2.5( Network Reliability Requirements ........................................................................................................... 10(
2.6( High Availability Requirements ............................................................................................................... 10(
2.7( Performance Requirements .................................................................................................................... 10(
2.8( Current Network Limitations.................................................................................................................... 10(
3.( General Network Design .................................................................................................................... 11(
3.1( Device Types and Roles ......................................................................................................................... 11(
3.2( 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( Classifier .......................................................................................................................................... 54(
5.1.2( Policer ............................................................................................................................................. 54(
5.1.3( Forwarding Class ............................................................................................................................ 54(
5.1.4( Congestion Management ................................................................................................................ 55(
5.1.5( Scheduler ........................................................................................................................................ 55(
5.1.6( Classification Rewrite ...................................................................................................................... 56(
5.1.7( 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 Author Date Reason for Change

Number
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 non-
disclosure 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.
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
1.2 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 File Name Provided to Juniper consultant on

Type (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.
Enterprise Network DATA Connectivity

Enterprise VOIP Telephony
HTTP/HTTPS Web Proxy Support
2.2 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.
The network must be positioned to support CoS/QoS in the future.

CoS/QoS will not be part of the initial deployment
2.3 Requirements on Routing Policies

This section documents the understanding and analysis for requirements related to routing policies.
Single OSPF Area in the Core

Filter Based Forwarding for web traffic redirection
2.4 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
Network must support geographical changes/growth
2.5 Network Reliability Requirements

This section documents understanding and analysis for network reliability requirements.
Device stability is critical due to remote location of network

Redundancy challenges related to limited Layer 1 infrastructure
2.6 High Availability Requirements

This section provides understanding and analysis on high availability requirements.
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)
2.7 Performance Requirements

This section provides understanding and analysis on the performance requirements.
Stability/Manageability is priority
Device configuration simplicity preferred over Performance tuning
Optimum cpu/memory utilization
2.8 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 Part Number

4 EX4200-24F
1 EX4200-48PX
ACCESS
QTY Part Number

33 EX4200-24PX
12 EX4200-48PX
3.2 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
NETWORK
USERS
Figure 1 - Mackay River Logical Diagram

CORE - Virtual Chassis
managed as single entity
(mr-z01-vc01-01-sw-core-a)
RADIO TOWER
vcp-1 vcp-0
4 3
vcp-0 vcp-1
OLD ADMIN
vcp-1 vcp-0 vcp-1 vcp-0

0 2 1
vcp-0 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 Field 2 Field 3 Field 4 Field 5 Field 6 Field 7
Building Sub- Device Device # of
Location Floor #
Code Building Type Function Units
Details
5 char 6 char 2 char 3 char 3 char 1 char
3 chars
max max max max max max
Examples
secw, fw, rt, pci,rsc,
sec, slp,
cgy, cvrl, cf, 01, sw, lb, dis, acc, a, b, c,
stav, rcn,
fmm, shawcb, 02,14, 17 rtf, wo, voi, vid, etc.
hp
slpb ups cor, osg
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 Description
ae 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.
ge 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.
gr Generic routing encapsulation (GRE) tunnel interface.
xe 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
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 Address
mr-z01-vc01-01-sw-cor-a 10.112.36.1
mr-z01-oldadm-01-sw-acc-a 10.112.36.248
mr-z01-vc02-01-sw-srv-a 10.112.36.247
mr-z01-vc03-01-sw-acc-a 10.112.36.245
mr-z01-mcc01-01-sw-acc-a 10.112.36.242
mr-z01-mcc02-01-sw-acc-a 10.112.36.241
mr-z01-mcc03-01-sw-acc-a 10.112.36.240
mr-z01-vc04-01-sw-acc-a 10.112.36.238
mr-z01-mcc04-01-sw-acc-a 10.112.36.237
mr-z01-mcc05-01-sw-acc-a 10.112.36.236
mr-z01-mcc06-01-sw-acc-a 10.112.36.235
mr-z01-mcc07-01-sw-acc-a 10.112.36.234
mr-z01-mcc08-01-sw-acc-a 10.112.36.233
mr-z01-mcc10-01-sw-acc-a 10.112.36.232
mr-z01-vc05-01-sw-acc-a 10.112.36.231
mr-z01-vc06-01-sw-acc-a 10.112.36.228
mr-z01-vc07-01-sw-acc-a 10.112.36.229
mr-z01-pad40-01-sw-acc-a 10.112.36.223
mr-z01-vc08-01-sw-acc-a 10.112.36.222
mr-z01-vc09-01-sw-acc-a 10.112.36.220
mr-z01-vc10-01-sw-acc-a 10.112.36.218
mr-z01-vc10-01-sw-acc-a 10.112.36.216
mr-z01-whs-01-sw-acc-a 10.112.36.211
mr-z01-camp-01-sw-acc-a 10.112.36.210
mr-z01-oldadm-01-sw-dmz-a 10.112.36.135
mr-z01-mcc10-01-sw-acc-a 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 L3
GATEWAY
vlan.400 10.112.36.1/24 VLAN L3
GATEWAY
vlan.402 10.112.19.1/26 VLAN L3
GATEWAY
vlan.403 10.112.19.65/26 VLAN L3
GATEWAY
vlan.414 10.112.16.97/27 VLAN L3
GATEWAY
vlan.415 10.112.17.1/29 VLAN L3
GATEWAY
vlan.451 10.112.16.33/27 VLAN L3
GATEWAY
vlan.500 10.112.20.1/24 VLAN L3
GATEWAY
vlan.501 10.112.21.1/24 VLAN L3
GATEWAY
vlan.502 10.112.22.1/24 VLAN L3
GATEWAY
vlan.503 10.112.18.1/25 VLAN L3
GATEWAY
vlan.504 10.112.23.1/24 VLAN L3
GATEWAY
vlan.700 10.112.24.1/24 VLAN L3
GATEWAY
vlan.701 10.112.25.1/24 VLAN L3
GATEWAY
vlan.702 10.112.26.1/24 VLAN L3
GATEWAY
vlan.704 10.112.27.1/24 VLAN L3
GATEWAY
vlan.900 10.112.28.1/27 VLAN L3
GATEWAY
ge-2/0/47 10.112.16.1/28 WAN UPLINK
ge-4/0/23 10.112.16.17/29 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 Type of Event or Error

any All (messages from all facilities)
authorization Authentication and authorization attempts
change-log Changes to the JUNOS configuration
conflict-log Configuration that is inconsistent with routing platform hardware
daemon Actions performed or errors encountered by various system processes
dfc Events related to dynamic flow capture
firewall Packet filtering actions performed by a firewall filter
ftp Actions performed or errors encountered by the FTP process
Commands issued at the JUNOS command-line interface (CLI) prompt or by a JUNOScript or
interactive-commands
NETCONF client application
kernel Actions performed or errors encountered by the JUNOS kernel
pfe Actions performed or errors encountered by the Packet Forwarding Engine
user 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 Description

any Includes all severity levels
none Disables logging of the associated facility to a destination
emergency System panic or other condition that causes the routing platform to stop functioning
alert Conditions that require immediate correction, such as a corrupted system database
critical Critical conditions, such as hard drive errors
Error conditions that generally have less serious consequences than errors in the emergency, alert, and
error
critical levels
warning Conditions that warrant monitoring
notice Conditions that are not errors but might warrant special handling
info 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"; ## SECRET-

DATA
user remote {
uid 2002;
class admin;
user tacgen {
uid 2000;
class admin;
authentication {
encrypted-password "$1$ukGQxC.E$ajBwitbuhhGGnsWINjf080"; ## SECRET-

DATA
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 {
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 {
mgmt-hosts;
protocol udp;
source-port [ ntp domain tacacs ];
term PERMIT-SOURCE-TCP {
from {
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 {
ether-options {
802.3ad ae0;
}
ae0 {
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 routing-
interfaces (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;
v402_serv_admin {
vlan-id 402;
v403_serv_ilo {
vlan-id 403;
v414_video_strm_srv {
vlan-id 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 {
unit 0 {
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 {
unit 0 {
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 non-
designated 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-to-
point 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#
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 action-
shutdown 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 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 routing-
instance 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-FROM-
SERVER
INET.0 WAE.INET.0 WAE DEVICE
FILTER REDIRECT-FROM-
HOST
ACCESS LAYER
WAE
ROUTING-INSTANCE
WAE TRAFFIC
INBOUND TRAFFIC
OTHER TRAFFIC MAIN
ROUTING-INSTANCE
Figure 7 - Filter Based Forwarding Overview

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 {
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 {
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 {
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 {
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. If the RID is manually configured, use that value

2. If no RID is manually configured, use the IP address configured on the loopback interface
3. If no IP address is configured on a loopback interface, use the highest IP address configured on a physical interface
4. 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-type p2p;
passive;
passive;
passive;
passive;
passive;
passive;
passive;
passive;
passive;
}
passive;
passive;
passive;
passive;
passive;
passive;
interface-type p2p;
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. Classifier
2. Policer
3. Forwarding Class
4. Congestion Management
5. Scheduler
6. Classification Rewrite
7. 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
Troubleshoot Extended Virtual Chassis configurations
http://www.juniper.net/techpubs/en_US/junos11.4/topics/example/virtual-chassis-ex4200-multiple-wiring-
closets.html
Resolution Guide - EX - Troubleshoot Dynamic Host Configuration Protocol
Resolution Guide - EX - Troubleshoot Spanning Tree Protocol (STP)
JUNOS For IOS Engineers
http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/junos-for-ios-
engineers/
!
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;
passive;
interface-type p2p;
passive;
passive;
interface vlan.404;
passive;
passive;
passive;
passive;
passive;
passive;
passive;
}
passive;
passive;
passive;
passive;
passive;
passive;
interface-type p2p;
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.
mode sparse;
mode sparse;
mode sparse;
mode sparse;
mode sparse;
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;
lldp-med {<- enable LLDP-med
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 {
mgmt-hosts;
destination-port ssh;
then accept;
term PERMIT-SNMP { <- allow SNMP polling
from {
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 {
mgmt-hosts;
protocol udp;
source-port [ ntp domain tacacs ];

}
term PERMIT-SOURCE-TCP { <- allow NTP traffic from mgmt. hosts
from {
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 {
WAE-REDIRECT;
source-port http;
then {
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 {
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;
v401_wan_inside {
vlan-id 401;
v402_serv_admin {
vlan-id 402;
v403_serv_ilo {
vlan-id 403;
v404_wan_wibnd {
vlan-id 404;
v414_video_strm_srv {
vlan-id 414;
v415_pcn_fw_tran {
vlan-id 415;
v450_dmz_security {
vlan-id 450;
v451_voip_srv {
vlan-id 451;
v452_security_inside2 {
vlan-id 452;
v500_admin_off_data {
vlan-id 500;
v501_pad_mcc_data {
vlan-id 501;
v502_trailer_data {
vlan-id 502;
v503_ctrlsys_mon {
vlan-id 503;
v504_trailer_cmplx_data {
vlan-id 504;
v700_admin_off_voice {
vlan-id 700;
v701_pad_mcc_voice {
vlan-id 701;
v702_trailer_voice {
vlan-id 702;
v704_trailer_cmplx_voice {
vlan-id 704;
v900_net_video {
vlan-id 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;
location RadioTower;
member 1 {
role line-card; <- member switch specified as a line-card (not eligible to become routing engine)
location OldAdmin;
member 2 {
role line-card;
serial-number FP0211492326;
location OldAdmin;
}
member 4 {
role line-card;
location RadioTower;
{master:0}[edit]
jtac@mr-z01-vc01-01-sw-core-a#
Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters

Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper(Networks(Ireland(
1194 North Mathilda Avenue 26/F, Cityplaza One Airside(Business(Park((
Sunnyvale, CA 94089 USA 1111 Kings Road Swords,(County(Dublin,(Ireland(
Phone: 888.JUNIPER (888.586.4737) Taikoo Shing, Hong Kong Phone:(35.31.8903.600(
or 408.745.2000 Phone: 852.2332.3636 EMEA(Sales:(00800.4586.4737(
Fax: 408.745.2100 Fax: 852.2574.7803 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.(

Low Level Design Review: Generated For: Suncor Project Name: Suncor (Mackay River) Generated On: August 9, 2012

Uploaded by

Copyright:

Available Formats

You might also like

Low Level Design Review: Generated For: Suncor Project Name: Suncor (Mackay River) Generated On: August 9, 2012

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Low Level Design Review: Generated For: Suncor Project Name: Suncor (Mackay River) Generated On: August 9, 2012

Uploaded by

Copyright:

Available Formats

Low Level Design Review

Generated For: Suncor

Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters

2012 Juniper Networks, Inc. Page 1 of 81

Document Version Control .......................................................................................................................... 5(

Who Should Read this Report ..................................................................................................................... 6(

Alphabetical Index of Terms ........................................................................................................................ 6(

Intellectual Property Rights ......................................................................................................................... 6(

1.( Introduction .......................................................................................................................................... 7(

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

Tables and Figures

Figure 1 - Mackay River Logical Diagram ............................................................................................ 12(

Author: James Austin

Version Author Date Reason for Change

Who Should Read this Report

Alphabetical Index of Terms

Intellectual Property Rights

Document Objective and Scope

Project Name Suncor MacKay River EX Refresh

Juniper has performed the following activities to collect the requirements.

Initial scoping call with Suncor: 31-May-12

1.2 Documentation Received to Understand Suncors Requirements

Document File Name Provided to Juniper consultant on

Name Email Phone Number

Network design other than for Juniper Network Elements

2.1 Description of Services to be Supported by the Network Infrastructure

Enterprise Network DATA Connectivity

2.2 Requirements Related to Class of Service and Quality of Service

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

2.3 Requirements on Routing Policies

Single OSPF Area in the Core

2.4 Scaling Requirements and Constraints

Network to be installed in remote location

2.5 Network Reliability Requirements

Device stability is critical due to remote location of network

2.6 High Availability Requirements

Non-stop bridging (Virtual Chassis)

2.7 Performance Requirements

2.8 Current Network Limitations

Current network devices are at or nearing End of Life

3.1 Device Types and Roles

QTY Part Number

QTY Part Number

3.2 Network Architecture Overview

CORE - VIRTUAL CHASSIS

only 2 access switches

Figure 1 - Mackay River Logical Diagram

vcp-1 vcp-0 vcp-1 vcp-0

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

Figure 3 - JUNOS Architecture

4.3 JUNOS Software

The initial network is deployed with JUNOS 11.4R3.7.

Table 3 - DNS Configuration

Table below explains the existing Suncor naming convention:

Suncor Network Naming Convention Standard (except Datacenters)

MKY MacKay River

4.7.2 Loopback Addressing

Suncor Mackay River Network was deployed without Loopback Addresses.