Академический Документы
Профессиональный Документы
Культура Документы
Table of Contents
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Protocol Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Step 1. Branch Office Device Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Step 2. Head End Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Step 3. Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
At the Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
At the Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Prefix Advertisement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix 1: Branch Office Type A Basic Profile Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix 2: Branch Office Type B Optimized Profile Configuration . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix 3: Branch Office Type C Critical Profile Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 21
About Juniper Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Introduction
Designing and deploying network infrastructure for assured network connectivity between branch
offices and data centers presents a challenge for high-performance organizations. They must deploy
a secure and reliable enterprise network infrastructure that connects large-scale branch office
deployments to the data center using an IPSec-based VPN overlay.
As detailed in the Branch Reference Architecture document (see Figure 1), Juniper Networks classifies
branch office architectures into three branch office profiles Branch Office Type A - Basic, Type B Optimized, and Type C - Critical. From a network perspective, the branch offices are defined as:
Branch Office Type A Basic: Typically a single device with single or dual Internet
connections. This profile is designed for small branch office locations (i.e., retail facilities,
small offices, etc.) and supports a very basic feature set and standard availability.
Branch Office Type B Optimized: Consists of two devices, fully meshed with a private WAN
and an Internet connection and supports small to medium size branch office locations and
offers high availability.
Branch Office Type C Critical: Consists of two routers and two secure services gateways,
in a fully meshed configuration, with Internet and private WAN connectivity. This profile
provides highest level of performance and availability and is designed to support diverse
requirements for services like VoIP, video etc.
The branch types and the services they provide are derived from a basic reference architecture in
which the connectivity between branches and data centers/head offices is provided via the use of a
public network (the Internet) and the use of private WAN/MAN networks (either using PTP point-topoint lines, a metro Ethernet solution or Layer2/Layer3-based VPNs).
Data Center B
Branch Office Type A
Basic Profile
J-series or SSG
J-ser
EX 3
Serie200
s
ies
Data Center A
Inter
net/
WAN
J-series or SSG
J-ser
J-ser
WX/
WXC
J-ser
ies
SSG
ies
SSG
EX 4
Serie200
E
X 4s
Serie200
s
WX/
WXC
J-ser
ies
Virtual Chassis
EX 4
Serie200
EX
4s
Serie200
s
ies
J-series or SSG
Virtual Chassis
Scope
This Application Note is designed to provide information about how to use Auto Connect VPN (AC
VPN) as part of an overall IPSec VPN network implementation. It offers configuration examples and
how-to information relevant to configure the branch office devices for dynamic connection using AC
VPN. A monitoring section is also included.
The Design Guide for Connectivity document captures all of the design considerations for
implementing branch office connectivity using an IPSec VPN overlay. Branch office HA designs are
detailed in the Branch Office HA Application Note.
Protocol Operation
AC VPN is a feature developed by Juniper Networks that allows the dynamic creation of branch-tobranch IPSec tunnels. These tunnels are created on an on-demand basis and are triggered by the
traffic generated at any given branch office. To accomplish this, AC VPN makes use of the NHRP. This
protocol was originally developed for non-broadcast multiple access (NBMA) networks and intended
to provide a discovery mechanism for stations to discover the L2 address of a device connecting to a
particular L3 network (or the egress router for that particular destination).
NHRP is reused and augmented to achieve a similar taskthat is, to discover the public IP address
of a VPN termination endpoint so whenever a branch office needs to send traffic to another branch
office, this office can establish an IPSec tunnel directly to the destination branch. To this effect, the
branch originating the traffic can use NHRP to discover the public IP address of the remote branch.
Some proprietary extensions have been added to the protocol and provide a way to simplify the
provisioning of these tunnels. Before presenting the details, it is important to understand the required
base topology of the network that is required for NHRP to work.
In order for AC VPN to work, it is necessary to have a star topology network that connects all the
branches to a central hub, as shown in Figure 2. The branch offices use these tunnels to register
the networks directly connected to each of them. The regional office stores (in a local database) a
mapping of all the networks that each branch office registered, together with the public IP address
each branch uses to terminate IPSec. Some additional information that helps the branches to
authenticate each other is also stored here.
Branch 2
Branch 1
Branch N
Manually Configured
Tunnel
PTP
Manually Configured
Tunnel
Network/
Internet
Regional
Office
Branch 1 (NHC)
Branch N
ACVPN Provisioned
Tunnel
Manually Configured
Tunnel
NHRP
Next Hop Server
PTP Network/
Internet
Manually Configured
Tunnel
Regional
Office
Design Considerations
The following are the design considerations and assumptions associated with this implementation:
The Next Hop Server (NHS) address must be the address of the tunnel interface terminating
the IPSec tunnels from the branch offices. In particular, the NHS will not detect requests on
loopback interfaces.
A device can only act as a Next Hop Client (NHC) or an NHS but not both. That is, hierarchies
are not supported.
On Type B - Optimized branch offices, no AC VPN is provided for the secondary device. That
is, in the event of a failure, the AC VPN service will not be available and traffic will be routed
through the hub.
When using Active/Active NetScreen Redundancy Protocol (NSRP), neither the Security
Associations (SAs) nor the Next Hop Resolution Protocol (NHRP) caches will be synchronized.
In the event of a failover, a new NHRP registration will be performed, and branch-to-branch
tunnels will have to be reestablished. This will not, however, have an impact on branch-tobranch traffic, as this traffic will still be routed through the hub.
Branch offices only that are connected to the same hub (that is, a data center or regional
office) can establish IPSec shortcuts between themselves. When branches are not connected
to the same regional office/data center, traffic flows using the preexisting topology.
AC VPN only establishes shortcuts between branch offices connected to the same hub for
multi-tier topologies. In a network like the one shown in Figure 4, only branch offices in
the same region will be able to establish shortcuts. However, traffic between branch offices
can still use normal routing and go through the different hubs until it reaches the desired
destination.
Branch 2
Branch 1
Branch N
IPSec
Tunnel
PTP Network/
Internet
IPSec
Tunnel
Regional
Office
IPSec Tunnel
or PTP Connection
IPSec Tunnel
or PTP Connection
PTP Network/Internet
Data
Center A
Data
Center B
IPSec Tunnel
or PTP Connection
IPSec
Tunnel
Branch
IPSec
Tunnel
Branch
IPSec
Tunnel
IPSec IPSec
Tunnel Tunnel
Branch
Branch
Branch
Implementation
Only a few things have to be configured to enable AC VPN. At each branch, NHRP has to be enabled
and an AC VPN dynamic VPN has to be configured. At the data center (hub or VPN termination
points) you need to enable NHRP and configure the VPN profile that branches use to connect to each
other. To perform this configuration, the following three steps need to be performed:
1. Configure each of the branch devices
2. Configure the devices at the head end
3. Verify the correct operation
Enable NHRP on the vr and tunnel interfaces connecting to the hub and configure the IP address of
the NHS:
set protocol nhrp
set protocol nhrp nhs <IP address of the tunnel interface of the HUB>
set interface <tunnel interface connecting to the HUB> protocol nhrp enable
Finally, statically add the networks that seek to be advertised to the NHS:
set protocol nhrp cache <advertised network IP/netmask>
Enable NHRP on the vr terminating the tunnels and on each tunnel interface connecting to a branch:
set protocol nhrp
set interface <tunnel interface connecting to the branch> protocol nhrp enable (Note, this command
has to be repeated for each tunnel interface that connects to branches using ACVPN)
The ScreenOS security configuration examples for each of the branch office profile types (Type A Basic, Type B - Optimized and Type C - Critical) can be found in Appendices 1, 2 and 3.
Step 3. Validation
The protocol operation can be monitored, both at the head end and at each branch. To begin,
it is useful to make sure that NHRP is configured. The command get protocol nhrp will show
information on the NRHP timers and interfaces.
At the Hub
hostname->get vr trust-vr protocol nhrp
NHRP instance at Vroute(trust-vr):
--------------------------------------------------------------------------NHRP Server
: 0.0.0.0
holdtime
: 300
resolution-request retry
: 6
retry interval
: 3 sec
: 7
: 0
pending resolution-request : 0
NHRP enabled interface
ACVPN profile in use
: 9
: acvpn
-----------------------------------------------------------------interface
Enabled Req-ID
-----------------------------------------------------------------tunnel.1
Yes
39
At the Branch
hostname->get vr trust-vr protocol nhrp
NHRP instance at Vroute(trust-vr):
--------------------------------------------------------------------------NHRP Server
: 10.255.1.254
holdtime
: 300
resolution-request retry
: 6
retry interval
: 3 sec
: 2
: 1
pending resolution-request : 0
NHRP enabled interface
ACVPN profile in use
: 1
: none
-----------------------------------------------------------------interface
Enabled Req-ID
-----------------------------------------------------------------tunnel.1
Yes
In both cases the previous example indicates that NHRP is enabled and configured on the tunnel
interface 1. At the branch office one can see the configured address of the NHS (which is obviously
0.0.0.0 at the hub). It is also useful to observe that the total number of NHRP cache entries differs
significantly at the hub than at each branch.
Prefix Advertisement
The NHS hub will receive all the prefixes advertised by every branch, as shown in the following:
hostname->get vr trust-vr protocol nhrp cache
------------------------------------------------------------------------------flags: R-registered, C-cached, L-replied, P-pushed, S-static, I-imported,
F-in FIB, D-being deleted.
------------------------------------------------------------------------------Prefix
Expire(in sec)
Flags
------------------------------------------------------------------------------10.5.5.0/24
1.4.0.248
10.255.1.5
128
RF 201
10.5.1.0/24
1.2.1.252
10.255.1.1
128
RF 297
10.5.3.0/24
1.2.1.249
10.255.1.2
128
RF 201
10.140.0.0/24
1.4.17.24
10.255.1.140
128
RF 243
10.140.1.0/25
1.4.17.24
10.255.1.140
128
RF 243
10.255.1.140/32
1.4.17.24
10.255.1.140
128
C 243
10.255.1.5/32
1.4.0.248
10.255.1.5
128
CF 201
10.255.1.1/32
1.2.1.252
10.255.1.1
128
C 297
10.255.1.2/32
1.2.1.249
10.255.1.2
128
CF 201
Branch offices will only receive a prefix from the hub when they forward traffic to another branch
office through the hub. After NHRP is configured, only the static entries will be present in the cache.
hostname->get vr trust-vr protocol nhrp cache
------------------------------------------------------------------------------flags: R-registered, C-cached, L-replied, P-pushed, S-static, I-imported,
F-in FIB, D-being deleted.
------------------------------------------------------------------------------Prefix
Expire(in sec)
Flags
------------------------------------------------------------------------------10.5.1.0/24
0.0.0.0
0.0.0.0
128
S 300
However, once traffic is exchanged between two branch offices with NHRP enabled, the caches at
each branch will be populated (by the hub) with information about each other.
hostname->get vr trust-vr protocol nhrp cache
------------------------------------------------------------------------------flags: R-registered, C-cached, L-replied, P-pushed, S-static, I-imported,
F-in FIB, D-being deleted.
------------------------------------------------------------------------------Prefix
sec)
Flags Expire(in
-------------------------------------------------------------------------------
10
0.0.0.0
0.0.0.0
128
S 300
10.5.3.0/24
1.2.1.249
0.0.0.0
P 213
NHRP will also send information to the branches about the certificates used by each peer for IPSec
authentication. This information can be seen viewed with the get nhrp peer command.
hostname->get vr trust-vr protocol nhrp peer
------------------------------------------------------------------------------Learned peers (Total = 1):
------------------------------------------------------------------------------Peer nhop prot
Self-cert-hash
ID type ID
Summary
The use of AC VPN allows the dynamic creation of branch-to-branch IPSec tunnels to efficiently
communicate between branch offices connected to the same regional office or data center. NHRP
is used to discover the public IP address of a VPN termination endpoint. Whenever a branch office
needs to send traffic to another branch office, the source branch establishes an IPSec tunnel directly
to the destination branch and that tunnel is designated as an NHRP route.
11
12
13
14
#NHRP has to be enabled on the tunnel interface connecting to the DC. This
MUST be a numbered interface.
set interface tunnel.3 protocol nhrp enable
#RIP using on-demand circuit extensions has to be enabled on the tunnel
interfaces for the RIP exchange to take place.
set interface tunnel.3 protocol rip
set interface tunnel.3 protocol rip enable
set interface tunnel.3 protocol rip metric 2
set interface tunnel.3 protocol rip demand-circuit
set interface bgroup0 protocol rip
set interface bgroup0 protocol rip enable
set interface bgroup0 protocol rip passive-mode
set interface tunnel.4 protocol rip
set interface tunnel.4 protocol rip enable
set interface tunnel.4 protocol rip metric 2
set interface tunnel.4 protocol rip demand-circuit
set interface tunnel.7 protocol rip
set interface tunnel.7 protocol rip enable
set interface tunnel.7 protocol rip metric 2
set interface tunnel.7 protocol rip demand-circuit
set interface tunnel.8 protocol rip
set interface tunnel.8 protocol rip enable
set interface tunnel.8 protocol rip metric 2
set interface tunnel.8 protocol rip demand-circuit
15
16
17
18
#Route maps are used to filter the routes advertised by this branch and
received from the Data Centers.
set access-list 1
set access-list 1 permit ip 172.18.0.0/16 1
set access-list 1 permit ip 192.168.4.0/24 2
set access-list 1 permit ip 192.168.5.0/24 3
set access-list 1 deny ip 10.128.0.0/9 8
set access-list 1 deny ip 10.0.0.0/9 9
set access-list 1 permit ip 10.0.0.0/8 10
set access-list 1 permit default-route 11
set access-list 2
set access-list 2 permit ip 10.20.0.0/16 1
set access-list 3
set access-list 3 permit ip 0.0.0.0/0 1
set route-map name remoteNetworks permit 1
set match ip 1
exit
set route-map name localNetworks permit 1
set match ip 2
exit
set route-map name rejectAll deny 1
set match ip 3
exit
#NHRP protocol
#Note that the NHS server address is the address of the tunnel interface at
the remote end of the IPSec tunnel, connecting to the DC.
#We also have to manually declare the networks we want to advertise to the
NH.
set protocol nhrp
set protocol nhrp nhs 10.255.5.254
set protocol nhrp cache 10.20.2.0/24
set protocol bgp 65100
unset synchronization
set reject-default-route
set neighbor 172.31.254.15 remote-as 65100 outgoing-interface loopback.10
set neighbor 172.31.254.15 enable
set neighbor 172.31.254.15 send-community
set neighbor 172.31.254.15 nhself-enable
set neighbor 172.31.255.15 remote-as 65100 outgoing-interface loopback.10
set neighbor 172.31.255.15 enable
set neighbor 172.31.255.15 send-community
set neighbor 172.31.255.15 nhself-enable
set redistribute route-map localNetworks protocol connected
exit
19
20
21
22
23
24
25
26
27
CORPORATE HEADQUARTERS
AND SALES HEADQUARTERS FOR
NORTH AND SOUTH AMERICA
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
Copyright 2008 Juniper Networks, Inc. All rights reserved. Juniper Networks,
the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks
of Juniper Networks, Inc. in the United States and other countries. JUNOS and
JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service
marks, registered trademarks, 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.
28