Internet Edge Implementation Guide

Implementation Guide
WAN
NEW NETWORK PLATFORM ARCHITECTURE:
Internet edge ImplementatIon guIde
Implementation Guide - Internet Edge
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 ConsiderationStrict primary and Secondary topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 achieving Secondary Business ConsiderationFirst 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 dmZthird layer of defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 dmZ: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 products and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 appendix atraffic Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 appendix BConfigurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 mX80-1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 mX80-2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 SrX3400 Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 about Juniper networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Copyright 2012, Juniper networks, Inc.
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 table 3: products with Software releases, part numbers, and licensing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Introduction
the Internet edge acts as the enterprises 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 network architects Security managers System test engineers
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
Customer peer
ISP Preference
400 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 policythis 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 policythis 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 policyWith 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 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) 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.
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. ISP1 AS300
(EX Series virtual instance) ge-0/0/21.0 1.1.1.2
eBGP
ISP2 AS500
(EX Series virtual instance) ge-0/0/22.0 3.3.3.2 eBGP 3.3.3.1 ge-1/0/0 MX80-2 AS100 ge-1/0/4 ge-1/0/5
eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100
ISP interfacing router
ae1 ge-1/1/4 ge-1/1/5 172.28.30.9
iBGP
ae1 ge-1/1/4 ge-1/1/5 172.28.30.10
ge-1/0/3 ge-1/0/2 Irb.0 172.28.30.1 reth0.0 172.28.30.2 ge-0/0/0 ge-0/0/2 Area 1
Default routes advertised
Irb.0 172.28.30.5 reth1.0 172.28.30.6
ge-8/0/0 ge-8/0/2 SRX3400-2
Security Devices
SRX3400-1 ge-0/0/6 Area 0 SRX Series reth2.0 172.28.30.13 EX Series vlan.5 172.28.30.14 ge-0/0/0 ge-0/0/1 EX4200 Core (virtual instance) ge-0/0/7 ge-8/0/6 Static Routes SRX Series reth3.0 172.28.30.17 EX Series vlan.6 172.28.30.18
ge-8/0/7
Core & DMZ
ge-0/0/4 ge-0/0/5 EX4200 DMZ (virtual instance)
10.10.10.0/24 Vlan.10
11.11.11.1
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.
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.
ISP1 AS300
eBGP
ISP2 AS500
eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100
ae1 ge-1/1/4 ge-1/1/5 172.28.30.9
iBGP
ae1 ge-1/1/4 ge-1/1/5 172.28.30.10
Irb.0 172.28.30.5 reth1.0 172.28.30.6
ge-8/0/0 ge-8/0/2 SRX3400-2
Security Devices
ge-8/0/7
Core & DMZ
10.10.10.0/24 Vlan.10
11.11.11.1
Figure 2: Box highlights the border (ISP interfacing) router connecting with the two ISPs Before we examine how the two business considerations are accomplished, lets 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 ConsiderationStrict 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-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 { : :
10
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 ISps 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.
11
Achieving Secondary Business ConsiderationFirst 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 { source-prefix-list { f Accept from white list.Police incoming ICMP
12
} 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; }
} then { policer limit-2m; count icmp-in; accept; }
trusted-networks; } protocol icmp;
13
} 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; }
} : :
} 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; } }
from { source-prefix-list { trusted-networks; } protocol tcp; port [ ssh ftp ftp-data ]; } then { count access-in; accept; }
14
SRX Series Security Devices

Business consideration:
the primary requirement of security devices is to protect the corporate network from attacks from the Internet. ISP1 AS300
eBGP
ISP2 AS500
eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100
ae1 ge-1/1/4 ge-1/1/5 172.28.30.9
iBGP
ae1 ge-1/1/4 ge-1/1/5 172.28.30.10
Irb.0 172.28.30.5 reth1.0 172.28.30.6
ge-8/0/0 ge-8/0/2 SRX3400-2
Security Devices
ge-8/0/7
Core & DMZ
10.10.10.0/24 Vlan.10
11.11.11.1
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, lets 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.
15
Achieving Business Consideration: Securing Traffic to and from the Core and DMZSecond 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
Core (trust zone) Internet (area 1, a.k.a. untrust zone) Core (trust zone) Core (trust zone)
ISP Preference
Internet (area 1, a.k.a. untrust zone) dmZ dmZ Core (trust zone)
NAT
Source nat destination nat none 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; } }
16
: : : applications { application-set application application application } application-set application application application application } }
} 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; } } } }
outbound-apps { junos-http; junos-https; junos-ping; dmz-services { junos-ping; junos-ssh; junos-ftp; 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.
17
Zone Definitions in SRX3400

We have seen the different restrictions imposed on the inter-zone traffic and the associated configuration. now lets 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; } } } } }
{ {
{ {
18
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 systemservices of ICmp echo.
19
NAT definitions: lets 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.
20
Core and DMZThird 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. ISP1 AS300
eBGP
ISP2 AS500
eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100
ae1 ge-1/1/4 ge-1/1/5 172.28.30.9
iBGP
ae1 ge-1/1/4 ge-1/1/5 172.28.30.10
Irb.0 172.28.30.5 reth1.0 172.28.30.6
ge-8/0/0 ge-8/0/2 SRX3400-2
Security Devices
ge-8/0/7
Core & DMZ
10.10.10.0/24 Vlan.10
11.11.11.1
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
21
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. ISP1 AS300
eBGP
ISP2 AS500
eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100
ae1 ge-1/1/4 ge-1/1/5 172.28.30.9
iBGP
ae1 ge-1/1/4 ge-1/1/5 172.28.30.10
Irb.0 172.28.30.5 reth1.0 172.28.30.6
ge-8/0/0 ge-8/0/2 SRX3400-2
Security Devices
ge-8/0/7
Core & DMZ
10.10.10.0/24 Vlan.10
11.11.11.1
Figure 5: EX Series virtual instance representing the DMZ and connected using static routes to the SRX Series cluster
22
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 } core-vlan { vlan-id 10; l3-interface } dmz-services { vlan-id 11; l3-interface } dmz-vlan { vlan-id 6; l3-interface } }
vlan.5;
vlan.10;
vlan.11;
vlan.6;
23
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
mX80-48t(2) SrX3400(2)
Software Release
10.4r7.5 11.4r2.14
Part number
mX80-48t-aC SrX3400BaSe-aC, SrX3K-16ge-SFp, SrX3K-Crm, SrX3K-npC, SrX3K-re-12-10 eX4200-48p
License
Base Base
eX4200
10.4r5.5
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 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.
24
Appendix ATraffic Behavior
ISP1
ISP2
MX80-1
MX80-2
IRB.0
reth.0
Security devices
SRX3400-1
SRX3400-2
Core & DMZ
EX4200 virtual instance
CORE
DMZ
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.
ISP1
ISP2
MX80-1
MX80-2
IRB.0
reth.0
Security devices
SRX3400-1
SRX3400-2
Core & DMZ
CORE
DMZ
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.
25
ISP1
ISP2
MX80-1
MX80-2
IRB.0
reth.0
Security devices
SRX3400-1
SRX3400-2
Core & DMZ
CORE
DMZ
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.
ISP1
ISP2
MX80-1
MX80-2
IRB.0
reth.0
Security devices
SRX3400-1
SRX3400-2
Core & DMZ
CORE
DMZ
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.
26
ISP1
ISP2
MX80-1
MX80-2
IRB.0
reth.0
Security devices
SRX3400-1
SRX3400-2
Core & DMZ
CORE
DMZ
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.
27
Appendix BConfigurations
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 { 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 {
28
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;
29
} 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;
} lo0 { unit 0 { family inet { filter { input re-protect; } address 127.0.0.1/32; } } }
unit 0 { family inet { address 172.28.30.1/30; } }
30
} } 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; }
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; } } }
31
} 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;
} 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; } }
term reject { then reject; }
32
} 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 {
protocol [ icmp igmp pim tcp ]; } then { count frag-attack; log; discard; }
33
} } 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;
policer limit-2m; count snmp-in; accept;
34
} 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; } }
} policer limit-2m { if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; } then discard; }
} filter t { term 1 { from { protocol tcp; } then { log; 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; } }
} then accept;
35
MX80-2 Configuration
## Last changed: 2012-04-06 22:47:23 UTC version 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 {
36
} } 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 {
address 3.3.3.1/24;
37
} } 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;
filter { input re-protect; } address 127.0.0.1/32;
38
} 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;
10.10.10.0/24; 172.16.0.0/12; 172.25.112.0/24;
} policy-statement ibgp-nhs { term next-hop-self {
} } term reject { then reject; }
39
} 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 {
} } 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; } }
then { next-hop self; }
40
} } 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;
policer limit-2m; count icmp-in; accept;
41
} 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; } }
accept;
42
} 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; } }
} policer limit-2m { if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; } then discard; }
SRX3400 Cluster Configuration

## Last changed: 2012-04-09 06:07:20 EDT version 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 {
43
} } 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 * {
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; } } } } }
44
} 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;
} ntp { server 172.25.113.38; }
any emergency; } file messages { any notice; authorization info; } file snmp-critical-traps { daemon critical; } file default-log-messages { any any; structured-data; }
45
} } 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; } } }
46
} event-options { event-script { file control-link-mib.xsl; } } snmp { community public; } routing-options {
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; } } }
47
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 {
static { route route route route } router-id
172.16.0.0/12 next-hop 172.25.113.1; 11.11.11.0/24 next-hop 172.28.30.18; 60.60.60.0/24 discard; 0.0.0.0/0 next-hop 192.168.5.20;
48
} } 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;
term accept { from { route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; }
49
} 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 {
} 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; } } } }
} then { source-nat { pool { outbound-nat; } } }
50
} 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 {
} 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; } } } } }
session-close; } count;
51
} } firewall { family inet { filter t {
} 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; } } } } }
ospf; bfd;
52
} } applications { application-set application application application } application-set application application application application } }
} filter t1 { term 1 { from { protocol tcp; } then { log; accept; } } }
term 1 { from { protocol icmp; } then { log; accept; } }
outbound-apps { junos-http; junos-https; junos-ping; dmz-services { junos-ping; junos-ssh; junos-ftp; junos-https;
EX4200 Configuration
root# show | no-more ## Last changed: 2011-11-15 16:16:07 UTC version 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; } } }
53
} 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; } } }
syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }
54
} 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 {
55
} 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 {
vlan { members dmz-services; }
56
} } 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; }
family inet { address 3.3.3.2/30; }
57
} 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; }
} } vlan { unit 5 { family inet address } } unit 6 { family inet address } } unit 10 { family inet address } } unit 11 { family inet address } } }
{ 172.28.30.14/30;
{ 172.28.30.18/30;
{ 10.10.10.1/24;
{ 11.11.11.1/24;
58
} firewall { family inet { filter loop-count { term accept { then { count loop-counter; accept; } } } filter loop-counter2 { term accept { then { count loop-counter2; accept; } } }
} 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; } } }
then accept; } term reject { then reject; }
59
} } 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;
60
DATA
group external { type external; authentication-key $9$sagaUqmT/CujHCuO1yrYgo; ## SECRETbfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; } neighbor 1.1.1.1 { local-address 1.1.1.2; peer-as 100; }
DATA
} 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; ## SECRETbfd-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.2 { local-address 4.4.4.1; peer-as 500; } }
61
} } 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; }
group isp { type external; import reject-default; neighbor 4.4.4.1 { local-address 4.4.4.2; peer-as 300; } }
62
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/topiccollections/security/software-all/security/index.html?policy-app-overview.html 3. Initiating Chassis Cluster manual group Failover: www.juniper.net/techpubs/software/junos-security/junossecurity10.1/junos-security-swconfig-security/topic-43680.html 4. Junos oS routing protocols Configuration guide: www.juniper.net/techpubs/en_US/junos12.1/informationproducts/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-routingprotocols-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 www.juniper.net.
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.
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
APAC Headquarters Juniper networks (Hong Kong) 26/F, Cityplaza one 1111 Kings road taikoo Shing, Hong Kong phone: 852.2332.3636 Fax: 852.2574.7803
EMEA Headquarters Juniper networks Ireland airside Business park Swords, County dublin, Ireland phone: 35.31.8903.600 emea Sales: 00800.4586.4737 Fax: 35.31.8903.601
to purchase Juniper networks solutions, please contact your Juniper networks representative at 1-866-298-6428 or authorized reseller.
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.
8010088-001-en aug 2012
printed on recycled paper
63

Internet Edge Implementation Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internet Edge Implementation Guide

Uploaded by

Copyright:

Available Formats

Implementation Guide

NEW NETWORK PLATFORM ARCHITECTURE:

Internet edge ImplementatIon guIde

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Table 1. Source of Advertised Routes and ISP Preferences

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100

ISP interfacing router

ae1 ge-1/1/4 ge-1/1/5 172.28.30.9

ae1 ge-1/1/4 ge-1/1/5 172.28.30.10

ge-1/0/3 ge-1/0/2 Irb.0 172.28.30.1 reth0.0 172.28.30.2 ge-0/0/0 ge-0/0/2 Area 1

Default routes advertised

Irb.0 172.28.30.5 reth1.0 172.28.30.6

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

Default routes advertised

Core & DMZ

ge-0/0/4 ge-0/0/5 EX4200 DMZ (virtual instance)

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100

ISP interfacing router

ae1 ge-1/1/4 ge-1/1/5 172.28.30.9

ae1 ge-1/1/4 ge-1/1/5 172.28.30.10

ge-1/0/3 ge-1/0/2 Irb.0 172.28.30.1 reth0.0 172.28.30.2 ge-0/0/0 ge-0/0/2 Area 1

Default routes advertised

Irb.0 172.28.30.5 reth1.0 172.28.30.6

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

Default routes advertised

Core & DMZ

ge-0/0/4 ge-0/0/5 EX4200 DMZ (virtual instance)

Achieving Primary Business ConsiderationStrict Primary and Secondary Topology

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Achieving Secondary Business ConsiderationFirst Layer of Defense

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

} then { policer limit-2m; count icmp-in; accept; }

trusted-networks; } protocol icmp;

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

Copyright 2012, Juniper networks, Inc.

Implementation Guide - Internet Edge

SRX Series Security Devices

eBGP 1.1.1.1 ge-1/0/0 MX80-1 AS100

ISP interfacing router

ae1 ge-1/1/4 ge-1/1/5 172.28.30.9

ae1 ge-1/1/4 ge-1/1/5 172.28.30.10

ge-1/0/3 ge-1/0/2 Irb.0 172.28.30.1 reth0.0 172.28.30.2 ge-0/0/0 ge-0/0/2 Area 1

Default routes advertised