Low Level Design Review - · PDF file09.08.2012 · HLD High Level Design ... following documents were referred to as part of the low level design review service delivery process:

© 2012 Juniper Networks, Inc. Page 1 of 81

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

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

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

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

Low Level Design Review

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

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 Suncor’s Requirements ................................................................... 8(1.2( Documentation Received to Understand Suncor’s Requirements ............................................................ 8(1.3( Suncor’s Contact Information .................................................................................................................... 8(1.4( Disclaimer(s) ............................................................................................................................................. 8(

2.( Understanding Suncor’s 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 Number

Author Date Reason for Change

0.1 James Austin August 15, 2012 Initial Draft

0.2 James Austin August 23, 2012 Added RSTP Configuration Recommendations

0.3 James Austin August 26, 2012 Added Diagrams 1.0 James Austin Sept. 4, 2012 Clean Up

Preface This document provides a Low Level Design for the integration of Juniper Networks products into Suncor’s 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 Suncor’s 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 Suncor’s existing high level design document as a part of Mackay River Upgrade Project. It contains a detailed low level design for the integration of Juniper’s products into Suncor’s 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 Suncor’s teams. Document Objective and Scope The main objective of this document is to document a low level design for Suncor’s 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 Suncor’s 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 Suncor’s Requirements

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

Document Type

File Name Provided to Juniper consultant on (Date)

Hardware List MacKay River BoM with spares.xls 26-July-2012 Diagram MacKay River Fiber Layout.vsd 26-July-2012 Design Document MacKayRiverNetworkDesign.doc 26-July-2012 Diagram MacKayRiverNetworkDesignAll4200s.vsd 26-July-2012 Hardware List MacKay River Summary BoM v1.0.xlsx 26-July-2012

Table 1 - Suncor Documentation 1.3 Suncor’s 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 [email protected] 403-296-6395 Nashaat Mansi, Solution Designer [email protected] 403-296-8555 Noel Dodd, Project Manager [email protected] 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 Suncor’s Proposed High Level Design Juniper and Suncor together have conducted a review of Suncor’s 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 Suncor’s 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 Suncor’s 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

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.

QTY Part Number 33 EX4200-24PX 12 EX4200-48PX

OSPF AREA 0

Legacy WAN

CORE - VIRTUAL CHASSIS5 member - EX4200 managed

as single entity

LOGICAL Overview

L3 Gateways (RVI)

ACCESSLayer 2 (802.1Q)

only 2 access switches drawn for clarity

IPIP NETWORK USERS

Figure 1 - Mackay River Logical Diagram

34

2 10

RADIO TOWER

OLD ADMIN

CORE - Virtual Chassismanaged as single entity

(mr-z01-vc01-01-sw-core-a)

vcp-1

vcp-1vcp-0

vcp-0

vcp-0

vcp-0 vcp-0vcp-1

vcp-1

vcp-1

Dedicated Virtual Chassis Link

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

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

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 Juniper‘s 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 down—providing 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

Location Building Code

Sub-Building Floor # Device

Type Device

Function # of Units

Details

3 chars 5 char max

6 char max

2 char max

3 char max

3 char max

1 char max

Examples

cgy, fmm,

sec, slp, stav, rcn,

hp

secw, cvrl, cf, shawcb,

slpb

01, 02,14, 17

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

ups

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

a, b, c, etc.

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

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 agent’s 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 {

vlan.702 10.112.26.1/24 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

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

interactive-commands Commands issued at the JUNOS command-line interface (CLI) prompt or by a JUNOScript or 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 Error conditions that generally have less serious consequences than errors in the emergency, alert, and 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 router’s 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 router’s 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. Suncor’s 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 { source-prefix-list { snmp-hosts; } protocol udp; destination-port snmp; } then accept;

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

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

then accept; } term DEFAULT-DENY { then { discard; } } } }

Table 16 - Control Plane Filter Configuration 4.9 Interface Configuration

4.9.1 ACCESS-CORE Interfaces IEEE 802.3ad link aggregation enables you to group Ethernet interfaces at the physical layer to form a single link layer interface, also known as a link aggregation group (LAG) or bundle. For more information, see IEEE Standard 802.3ad, Link Aggregation. The Link Aggregation Control Protocol (LACP) is a mechanism for exchanging port and system information to create and maintain LAG bundles. The LAG bundle distributes MAC clients across the link layer interface and collects traffic from the links to present to the MAC clients of the LAG bundle.

To create the links in the LAG bundles, you can add one or more Ethernet physical interfaces to it. The LACP detects Ethernet interfaces as links if they are configured on the same line module and have the same physical layer characteristics. The LACP also assigns to the LAG bundle the same MAC address of the Ethernet link with the highest port priority, which is the lowest value.

The LACP also controls the exchange of LACP protocol data units (PDUs) between the Ethernet links in the LAG bundle. The PDUs contain information about each link and enable the LAG bundle to maintain them.

By default, Ethernet links do not exchange PDUs, which contain information about the state of the link. You can configure Ethernet links to actively transmit PDUs, or passively transmit them, sending out LACP PDUs only when it receives them from another link. The transmitting link is known as the Actor and the receiving link is known as the Partner.

In the Suncor Mackay River network, access switches connect to the CORE via 802.3AD Aggregated Ethernet Interfaces. LACP is configured as the control mechanism for the AE links. 802.1Q trunks are configured over the Aggregated Ethernet Interfaces. The following configuration template is provided for reference.

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

ether-options { 802.3ad ae0; } } ae0 { description <description>; aggregated-ether-options { lacp { active; } } unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; } } } }

Table 17 - Core Interface Configuration 4.9.2 CORE RVI Interfaces To segment traffic on a LAN into separate broadcast domains, you create separate virtual LANs (VLANs). VLANs limit the amount of traffic flowing across the entire LAN, reducing the possible number of collisions and packet retransmissions within the LAN. For example, you might want to create a VLAN that includes the employees in a department and the resources that they use often, such as printers, servers, and so on.

Of course, you also want to allow these employees to communicate with people and resources in other VLANs. To forward packets between VLANs you normally you need a router that connects the VLANs. However, you can accomplish this forwarding on a switch without using a router by configuring a routed VLAN interface (RVI). Using this approach reduces complexity and avoids the costs associated with purchasing, installing, managing, powering, and cooling another device.

An RVI is a special type of Layer 3 virtual interface named vlan. Like normal Layer 3 interfaces, the vlan interface needs a logical unit number with an IP address. In fact, to be useful an RVI needs at least two logical units and two IP addresses—you 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; l3-interface vlan.400; } v402_serv_admin { vlan-id 402; l3-interface vlan.402; } v403_serv_ilo { vlan-id 403; l3-interface vlan.403; } v414_video_strm_srv { vlan-id 414; l3-interface vlan.414; }

Table 20 - VLAN Configuration 4.10.2 Assigning Physical interfaces to VLANs The VLAN tag is a 4 byte tag inserted into Ethernet frames and is used to consistently associate traffic with a particular VLAN. The individual frames must be tagged as they are passed throughout a network. When assigning a VLAN to a port on the switch, the user can assign either of the following modes:

Access mode - also known as untagged mode: This mode is used to connect network devices, such as desktop computers, IP telephones, printer, and file

servers. The port receives and transmits untagged Ethernet frames from the network devices. This mode is the default mode for all ports. Example of switch port configuration in the access mode:

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

Table 21 - Access Port Configuration

Trunk mode - also known as tagged mode :

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

ge-4/0/21 { description <description>; unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; }

Table 22 - Trunk Port Configuration In the Suncor Mackay River Network, both modes are used. Uplinks from the Access Layer to the CORE are configured as trunks. VOIP devices that are non-LLDP capable are also serviced via ports configured as trunks. Devices that are not VLAN aware or participate in only a single VLAN are serviced via access mode interfaces. 4.10.3 RSTP Juniper Networks EX Series Ethernet Switches provide Layer 2 loop prevention through Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), and VLAN Spanning Tree Protocol (VSTP). The default factory configuration for EX Series switches uses RSTP. If your network includes 802.1D 1998 bridges, you can explicitly configure STP. Note that when doing so, the EX Series switches use the IEEE 802.1D 2004 specification, force version 0, which is an RSTP configuration that is compatible with basic STP. If you use VLANs, we recommend that you enable MSTP unless your network requires the device compatibility provided by VSTP.

RSTP is an evolution of the STP IEEE 802.1D protocol designed to provide faster spanning tree re-convergence after a switch port, switch, or LAN failure. STP takes up to 50 seconds to respond to topology changes while RSTP responds to changes within the timeframe of three hello BPDUs (Bridge Protocol Data Units), or 6 seconds. RSTP calculates the spanning tree in the same manner as STP, but re-convergence after a connectivity failure works differently. The key difference between STP and RSTP is that the latter does not use timers (rather a handshake) to transition between port states and roles.

A port’s state determines how it processes a frame. A port’s 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:

• Discarding—The 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.

• Learning—The 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.

• Forwarding—The 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 port—The 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 port—The 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 port—A 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 port—A 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 port—The 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# set interface ge-0/0/6 edge user@switch#

Table 23 - RSTP Edge Port Configuration

4.10.4 storm-control A traffic storm is generated when messages are broadcast on a network and each message prompts a receiving node to respond by broadcasting its own messages on the network. This, in turn, prompts further responses, creating a snowball effect. The LAN is suddenly flooded with packets, creating unnecessary traffic that leads to poor network performance or even a complete loss of network service. Storm control enables the switch to monitor traffic levels and to drop broadcast and unknown unicast packets when a specified traffic level—called the storm control level—is 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 interface ge-0/0/5 edge user@switch# set interface ge-0/0/6 edge user@switch# set bpdu-block-on-edge

Table 25 - bpdu-block configuration 4.11 Routing

4.11.1 Filter Based Forwarding For IPv4, IPv6, or MPLS-tagged IPv4 traffic only, you can use stateless firewall filters in conjunction with forwarding classes and routing instances to control how packets travel in a network. This is called filter-based forwarding (FBF).

You can define a filtering term that matches incoming packets based on source address and then classifies matching packets to a specified forwarding class. This type of filtering can be configured to grant certain types of traffic preferential treatment or to improve load balancing. To configure a stateless firewall filter to classify packets to a forwarding class, configure a term with the nonterminating action forwarding-class class-name.

You can also define a filtering term that directs matching packets to a specified routing instance. This type of filtering can be configured to route specific types of traffic through a firewall or other security device before the traffic continues on its path. To configure a stateless firewall filter to direct traffic to a routing instance, configure a term with the terminating action 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

INET.0 WAE.INET.0

FILTER REDIRECT-FROM-HOST

WAE DEVICE

FILTER REDIRECT-FROM-SERVER

ACCESS LAYER

INBOUND TRAFFICWAE TRAFFIC

OTHER TRAFFIC MAIN ROUTING-INSTANCE

WAE 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 { source-prefix-list { WAE-REDIRECT; } source-port http; } then { routing-instance WAE; } } term default { then accept; } } filter REDIRECT-FROM-HOST { term REDIRECT-FROM-HOST { from { destination-prefix-list { WAE-REDIRECT; } destination-port http; } then {

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

Table 27 - FBF Firewall Filter Configuration Application of the firewall filters on the WAN facing interfaces

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

no-auto-negotiation; link-mode full-duplex; speed { 100m; } } unit 0 { family inet { filter { input REDIRECT-FROM-SERVER; } address 10.112.16.17/29; } } }

Table 28 - FBF WAN Filter Application Application of the REDIRECT-FROM-HOST firewall filter on LAN facing interfaces (only 1 shown for clarity)

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

Table 29 - FBF LAN Filter Application 4.11.2 Static Routing The Suncor Mackay River Network also provides WAN connectivity for Suncor’s 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 vlan.401 { interface-type p2p; } interface vlan.402 {

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

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

}

Table 31 - OSPF Configuration 4.12 Network Services

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

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

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

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

server 10.112.19.57; server 10.146.96.22; }

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

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

5. Class of Service The Suncor Mackay River Network does not currently use CoS. The data here is provided for reference purposes. This section contains a discussion of the seven components of the JUNOS class of service architecture: 1. 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 packet’s 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 packet’s class of service. The next-hop can be an IP address, and interface, or an LSP.

6. Troubleshooting Resources Juniper Networks maintains an extensive searchable database of documentation for all platforms. Please visit http://support.juniper.net Below are some examples of the documentation available which is relevant to the Suncor Mackay River network. Resolution Guide - EX - Verify/Troubleshoot VLAN interface http://kb.juniper.net/InfoCenter/index?page=content&id=KB22220 Resolution Guides - EX - Troubleshoot/Verify Interface http://kb.juniper.net/InfoCenter/index?page=content&id=KB22217 Troubleshoot Extended Virtual Chassis configurations http://www.juniper.net/techpubs/en_US/junos11.4/topics/example/virtual-chassis-ex4200-multiple-wiring-closets.html Resolution Guide - EX - Troubleshoot Dynamic Host Configuration Protocol http://kb.juniper.net/InfoCenter/index?page=content&id=KB23335 Resolution Guide - EX - Troubleshoot Spanning Tree Protocol (STP) http://kb.juniper.net/InfoCenter/index?page=content&id=KB22774 JUNOS For IOS Engineers http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/junos-for-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; interface vlan.400 { passive; } interface vlan.401 {

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

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

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

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

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

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

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

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

} filter REDIRECT-FROM-HOST { <- Filter Based Forwarding filter used for WAE functionality – applied on LAN interfaces term REDIRECT-FROM-HOST { from { destination-prefix-list { WAE-REDIRECT; } destination-port http; } then { routing-instance WAE; } } term default { then accept; } } } } routing-instances { WAE { <- define WAE routing instance instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop 10.112.16.104; <- forward all traffic to WAE IP } } }

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

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

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

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

} member 4 { role line-card; serial-number BR0212170699; location RadioTower; } } {master:0}[edit] jtac@mr-z01-vc01-01-sw-core-a# !

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

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

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

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

Documents

Low Level Design Review - · PDF file09.08.2012 · HLD High Level Design ... following documents were referred to as part of the low level design review service delivery process: