Internet Edge Implementation Guide

Implementation Guide

NEW NETWORK PLATFORM ARCHITECTURE:

WAN

Internet edge ImplementatIon guIde

2 Copyright © 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Key assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

routing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Failure Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Symmetric and predictable routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

protocol operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Border routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Business Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

achieving primary Business Consideration—Strict primary and Secondary topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

achieving Secondary Business Consideration—First layer of defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

SrX Series Security devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Business consideration: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Zone definitions in SrX3400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

trust zone configuration: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

untrust configuration: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Core and dmZ—third layer of defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

dmZ: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

products and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

appendix a—traffic Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

appendix B—Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

mX80-1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

mX80-2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

SrX3400 Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

about Juniper networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Copyright © 2012, Juniper networks, Inc. 3


List of FiguresFigure 1: test topology simulating Internet edge with dedicated primary (ISp1) and secondary (ISp2). . . . . . . . . . . . . . . . . .7

Figure 2: Box highlights the border (ISp interfacing) router connecting with the two ISps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 3: SrX Series security devices in a cluster connected to mX80 routers and the core using oSpF . . . . . . . . . . . . . . . 15

Figure 4: eX Series virtual instance representing the core of the network and connected to SrX Series

cluster using oSpF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 5: eX Series virtual instance representing the dmZ and connected using static routes to the

SrX Series cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 6: ISp1 failure causes traffic to flow through ISp2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 7: mX80-1 failure causes traffic to flow through mX80-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 8: IrB failure on mX80-1 causes traffic to flow through mX80-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 9: Failure of the reth.0 interface causes outbound traffic to use the SrX3400-2 data plane. . . . . . . . . . . . . . . . . . . 26

Figure 10: active SrX3400-1 node failure causes all traffic to route through the SrX3400-2 to ISp1 . . . . . . . . . . . . . . . . . 27

List of Tablestable 1. Source of advertised routes and ISp preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

table 2. overview of SrX Series Security policies Implemented to Control access, with associated nat policies . . . . . .16

table 3: products with Software releases, part numbers, and licensing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24



Introductionthe Internet edge acts as the enterprise’s gateway to the Internet. It provides connectivity to the Internet for data

center, campus, and branch offices, and it connects remote workers, customers, and partners to enterprise resources.

It can also be used to provide backup connectivity to the Wan for branch offices, in case the primary connection to the

enterprise Wan fails.

today’ s Internet edge must enable access to a variety of applications such as cloud computing solutions, mission

critical applications, and bandwidth hungry applications such as video. the Internet edge must also scale seamlessly

to support growing application performance and bandwidth needs, while supporting a rich set of routing and security

features.

this implementation guide will help network designers create a simplified Internet edge solution using Juniper

networks® mX Series 3d universal edge routers, SrX Series Secure Services gateways, and eX Series ethernet

Switches. It details specific design considerations, best practices, and Juniper tools that can be used to build the

optimal solution. this guide concludes with a real-world deployment example that illustrates the solution and

recommended configurations in detail.

Scopethis Internet edge implementation guide discusses design concepts and articulates implementation details to help

Wan architects and engineers deploy an Internet edge solution. although the specific implementation will vary, the

fundamental building blocks provided here can help accelerate any deployment.

the guide has been structured to include the following sections:

• target audience: describes organizations that will find this document applicable and recommended readers.

• Key assumptions: the Internet edge solution described in this document makes several assumptions about deployment

details, which are described in this section.

• design Considerations: the most important design considerations such as routing, security, resiliency, and quality of

service (QoS) that must be addressed in designing an Internet edge deployment are summarized here. this section

describes the factors driving the need for these considerations and provides a high-level background applicable to the

solution described in this document.

• protocol operation: this section details some of the important protocols that are enabled in this Internet edge design.

the specific uses of these protocols are also described here.

• Implementation: this section details the actual implementation of the Internet edge. It starts with a high-level overview

of the topology and business considerations, which is followed by a more detailed explanation of the three parts of the

topology (border routers, security devices, and core and dmZ). the detailed explanation of each section highlights the

best practices and configuration.

• appendices: appendix a and B provide traffic behavior detail and actual configuration code.

Target Audiencethis guide is well suited for organizations that are:

• designing robust, highly scalable, and resilient Internet edge infrastructure

• Simplifying management by consolidating devices and eliminating single purpose devices in the Internet edge

• Improving security within the Internet edge solution

this guide serves as a reference tool for the following audience:

• network engineers

• network architects

• Security managers

• System test engineers



Key Assumptionsthis guide assumes that:

• the Internet edge topology consists of at least two Internet facing routers. Smaller designs that consist of only one

Internet edge router are special cases of the design also described here. In some cases, such smaller designs do not use

Bgp to peer with Internet service providers (ISps).

• the two ISps do not share the same ISp link or intermediate carriers; this is to ensure that at least one of the carriers is

always available.

• the topology described here is based on several medium-sized campus and data center networks and is assumed to be

applicable to similar deployments.

• the Internet edge deployment is considered separate from the Wan deployment.

• the Bgp local preference values for the ISps is as listed below:

Note: For more scope information, see Caveats section later in this guide.

Table 1. Source of Advertised Routes and ISP Preferences

Source of Advertised Routes

ISP Preference

Customer 400

peer 300

Design Considerationsthere are many design considerations for an Internet edge deployment. Some of these are highlighted below (please

note that an exhaustive discussion on these considerations is beyond the scope of this guide).

Routing Considerationsenterprises are driven by trade-offs among many objectives when designing their routing topologies. the most

common trade-offs center around the following objectives:

• Improve resiliency

• reduce cost

• Improve performance

• Improve utilization

other considerations include predictable performance by ensuring that outbound and inbound traffic flows use the

same path. the weighting of these objectives affect how enterprises design their inbound and outbound routing

topologies.

there are three main routing policy categories: topology-driven, primary-secondary, and load-shared routing. In this

solution guide, the design uses a strict primary-secondary topology.

these topologies are briefly explained below.

• Topology-driven routing policy—this form of routing policy is optimized to maximize performance and utilization of links.

In this routing policy, all routes are accepted without attribute modification. thus, the Bgp path selection algorithm looks

at factors such as Bgp path length, multiple exit discriminator (med), interior gateway protocol (Igp) metric, etc., in that

order, to determine the best route. When two Bgp paths are of the same length, then the med attribute is evaluated. In

case multiple Bgp paths are still tied, the nearest exit is chosen and Igp metrics are subsequently evaluated.

• Primary/secondary routing policy—this Internet edge architecture is designed to reduce cost and improve resiliency.

therefore, these networks have designated primary (actively used) and secondary (standby) ISp connections. Such

a topology is referred to as strict primary-secondary. Some topologies use the secondary ISp connections for specific

routes, also known as loose primary-secondary routing. Such deployments are a trade-off between cost and resiliency

versus the additional flexibility gained by sending specific traffic through the secondary links.

• Load shared routing policy—With this policy, the Internet edge architecture is optimized for optimal utilization. It

designates a large range of routes to each ISp connection. When designing this routing topology, it is important to pay

particular attention to failure scenarios in any ISp link, as such failures will result in all traffic falling back to a surviving

ISp link and this may result in performance degradation. a more dynamic load shared routing scheme will involve routing

based on a variety of metrics such as bandwidth over the ISp that advertises the most preferable route to the destination.



other factors that can influence routing topology include:

• routing policies such as local preference adopted by the ISps.

• type of ISp (tier 1, tier 2, etc.). For instance, a tier 1 ISp will have a shorter route than a tier 2 service provider and hence

may be preferred by the Internet edge routers.

a common question that arises in many Internet edge deployments is when do we use full Bgp feeds? the answer

depends on the specific use of these routes. one use case of a full Bgp feed may be in a load shared routing topology.

In such a topology, ISp routers need to dynamically transmit over several possible routes, using a variety of metrics

learned from the ISps. a full Bgp feed will allow the Internet edge to choose the best possible route.

Security Considerationsan Internet edge is the gateway to the Internet and therefore must be designed to protect corporate resources from

attacks. to improve protection, Juniper recommends using multiple layers of security such as:

• protect against distributed denial of service (ddoS) using firewall filters

• guard against malicious traffic using firewalls on the security devices

• minimize compromising all infrastructure using separate logical tiers for routing and security

• prevent leaking internal traffic using SrX Series zones and non-routable Ip addresses

• prevent exposure of internal Ip addresses and firewall to the external world using network address translation (nat)

this Internet edge deployment incorporates the above described security best practices. the SrX Series security

cluster is configured to restrict traffic using various security policies. the devices also have nat enabled to perform

destination nat and secure nat (dnat and Snat). the Juniper networks mX80 3d universal edge router

complements the security enabled in the SrX Series with firewall filters. In addition to these, the network topology is

architected to enhance security in every way possible.

Failure ConsiderationSymmetric and Predictable RoutingWhen designing their Internet edge network topologies, enterprises must not only consider normal operations but must

also consider failure conditions and subsequent behavior upon restoration from failure. For instance, when a primary ISp

link fails (in primary-secondary routing policy), ingress and egress traffic gets routed through the secondary link. upon

restoration of the ISp link, the ingress and egress traffic must switch to the primary link. the Internet edge deployment

highlights this best practice. to understand traffic flow under several failure conditions, please refer to appendix a.

Quality of ServiceSince traffic is sent to the Internet, QoS is not implemented on egress traffic. For ingress traffic, QoS is deployed inside

the enterprise network. For this reason, this Internet edge deployment does not detail specific QoS configurations. the

dmZ houses many externally accessible services such as the domain name System (dnS), Http, and Ftp servers, to

name a few.

Protocol Operationthere are several protocols enabled in this Internet edge design, which include:

OSPF: the Igp protocol of choice in our implementation is oSpF. oSpF is enabled internally in the topology, divided

into two areas: the backbone area, area 0, which exchanges routes between the core and the SrX Series security

devices; and area 1, which is used to advertise summary routes to the ISp interfacing routers from the security devices.

note that oSpF can exchange routes between areas, and for this reason we rely on security devices to control any

traffic exchange between the oSpF areas. alternatively, we could have used oSpF in the core and IS-IS to advertise

routes to ISp interfacing routers from the security devices.

EBGP: eBgp is enabled between Bgp peers that belong to two different autonomous Systems (aS). In this validation,

we enabled eBgp between the Internet facing routers (mX80) and the ISp routers. the ISps internally peer using eBgp.

IBGP: IBgp is used to peer between Bgp peers that belong to the same aS. It uses the loopback address of the

routers so that any failure on the links does not impact the protocol. the IBgp peers need not be neighbors. In our

implementation, we have enabled IBgp between the mX80 routers purely to illustrate alternate topology.

Redundant Ethernet (reth): link aggregation groups (lags) can be established across nodes in a chassis cluster. link

aggregation allows a redundant ethernet interface (known as a reth interface in ClI commands) to add multiple child

interfaces from both nodes and thereby create a redundant ethernet interface lag. these are logical interfaces that

are assigned to physical links on an SrX Series cluster (redundant nodes)

Integrated routing and bridging (IRB): an IrB interface acts as a layer 3 routing interface for a bridge domain. the IrB

interface, in this solution, is used for interfacing the mX Series with the reth interface on the SrX Series.



Implementationthis section describes the Internet edge implementation highlighting different best practices for the topology and the

associated configuration. the implementation is divided into the following sections:

1. Border routers

2. Security devices

3. Core and dmZ

In each section, we will cover the associated important configuration, the best practices, and any variations to the

topologies that are observed in the field.

Figure 1: Test topology simulating Internet edge with dedicated primary (ISP1) and secondary (ISP2).

Figure 1 shows the Internet edge deployment of a small campus or data center. the ISp interfacing router, mX80-1, is

connected to the ISp1, and mX80-2 is connected to ISp2 using eBgp. ISp1 is the primary and ISp2 is the secondary; this

implies that all traffic is sent and received using the primary ISp, by default, and when ISp1 becomes unreachable, ISp2

is used. mX80-1 and mX80-2 are connected to each other using IBgp links over an aggregate ethernet ae interface

(ae1 on each mX Series router). the mX80 routers are connected to the clustered SrX Series devices using oSpF. the

mX80-1 and SrX Series cluster interface with irb.0 and reth0.0. the mX80-2 and SrX Series cluster interface with

irb.0 and reth1.0. the SrX Series cluster operates in active/standby mode. Figure 1 also shows the eX Series virtual

instances representing the dmZ and the core of the network. the dmZ is connected to the SrX Series cluster using

static routes, and the core is connected to the SrX Series using oSpF.

In order to ensure that we have very predictable performance and simplified debugging, we recommend using symmetric

routing. our topology uses symmetric routing so that outbound and inbound traffic flow using the same path.

We will examine this topology below in greater detail.

MX80-2AS100

Defaultroutes

advertised

ISP2AS500

(EX Seriesvirtual instance)

Irb.0172.28.30.5

iBGP

Area 1

Area 0 Static Routes

ae1ge-1/1/4ge-1/1/5

172.28.30.91.1.1.1

ge-1/0/03.3.3.1

ge-1/0/0

3.3.3.21.1.1.2ge-0/0/21.0 ge-0/0/22.0

eBGP

eBGP

eBGP

ge-1/0/5

ge-1/0/4ge-1/0/3

ge-1/0/2

ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2

ge-0/0/6

ge-0/0/0ge-0/0/1

ge-0/0/4ge-0/0/5

ge-8/0/7ge-8/0/6ge-0/0/7

ae1ge-1/1/4ge-1/1/5

172.28.30.10

reth1.0172.28.30.6

Irb.0172.28.30.1

SRX Series reth2.0172.28.30.13

EX Series vlan.5172.28.30.14



10.10.10.0/24Vlan.10

11.11.11.1

reth0.0172.28.30.2

ISP1AS300


ISPinterfacingrouter

SecurityDevices

Core & DMZ

MX80-1AS100

SRX3400-2SRX3400-1

EX4200DMZ

(virtual instance)

Defaultroutes

advertised

EX4200Core

(virtual instance)



Border Routersthe border (ISp interfacing) routers route Internet traffic to and from the core network and dmZ.

Business Considerations • the primary business consideration of a strict primary and secondary topology is to minimize cost and improve resiliency.

Cost is minimized because the customer incurs most of the cost only for a single dedicated link. Customers can also

benefit from improved traffic resiliency, with minimal loss of critical user traffic, by failing over to a standby link.

• Secondary business consideration is to protect the core of the network from security attacks from the Internet, since the

border router acts as the first layer of defense.

Figure 2: Box highlights the border (ISP interfacing) router connecting with the two ISPs

Before we examine how the two business considerations are accomplished, let’s understand the border router topology

highlighted by the box in Figure 2. there are two mX80 routers (mX80-1 and mX80-2) that are connected using an

IBgp link. the mX80-1 is connected to ISp1 (primary ISp), and mX80-2 is connected ISp2 (secondary ISp) using eBgp.

Achieving Primary Business Consideration—Strict Primary and Secondary Topologyoutbound routing with ISp1 as primary:

In this section, we will examine how to achieve strict primary-secondary configuration for outbound traffic from the

Internet edge. In the strict primary-secondary topology, mX80-1 and mX80-2 accept default routes (0.0.0.0/0) from

ISp1 and ISp2. accepting default routes from ISps also ensures that the Internet edge is not used as a transit point for

ISp1 to ISp2 traffic. note that there are other ways of preventing the Internet edge from becoming a transit point for

ISp1 to ISp2 traffic, such as using filters to prevent the two mX Series routers from advertising ISp learned routes to

each other.

MX80-2AS100

Defaultroutes

advertised

ISP2AS500


Irb.0172.28.30.5

iBGP

Area 1


ae1ge-1/1/4ge-1/1/5

172.28.30.91.1.1.1

ge-1/0/03.3.3.1

ge-1/0/0

3.3.3.21.1.1.2ge-0/0/21.0 ge-0/0/22.0

eBGP

eBGP

eBGP

ge-1/0/5

ge-1/0/4ge-1/0/3

ge-1/0/2

ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2

ge-0/0/6

ge-0/0/0ge-0/0/1

ge-0/0/4ge-0/0/5

ge-8/0/7ge-8/0/6ge-0/0/7

ae1ge-1/1/4ge-1/1/5

172.28.30.10

reth1.0172.28.30.6

Irb.0172.28.30.1





10.10.10.0/24Vlan.10

11.11.11.1

reth0.0172.28.30.2

ISP1AS300



SecurityDevices

Core & DMZ

MX80-1AS100

SRX3400-2SRX3400-1

EX4200DMZ

(virtual instance)

Defaultroutes

advertised

EX4200Core

(virtual instance)



MX80-1:

protocols { bgp { traceoptions { file bgp.log; flag all; } group isp1 { type external; import [ localpref-80 default-only ]; authentication-key “$9$9c0zt0IylMNdsEcds24DjCtu”; ## SECRET-DATA export ebgp-out; neighbor 1.1.1.2 { local-address 1.1.1.1; peer-as 300; } } :}

policy-options { : policy-statement default-only { term match-default { from { route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; } } : policy-statement localpref-80 { then { local-preference 80; } } :}

the above configuration snippet (in red) shows the setting for influencing the outbound routing. Setting the local

preference value to 80 ensures that ISp1 is the preferred outbound route. mX80-2 will set a lower value for local

preference, i.e., 70 (see below for details).

note that for the purpose of this implementation guide, the setting of local preference value to influence outbound

routing is not required and is illustrated here purely for purposes of future extension. the local preference setting,

as illustrated here, is useful when mX80-1 and mX80-2 advertise ISp routes to each other using the IBgp links. For

instance, mX80-2 will send outbound traffic that it receives from the SrX Series to mX80-1 over the IBgp link rather

than directly to ISp2 (assuming the destination is reachable over the ISp2 link and all other conditions are favorable).

However, in this implementation guide we only accept default routes from both ISps, and we influence the outbound

traffic using Igp metrics (as discussed below). We also enforce strict primary-secondary, with no traffic between the

two mX Series routers using the IBgp link. as long as mX80-1 and ISp1 are active, all traffic will be sent to mX80-1.

upon failure of ISp1 traffic, mX80-1 stops advertising the default routes and traffic will be sent to mX80-2.



MX80-2:

protocols { bgp { group isp2 { type external; import [ localpref-70 default-only ]; authentication-key “$9$eshMLNs2aikPdbkP5Q9CKM8”; ## SECRET-DATA export ebgp-out; bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; } neighbor 3.3.3.2 { local-address 3.3.3.1; peer-as 500; } } :}

the outbound routing configuration also needs to influence the outbound traffic from SrX Series to mX Series to prefer

the link to mX80-1, since ISp1 is the preferred primary. to ensure that this occurs, we set the Igp metric to 20 on the

irb.0 interface between mX80-2 and the SrX Series cluster. the Igp metric on the IrB interface between mX80-1 and

the SrX Series cluster has the default value of 0. therefore, as long as the link between the Juniper networks SrX3400

Services gateway (SrX3400-1) and mX80-1 is active, the SrX3400-1 will send traffic to mX80-1.

policy-statement default-to-ospf { term accept { from { protocol bgp; route-filter 0.0.0.0/0 exact; state active; } then { metric 20; accept; } } term reject { then reject; }}

protocols { : :



ospf { export default-to-ospf; import ospf-reject-default; area 0.0.0.1 { interface irb.0 { bfd-liveness-detection { minimum-interval 300; full-neighbors-only; } } interface lo0.0; } }}

Inbound routing with ISP1 as primary:

We have seen the configuration for outbound routing in the mX80 routers using ISp1 as the dedicated primary. next, we

will examine how to influence the inbound traffic to use ISp1 as the dedicated primary.

as previously explained, in routing considerations the actual behavior is subject to the ISp’s own unique routing policies

and what customer settings are accepted by the ISp.

MX80-2:

policy-options { : policy-statement ebgp-out { term term1 { from { route-filter 60.60.60.0/24 exact; } then { local-preference 200; as-path-prepend “100 100”; accept; } } term reject { then reject; } } :}

the code snippet above shows the local preference and as-path-prepend values that are necessary to ensure that ISp2

is the secondary ISp for inbound routes. the local preference is set to a value lower than what the ISp2 will assign to

customer advertised routes, causing ISp2 to prefer routes advertised by its peer. Further, the aS-patH prepend ensures

that ISp2 will favor peer routes because mX80-2 advertised routes are longer than that advertised by the ISp peers.

the aS-patH length advertisement is necessary to ensure that ISp2 will continue to be the secondary ISp for inbound

routes even after recovery from any failures in the ISp network.

the ISp interfacing routers also play a critical role as the first layer of defense in a layered defense approach to protect

the rest of the enterprise network from the Internet.



Achieving Secondary Business Consideration—First Layer of DefenseSecuring and protecting against denial of service (doS) attacks:

to prevent attacks against the Internet edge network, mX Series routers are configured with re-protect firewall filters.

the filter is used to prevent small packet attacks, fragments, and floods of traffic from specific protocols such as ICmp,

Bgp, oSpF, Snmp, udp, and tCp. the filter is applied to the loopback interface of the mX Series router, and it applies

to traffic destined for the router and not transit traffic. thus, to protect against Ip fragment attacks used to circumvent

l4-l7 filters transiting these routers, other filters must be set up.

these are shown below:

MX80-1:

interfaces {:lo0 { unit 0 { family inet { filter { input re-protect; f re-protect filter applied to loopback interface } address 127.0.0.1/32; } } }:}

firewall { family inet { filter re-protect { interface-specific; term small-packets { f Prevent Small Packet Attack from { packet-length 0-24; } then { count small-packet-attack; log; discard; } } term fragment-packets { from { f Prevent Fragment DOS (non-initial) fragment-offset-except 0; protocol [ icmp igmp pim tcp ]; } then { count frag-attack; log; discard; } } term icmp-in { from { source-prefix-list { f Accept from white list.Police incoming ICMP



trusted-networks; } protocol icmp; } then { policer limit-2m; count icmp-in; accept; } } term bgp-in { from { source-prefix-list { trusted-bgp-peer; } protocol tcp; port bgp; } then { policer limit-2m; count bgp-in; accept; } } term ospf-in { from { source-prefix-list { trusted-ospf-neighbor; } protocol ospf; } then { policer limit-2m; count ospf-in; accept; } } term snmp-in { from { source-prefix-list { trusted-networks; } protocol udp; port snmp; } then { policer limit-2m; count snmp-in; accept; } } term access-in {f Control access from trusted networks from { source-prefix-list { trusted-networks; }



from { source-prefix-list { trusted-networks; } protocol tcp; port [ ssh ftp ftp-data ]; } then { count access-in; accept; } } term udp-services { from { source-prefix-list { trusted-networks; } protocol udp; source-port 1024-65535; } then { policer limit-2m; count udp-in; accept; } } : : term deny-all { then { count illegal-traffic-in; log; discard; } } } : : } policer limit-2m { f Policer definition to limit traffic to 2Mb with 500K burst if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; } then discard; }}



SRX Series Security Devices Business consideration: the primary requirement of security devices is to protect the corporate network from attacks from the Internet.

Figure 3: SRX Series security devices in a cluster connected to MX80 routers and the core using OSPF

Before we examine how the business requirement is accomplished, let’s understand the network setup for the security

devices. the SrX Series devices (highlighted by the box in Figure 3) are connected together in an active/standby mode

cluster configuration, which enables device-level resiliency. this guide does not use the SrX Series in an active/active

mode.

the SrX Series is connected to the mX Series using reth and is an area border router (aBr) that advertises routes

(using area 1) to mX Series routers. the backbone area (area 0) is between the core and the SrX Series cluster. the

core area router (or routers) interfacing with the SrX Series is expected to summarize routes before advertising them

to SrX Series Services gateways.

the SrX3400 cluster is connected to the eX Series virtual instance, simulating the core using reth2.0. the core of

the network is denoted by 10.10.10.0/24 subnet. the SrX Series cluster is connected to an eX Series virtual instance

that simulates the dmZ, using reth3.0. the dmZ is denoted by the 11.11.11.0/24 subnet. oSpF area 0 is between the

SrX Series cluster and the eX Series core virtual instance. the concerns about leaking internal core routes to area 1

are addressed using strict security policies that control access between the zones. the dmZ is linked to SrX Series

gateways using static routes (most dmZs are small enough to do this). Further, static routes are an additional layer of

protection that are used to avoid leaking routes between the different zones.

MX80-2AS100

Defaultroutes

advertised

ISP2AS500


Irb.0172.28.30.5

iBGP

Area 1


ae1ge-1/1/4ge-1/1/5

172.28.30.91.1.1.1

ge-1/0/03.3.3.1

ge-1/0/0

3.3.3.21.1.1.2ge-0/0/21.0 ge-0/0/22.0

eBGP

eBGP

eBGP

ge-1/0/5

ge-1/0/4ge-1/0/3

ge-1/0/2

ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2

ge-0/0/6

ge-0/0/0ge-0/0/1

ge-0/0/4ge-0/0/5

ge-8/0/7ge-8/0/6ge-0/0/7

ae1ge-1/1/4ge-1/1/5

172.28.30.10

reth1.0172.28.30.6

Irb.0172.28.30.1





10.10.10.0/24Vlan.10

11.11.11.1

reth0.0172.28.30.2

ISP1AS300



SecurityDevices

Core & DMZ

MX80-1AS100

SRX3400-2SRX3400-1

EX4200DMZ

(virtual instance)

Defaultroutes

advertised

EX4200Core

(virtual instance)



Achieving Business Consideration: Securing Traffic to and from the Core and DMZ—Second Layer of Defensethe primary function of the SrX Series security device is to control access to the core and dmZ. the SrX Series also

performs source and destination nat. the nat functionality is used to not only translate internal private Ip addresses

but also to hide the internal network addresses from attacks. thus, SrX Series gateways add multiple additional layers

of defense.

Table 2. Overview of SRX Series Security Policies Implemented to Control Access, with Associated NAT Policies

Source ISP Preference NAT

Core (trust zone) Internet (area 1, a.k.a. untrust zone) Source nat

Internet (area 1, a.k.a. untrust zone) dmZ destination nat

Core (trust zone) dmZ none

Core (trust zone) Core (trust zone) none

table 2 shows the different firewall policies that are set up to control access between the different zones. the table

also indicates the different nat policies that hide internal Ip addresses, providing an additional layer of security. It

should be noted that the nat policies are not set up for access between the core and dmZ because nat-level security

is not necessary for traffic within the network. We will examine the configuration relevant to table 2 in detail below.

SRX3400:

policies { from-zone trust to-zone untrust { policy outbound-access { match { source-address trust; f Traffic is from trust zone destination-address any; f Traffic is destined to any address application outbound-apps; f Access is from specified apps } then { permit; f Traffic is Permitted log { session-init; session-close; } count; } } } from-zone untrust to-zone dmz { policy untrust-to-dmz { match { source-address any; f Traffic is from any address(internet) destination-address 11.11.11.1/32;f Traffic destined to DMZ services application dmz-services; ;f Permit only specific DMZ applications } then { permit; f Traffic is Permitted, if all conditions satisfied log { session-close; } count; } }



} from-zone trust to-zone dmz { policy trust-to-dmz { match { source-address trust; f Traffic is from core destination-address 11.11.11.1/32; f Traffic destined to DMZ application [ junos-ping junos-http junos-ftp ]; } then { permit; log { session-close; } count; } } } from-zone trust to-zone trust { policy trust-to-trust { match { source-address any;f Traffic from any source address in trust zone destination-address any;f Traffic to any destn. address in trust zone application any; } then { permit { application-services { idp; } } } } :::applications { application-set outbound-apps { application junos-http; application junos-https; application junos-ping; } application-set dmz-services { application junos-ping; application junos-ssh; application junos-ftp; application junos-https; }}

the above configuration represents the access restrictions shown in table 2. the traffic is permitted as long as it is

from the designated source to the specific destination and is from one of the permitted applications. to illustrate

this point, see the policy outbound-access under from-zone trust to-zone untrust. Here, application traffic (Http.

HttpS, and ICmp echo) from the core to any Internet destination is permitted. Similar reasoning holds for other

security policies. note that the dmZ applications that can be accessed can also be controlled by adding or deleting the

applications specified under dmz-services in the applications configuration. all other traffic is blocked.



Zone Definitions in SRX3400We have seen the different restrictions imposed on the inter-zone traffic and the associated configuration. now let’s

examine the configuration of the trust, untrust, and dmZ zones. Zone configuration, in this topology, includes the

following items:

• addresses that are included in the zone

• Interfaces that are part of the trust zone

• Services and protocols supported on the interface in the zone

Trust zone configuration:

zones { security-zone trust { address-book { address trust 10.10.10.0/24; } interfaces { reth2.0 { host-inbound-traffic { system-services { ping; } protocols { ospf; bfd; } } } } }

Untrust configuration:

security-zone untrust { screen untrust-screen; interfaces { reth0.0 { host-inbound-traffic { system-services { ping; } protocols { ospf; bfd; } } } reth1.0 { host-inbound-traffic { system-services { ping; } protocols { ospf; bfd; } } } } }



The untrust zone includes all traffic inbound from reth0.0 and reth1.0. These two reth interfaces are on the OSPF Area 1 and enable the OSPF and BFD protocol packets in the untrust zone. The untrust zone configuration also uses the untrust-screen to enable intrusion detection service (IDS), as shown in the security configuration below. Here, DoS attack prevention is enabled (ICMP, IP, and TCP).

security { : : screen { ids-option untrust-screen { icmp { ping-death; } ip { source-route-option; tear-drop; } tcp { syn-flood { alarm-threshold 1024; attack-threshold 200; source-threshold 1024; destination-threshold 2048; timeout 20; } : } :

}

DMZ zone configuration:

security-zone dmz { address-book { address 60.60.60.0/24 60.60.60.0/24; address 11.11.11.1/32 11.11.11.1/32; address 60.60.60.10/32 60.60.60.10/32; address 11.11.11.10/32 11.11.11.10/32; } interfaces { reth3.0 { host-inbound-traffic { system-services { ping; } } } } }

the configuration for security-zone dmZ shows several addresses in the address book. the address book for

a security zone contains the Ip address or domain names of hosts and subnets whose traffic is either allowed,

blocked, encrypted, or user authenticated. For our purpose, the addresses are those for which traffic is allowed. the

60.60.60.0/24 is the subnet address for nat. the 60.60.60.10 address is the specific nat address for hiding the dmZ

11.11.11.1 address. the 11.11.11.10/32 is not currently used by this topology.

the reth3.0 interface is connected to the eX Series virtual instance simulating the dmZ, and it supports the system-

services of ICmp echo.



NAT definitions: let’s examine the configuration and usage of nat in more detail.

Security {:: nat { traceoptions { file nat.log; flag all; } source { pool outbound-nat {f NAT address pool range for ISP traffic address { 60.60.60.50/32 to 60.60.60.100/32; } } rule-set source-nat { from zone trust; to zone untrust; rule trust-nat { match {f Applies SNAT on traffic leaving core source-address 10.10.10.0/24; } then { source-nat { pool { outbound-nat; } } } } } } destination { pool dmz-server1 {f NAT address pool range for ISP traffic address 11.11.11.1/32; } rule-set dmz-server1-rule { from zone untrust; rule one-to-one { match {f Applies DNAT on DMZ bound traffic from internet destination-address 60.60.60.10/32; } then { destination-nat pool dmz-server1; } }

}

}

}

the Internet edge implementation uses Source nat (Snat) to mask internal Ip addresses from the core of the

network. the nat addresses here are taken from an nat pool of 50 specified addresses. the Snat is applied to all

traffic from the core (trust zone) to the Internet (untrust zone).

all traffic destined for dmZ from the Internet (untrust zone) will have a destination address of 60.60.60.10. note: the

60.60.60.10 address is assumed to be a well-known address in the Internet. therefore all dmZ bound traffic will trigger

a match with the destination address and translation to the 11.11.11.1 address, which is the dmz-server1 dnat pool. note

that we advertised the 60.60.60.0/24 subnet to the ISp in the mX80 routing configuration.



Core and DMZ—Third Layer of Defensethe core and dmZ can enable the third layer of defense by using additional firewall filters and private Ip addresses.

Coremost Internet edge deployments connect to a core such as the campus core or data center core. the core is the nerve

center of the network and is the gateway to most sensitive information. the layered security that we have seen so far

is designed to protect the core infrastructure. most deployments use the core to configure the QoS policies and add

additional policing and security capabilities.

Figure 4: EX Series virtual instance representing the core of the network and connected to SRX Series cluster using OSPF

the core, which is highlighted by the box in Figure 4, is represented here to model different components connected to

the Internet edge. We do not attempt to model the core in detail. this implementation guide represents the core of the

network using a Juniper networks eX4200 ethernet Switch virtual instance. the configuration shown below highlights

this key configuration representing the core.

EX4200 configuration:

routing-instances { core { instance-type virtual-router; f virtual instance interface vlan.5; f VLAN interface connecting to SRX cluster interface vlan.10; f VLAN interface connecting to core protocols { ospf { import no-dmz-prefix-in-core-routing-instance; area 0.0.0.0 {f OSPF backbone connects core to SRX cluster

MX80-2AS100

Defaultroutes

advertised

ISP2AS500


Irb.0172.28.30.5

iBGP

Area 1


ae1ge-1/1/4ge-1/1/5

172.28.30.91.1.1.1

ge-1/0/03.3.3.1

ge-1/0/0

3.3.3.21.1.1.2ge-0/0/21.0 ge-0/0/22.0

eBGP

eBGP

eBGP

ge-1/0/5

ge-1/0/4ge-1/0/3

ge-1/0/2

ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2

ge-0/0/6

ge-0/0/0ge-0/0/1

ge-0/0/4ge-0/0/5

ge-8/0/7ge-8/0/6ge-0/0/7

ae1ge-1/1/4ge-1/1/5

172.28.30.10

reth1.0172.28.30.6

Irb.0172.28.30.1





10.10.10.0/24Vlan.10

11.11.11.1

reth0.0172.28.30.2

ISP1AS300



SecurityDevices

Core & DMZ

MX80-1AS100

SRX3400-2SRX3400-1

EX4200DMZ

(virtual instance)

Defaultroutes

advertised

EX4200Core

(virtual instance)



interface vlan.10; interface vlan.5 { bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; full-neighbors-only; } } } } } }

the configuration shows a core virtual routing instance in the eX4200. the virtual router enables oSpF with SrX3400

in the backbone area (area 0). Vlan.5 connects to the SrX Series cluster and vlan.10 is part of the core subnet. We also

enable Bidirectional Forwarding detection (BFd) protocol for rapid detection of failures.

DMZ:In most Internet edge deployments, the dmZ houses the Web servers, Ftp servers, dnS servers, etc. larger dmZs often

include server load balancers. the dmZ is protected by a firewall.

Figure 5: EX Series virtual instance representing the DMZ and connected using static routes to the SRX Series cluster

MX80-2AS100

Defaultroutes

advertised

ISP2AS500


Irb.0172.28.30.5

iBGP

Area 1


ae1ge-1/1/4ge-1/1/5

172.28.30.91.1.1.1

ge-1/0/03.3.3.1

ge-1/0/0

3.3.3.21.1.1.2ge-0/0/21.0 ge-0/0/22.0

eBGP

eBGP

eBGP

ge-1/0/5

ge-1/0/4ge-1/0/3

ge-1/0/2

ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2

ge-0/0/6

ge-0/0/0ge-0/0/1

ge-0/0/4ge-0/0/5

ge-8/0/7ge-8/0/6ge-0/0/7

ae1ge-1/1/4ge-1/1/5

172.28.30.10

reth1.0172.28.30.6

Irb.0172.28.30.1





10.10.10.0/24Vlan.10

11.11.11.1

reth0.0172.28.30.2

ISP1AS300



SecurityDevices

Core & DMZ

MX80-1AS100

SRX3400-2SRX3400-1

EX4200DMZ

(virtual instance)

Defaultroutes

advertised

EX4200Core

(virtual instance)



our implementation of Internet edge dmZ, which is represented by the box in Figure 5, involves an eX Series virtual

instance. In a more realistic representation, the eX4200 virtual instance would be replaced by an eX4200 ethernet

Switch with Virtual Chassis technology acting as access switch and connected to the SrX Series using Igp or static

routes. For larger deployments, a server load balancer (SlB) is used to redirect traffic between the access devices.

In Figure 5, the dmZ is connected to the SrX Series cluster using static routes connected to the SrX Series reth3.0 on

vlan.6. this is representative of a smaller deployment with fewer servers and switches in the dmZ. Some customers

prefer static routes because that limits the chance of leaking routes between the rest of the network and the dmZ. In

our implementation, dmZ services such as Ftp are represented by the Ip address 11.11.11.1 connected to the eX4200 on

vlan.11. We also simulate Ftp services using this address.

Below is the configuration for the dmZ virtual instance. the virtual instance has services such as Ftp and SSH enabled,

and can thus be used to simulate a real dmZ.

dmz { instance-type virtual-router; f virtual instance interface vlan.6; f interface connecting to SRX cluster interface vlan.11; f DMZ services routing-options { static { route 0.0.0.0/0 next-hop 172.28.30.17; f Static route to SRX cluster } } }

vlans { SRX3400-vlan { vlan-id 5; l3-interface vlan.5; } core-vlan { vlan-id 10; l3-interface vlan.10; } dmz-services { vlan-id 11; l3-interface vlan.11; } dmz-vlan { vlan-id 6; l3-interface vlan.6; }}



Caveats• the test topology does not simulate a real multi-carrier network. For instance, a real carrier network might have many

different ISps (both tier 1 and/or tier 2) that are interconnected and have their own routing policies. Simulating such a

network, and failures and recovery within this type of ISp network, is beyond the scope of this document.

• an exhaustive setup for doS prevention is not detailed or validated in the document.

Products and Software

Table 3: Products with Software Releases, Part Numbers, and Licensing Information

Product Software Release Part number License

mX80-48t(2) 10.4r7.5 mX80-48t-aC Base

SrX3400(2) 11.4r2.14 SrX3400BaSe-aC,SrX3K-16ge-SFp,

SrX3K-Crm,SrX3K-npC,

SrX3K-re-12-10

Base

eX4200 10.4r5.5 eX4200-48p Base and eX-48-aFl (advanced feature license)

Summaryas enterprises rely on the Internet edge to provide access to cloud computing applications, mission critical

applications, and video feeds, they need a network that can seamlessly scale for increasing application performance

and bandwidth needs, while at the same time supporting a rich set of routing and security features. the Juniper

solution described in this guide is designed with these objectives in mind. It will enable customers to drastically reduce

deployment time and minimize errors by using the steps and best practices described in this guide, as well as the

architecture guidelines and validated configurations outlined within.



Appendix A—Traffic Behavior

Figure 6: ISP1 failure causes traffic to flow through ISP2

Figure 6, shows that when ISp1 fails, all outbound traffic will flow through ISp2 from SrX3400-1, when its data plane is

active, to mX80-2 and to ISp2. Inbound traffic will follow the same path back.

Figure 7: MX80-1 failure causes traffic to flow through MX80-2

In Figure 7, we see what happens when mX80-1 fails. the traffic from SrX3400-1 will flow directly to mX80-2 and out

to ISp2. Inbound traffic will follow the same path.


Securitydevices

Core & DMZ

MX80-1

ISP2

MX80-2

reth.0

SRX3400-1 SRX3400-2

EX4200virtual instance


CORE DMZ

IRB.0

ISP1


Securitydevices

Core & DMZ

MX80-1

ISP2

MX80-2

reth.0

SRX3400-1 SRX3400-2



CORE DMZ

IRB.0

ISP1



Figure 8: IRB failure on MX80-1 causes traffic to flow through MX80-2

In Figure 8, IrB.0 logical interface failure on mX80-1 will cause all traffic to flow through mX80-2, while SrX3400 and

mX80-1 lose reachability.

Figure 9: Failure of the reth.0 interface causes outbound traffic to use the SRX3400-2 data plane

In Figure 9, IrB.0 logical interface failure on mX80-1 will cause all traffic to flow through mX80-2. SrX3400 and mX80-1

lose reachability.


Securitydevices

Core & DMZ

MX80-1

ISP2

MX80-2

reth.0

SRX3400-1 SRX3400-2



CORE DMZ

IRB.0

ISP1


Securitydevices

Core & DMZ

MX80-1

ISP2

MX80-2

reth.0

SRX3400-1 SRX3400-2



CORE DMZ

IRB.0

ISP1



Figure 10: Active SRX3400-1 node failure causes all traffic to route through the SRX3400-2 to ISP1

In Figure 10, we see what happens when SrX3400-1 fails. note that this can be a complete failure or data plane failure

that can be affected using commands such as redundancy group 1 failover (does not affect routing engine failover).

please see the references section for more information about SrX Series failover best practices.


Securitydevices

Core & DMZ

MX80-1

ISP2

MX80-2

reth.0

SRX3400-1 SRX3400-2



CORE DMZ

IRB.0

ISP1



Appendix B—ConfigurationsBelow is a complete configuration from the deployment featured in this guide. note that the eX4200 configuration

includes all of the virtual instances representing ISp1, ISp2, core, and dmZ.

MX80-1 Configuration

## Last changed: 2012-04-09 14:48:36 UTCversion 10.4R7.5;system { host-name NYCD-MX80-48T-1; root-authentication { encrypted-password “$1$T7VMtd4Z$QWE45ZLVEjD7Gbw/fuQzw.”; ## SECRET-DATA } login { user juniper { uid 2000; class super-user; authentication { encrypted-password “$1$y55tvJET$8we6weqLNf/B4PcKcKBbp.”; ## SECRET-DATA } } user lhunt { uid 2001; class super-user; authentication { encrypted-password “$1$c868xtVv$MZKVd0ArvtcuIpahtLf7w1”; ## SECRET-DATA } } } services { ftp; ssh; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}chassis { aggregated-devices { ethernet { device-count 4; } }}interfaces {



ge-1/0/0 { unit 0 { description “connection to ISP1”; family inet { address 1.1.1.1/24; } } } ge-1/0/1 { unit 0; } ge-1/0/2 { description “connection to SRX Reth0.0”; mtu 1500; encapsulation ethernet-bridge; unit 0 { family bridge; } } ge-1/0/3 { description “connection to SRX Reth0.0”; mtu 1500; encapsulation ethernet-bridge; unit 0 { family bridge; } } ge-1/1/4 { gigether-options { 802.3ad ae1; } } ge-1/1/5 { gigether-options { 802.3ad ae1; } } ae1 { unit 0 { family inet { filter { input t; } address 172.28.30.9/30; } } } fxp0 { unit 0 { family inet { address 172.25.113.66/24; } } } irb { mtu 1500;



unit 0 { family inet { address 172.28.30.1/30; } } } lo0 { unit 0 { family inet { filter { input re-protect; } address 127.0.0.1/32; } } }}routing-options { static { route 172.16.0.0/12 next-hop 172.25.113.1; inactive: route 60.60.60.0/24 { inactive: discard; } } router-id 172.28.30.1; autonomous-system 100;}protocols { bgp { traceoptions { file bgp.log; flag all; } group isp1 { type external; import [ localpref-80 default-only ]; authentication-key “$9$9c0zt0IylMNdsEcds24DjCtu”; ## SECRET-DATA export ebgp-out; neighbor 1.1.1.2 { local-address 1.1.1.1; peer-as 300; } } group internal { type internal; export ibgp-nhs; neighbor 172.28.30.10 { local-address 172.28.30.9; inactive: export prefer-ibgp; } } } ospf { traceoptions { file ospf.log; flag event detail;



flag all; } export default-to-ospf; import ospf-reject-default; area 0.0.0.1 { interface irb.0 { bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; full-neighbors-only; } } } }}policy-options { prefix-list trusted-networks { 1.1.1.1/32; 1.1.1.2/32; 10.10.10.0/24; 172.16.0.0/12; 172.25.112.0/24; } prefix-list trusted-bgp-peer { 1.1.1.2/32; 172.28.30.10/32; } prefix-list trusted-ospf-neighbor { 172.28.30.2/32; } prefix-list bfd-out { 172.28.30.1/32; } prefix-list bfd-in { 172.28.30.2/32; } policy-statement default-only { term match-default { from { route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; } } policy-statement default-to-ospf { term accept { from { protocol bgp; route-filter 0.0.0.0/0 exact; state active; } then accept; }



term reject { then reject; } } policy-statement ebgp-out { term advertise { from { route-filter 60.60.60.0/24 exact; } then accept; } term reject { then reject; } } policy-statement ibgp-nhs { term next-hop-self { then { next-hop self; } } } policy-statement localpref-80 { then { local-preference 80; } } policy-statement ospf-reject-default { term ospf-reject { from { protocol ospf; route-filter 0.0.0.0/0 exact; } then reject; } term accept { then accept; } }}firewall { family inet { filter re-protect { interface-specific; term small-packets { from { packet-length 0-24; } then { count small-packet-attack; log; discard; } } term fragment-packets { from { fragment-offset-except 0;



protocol [ icmp igmp pim tcp ]; } then { count frag-attack; log; discard; } } term icmp-in { from { source-prefix-list { trusted-networks; } protocol icmp; } then { policer limit-2m; count icmp-in; accept; } } term bgp-in { from { source-prefix-list { trusted-bgp-peer; } protocol tcp; port bgp; } then { policer limit-2m; count bgp-in; accept; } } term ospf-in { from { source-prefix-list { trusted-ospf-neighbor; } protocol ospf; } then { policer limit-2m; count ospf-in; accept; } } term snmp-in { from { source-prefix-list { trusted-networks; } protocol udp; port snmp; } then {



policer limit-2m; count snmp-in; accept; } } term access-in { from { source-prefix-list { trusted-networks; } protocol tcp; port [ ssh ftp ftp-data ]; } then { count access-in; accept; } } term udp-services { from { source-prefix-list { trusted-networks; } protocol udp; source-port 1024-65535; } then { policer limit-2m; count udp-in; accept; } } term loopback-in { from { source-address { 127.0.0.1/32; } destination-address { 127.0.0.1/32; } } then { count loopback-in; accept; } } term ssh-out { from { source-address { 1.1.1.1/32; } destination-address { 1.1.1.2/32; } protocol tcp; port ssh;



} then accept; } term bfd { from { inactive: source-prefix-list { bfd-out; } inactive: destination-prefix-list { bfd-in; } protocol udp; source-port 49152-65335; destination-port 3784-3785; } then { count accept-bfd; accept; } } term deny-all { then { count illegal-traffic-in; log; discard; } } } filter t { term 1 { from { protocol tcp; } then { log; accept; } } } } policer limit-2m { if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; } then discard; }}bridge-domains { SRX3400 { domain-type bridge; vlan-id 10; interface ge-1/0/2.0; interface ge-1/0/3.0; routing-interface irb.0; }}



MX80-2 Configuration

## Last changed: 2012-04-06 22:47:23 UTCversion 10.4R1.9;system { host-name NYCD-MX80-48T-2; root-authentication { encrypted-password “$1$AjTQIoH.$5.eIAhSNZcEoBRSLlERGv1”; ## SECRET-DATA } login { user juniper { uid 2000; class super-user; authentication { encrypted-password “$1$TJxwe5o6$1VabGZHDoW.7Wn1ug54IU0”; ## SECRET-DATA } } user lhunt { uid 2001; class super-user; authentication { encrypted-password “$1$1thYXi.k$weFHxV3NcRDCBlKiSeqtH/”; ## SECRET-DATA } } } services { ftp; ssh; telnet; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}chassis { aggregated-devices { ethernet { device-count 4; } }}interfaces { ge-1/0/0 { unit 0 { description “connection to ISP2”; family inet {



address 3.3.3.1/24; } } } ge-1/0/4 { description “connection to SRX Reth1.0”; mtu 1500; encapsulation ethernet-bridge; unit 0 { family bridge; } } ge-1/0/5 { description “connection to SRX Reth1.0”; mtu 1500; encapsulation ethernet-bridge; unit 0 { family bridge; } } ge-1/1/4 { gigether-options { 802.3ad ae1; } } ge-1/1/5 { gigether-options { 802.3ad ae1; } } ae1 { unit 0 { description “connection to mx80-1”; family inet { address 172.28.30.10/30; } } } fxp0 { unit 0 { family inet { address 172.25.113.67/24; } } } irb { mtu 1500; unit 0 { family inet { address 172.28.30.5/30; } } } lo0 { unit 0 { family inet {



filter { input re-protect; } address 127.0.0.1/32; } } }}routing-options { static { route 172.16.0.0/12 next-hop 172.25.113.1; inactive: route 70.70.70.0/24 discard; } autonomous-system 100;}protocols { bgp { group isp2 { type external; import [ localpref-70 default-only ]; authentication-key “$9$eshMLNs2aikPdbkP5Q9CKM8”; ## SECRET-DATA export ebgp-out; bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; } neighbor 3.3.3.2 { local-address 3.3.3.1; peer-as 500; } } group internal { type internal; local-address 172.28.30.10; export ibgp-nhs; neighbor 172.28.30.9; } } ospf { export default-to-ospf; import ospf-reject-default; area 0.0.0.1 { interface irb.0 { bfd-liveness-detection { minimum-interval 300; full-neighbors-only; } } interface lo0.0; } }}policy-options { prefix-list trusted-networks { 3.3.3.1/32; 3.3.3.2/32;



10.10.10.0/24; 172.16.0.0/12; 172.25.112.0/24; } prefix-list trusted-bgp-peer { 3.3.3.2/32; 172.28.30.9/32; } prefix-list trusted-ospf-neighbor { 172.28.30.6/32; } policy-statement default-only { term match-default { from { route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; } } policy-statement default-to-ospf { term accept { from { protocol bgp; route-filter 0.0.0.0/0 exact; state active; } then { metric 20; accept; } } term reject { then reject; } } policy-statement ebgp-out { term term1 { from { route-filter 60.60.60.0/24 exact; } then { local-preference 200; as-path-prepend “100 100”; accept; } } term reject { then reject; } } policy-statement ibgp-nhs { term next-hop-self {



then { next-hop self; } } } policy-statement localpref-70 { then { local-preference 70; } } policy-statement ospf-reject-default { term ospf-reject { from { protocol ospf; route-filter 0.0.0.0/0 exact; } then reject; } term accept { then accept; } }}firewall { family inet { filter re-protect { interface-specific; term small-packets { from { packet-length 0-24; } then { count small-packet-attack; log; discard; } } term fragment-packets { from { fragment-offset-except 0; protocol [ icmp igmp pim tcp ]; } then { count frag-attack; log; discard; } } term icmp-in { from { source-prefix-list { trusted-networks; } protocol icmp; } then {



policer limit-2m; count icmp-in; accept; } } term bgp-in { from { source-prefix-list { trusted-bgp-peer; } protocol tcp; port bgp; } then { policer limit-2m; count bgp-in; accept; } } term ospf-in { from { source-prefix-list { trusted-ospf-neighbor; } protocol ospf; } then { policer limit-2m; count ospf-in; accept; } } term snmp-in { from { source-prefix-list { trusted-networks; } protocol udp; port snmp; } then { policer limit-2m; count snmp-in; accept; } } term access-in { from { source-prefix-list { trusted-networks; } protocol tcp; port [ ssh ftp ftp-data ]; } then { count access-in;



accept; } } term udp-services { from { source-prefix-list { trusted-networks; } protocol udp; source-port 1024-65535; } then { policer limit-2m; count udp-in; accept; } } term loopback-in { from { source-address { 127.0.0.1/32; } destination-address { 127.0.0.1/32; } } then { count loopback-in; accept; } } term bfd { from { inactive: source-prefix-list { bfd-out; } inactive: destination-prefix-list { bfd-in; } protocol udp; source-port 49152-65335; destination-port 3784-3785; } then { count accept-bfd; accept; } } term deny-all { then { count illegal-traffic-in; log; discard; } } }



} policer limit-2m { if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; } then discard; }}bridge-domains { SRX3400 { domain-type bridge; vlan-id 10; interface ge-1/0/4.0; interface ge-1/0/5.0; routing-interface irb.0; }}

SRX3400 Cluster Configuration

## Last changed: 2012-04-09 06:07:20 EDTversion 11.4R2.14;groups { node0 { system { host-name FW-1; backup-router 11.11.11.1 destination 172.25.113.0/24; services { ssh; netconf { ssh; } } syslog { file default-log-messages { any any; structured-data; } } } interfaces { fxp0 { unit 0 { family inet { address 172.25.113.89/24; address 172.25.113.90/24 { master-only; } } } } } } node1 {



system { host-name FW-2; backup-router 11.11.11.1 destination 172.25.113.0/24; services { ssh; netconf { ssh; } } } interfaces { fxp0 { unit 0 { family inet { address 172.25.113.91/24; address 172.25.113.90/24 { master-only; } } } } } }}apply-groups “${node}”;system { time-zone America/New_York; root-authentication { encrypted-password “$1$EWm8sgwH$jPWA12glXxKXiXa97oM1a.”; ## SECRET-DATA } scripts { op { file srx-monitor.xsl; } } login { user juniper { uid 2004; class super-user; authentication { encrypted-password “$1$PAmLNRkM$X/zQNzaG/pM6W/WcL/0gY.”; ## SECRET-DATA } } } services { ssh; web-management { https { system-generated-certificate; interface [ reth0.200 reth0.109 ]; } } } syslog { user * {



any emergency; } file messages { any notice; authorization info; } file snmp-critical-traps { daemon critical; } file default-log-messages { any any; structured-data; } } ntp { server 172.25.113.38; }}chassis { cluster { control-link-recovery; reth-count 10; redundancy-group 0 { node 0 priority 254; node 1 priority 1; } redundancy-group 1 { node 0 priority 254; node 1 priority 1; interface-monitor { ge-0/0/0 weight 255; ge-8/0/0 weight 255; ge-8/0/1 weight 255; ge-0/0/2 weight 255; ge-0/0/6 weight 255; ge-8/0/6 weight 255; ge-8/0/7 weight 255; ge-0/0/7 weight 255; } } }}interfaces { ge-0/0/0 { gigether-options { redundant-parent reth0; } } ge-0/0/2 { gigether-options { redundant-parent reth1; } } ge-0/0/6 { gigether-options { redundant-parent reth2;



} } ge-0/0/7 { gigether-options { redundant-parent reth3; } } ge-8/0/0 { gigether-options { redundant-parent reth0; } } ge-8/0/1 { gigether-options { redundant-parent reth1; } } ge-8/0/6 { gigether-options { redundant-parent reth2; } } ge-8/0/7 { gigether-options { redundant-parent reth3; } } ae1 { unit 0 { family inet { filter { input t; } } } } fab0 { fabric-options { member-interfaces { ge-0/0/4; } } } fab1 { fabric-options { member-interfaces { ge-8/0/4; } } } lo0 { unit 0 { family inet { address 127.0.0.1/32; } }

}



reth0 { mtu 1500; redundant-ether-options { redundancy-group 1; } unit 0 { description “Connection to MX-1”; family inet { address 172.28.30.2/30; } } } reth1 { mtu 1500; redundant-ether-options { redundancy-group 1; } unit 0 { description “Connection to MX-2”; family inet { address 172.28.30.6/30; } } } reth2 { redundant-ether-options { redundancy-group 1; } unit 0 { description “Connection EX4200 Core VLAN”; family inet { address 172.28.30.13/30; } } } reth3 { redundant-ether-options { redundancy-group 1; } unit 0 { description “Connection EX4200 DMZ VLAN”; family inet { address 172.28.30.17/30; } } }}event-options { event-script { file control-link-mib.xsl; }}snmp { community public;}routing-options {



static { route 172.16.0.0/12 next-hop 172.25.113.1; route 11.11.11.0/24 next-hop 172.28.30.18; route 60.60.60.0/24 discard; route 0.0.0.0/0 next-hop 192.168.5.20; } router-id 172.25.113.89;}protocols { ospf { traceoptions { file ospf.log; flag all; } export export-to-ospf; inactive: import import-to-ospf; area 0.0.0.0 { interface reth2.0 { bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; full-neighbors-only; } } } area 0.0.0.1 { interface reth0.0 { bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; full-neighbors-only; } } interface reth1.0 { bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; full-neighbors-only; } } } }}policy-options { policy-statement export-to-ospf { term accept { from { route-filter 60.60.60.0/24 exact; } then accept; } term reject { then reject; } } policy-statement import-to-ospf {



term accept { from { route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; } }}security { flow { traceoptions { file flow.log; flag basic-datapath; } } screen { ids-option untrust-screen { icmp { ping-death; } ip { source-route-option; tear-drop; } tcp { syn-flood { alarm-threshold 1024; attack-threshold 200; source-threshold 1024; destination-threshold 2048; timeout 20; } land; } } } nat { traceoptions { file nat.log; flag all; } source { pool outbound-nat { address { 60.60.60.50/32 to 60.60.60.100/32; } } rule-set source-nat { from zone trust; to zone untrust; rule trust-nat { match { source-address 10.10.10.0/24;



} then { source-nat { pool { outbound-nat; } } } } } } destination { pool dmz-server1 { address 11.11.11.1/32; } rule-set dmz-server1-rule { from zone untrust; rule one-to-one { match { destination-address 60.60.60.10/32; } then { destination-nat pool dmz-server1; } } } } } policies { from-zone trust to-zone untrust { policy outbound-access { match { source-address trust; destination-address any; application outbound-apps; } then { permit; log { session-init; session-close; } count; } } } from-zone untrust to-zone dmz { policy untrust-to-dmz { match { source-address any; destination-address 11.11.11.1/32; application dmz-services; } then { permit; log {



session-close; } count; } } } from-zone trust to-zone dmz { policy trust-to-dmz { match { source-address trust; destination-address 11.11.11.1/32; application [ junos-ping junos-http junos-ftp ]; } then { permit; log { session-close; } count; } } } from-zone trust to-zone trust { policy trust-to-trust { match { source-address any; destination-address any; application any; } then { permit { application-services { idp; } } } } } } datapath-debug { traceoptions { file flow.log; } } zones { security-zone trust { address-book { address trust 10.10.10.0/24; } interfaces { reth2.0 { host-inbound-traffic { system-services { ping; } protocols {



ospf; bfd; } } } } } security-zone untrust { screen untrust-screen; interfaces { reth0.0 { host-inbound-traffic { system-services { ping; } protocols { ospf; bfd; } } } reth1.0 { host-inbound-traffic { system-services { ping; } protocols { ospf; bfd; } } } } } security-zone dmz { address-book { address 60.60.60.0/24 60.60.60.0/24; address 11.11.11.1/32 11.11.11.1/32; address 60.60.60.10/32 60.60.60.10/32; address 11.11.11.10/32 11.11.11.10/32; } interfaces { reth3.0 { host-inbound-traffic { system-services { ping; } } } } } }}firewall { family inet { filter t {



term 1 { from { protocol icmp; } then { log; accept; } } } filter t1 { term 1 { from { protocol tcp; } then { log; accept; } } } }}applications { application-set outbound-apps { application junos-http; application junos-https; application junos-ping; } application-set dmz-services { application junos-ping; application junos-ssh; application junos-ftp; application junos-https; }}

EX4200 Configuration

root# show | no-more## Last changed: 2011-11-15 16:16:07 UTCversion 10.4R5.5;system { root-authentication { encrypted-password “$1$FzavJZ6n$WdcS2.acqul4IaNOsqNEM0”; ## SECRET-DATA } services { ftp; ssh; web-management { http { interface ge-0/0/11.0; } } }



syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }}chassis { aggregated-devices { ethernet { device-count 4; } }}interfaces { ge-0/0/0 { unit 0 { family ethernet-switching { vlan { members SRX3400-vlan; } } } } ge-0/0/1 { unit 0 { family ethernet-switching { vlan { members SRX3400-vlan; } } } } ge-0/0/2 { unit 0 { family ethernet-switching { vlan { members core-vlan; } } } } ge-0/0/3 { unit 0 { family ethernet-switching { vlan { members core-vlan; } } }



} ge-0/0/4 { unit 0 { family ethernet-switching { vlan { members dmz-vlan; } } } } ge-0/0/5 { unit 0 { family ethernet-switching { vlan { members dmz-vlan; } } } } ge-0/0/6 { unit 0 { family ethernet-switching; } } ge-0/0/7 { unit 0 { family ethernet-switching; } } ge-0/0/8 { unit 0 { family ethernet-switching; } } ge-0/0/9 { unit 0 { family ethernet-switching; } } ge-0/0/10 { unit 0 { family inet { address 1.1.1.2/24; } } } ge-0/0/11 { unit 0 { family inet { address 2.2.2.2/24; } } } ge-0/0/12 { unit 0 { family ethernet-switching {



vlan { members dmz-services; } } } } ge-0/0/13 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; } } } } ge-0/0/14 { unit 0 { family ethernet-switching; } } ge-0/0/15 { unit 0 { family inet { address 4.4.4.1/30; } } } ge-0/0/16 { unit 0 { family inet { address 4.4.4.2/30; } } } ge-0/0/20 { unit 0 { family ethernet-switching; } } ge-0/0/21 { unit 0 { family inet { address 1.1.1.2/30; } } } ge-0/0/22 { unit 0 { family inet { address 2.2.2.2/30; } } } ge-0/0/23 { unit 0 {



family inet { address 3.3.3.2/30; } } } ge-0/1/0 { unit 0 { family ethernet-switching; } } xe-0/1/0 { unit 0 { family ethernet-switching; } } ge-0/1/1 { unit 0 { family ethernet-switching; } } xe-0/1/1 { unit 0 { family ethernet-switching; } } ge-0/1/2 { unit 0 { family ethernet-switching; } } xe-0/1/2 { unit 0 { family ethernet-switching; } } ge-0/1/3 { unit 0 { family ethernet-switching; } } lo0 { unit 0 { family inet { filter { input loop-count; } address 63.87.0.1/24; } } unit 2 { family inet { filter { input loop-counter2; } address 63.89.0.1/24; }



} } vlan { unit 5 { family inet { address 172.28.30.14/30; } } unit 6 { family inet { address 172.28.30.18/30; } } unit 10 { family inet { address 10.10.10.1/24; } } unit 11 { family inet { address 11.11.11.1/24; } } }}protocols { igmp-snooping { vlan all; } rstp; lldp { interface all; } lldp-med { interface all; }}policy-options { policy-statement export-to-bgp { term accept { from { route-filter 63.87.0.0/24 exact; route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; } } policy-statement export-to-bgp-isp2 { term accept { from { route-filter 0.0.0.0/0 exact; route-filter 63.89.0.0/24 exact; }



then accept; } term reject { then reject; } } policy-statement no-dmz-prefix-in-core-routing-instance { term reject { from { protocol ospf; route-filter 60.60.60.0/24 exact; route-filter 70.70.70.0/24 exact; } then reject; } term accept { then accept; } } policy-statement reject-default { term no-default { from { route-filter 0.0.0.0/0 exact; } then reject; } term accept { then accept; } } policy-statement test { term term1 { from { route-filter 10.10.10.0/24 exact; } } }}firewall { family inet { filter loop-count { term accept { then { count loop-counter; accept; } } } filter loop-counter2 { term accept { then { count loop-counter2; accept; } } }



}}routing-instances { core { instance-type virtual-router; interface vlan.5; interface vlan.10; protocols { ospf { import no-dmz-prefix-in-core-routing-instance; area 0.0.0.0 { interface vlan.10; interface vlan.5 { bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; full-neighbors-only; } } } } } } dmz { instance-type virtual-router; interface vlan.6; interface vlan.11; routing-options { static { route 0.0.0.0/0 next-hop 172.28.30.17; } } } isp-1 { instance-type virtual-router; interface ge-0/0/15.0; interface ge-0/0/21.0; interface lo0.0; routing-options { static { route 63.87.0.0/24 discard; route 172.28.30.0/24 next-hop 1.1.1.1; route 0.0.0.0/0 discard; } autonomous-system 300; } protocols { ## ## Warning: requires ‘bgp’ license ## bgp { traceoptions { file bgp.log; flag all; } export export-to-bgp;



group external { type external; authentication-key “$9$sagaUqmT/CujHCuO1yrYgo”; ## SECRET-DATA bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; } neighbor 1.1.1.1 { local-address 1.1.1.2; peer-as 100; } } group isp { type external; import reject-default; neighbor 4.4.4.2 { local-address 4.4.4.1; peer-as 500; } } } } } isp-2 { instance-type virtual-router; interface ge-0/0/16.0; interface ge-0/0/23.0; interface lo0.2; routing-options { static { route 63.89.0.0/24 discard; route 172.28.30.0/24 next-hop 3.3.3.1; route 0.0.0.0/0 discard; } autonomous-system 500; } protocols { ## ## Warning: requires ‘bgp’ license ## bgp { export export-to-bgp-isp2; group external { type external; authentication-key “$9$QedE3/t1RSM87uO87-V4oz36”; ## SECRET-DATA bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; } neighbor 3.3.3.1 { local-address 3.3.3.2; peer-as 100; } }



group isp { type external; import reject-default; neighbor 4.4.4.1 { local-address 4.4.4.2; peer-as 300; } } } } }}ethernet-switching-options { storm-control { interface all; }}vlans { SRX3400-vlan { vlan-id 5; l3-interface vlan.5; } core-vlan { vlan-id 10; l3-interface vlan.10; } dmz-services { vlan-id 11; l3-interface vlan.11; } dmz-vlan { vlan-id 6; l3-interface vlan.6; }}poe { interface all;}



8010088-001-en aug 2012

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.

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

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

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

www.juniper.net

to purchase Juniper networks solutions,

please contact your Juniper networks

representative at 1-866-298-6428 or

authorized reseller.

printed on recycled paper

although Juniper networks has attempted to provide accurate information in this guide, Juniper networks does not warrant or guarantee

the accuracy of the information provided herein. third party product descriptions and related technical details provided in this document

are for information purposes only and such products are not supported by Juniper networks. all information provided in this guide is

provided “as is”, with all faults, and without warranty of any kind, either expressed or implied or statutory. Juniper networks and its

suppliers hereby disclaim all warranties related to this guide and the information contained herein, whether expressed or implied of

statutory including, without limitation, those of merchantability, fitness for a particular purpose and noninfringement, or arising from a

course of dealing, usage, or trade practice.

References1. Junos oS Security Configuration guide: www.juniper.net/techpubs/en_US/junos10.4/information-products/

topic-collections/security/software-all/security/index.html

2. Security policy applications: www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/security/software-all/security/index.html?policy-app-overview.html

3. Initiating Chassis Cluster manual group Failover: www.juniper.net/techpubs/software/junos-security/junos-security10.1/junos-security-swconfig-security/topic-43680.html

4. Junos oS routing protocols Configuration guide: www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/config-guide-routing/config-guide-routing.pdf

5. routing protocols and policies Configuration guide for Security: www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/security/software-all/routing/junos-security-swconfig-routing-protocols-and-policies.pdf

6. enterprise Wan reference architecture: www.juniper.net/us/en/local/pdf/reference-architectures/8030007-en.pdf

7. Internet edge Solutions Brief: www.juniper.net/us/en/local/pdf/solutionbriefs/3510393-en.pdf

About Juniper NetworksJuniper networks is in the business of network innovation. From devices to data centers, from consumers to cloud

providers, Juniper networks delivers the software, silicon and systems that transform the experience and economics of

networking. the company serves customers and partners worldwide. additional information can be found at

www.juniper.net.

https://remote.juniper.net/,DanaInfo=.awxyCnztpxn1Kzr7+

www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/security/software-all/security/,DanaInfo=.aiuAmmwgGrwz2L0s8+index.html




www.juniper.net/techpubs/software/junos-security/junos-security10.1/junos-security-swconfig-security/,DanaInfo=.aiuAmmwgGrwz2L0s8+topic-43680.html

www.juniper.net/techpubs/software/junos-security/junos-security10.1/junos-security-swconfig-security/,DanaInfo=.aiuAmmwgGrwz2L0s8+topic-43680.html

www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/config-guide-routing/,DanaInfo=.aiuAmmwgGrwz2L0s8+config-guide-routing.pdf

www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/config-guide-routing/,DanaInfo=.aiuAmmwgGrwz2L0s8+config-guide-routing.pdf

www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/security/software-all/routing/,DanaInfo=.aiuAmmwgGrwz2L0s8+junos-security-swconfig-routing-protocols-and-policies.pdf



www.juniper.net/us/en/local/pdf/reference-architectures/,DanaInfo=.aiuAmmwgGrwz2L0s8+8030007-en.pdf

www.juniper.net/us/en/local/pdf/reference-architectures/,DanaInfo=.aiuAmmwgGrwz2L0s8+8030007-en.pdf

www.juniper.net/us/en/local/pdf/solutionbriefs/,DanaInfo=.aiuAmmwgGrwz2L0s8+3510393-en.pdf

Date post:	01-Nov-2014
Category:	Documents
Upload:	michael-leonard
View:	27 times
Download:	0 times

Internet Edge Implementation Guide

Documents