WAN Routing Configuration Examples for the Secure Services Gateway Family

calvesnorthΔίκτυα και Επικοινωνίες

24 Οκτ 2013 (πριν από 4 χρόνια και 16 μέρες)

121 εμφανίσεις

Application Note
WAN Routing Configuration Examples for the
Secure Services Gateway Family













Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
408 745 2000 or 888 JUNIPER
www.juniper.net


Part number: 350095-001
Chien-shun Chu
SPG Technical Marketing
November, 2006

2 Copyright © 2006, Juniper Networks, Inc

Table of Contents

Scenario Topology: Single Point-to-Point WAN Connection - No VPN 3
Using QoS 4

Using Cisco HDLC WAN encapsulation 5

Using PPP WAN encapsulation 5

Using Frame Relay WAN encapsulation 5

Configuration Commands: HDLC, MLPPP, MLFR 5

Cisco HDLC Configuration Commands: 5

PPP Configuration Commands: 6

Frame Relay Configuration Commands 6

OSPF Configuration Commands: 6

QoS Configuration Commands: 6

Scenario Topology: Single point-to-point WAN Connection -- VPN 6
Using QoS 7

Using HDLC, PPP, or Frame Relay WAN encapsulations 8

HDLC, PPP and Frame Relay Configuration Commands: 8

VPN Tunnel Interface Configuration Commands: 8

OSPF and Static Route Configuration Commands 8

QoS Configuration Commands: 8

Scenario Topology: Dual T1 Interfaces Across Private Lines 9
Using QoS in the Configuration 9

Configuration Commands: Dual T1 With Private Lines 9

HDLC, PPP and Frame Relay Configuration Commands: 9

OSPF and Static Route Configuration Commands: 10

QoS configuration commands: 10

Scenario Topology: Dual T1 With ISP Redundancy 10
HDLC, PPP and Frame Relay Configuration Commands: 11

OSPF and Static Route Configuration Commands: 11

QoS configuration commands: 11

Using MLPPP (RFC1990) in a Dual T1 Configuration 11

Using MLFR in a Dual T1 Configuration 12

Configuration Commands: Dual T1 With ISP Redundancy 12

MLPPP Configuration Commands: 12

MLFR Configuration Commands: 13

VPN Configuration Commands: 13

OSPF Configuration Commands: 13

QoS Configuration Commands: 13

Scenario Topology: Mix-and-match WAN interfaces 14
Configuration Commands: Mix and Match WAN Interfaces 14

Interface Configuration Commands: 14

VPN Configuration Commands: 15

OSPF Configuration Commands: 15

QoS Configuration Commands: 15

Appendix 1: – Troubleshooting and Debug commands 16
3 Copyright © 2006, Juniper Networks, Inc

Executive Summary
The Juniper Networks Secure Services Gateway (SSG) Family of purpose-built
security appliances delivers a perfect mix of performance, security and
LAN/WAN connectivity for branch office deployments of all sizes. Network traffic
is protected by proven ScreenOS functionality that includes a complete set of
Unified Threat Management (UTM) security features (Stateful firewall, IPSec
VPN, IPS, Antivirus, Anti-Spam, and Web Filtering).
Complementing the powerful UTM security features is a robust routing engine
that allows the SSG Family to be deployed as a traditional branch office router or
as a combination firewall and routing device to reduce capital and operational
expenses. The ScreenOS routing engine supports a wide range of routing
protocols (OSPF, BGP, RIPv1/2) and WAN encapsulations (PPP, MLPPP, FR,
MLFR, HDLC, ADSL and MLADSL).
This document outlines a series of routing deployment scenarios and
configuration examples starting with a basic T1 connection using OSPF and
advancing to more elaborate configurations using MLPPP and MLFR. The
Configuration Commands required to implement the deployment scenarios on
any one of the SSG Family platforms are included in each scenario.

Scenario Topology: Single Point-to-Point WAN Connection - No VPN
In this scenario, a single WAN interface is used to establish a clear text (no VPN)
point-to-point connection over a T1 interface. Any one of the three WAN
encapsulations can be used – HDLC, PPP or Frame Relay.
The WAN interfaces are configured in the untrust zone while the LAN / Ethernet
interfaces are configured in trust zone.

PC-1
PC-2
FW-1
Remote Office
(OSPF Area 55)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
PC-1
SSG-1
T1 in various protocols –
Cisco HDLC,
PPP or Frame Relay
PC-2
FW-1
Remote Office
(OSPF Area 56)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
Router
w// T1 interface
PC-1
PC-2
FW-1
Remote Office
(OSPF Area 55)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
PC-1
SSG-1
T1 in various protocols –
Cisco HDLC,
PPP or Frame Relay
PC-2
FW-1
Remote Office
(OSPF Area 56)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
Router
w// T1 interface
4 Copyright © 2006, Juniper Networks, Inc

Using QoS
Like most traditional branch office routers, the SSG Family supports QoS,
allowing administrators to apply traffic shaping policies to traffic flowing in and out
of the branch office, thereby ensuring that key applications are not starved of
required bandwidth. There are four primary mechanisms for applying QoS on the
SSG family.
Traffic Shaping applies guaranteed bandwidth, policied bandwidth and
maximum bandwidth to all traffic crossing an interface, to specific applications or
to both. When enabled at the policy level, QoS ensures that the application
receives its guaranteed bandwidth. There are three different traffic shaping
options available for each policy:
• Guaranteed bandwidth (gbw), means that regardless of what else happens in
the device, this rate would be guaranteed to the appropriate traffic
• Policied bandwidth (pbw), means that the application within the policy
receives the allocated bandwidth.
• Maximum bandwidth (mbw), means that appropriate traffic can never exceed
this rate.
Priority queuing is a feature that allows all your users and applications to have
access to available bandwidth as they need it, while ensuring that important
traffic can get through, if necessary at the expense of less important traffic.
Priority queuing (eight levels) can be enabled in conjunction with guaranteed
bandwidth or in a stand alone manner.
• Up to 8 separate traffic queues for different priority of traffics.
• Enforced via QoS traffic hierarchy. That is; bandwidth requirement highest
priority queue will be satisfied before lower priority queues.
Ingress / egress policing is traffic control at the ingress and egress side of the
security device. By constraining the flow of traffic at the point of ingress, traffic
exceeding your bandwidth setting is treated with minimal processing, conserving
system resources.
• Drop packets if rate exceeds the configured max bandwidth per interface.
• Useful to prevent attacks or floods, as well as to budget bandwidth among
interfaces.
DSCP (DiffServ Codepoint Marking) aka DiffServ marking/stamping, governs
how traffic is processed by down stream devices (routers). DSCP can be enabled
in conjunction with traffic shaping or independently.
• By default, overwrite “IP Precedence” bits based on priority and leave the
rest of the bits intact.
• Useful in classifying and marking different types of traffic, e.g., VoIP, http for
the downstream device to perform QoS tasks.
5 Copyright © 2006, Juniper Networks, Inc

In the example below, policy ID X has configuration of “gbw 128”, meaning that
128KBs bandwidth is guaranteed for VoIP (SIP) traffic in the egress direction
(from trust zone to untrust zone). Policy Y is deployed to use leftover bandwidth
from policy X.
• “set policy id X from "Trust" to "Untrust" "Subnet 1" "Subnet 2" "SIP" permit
traffic gbw 128 priority 1”
• “set policy id Y from "Trust" to "Untrust" "Any" "Any" "ANY" permit”
The sequence of the policies are important. That is, policy X has to be the first
policy, followed by Y as the SSG platform will perform “first match” on all ingress
packets. Specific tasks should be placed in top of the policies list in order to be
matched ahead of the other policies.
Note that QoS can be applied in the following WAN scenarios on an interface or
per policy basis:
• T1, E1, ISDN BRI S/T, DS3 or ADSL 2+ interface running PPP or HDLC
• T1, E1, ISDN BRI S/T, DS3 or ADSL 2+ interfaces running MLPPP
• Serial running PPP (assuming fixed bandwidth)
The variable nature of Frame relay and Multilink Frame relay dictates that
ScreenOS QoS cannot be applied when those encapsulations are in use.
Using Cisco HDLC WAN encapsulation
HDLC is the default WAN interface encapsulation protocol on Cisco routers.
Through its HDLC support, the SSG Family can fully interoperate with Cisco
routers. In this scenario, OSPF is running on the WAN interface as well as
Ethernet interface of the SSG.
Using PPP WAN encapsulation
Whereas Cisco HDLC is a proprietary extension from the ISO standard HDLC
and is not universally supported while interfacing with a non Cisco router, PPP
(Point-to-Point Protocol) is a standard defined by IETF RFC 1661. It is supported
by all vendors (including Cisco) and as such, can interoperate with a wider range
of 3
rd
party network appliances.
The configuration on the SSG to support PPP is fairly straightforward. A PPP
profile is defined (via “set ppp profile” command) to outline key PPP related
parameters (e.g., authentication and addressing method). Other configuration
tasks such as QoS and OSPF (if needed) are identical to the HDLC
configuration.
Using Frame Relay WAN encapsulation
Frame Relay, like PPP is a common and widely supported WAN protocol. There
is very little difference between Frame Relay and PPP in terms of configuration.
See configuration commands below.
Configuration Commands: HDLC, MLPPP, MLFR
Cisco HDLC Configuration Commands:
set interface "ethernet0/0" zone "Trust"
set interface "serial1/0" zone "Trust"
6 Copyright © 2006, Juniper Networks, Inc

set interface "serial1/1" zone "Untrust"
set interface "serial1/0" encap cisco-hdlc
set interface serial1/0 ip 10.1.2.28/24
PPP Configuration Commands:
set interface "ethernet0/0" zone "Trust"
set interface "serial1/0" zone " Untrust"
set interface "serial1/0" encap ppp
set interface serial1/0 ip 10.1.2.28/24
set ppp profile "PPP1"
set ppp profile "PPP1" netmask 255.255.255.0
set ppp profile "PPP1" static-ip
set interface "serial1/0" ppp profile PPP1
Frame Relay Configuration Commands
set interface "serial1/0" zone "Untrust"
set interface "serial1/0.10" zone "Untrust"
set interface "serial1/0" encap frame-relay
set interface serial1/0.10 ip 10.1.2.28/24
set interface "serial1/0.10" frame-relay dlci 100
set interface "serial1/0.10" frame-relay inverse-arp
OSPF Configuration Commands:
set interface serial1/0 protocol ospf area 0.0.0.0
set interface serial1/0 protocol ospf enable
set interface serial1/0 protocol ospf retransmit-interval 5
set interface serial1/0 protocol ospf cost 64
set interface ethernet0/1 protocol ospf area 0.0.0.56
set interface ethernet0/1 protocol ospf enable
set interface ethernet0/1 protocol ospf retransmit-interval 5
set interface ethernet0/1 protocol ospf cost 10
QoS Configuration Commands:
set policy id 1 name "SIP" from "Trust" to "Untrust" "Any" "Any"
"SIP" permit traffic gbw 128 priority 7
set policy id 1
set policy id 2 from "Trust" to "Untrust" "Any" "Any" "ANY"
permit
set policy id 2
Scenario Topology: Single point-to-point WAN Connection -- VPN
Adding a VPN tunnel to the previous example is a very simple process of
inserting the necessary VPN tunnel configuration commands. The protocol used
can be Cisco HDLC, PPP or Frame Relay.
The SSG-1 will have a static route to the ISP router (default gateway) for all the
traffic generated from the branch office – IPsec VPN, web, ftp, etc. The IPSec
VPN traffic will be transported via the Internet and reach FW-1 at headquarters.
ScreenOS provides two different mechanisms for building an IPSec VPN – route-
based VPN or policy-based VPN. Route based VPN allows “tunnel” interface to
act as IPSec VPN tunnels while a policy based VPN will utilize other policies
within ScreenOS to trigger IPSec VPN connections.
In cases where there are many branch offices, scalability can be addressed by
using route based VPNs with routing protocols, for example OSPF on all of the
VPN tunnels. OSPF leverages the dynamic routing function while minimizing
operational and administrative tasks.
7 Copyright © 2006, Juniper Networks, Inc

A route based VPN tunnel interface as well as the serial interface on SSG-1 are
placed in the “untrust” zone while Ethernet interface at branch offices are defined
as “trust” zone. System administrator can build policies for different types of
traffic between “trust” to “untrust” zone. Those traffic utilizes tunnel interface will
be encrypted into IPSec VPN while others can be transmitted in plain text to a
destination on the Internet. The picture on the left shows how this solution is
implemented. The picture on the top right shows logical topology of this solution
-- VPN tunnels from all branch offices are placed into OSPF area 0. Thus; FW-1
will be able to map the traffic to proper tunnel interface and reach the remote
branch offices.
Using QoS
In this QoS example, three different types of traffic are used:
• Voice: Reserve 128Kbs for SIP over VPN on SSG-1 – via
“set policy id X from "Trust" to "Untrust" "PC-1
Subnet" "PC-2 Subnet" "SIP" permit traffic gbw 128
priority 1”
• VPN: Assign priority on VPN traffic over plain-text traffic – via
“set policy id Y from "Trust" to "Untrust" " PC1
Subnet" " PC1 Subnet” "ANY" permit priority 2”
• Non-VPN Traffic: leftover from previous policies – via
“set policy id Z from "Trust" to "Untrust" "Any" "Any"
"ANY" permit”
The key difference between policy X, Y and Z is the source and destination of
packets. Packets matching “PC-1 subnet” as source and “PC-2 subnet” as
destination will use the tunnel interface as defined via static route. All packets
that are routed over the tunnel interface will be encrypted.
VoIP calls will match policy X and have 128KBs reserved on the IPSec VPN
tunnel. There has no bandwidth guaranteed via policy Y, however; all packets
match policy Y will be placed into queue with priority of 2. Those packets will
have a lower priority over VoIP packets (defined in policy X) but would have
higher priority over packets in policy Z (non-encrypted packets). Packets that do

PC-1
PC-2
FW-1
OSPF Area 0
On VPN tunnels
PC
PC-1
1
SSG-1
T1 in various protocols –
Cisco HDLC,
PPP or Frame Relay
PC
PC-2
FW-1
-
Branch
Office
Router
w// T1 interface
Head-
quarter
Branch
Offices
Head-
quarter
Branch
Office
Internet
PC-1
PC-2
FW-1
OSPF Area 0
On VPN tunnels
PC
PC-1
1
SSG-1
T1 in various protocols –
Cisco HDLC,
PPP or Frame Relay
PC
PC-2
FW-1
-
Branch
Office
Router
w// T1 interface
Head-
quarter
Branch
Offices
Head-
quarter
Branch
Office
Internet
8 Copyright © 2006, Juniper Networks, Inc

not match either policy X or Y – web, ping, etc to the Internet- will utilize
remaining bandwidth on the WAN interface over policy Z.
Using HDLC, PPP, or Frame Relay WAN encapsulations
As in the previous example, the SSG Family can support Cisco HDLC, PPP and
frame Relay thereby ensuring interoperability with other networking components.
Please refer to the previous example for appropriate HDLC, PPP and Frame
Relay configuration commands.
HDLC, PPP and Frame Relay Configuration Commands:
Please refer to the previous example for appropriate OSPF, HDLC, PPP and
Frame Relay configuration commands.
VPN Tunnel Interface Configuration Commands:
set ike gateway "VPN to HQ" address x.x.x.x Main outgoing-
interface "serial1/0.10" preshare "xxx” sec-level standard
set interface "tunnel.1" zone "Untrust"
set interface tunnel.1 ip 192.168.1.28/24
set vpn "VPN to SSG-550" gateway "VPN to HQ" no-replay tunnel
idletime 0 sec-level standard
set vpn "VPN to SSG-550" id 1 bind interface tunnel.1
OSPF and Static Route Configuration Commands
set route PC-2_subnet interface tunnel.1 preference 20
set route 0.0.0.0/0 interface serial1/0 gateway 10.1.2.36
preference 20
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf enable
set interface tunnel.1 protocol ospf cost 10
QoS Configuration Commands:
set policy id 1 name "SIP via VPN" from "Trust" to "Untrust"
"Any" "Any" "SIP" permit traffic gbw 128 priority 1
set policy id 1
set policy id 2 from "Trust" to "Untrust" " PC1 Subnet" " PC1
Subnet” "ANY" permit gbw 0 priority 2
set policy id 2
set policy id 3 from "Trust" to "Untrust" "Any" "Any" "ANY"
permit
set policy id 3
9 Copyright © 2006, Juniper Networks, Inc

Scenario Topology: Dual T1 Interfaces Across Private Lines
In this scenario, two T1 interfaces are configured to provide redundancy at the
WAN interface level using OSPF routing protocol over private lines.
Both T1s from SSG-1 are active with SSG-1 making traffic decisions over the
T1s via OSPF in order to make best use of both links. ECMP should be enabled
(“set max-ecmp-routes”) in order to use both T1s as valid OSPF routes and
perform load balancing across the interfaces.
The policies are defined on the Ethernet interface of SSG-1 as trust zone and
both T1 interfaces as untrust zone.
Using QoS in the Configuration
Two types of traffics are defined in the policy setting of SSG-1:
• Voice: reserve 128Kb/s on SSG-1 for SIP packets:– via
“set policy id X from "Trust" to "Untrust" "PC-1 Subnet"
"PC-2 Subnet" "SIP" permit traffic gbw 128 priority 1
• Data (other packets): leftover from VoIP– via
set policy id 1 from "Trust" to "Untrust" "Any" "Any"
"ANY" permit”

Please refer to previous examples of QoS configurations for detailed
explanations of these two policies.
Configuration Commands: Dual T1 With Private Lines
Listed below are the key configuration components that can be added to the SSG
Family configurations when using dual T1 interfaces over private lines.
As in the previous example, the SSG Family can support Cisco HDLC, PPP and
frame Relay thereby ensuring interoperability with other networking components.
Please refer to the previous example for appropriate HDLC, PPP and Frame
Relay configuration commands.
HDLC, PPP and Frame Relay Configuration Commands:
PC-1
PC-2
FW-1
Remote Office
(OSPF Area 55)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
PC-1
SSG-1
2 x T1s
PC-2
FW-1
Remote Office
(OSPF Area 56)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
2 x Routers
w// T1 interface
PC-1
PC-2
FW-1
Remote Office
(OSPF Area 55)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
PC-1
SSG-1
2 x T1s
PC-2
FW-1
Remote Office
(OSPF Area 56)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
2 x Routers
w// T1 interface
10 Copyright © 2006, Juniper Networks, Inc

Please refer to the previous example for appropriate OSPF, HDLC, PPP and
Frame Relay configuration commands.
OSPF and Static Route Configuration Commands:
set route 0.0.0.0/0 interface serial1/0 gateway 10.1.2.36
set route 0.0.0.0/0 interface serial1/1 gateway 10.1.3.36
set interface serial1/0 protocol ospf area 0.0.0.0
set interface serial1/0 protocol ospf enable
set interface serial1/0 protocol ospf retransmit-interval 5
set interface serial1/0 protocol ospf cost 64
set interface serial1/1 protocol ospf area 0.0.0.0
set interface serial1/1 protocol ospf enable
set interface serial1/1 protocol ospf retransmit-interval 5
set interface serial1/1 protocol ospf cost 64
set interface ethernet0/1 protocol ospf area 0.0.0.55
set interface ethernet0/1 protocol ospf enable
set interface ethernet0/1 protocol ospf retransmit-interval 5
set interface ethernet0/1 protocol ospf cost 1
QoS configuration commands:
set policy id 1 name "SIP " from "Trust" to "Untrust" "Any" "Any"
"SIP" permit traffic gbw 128 priority 1
set policy id 1
set policy id 3 from "Trust" to "Untrust" "Any" "Any" "ANY"
permit
set policy id 3
Scenario Topology: Dual T1 With ISP Redundancy
This scenario expands upon the previous example, using VPN tunnels across
dual T1s, each of which is connecting to a separate ISP. Utilizing the ISP
infrastructure as opposed to private lines allows enterprise customers to utilize
inexpensive WAN links to establish secure and low-cost connectivity solution.
The T1 interfaces in SSG-1 are classified into the untrust zone. Two static routes
were defined on the SSG-1 pointing to routers owned by the ISP as default
gateway to reach hosts on the Internet (e.g., google.com) as well as
headquarters. ECMP is used in order for the SSG to take advantage of both T1
links. Using the Internet provides fully meshed connectivity between both SSG
since there are possibilities where one T1 on SSG is down but still reachable via
the 2
nd
T1. A Loopback interface will serve as the “anchor” for the VPN so that
VPN can be routed over either one of T1 connections. OSPF would be the
recommended protocol on the IPSec VPN (tunnel) interfaces as stated in the
single T1 scenario. This will ease the management of large scale IPSec VPN
tunnel roll-out because OSPF will discover redundant VPN routes automatically
in the event that one ISP connection fails.
11 Copyright © 2006, Juniper Networks, Inc

A route-based VPN is used in this application as a policy-based VPN does not
allow multiple policies (VoIP over VPN and regular VPN) to be built between
same source and destination. Tunnels are required for route-based VPN; with
tunnel interfaces assigned on the untrust zone. QoS commands can be applied
from previous section if QoS is desired.
HDLC, PPP and Frame Relay Configuration Commands:
Please refer to the previous example for appropriate OSPF, HDLC, PPP and
Frame Relay configuration commands.
OSPF and Static Route Configuration Commands:
set route 0.0.0.0/24 interface serial1/0 gateway 10.1.2.36
set route 10.1.1.0/24 interface serial1/1 gateway 10.1.3.36
set route 10.1.5.0/24 interface tunnel.1
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf enable
set interface tunnel.1 protocol ospf retransmit-interval 5
set interface tunnel.1 protocol ospf cost 10

QoS configuration commands:
set policy id 1 name "SIP " from "Trust" to "Untrust" "Any" "Any"
"SIP" permit traffic gbw 128 priority 1
set policy id 1
set policy id 3 from "Trust" to "Untrust" "Any" "Any" "ANY"
permit
set policy id 3

Using MLPPP (RFC1990) in a Dual T1 Configuration
Multilink PPP (MLPPP) is a method of enabling one or more physical (PPP)
interfaces to be aggregated into a bundle. Packet sessions can be spilt,
recombined and re-sequenced across the MLPPP bundle, thereby improving
PC-1
PC-2
FW-1
Remote Office
2 x Routers
w/ T1 interface
SSG-1
w/ 2 x T1s
ISP Networks
/ Internet
Headquarter
PC-1
PC-2
FW-1
Remote Office
2 x Routers
w/ T1 interface
SSG-1
w/ 2 x T1s
ISP Networks
/ Internet
Headquarter
12 Copyright © 2006, Juniper Networks, Inc

resiliency of the connection. Note that all PPP links in the MLPPP bundle cannot
be split across multiple devices - the MLPPP bundle must be on the same source
and or destination device.
In the event that interface failover (T1 primary to T1 secondary) occurs, sessions
and connections that were in process during the failover are maintained when
using MLPPP.

In cases where the SSG is connecting to a non-SSG platform, it is important to
note that ScreenOS on the SSG Family do not support PPP, TCP or UDP
compression over MLPPP. To ensure interoperability MLPPP compression will
need to be disabled on those (non-SSG Family) devices supporting compression.
Route based VPN were used for the VPN application of MLPPP in order to
provide QoS via policies for different traffic – SIP or regular data packets. “ip
unnumbered” was used on the Tunnel interfaces in order to conserve the IP
address. QoS commands are the same as those used in the previous
configuration example.
Using MLFR in a Dual T1 Configuration
Multilink Frame Relay (MLFR) in ScreenOS is based on the Frame Relay Forum
FRF.16, Multilink Frame Relay UNI/Network-to-Network Interface (NNI)
Implementation Agreement. Like MLPPP, this feature provides a cost-effective
way to increase bandwidth and resiliency for particular applications by enabling
multiple serial links to be aggregated into a single bundle of bandwidth. Like
MLPPP, MLFR requires PVCs to be sourced and terminated on the same
chassis.
Configuration Commands: Dual T1 With ISP Redundancy
MLPPP Configuration Commands:
set interface "ethernet0/1" zone "Trust"
set interface "serial1/0" zone "Untrust"
set interface "serial1/1" zone "Untrust"
set interface "ml1" zone "Untrust"
set interface "tunnel.1" zone "Trust"
PC-1
PC-2
FW-1
Remote Office
(OSPF Area 55)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
PC-1
SSG-1
2 x T1s in
MLPPP Bundle
PC-2
FW-1
Remote Office
(OSPF Area 56)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
Router-1
PC-1
PC-2
FW-1
Remote Office
(OSPF Area 55)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
PC-1
SSG-1
2 x T1s in
MLPPP Bundle
PC-2
FW-1
Remote Office
(OSPF Area 56)
HQ LAN
(OSPF Area 55)
HQ WAN
(OSPF Area 0)
Router-1
13 Copyright © 2006, Juniper Networks, Inc

set interface "ml1" encap mlppp
set interface ethernet0/1 ip 10.1.1.55/24
set interface ml1 ip 10.1.2.55/24
set interface tunnel.1 ip 192.168.1.55/24
set ppp profile "MLPPP1"
set ppp profile "MLPPP1" netmask 255.255.255.0
set ppp profile "MLPPP1" static-ip
set interface "ml1" ppp profile MLPPP1
set interface serial1/0 bundle ml1
set interface serial1/1 bundle ml1
MLFR Configuration Commands:
set interface "ethernet0/1" zone "Trust"
set interface "serial1/0" zone "Untrust"
set interface "serial1/1" zone "Untrust"
set interface "ml2" zone "Untrust"
set interface "ml2.1" zone "Untrust"
set interface "tunnel.1" zone "Untrust"
set interface "ml2" encap mlfr-uni-nni
set interface ethernet0/1 ip 10.1.1.55/24
set interface ml2.1 ip 10.1.2.55/24
set interface tunnel.1 ip unnumbered interface ethernet0/1
set interface serial1/0 bundle ml2
set interface serial1/1 bundle ml2
set interface "ml2.1" frame-relay dlci 100
set interface "ml2.1" frame-relay inverse-arp
VPN Configuration Commands:
set ike gateway "VPN to 56" address 10.1.2.56 Main outgoing-
interface "ml1" preshare "bxP4jaZBNMAJresXw6CN6EArhqnofT8TDQ=="
sec-level standard
set vpn "VPN to 56" gateway "VPN to 56" no-replay tunnel idletime
0 sec-level standard
set vpn "VPN to 56" id 4 bind interface tunnel.1
OSPF Configuration Commands:
set interface ethernet0/1 protocol ospf area 0.0.0.55
set interface ethernet0/1 protocol ospf enable
set interface ethernet0/1 protocol ospf retransmit-interval 5
set interface ethernet0/1 protocol ospf cost 1
set interface ml1 protocol ospf area 0.0.0.0
set interface ml1 protocol ospf enable
set interface ml1 protocol ospf retransmit-interval 5
set interface ml1 protocol ospf cost 10
QoS Configuration Commands:
Please refer to the previous example for appropriate QoS configuration
commands.

14 Copyright © 2006, Juniper Networks, Inc

Scenario Topology: Mix-and-match WAN interfaces
In this final scenario, the SSG device uses an Ethernet interface connected to an
external cable or xDSL modem as the primary WAN interface and a leased line
(fractional T1/E1) as the backup. The SSG is configured to utilize bandwidth
across both cable/xDSL modem and leased line under normal operations.
The left hand diagram illustrates the physical connection at the remote site.
SSG-1 employs a dual connection – one xDSL/Cable connection (via Ethernet to
SSG-1) and one point-to-point leased line to corporate headquarters. Under
normal conditions, all unencrypted traffic is transmitted via the xDSL/Cable; serial
interface would provide IPSec tunnel back to headquarters. Traffic will be moved
to the survival link if either xDSL/Cable or leased line is down.
The right hand diagram illustrates the logical connections with two VPN tunnels
between SSG-1 and FW-1. VPN over serial interface carries a manually
assigned lower cost and will be selected by OSPF as the preferred route
between PC-1 and PC-2. VPN over xDSL/Cable will be selected if the
connection over the serial interface is broken.
Unencrypted traffic will use xDSL/Cable as the primary connection. In the event
of xDSL/Cable unavailable, a default route / Internet connection from
headquarters is advertised via OSPF to SSG-1. In this scenario, SSG-1 can use
the serial interface to reach the Internet. QoS commands are the same as those
used in the previous configuration examples.
Configuration Commands: Mix and Match WAN Interfaces
Interface Configuration Commands:
set interface "ethernet0/1" zone "Trust"
set interface "serial1/0" zone "Untrust"
set interface "serial1/1" zone "Untrust"
set interface "tunnel.1" zone "Untrust"
set interface "tunnel.2" zone "Untrust"
set interface "serial1/0" encap ppp
set interface ethernet0/1 ip 10.1.1.55/24
set interface serial1/0 ip 10.1.2.55/24
PC-2
PC-1
FW-1
SSG-1
Ethernet
Interface
Serial
Interface
PC-2
PC-1
HQ WAN
OSPF Area 0
FW-1
SSG-1
Remote Office
OSPF Area 55
HQ LAN
OSPF Area 55
VPN over
Ethernet / xDSL
VPN over
Serial Interface
PC-2
PC-1
Headquarter
-1
‘net
Remote Office
Router-1
Interface
PC-2
PC-1
SSG-1
VPN over
Ethernet / xDSL
VPN over
Serial Interface
15 Copyright © 2006, Juniper Networks, Inc

set interface tunnel.1 ip 192.1.1.55/24
set interface tunnel.2 ip 172.1.1.55/24
set ppp profile "PPP1"
set ppp profile "PPP1" netmask 255.255.255.0
set ppp profile "PPP1" static-ip
set interface "serial1/0" ppp profile PPP1
VPN Configuration Commands:
set ike gateway "gw56" address 10.1.2.56 Main outgoing-interface
"serial1/0" preshare "9OE1rfbwNP00C2soGcCy7MskJ0nn6Vf6Bw==" sec-
level standard
set ike gateway "gw56-1" address 10.1.4.56 Main outgoing-interface
"ethernet0/2" preshare "lktBHDO4NwNJfOsAXTC7nVlcXrn96EXfRA==" sec-
level standard
set ike respond-bad-spi 1
set vpn "vpn56" gateway "gw56" no-replay tunnel idletime 0 sec-
level standard
set vpn "vpn56" monitor
set vpn "vpn56" id 1 bind interface tunnel.1
set vpn "vpn56-1" gateway "gw56-1" no-replay tunnel idletime 0
sec-level standard
set vpn "vpn56-1" monitor
set vpn "vpn56-1" id 2 bind interface tunnel.2
OSPF Configuration Commands:
set route 0.0.0.0/0 interface ethernet0/2 gateway 10.1.4.1
preference 20
set interface ethernet0/1 protocol ospf area 0.0.0.55
set interface ethernet0/1 protocol ospf enable
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf enable
set interface tunnel.2 protocol ospf area 0.0.0.0
set interface tunnel.2 protocol ospf enable
set interface tunnel.2 protocol ospf cost 20
QoS Configuration Commands:
Please refer to the previous example for appropriate QoS configuration
commands.

16 Copyright © 2006, Juniper Networks, Inc

Appendix 1: – Troubleshooting and Debug commands
Single Point-to-Point WAN Connection, No VPN
• All WAN connection protocol
o Use “
get interface serial a/b
” to obtain link, link protocol and physical status of
serial interface.
o Check T1/E1 related configuration, e.g., framing, encoding and number of time slot
information from “
get interface serial a/b
”.
• Cisco HDLC
o Ensure HDLC keep-alive setting identical on both SSG-1 and other device
o Use “
debug hdlc all
” to see the HDLC handshake status.
• PPP
o Ensure PPP keep-alive setting identical on both SSG-1 and other device
o Use “
debug ppp all
” to see the HDLC handshake status.

• Frame Relay
o Ensure Frame Relay LMI /DLCI agrees with the setting provided by the service
provider.
o Use “
debug frame all
” to see the Frame Relay messages. Pay special attention to
LMI related messages.

Single Point-to-Point WAN Connection, VPN
• Use WAN interface related commands to establish WAN connectivity
• “
get event | include 536
” to observe VPN related messages
• “
get sa active
” and “
get ike cookies
” to observe VPN Phase 1 & 2 related information
• “
set ffilter ip-proto 1
”, “
debug flow basic
” and fire a ping packet between source
and destination of the VPN tunnel then review the packet flow via “
get db stream
” to review
how the packet was processed.

Multi-link (MLPPP and MLFR) WAN Connections
o Break the multi-link bundle to make sure each physical T1/E1 interface can properly
establish link
o Perform WAN protocol (PPP or Frame Relay) related commands to troubleshoot any
connectivity related problems, if necessary.
o Use “
debug ml ppp
” or “
debug ml fr
” or to troubleshoot MLPPP or MLFR related
problems.