Implementation Guide NEW NETWORK PLATFORM ARCHITECTURE: WAN. Internet Edge

(1)

NEW NETWORK PLATFORM ARCHITECTURE:

WAN

Internet edge

(2)

List of Figures

Figure 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 Tables

table 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

(4)

Introduction

the 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.

Scope

this 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 Audience

this 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

(5)

Key Assumptions

this 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 Considerations

there 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 Considerations

enterprises 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.

(6)

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 Considerations

an 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 Consideration

Symmetric and Predictable Routing

When 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 Service

Since 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 Operation

there 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)

(7)

Implementation

this 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-2 AS100 Default routes advertised ISP2 AS500 (EX Series virtual instance) Irb.0 172.28.30.5 iBGP Area 1

Area 0 Static Routes ae1 ge-1/1/4 ge-1/1/5 172.28.30.9 1.1.1.1 ge-1/0/0 ge-1/0/03.3.3.1 3.3.3.2 1.1.1.2 ge-0/0/21.0 ge-0/0/22.0 eBGP eBGP eBGP ge-1/0/5 ge-1/0/4 ge-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/0

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

(8)

Border Routers

the 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 Topology

outbound 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-2 AS100 Default routes advertised ISP2 AS500 (EX Series virtual instance) Irb.0 172.28.30.5 iBGP Area 1

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

ge-0/0/6

ge-0/0/0

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

(9)

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).

(10)

MX80-2:

protocols { bgp {

group isp2 { type external;

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.

(11)

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.

(12)

Achieving Secondary Business Consideration—First Layer of Defense

Securing 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 {

(13)

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 {

(14)

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

(15)

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-2 AS100 Default routes advertised ISP2 AS500 (EX Series virtual instance) Irb.0 172.28.30.5 iBGP Area 1

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

ge-0/0/6

ge-0/0/0

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

(16)

Achieving Business Consideration: Securing Traffic to and from the Core and DMZ—Second Layer of Defense

the 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

(17)

}

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; } }

(18)

Zone Definitions in SRX3400

We 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:

(19)

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; } } } } }

(20)

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).

(21)

Core and DMZ—Third Layer of Defense

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

most 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 { MX80-2 AS100 Default routes advertised ISP2 AS500 (EX Series virtual instance) Irb.0 172.28.30.5 iBGP Area 1

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

(22)

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-2 AS100 Default routes advertised ISP2 AS500 (EX Series virtual instance) Irb.0 172.28.30.5 iBGP Area 1

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

(23)

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

(24)

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)

Summary

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

(25)

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

(26)

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

(27)

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.

(28)

Appendix B—Configurations

Below 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 UTC version 10.4R7.5;

system {

host-name NYCD-MX80-48T-1; root-authentication {

(29)

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 {

(30)

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;

(31)

(32)

(33)

(34)

(35)

(36)

MX80-2 Configuration

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 {

(37)

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 {

(38)

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;

(39)

(40)

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;

(41)

(42)

(43)

} 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

(44)

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 ]; }

} }

(45)

(46)

(47)

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 {

(48)

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;

(49)

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 {

(50)

} 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; } } }

(51)

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; } } }

(52)

(53)

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

system {

root-authentication {

(54)

(55)

(56)

(57)

(58)

(59)

(60)

} } 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 { ##

(61)

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;

(62)

(63)

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

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.

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.

References

1. 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 Networks

Juniper 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

Implementation Guide NEW NETWORK PLATFORM ARCHITECTURE: WAN. Internet Edge

NEW NETWORK PLATFORM ARCHITECTURE:

WAN

Internet edge

Table of Contents

List of Figures

List of Tables

Introduction

Scope

Target Audience

Key Assumptions

Design Considerations

Routing Considerations

Security Considerations

Failure Consideration

Quality of Service

Protocol Operation

Implementation

Border Routers

Business Considerations

Achieving Primary Business Consideration—Strict Primary and Secondary Topology

Achieving Secondary Business Consideration—First Layer of Defense

SRX Series Security Devices

Core and DMZ—Third Layer of Defense

Caveats

Products and Software

Summary

Appendix A—Traffic Behavior

Appendix B—Configurations

MX80-1 Configuration

MX80-2 Configuration

SRX3400 Cluster Configuration

EX4200 Configuration

References

About Juniper Networks