implementing a bgp configuration on ipsec-based … note - implementing a bgp configuration on...

APPLICATION NOTE

Copyright © 2009, Juniper Networks, Inc.

ImplementIng a Bgp ConfIguratIon on IpSeC-BaSed VpnS

Minimizing the Impact on VPN Concentrators by Using Route Reflectors to Concentrate BGP Sessions

ii Copyright © 2009, Juniper Networks, Inc.

applICatIon note - Implementing a Bgp Configuration on Ipsec-Based Vpns

Table of Figuresfigure 1: Branch office architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

figure 2: Border gateway protocol topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

figure 3: Bgp topology—static routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

figure 4: Bgp topology—static routes to branch loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Target Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Design Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

description and deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

BGP Routing Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

BGP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

appendix 1: Branch office type a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

appendix 2: Branch office type B Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

appendix 3: Branch office type C Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

appendix 4: Calculating routes, forwarding entries and Ipsec tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

about Juniper networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Copyright © 2009, Juniper Networks, Inc. 1


IntroductionDesigning 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, Type B and Type C. From a network perspective, the branch offices are defined as:

Branch office type a• —typically a single device with single or dual Internet connections. This profile is designed for small branch offices like retail facilities and small offices, and supports a very basic feature set and standard availability.

Branch office type B• —consists of two devices, fully meshed with a private WAN and an Internet connection. This profile supports small to medium size branch office locations, and offers high availability (HA).

Branch office type C• —consists of two routers and two secure services gateways in a fully meshed configuration, with Internet and private WAN connectivity. This profile provides the highest level of performance and availability, and is designed to support diverse requirements for services like VoIP and video.

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, using either PTP point-to-point lines, a metro Ethernet solution or Layer2/Layer3-based VPNs.

figure 1: Branch office architecture

J Series

SSG SeriesWX Series/WXC Series

SSG Series

DATA CENTER 2DATA CENTER 1 BRANCH OFFICE TYPE A

BRANCH OFFICE TYPE B

BRANCH OFFICE TYPE C

J Series

SSG Series WX Series/WXC Series

SSG Series

SSG Series

WAN

INTERNET

2 Copyright © 2009, Juniper Networks, Inc.


ScopeThis applications note is designed to provide information about how to use BGP as part of an overall IPsec VPN network implementation where more than 1000 branch offices are connected over a single converged enterprise network. It offers configuration examples and “how to” information relevant to connecting large numbers of branch offices using both IPsec-based VPN as a tunneling mechanism and BGP.

Target AudienceIT managers•

Systems engineers•

Network analysts and engineers•

Network administrators•

Security managers •

Others with similar responsibilities•

For additional reference, the Design Guide for Connectivity document captures all of the design considerations for implementing branch office connectivity using an IPsec VPN overlay. Branch office high availability (HA) designs have been detailed in the Branch Office HA Application Note.

Design ConsiderationsThe following list summarizes the design assumptions and constraints about the size of the network. Unless otherwise stated, our recommendations assume that:

The routing design must be scalable. A large sized number of sites (> 1,000 sites) have to be able to be deployed •without significantly impacting the CPU resources or memory of the VPN devices.

Whenever redundant links are used, no single point of failure should be present. As seen on the reference •architecture, head and regional offices have more than one connection to the public and private networks. In the case of Type B and Type C branch offices, redundant paths have to be provided that use all of the links these branches have to the external networks.

Route aggregation must be performed whenever possible to reduce the size of the routing tables.•

Remote sites may be connected behind Network Address Translation (NAT) devices. Some small branches and •remote users share Internet connectivity with other users, and in such cases, the IP addresses assigned to them may be private.

Provisioning is easy. When there are a large number of sites, it is important to reduce the complexity of the •configuration on a per-site basis, wherever possible. That is, configurations that must be performed multiple times should be as simple as possible.

Link-failure detection mechanisms are recommended. Because IPsec tunnels are built using a Layer 3 •infrastructure, routing failures are possible where neither of the extremes of the tunnel are notified of the malfunction. Traditional BGP keepalive mechanisms can be slow to converge, so it is preferable to use VPN monitor to detect link failures, as it provides a fast convergence.



Design RequirementsThe network design requirements associated with a BGP implementation are provided in Table 1 and Table 2. The equations used to calculate the data presented in Table 1 may be found in Appendix 4.

Table 1: Routing, Forwarding and Tunneling Scale NUMBER OF BRANCH OFFICES

NUMBER OF ROUTES NUMBER OF FORWARDING ENTRIES

NUMBER OF TUNNELS

1,000 4,000 4,000 w/ ECMP: 2,000 w/out ECMP

2,000

5,000 20,000 20,000 w/ ECMP: 10,000 w/out ECMP

10,000

Note: Additional regional office hubs add to the overall scale.

Table 2: Routing Scale Mapped by ProductPLATFORM ISG1000 ISG2000 SSG550Mmax number of Ipsec tunnels

2,000 10,000 1,024

max number of routes 10,000 20,000 20,000

max number of forwarding entries

10,000 20,000

Note: Additional regional office hubs add to the overall scale.

Hardware RequirementsBranch Office—Juniper Networks SSG Series Secure Services Gateways including: SSG5, SSG20, SSG140, •SSG320M, SSG550M, and Juniper Networks J Series Services Routers

Data Center—Juniper Networks ISG1000 Integrated Security Gateway and ISG2000 Integrated Security Gateway •

Software RequirementsJuniper Networks ScreenOS• ® version 6.0 or higher

Description and Deployment Scenario BGP is a routing protocol used in Internet core routers. It works by maintaining a table of IP networks (or “prefixes”) that designate network reachability. BGP does not use traditional Interior Gateway Protocol (IGP) metrics, but makes routing decisions based on path, network policies and/or preconfigured weights. Using BGP as a routing protocol offloads most of the routing propagation to a device other than the VPN devices. To do this, BGP implementations propagate routing information with the aid of route reflectors.

BGP Routing TopologyThe BGP routing topology shown in Figure 2 uses a pair of route reflectors (one on each data center) to concentrate all BGP sessions and to minimize the impact on the VPN concentrators. By using route reflectors, each VPN terminator only needs a single BGP session to each (as opposed to one BGP session to each of the branches). This means that independent of the IPsec tunnel topology, each branch will have two BGP sessions, one to each route reflector, in order to provide redundancy.



figure 2: Bgp topology

There are a few things to note. First, the branch offices should have sessions with the route reflectors but they should not be clients. Since we want to summarize everything sent from the branch offices as much as possible, routes received from a branch office should not be advertised to other branch offices, except in particular cases where no summarization is possible. Branch offices should only receive an aggregate of the whole network and not any more specific prefixes. By configuring the sessions between the route reflectors and the branches as non-client, routes received from the branches are only sent to the route reflector clients—in this case the VPN terminating routers.

The VPN terminating firewalls should each have a BGP session to each of the route reflectors. These should be client sessions of the route reflectors, since prefixes advertised by peers (for example, aggregates of the whole network) should be sent to every branch.

Loopback interfaces should be used to build the BGP peering sessions. The reason for this is twofold. First, loopbacks can be assigned from the same pool of addresses, allowing them to be easily summarized. This is mostly important in the branches where the next hop received for these routes corresponds to the BGP peer address. If these addresses are not easy to summarize, the VPN firewalls have to redistribute thousands of routes (one for each branch) to the IGP (OSPF in this diagram), in order for the BGP speakers on the network to resolve the next hop of the branch office prefixes. Instead, by summarizing these addresses, only a handful of routes and ideally only one is needed to inject into the IGP.

Secondly, if the branch offices have more than one connection to the Internet (or whatever transport network they are using), the use of a loopback allows Equal Cost Multipath (ECMP) to be performed without the need to configure two parallel BGP sessions between each branch and each data center. This minimizes the total number of peering sessions required.

DATA CENTER 1

OSPFAREA 0

DATA CENTER 2

IBGPRR Client

IBGPRR Client

IBGPRR Client

RR1

RR2

CE 1

CE N

IBGPnon-client

IBGPnon-client

IBGPnon-client

IBGPnon-client

AdvertisesCE 1 NetworksBGP session terminated on lo.0interface (10.255.255.1)

BGP AdvertisesDC 1 NetworkDC1 + DC2 Aggregate Network

BGP AdvertisesDC 1 NetworkDC1 + DC2 Aggregate Network

BGP sessions terminated onl0.0 interface (172.31.254.15)

BGP sessions terminated onl0.0 interface (172.31.254.15)

AdvertisesCE 1 NetworksBGP session terminated on lo.0interface (10.255.255.N)



So, as discussed previously, the set of routes needed to set up the BGP peering sessions is shown in Figure 3.

figure 3: Bgp topology—static routes

Please note that by propagating an aggregate of the loopback interfaces into the IGP (OSPF in this case), it is possible to black hole part of the traffic going to the branches. That is, in the unlikely event that a single branch office can establish the tunnels to only one data center (and not the other), traffic from the data center to the branch could be wrongly routed to the VPN concentrator that has no connectivity to the branch. This would not be a problem if none of the branches can establish their tunnels to the VPN concentrator, since in that case, the aggregate route pointing to the loopback network would cease to be advertised.

Another way to avoid this problem is to redistribute the static routes pointing to the loopback interfaces into BGP. In this way, whenever a branch loses connectivity with a particular VPN concentrator, that single host route stops being advertised, forcing the traffic to be rerouted to the other data center.

The above can also be used when distributing the load across multiple VPN concentrators on each data center. If more than one concentrator is used, the static routes pointing to the branch loopbacks must be distributed into the IGP. Since there could be several thousands of these, it is preferable to use BGP as the IGP in this case, and inject these routes into BGP.

With two tunnels connecting each branch office to each data center (Figure 4), customers have the choice of using both tunnels simultaneously with ECMP, or using only one of the tunnels. Using both tunnels simultaneously utilizes both links and connects each branch to both of the two tunnels simultaneously. For configurations that use only one tunnel, one link is used as primary and the other link is available as a backup. This is easily controlled by the manner in which the static routes at each end of the tunnel are configured.

DATA CENTER 1

DATA CENTER 2

OSPFAREA 0

BRANCHOFFICE

RR1

RR2

Static RoutesNet 10.255.255.0/24through tunnels 1 and 2 redistributed into OSPF

Static RoutesNet 10.255.255.0/24through tunnels 7 and 8redistributed into OSPF

lo0 IP 172.31.254.15terminates the BGP sessions


lo10 IP 172.31.255.7terminates the BGP

sessions

IPsec Tunnel 7

IPsec Tunnel 2

IPsec Tunnel 8

IPsec Tunnel 1


session to the RRs


sessions

Static RoutesNet 172.31.254.0/24

through tunnels 1 and 2Net 172.31.255.0/24

through tunnels 7 and 8



figure 4: Bgp topology—static routes to branch loopbacks

By configuring two static routes to the remote loopback interfaces with equal metrics on each endpoint—both the branch office and the VPN firewalls with enabling ECMP—the traffic is balanced across both tunnels.

Note: It is not necessary to configure two BGP sessions between each branch and each data center because of the recursive nature of BGP.

As an example, consider what happens when a branch office receives a prefix from one of the route reflectors. This prefix has the IP address of the peer that originated it as the next-hop IP (for example, the loopback IP address of the VPN firewall on data center 1). The branch firewall then performs a recursive lookup to determine how to reach that next hop. Since two routes are found with the same metric (the static routes we previously configured), the two next hops are installed in the routing and forwarding tables and ECMP is performed.

Finally, once the BGP sessions have been configured and established, route maps must be provisioned to control the advertisement of prefixes. Branch offices only advertise their locally connected networks, while the VPN firewalls advertise aggregates of their local networks and the aggregate of both data center networks (used only in case of failures in one data center).

BGP ConfigurationAppendix 1, 2 and 3 provide configuration examples for each of the branch office profiles (Types A through C respectively). The configuration text may be used to configure branch office SSG Series devices for use with BGP.

Summary The main advantages of using BGP for a routing protocol are that it can accommodate multiple devices and can scale to a large number of remote offices (between 1000 and 5000 locations). Route processing is somewhat distributed by the use of route reflectors, however each device must still go through the BGP route selection process. The number of sessions that each firewall has to maintain is minimal, as is the number of messages that it has to process.

DATA CENTER 1

DATA CENTER 2

OSPFAREA 0

BRANCHOFFICE

RR1

RR2

Static RoutesNet 10.255.255.1/32through tunnels 1 and 2 redistributed into BGP

Static RoutesNet 10.255.255.1/32through tunnels 7 and 8redistributed into OSPF




sessions

IPsec Tunnel 7

IPsec Tunnel 2

IPsec Tunnel 8

IPsec Tunnel 1


session to the RRs


sessions

Static RoutesNet 172.31.254.0/24

through tunnels 1 and 2Net 172.31.255.0/24

through tunnels 7 and 8



Appendix 1: Branch Office Type A Configuration The following configuration needs to be implemented on the branch device (appropriate SSG Series model, running ScreenOS 6.0).

#Zones Definitions

set zone “Trust” vrouter “trust-vr”

set zone “Untrust” vrouter “trust-vr”

set zone “DMZ” vrouter “trust-vr”

#Interface Configurations interface e0/0 and e0/1 are connected to the Internet and receive public addresses through DHCP. Interface bgroup0 is connected to the trust zone and has DHCP server enabled.

set interface “ethernet0/0” zone “Untrust”


set interface “ethernet0/6” zone “Trust”

set interface “bgroup0” zone “Trust”

set interface bgroup0 port ethernet0/2




set interface ethernet0/0 ip 1.4.0.253/24

set interface ethernet0/0 route



set interface bgroup0 ip 10.5.1.1/24

set interface bgroup0 route

set interface ethernet0/0 dhcp client enable

set interface ethernet0/1 dhcp client enable

set interface bgroup0 dhcp server service

set interface bgroup0 dhcp server auto

set interface bgroup0 dhcp server option gateway 10.5.1.1

set interface bgroup0 dhcp server option netmask 255.255.255.0

set interface bgroup0 dhcp server option domainname gamma.jnpr.net

set interface bgroup0 dhcp server option dns1 192.168.3.5

set interface bgroup0 dhcp server ip 10.5.1.10 to 10.5.1.25

unset interface bgroup0 dhcp server config next-server-ip



#Tunnel Interface Definitions

#Tunel.1 and Tunnel.2 terminate the tunnels going to DCA, while interface tunnel.7 and tunnel.8 terminate the vpn tunnels going to DCB.

set interface “tunnel.1” zone “vpn”




set interface tunnel.1 ip 10.255.1.1/24




#The loopback interface is used to terminate the IBGP sessions across the IPsec tunnels.

set interface “loopback.1” zone “Untrust”

set interface loopback.1 ip 10.255.255.2/32

set interface loopback.1 route

#This allows for asymmetric traffic inside the VPN tunnels. That is, if a tunneled packet arrives through a tunnel that fails the RPF check, the packet is still accepted.

set flow reverse-route tunnel prefer

#VPNMONITOR is enabled and the counters are set such that a failure will be detected in about 5 seconds.

set vpnmonitor threshold 5

set vpnmonitor interval 1

#IPsec tunnel definitions

set ike gateway “ISG2000-E_lo.1” address 1.2.0.6 Aggr local-id “SSG5-A_1” outgoing-interface “ethernet0/1” preshare “ZiWzJZf1NQtuCGsllrCBMSAh60n/fhFP4g==” sec-level standard

set ike gateway “ISG2000-E_lo.2” address 1.3.0.6 Aggr local-id “SSG5-A_2” outgoing-interface “ethernet0/0” preshare “ZiWzJZf1NQtuCGsllrCBMSAh60n/fhFP4g==” sec-level standard

set ike gateway “ISG2000-G_lo.1” address 1.2.0.25 Aggr local-id “SSG5-A_1” outgoing-interface “ethernet0/1” preshare “ZiWzJZf1NQtuCGsllrCBMSAh60n/fhFP4g==” sec-level standard

set ike gateway “ISG2000-G_lo.2” address 1.3.0.25 Aggr local-id “SSG5-A_2” outgoing-interface “ethernet0/0” preshare “ZiWzJZf1NQtuCGsllrCBMSAh60n/fhFP4g==” sec-level standard

set vpn “SSG5-A_to_ISG2000-E_1” gateway “ISG2000-E_lo.1” no-replay tunnel idletime 0 sec-level standard

set vpn “SSG5-A_to_ISG2000-E_1” monitor optimized rekey

set vpn “SSG5-A_to_ISG2000-E_1” id 3 bind interface tunnel.1

set vpn “SSG5-A_to_ISG2000-E_2” gateway “ISG2000-E_lo.2” no-replay tunnel idletime 0 sec-level standard





set vpn “SSG5-A_to_ISG2000-G_1” gateway “ISG2000-G_lo.1” no-replay tunnel idletime 0 sec-level standard

set vpn “SSG5-A_to_ISG2000-G_1” monitor optimized rekey

set vpn “SSG5-A_to_ISG2000-G_1” id 7 bind interface tunnel.7

set vpn “SSG5-A_to_ISG2000-G_2” gateway “ISG2000-G_lo.2” no-replay tunnel idletime 0 sec-level standard



set vrouter “trust-vr”

set router-id 10.255.255.2

set max-ecmp-routes 4

#BGP configuration

set protocol bgp 65100

set enable

#Disable BGP sync so that a route received only through BGP will still be accepted.

unset synchronization

#Neighbors declaration. Note that nhself is enabled so that the next hop sent on the routes originated by this device will be the address of the loopback.1 interface. (10.255.255.2).

set neighbor 172.31.255.15 remote-as 65100 outgoing-interface loopback.1

set neighbor 172.31.255.15 enable

set neighbor 172.31.255.15 send-community

set neighbor 172.31.255.15 nhself-enable





exit

set access-list 1

set access-list 1 permit ip 172.18.0.0/16 1



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 2




#Route map definitions

#remoteNetworks: Matches all the networks sent by each data center. Note that the network 10.0.0.0/8 is accepted, but no specific routes in that range will be. This route map can be used (but is not mandatory) to filter out the routes sent by the HUB.

set route-map name “remoteNetworks” permit 1

set match ip 1

exit

#localNetworks: Matches the Trust zone networks (10.5.1.0/24 in this case).

set route-map name “localNetworks” permit 1

set match ip 2

exit

unset add-default-route

#Static Routes

#These static routes point to the loopback networks of each data center (172.31.254.0/24 to DCA, 172.31.255.0/24 to DCB and an aggregate of all the loopbacks network 172.31.252.0/22 through both DCA+DCB). Note that by controlling the route metrics, it is possible to choose which IPsec tunnel is going to be primary and which is going to be a backup.

set route 172.31.254.0/24 interface tunnel.1 gateway 10.255.1.254








#These static routes force each of the parallel tunnels to use a different outgoing link. That is, the branch has two tunnels going to each DC. Each of these tunnels is going to use a different egress interface.

set route 1.3.0.0/27 gateway 1.4.0.1


#Advertise all of the local subnets (Trust network in this example) through BGP.

set protocol bgp

set redistribute route-map “localNetworks” protocol connected

exit

exit



#Enable BGP on the tunnel interfaces.

set interface tunnel.1 protocol bgp






Appendix 2: Branch Office Type B Configuration The following configuration needs to be implemented on the branch device (appropriate SSG Series model, running ScreenOS 6.0).

#Zone Definitions




set zone “VLAN” vrouter “trust-vr”

set zone id 101 “VPN”

set zone id 102 “Guest”

set zone “Trust” tcp-rst

unset zone “Untrust” block

set zone “Untrust” asymmetric-vpn

set zone “DMZ” tcp-rst

set zone “Guest” tcp-rst

#Interface Definitions

#Interface s1/0 connects to the PTP network

set interface “serial1/0” zone “Untrust”

set interface “serial1/0” encap ppp

set interface serial1/0 t1-options fcs 32

set interface serial1/0 t1-options timeslots 1-24

set interface serial1/0 ip 172.18.20.5/30

set interface serial1/0 route

set ppp profile “t1”

set ppp profile “t1” static-ip

set interface “serial1/0” ppp profile t1

#Interface e0/1 connects to the other device in the branch. The other firewall device is connected to the Internet and it advertises a default route through this link using RIP.




#Guest and Trust zone interfaces. Note the use of NetScreen Redundancy Protocol (NSRP) so in the event of a failure, the other firewall device in the branch will take over these IPs.

set interface “ethernet0/2” zone “Guest”

set interface ethernet0/2:1 ip 192.168.12.1/24

set interface ethernet0/2:1 nat

set interface ethernet0/2:1 dhcp server service



set interface ethernet0/2:1 dhcp server auto

set interface ethernet0/2:1 dhcp server option gateway 192.168.12.1

set interface ethernet0/2:1 dhcp server option netmask 255.255.255.0

set interface ethernet0/2:1 dhcp server option domainname gamma.jnpr.net

set interface ethernet0/2:1 dhcp server option dns1 192.168.3.5

set interface ethernet0/2:1 dhcp server ip 192.168.12.10 to 192.168.12.50

set interface “bgroup0” zone “Trust”


set interface bgroup0:1 ip 10.20.2.1/24

set interface bgroup0:1 route

set interface bgroup0:1 dhcp server service

set interface bgroup0:1 dhcp server enable

set interface bgroup0:1 dhcp server option domainname gamma.jnpr.net

set interface bgroup0:1 dhcp server option dns1 192.168.3.5

set interface bgroup0:1 dhcp server ip 10.20.2.10 to 10.20.2.100

#Loopback Interfaces

#Interface Loopback.1 is used to terminate the IPsec tunnels routed through the PTP network.




#Interface Loopback.10 is used to establish the BGP peering session.




#Tunnel Interfaces

#Interface tunnel.5 terminates the tunnel from Data Center A.

set interface “tunnel.5” zone “VPN”


#Interface tunnel.8 terminates the tunnel from Data Center B.

set interface “tunnel.8” zone “VPN”




#NSRP Configuration. Note that this is a mixed mode config (the ingress interface is a VSI, while the egress interface is either the serial interface to the PTP network or the Ethernet interface to the other firewall connected to the Internet).

set nsrp cluster id 7

unset nsrp data-forwarding

unset nsrp rto-mirror session ping

set nsrp vsd-group master-always-exist

unset nsrp vsd-group id 0

set nsrp vsd-group id 1 priority 50

set nsrp vsd-group id 1 preempt

set nsrp arp 5

set nsrp interface ethernet0/4

set nsrp monitor threshold 100

set nsrp monitor interface bgroup0

#Track IP is used to trigger a failover when either of the IPsec tunnels is down.

set nsrp monitor track-ip ip

set nsrp monitor track-ip threshold 5

set nsrp monitor track-ip ip 10.255.5.254 interface tunnel.5

set nsrp monitor track-ip ip 10.255.5.254 interval 2

set nsrp monitor track-ip ip 10.255.5.254 weight 255

set nsrp monitor track-ip ip 10.255.15.254 interface tunnel.8

set nsrp monitor track-ip ip 10.255.15.254 interval 2

set nsrp monitor track-ip ip 10.255.15.254 weight 255

unset nsrp config sync

#IPsec configuration



set ike gateway “ISG2000-E_lo.5:1” address 172.18.8.162 Main outgoing-interface “loopback.1” preshare “gNgxAuzNNj6I6BsxdsCSOY/65FnESx3eaA==” sec-level standard

set vpn “SSG20-C_to_ISG2000-E_1” gateway “ISG2000-E_lo.5:1” no-replay tunnel idletime 0 sec-level standard

set vpn “SSG20-C_to_ISG2000-E_1” monitor optimized rekey

set vpn “SSG20-C_to_ISG2000-E_1” id 1 bind interface tunnel.5

set ike gateway “ISG2000-G_lo.5:1” address 172.18.16.162 Main outgoing-interface “loopback.1” preshare “gNgxAuzNNj6I6BsxdsCSOY/65FnESx3eaA==” sec-level standard

set vpn “SSG20-C_to_ISG2000-G_1” gateway “ISG2000-G_lo.5:1” no-replay tunnel idletime 0 sec-level standard

set vpn “SSG20-C_to_ISG2000-G_1” monitor optimized rekey

set vpn “SSG20-C_to_ISG2000-G_1” id 2 bind interface tunnel.8




unset auto-route-export



#The localNetworks route map is used to filter out the routes sent to the route reflectors (only the Trust network is sent).

#The rejectAll route map is used to filter out the RIP updates sent to the remote firewall so that we don’t send any routes to the other firewall in the cluster.

set access-list 2


set access-list 3



set match ip 2

exit

set route-map name “rejectAll” deny 1

set match ip 3

exit

unset add-default-route

#RIP Configuration. RIP is in use only to receive a default route from the other firewall in the branch.

set protocol rip

set enable

set default-metric 1

set alt-route 3

exit

#BGP configuration. Note that, as opposed to the Type C branches, the BGP sessions are terminated on a non-VSI loopback. Each firewall then has its own set of BGP sessions to each of the route reflectors and is constantly connected to them regardless of the NSRP state.


set enable


set reject-default-route












exit

#Static Routes

#These routes point to the remote loopback addresses of the route reflectors and the VPN concentrators.




set route 172.31.252.0/22 interface tunnel.8 gateway 10.255.15.254 metric 10

#These static routes point to the loopback addresses of the VPN concentrators though the PTP network. In this way, the IPsec tunnels terminated on loopbacks in this range will be routed through the PTP network. All other traffic will be sent through the Internet.



exit

#BGP has to be enabled on the tunnel interfaces.


set interface tunnel.8 protocol

#Finally BGP is enabled on the Ethernet interface connecting to the other firewall device. Note the use of the route map to filter out the updates generated in this device.

set interface ethernet0/1 protocol rip

set interface ethernet0/1 protocol rip enable

set interface ethernet0/1 protocol rip route-map “rejectAll” out



Appendix 3: Branch Office Type C Configuration The following configuration needs to be implemented on the branch device (appropriate SSG Series model, running ScreenOS 6.0).


set protocol ospf

set enable

exit

set preference ospf-e2 90

exit

#Zones Definitions




set zone id 101 “Guest”

set zone id 102 “vpn”

set zone “Untrust” asymmetric-vpn

#Interface Configurations interface e0/0 and e0/2 are connected to the J Series routers.

#Interface eth0/8:1 has NSRP enabled and is connected to the DMZ zone. Interface e0/9:1 is also part of the same VSD and is connected to the Trust zone. Finally interface e0/1:1 is connected to the Guest zone. All these interfaces have DHCP enabled.

#Please see the Branch HA document for further reference.


set interface “ethernet0/1” zone “Guest”


set interface “ethernet0/8” zone “DMZ”

set interface “ethernet0/9” zone “Trust”




set interface ethernet0/1:1 route









set interface “ethernet0/0” loopback-group “loopback.2:1”



set interface “ethernet0/2” loopback-group “loopback.2:1”



set interface ethernet0/1:1 dhcp server enable

set interface ethernet0/9:1 dhcp server enable



set interface ethernet0/1:1 dhcp server option domainname vpwan.gamma.juniper.net






set interface ethernet0/9:1 dhcp server option domainname vpwan.gamma.juniper.net






#Tunnel Interface Definitions

#Tunel.1 and Tunnel.5 terminate the tunnels going to data center A, while interface tunnel.7 and tunnel.8 terminate the vpn tunnels going to data center B.









#Loopback Interface Definition

#The loopback.10 (10.255.255.5) interface is used to terminate the IBGP sessions across the IPsec tunnels.

#Interfaces loopback.1:1 and loopback.2:1 are used to terminate the IPsec tunnels coming from the PTP network and from the Internet respectively. These interfaces are advertised into OSPF so only the active VSD will terminate the tunnels. (See the Branch HA and Branch Architecture documents for further reference.)








set interface loopback.1:1 ip 172.18.1.3/32

set interface loopback.1:1 route







#This allows for asymmetric traffic inside the VPN tunnels. That is, if a tunneled packet arrives through a tunnel that fails the RPF check, the packet is still accepted.

set flow reverse-route tunnel prefer

#VPNMONITOR is enabled; the counters are set such that a failure will be detected in about 5 seconds.



#IPsec tunnel definitions

set ike gateway “ISG2000-E_lo.1:1” address 1.2.0.6 Main outgoing-interface “loopback.2:1” preshare “gNgxAuzNNj6I6BsxdsCSOY/65FnESx3eaA==” sec-level standard

set ike gateway “ISG2000-E_lo.5:1” address 172.18.8.162 Main outgoing-interface “loopback.1:1” preshare “8qtO+6KRNskXzTsrY7CJmOgqWunGMVQtrg==” sec-level standard

set ike gateway “ISG2000-G_lo.1:1” address 1.2.0.25 Main outgoing-interface “loopback.2:1” preshare “gNgxAuzNNj6I6BsxdsCSOY/65FnESx3eaA==” sec-level standard

set ike gateway “ISG2000-G_lo.5:1” address 172.18.16.162 Main outgoing-interface “loopback.1:1” preshare “8qtO+6KRNskXzTsrY7CJmOgqWunGMVQtrg==” sec-level standard

set vpn “SSG140-A_to_ISG2000-E_1” gateway “ISG2000-E_lo.5:1” no-replay tunnel idletime 0 sec-level standard



set vpn “SSG140-A_to_ISG2000-E_2” gateway “ISG2000-E_lo.1:1” no-replay tunnel idletime 0 sec-level standard



set vpn “SSG140-A_to_ISG2000-G_1” gateway “ISG2000-G_lo.5:1” no-replay tunnel idletime 0 sec-level standard



set vpn “SSG140-A_to_ISG2000-G_2” gateway “ISG2000-G_lo.1:1” no-replay tunnel idletime 0 sec-level standard




set router-id 10.255.255.5




#BGP configuration


set enable

#Disable BGP sync so that a route received only through BGP will still be accepted.


#Neighbors declaration. Note that nhself is enabled so the next hop sent on the routes originated by this device will be the address of the loopback.10:1 interface (10.255.255.5). Also note that the configuration from the BGP point of view is almost identical to the one for Type A branches. The main difference is that we terminate BGP on a VSI interface (loopback.10:1) that will failover to the backup device in the event of a failure.

set neighbor 172.31.255.15 remote-as 65100 outgoing-interface loopback.10:1




set neighbor 172.31.254.15 remote-as 65100 outgoing-interface loopback.10:1




exit

set access-list 1




set access-list 1 permit default-route 10

set access-list 2


set access-list 3




#remoteNetworks: Matches all the networks sent by each data center. Note that the network 10.0.0.0/8 is accepted, but no specific routes in that range are. This route map can be used (but is not mandatory) to filter out the routes sent by the hub.

set route-map name “remoteNetworks” permit 1

set match ip 1

exit



#localNetworks: It matches the Trust zone networks (10.140.0.0/23 in this case).


set match ip 2

exit

#Static Routes

#These static routes point to the loopback networks of each data center (172.31.254.0/24 to DCA, 172.31.255.0/24 to DCB, and an aggregate of all the loopbacks network 172.31.252.0/22 through both DCA+DCB). The metrics have been set up such that the tunnel interfaces going through the PTP network are preferred over the ones using the Internet. Since the next hop on the routes received through BGP will belong to one of these loopback networks, by changing these metrics we can change which tunnel is preferred.









#These two networks are public ranges that were assigned to this branch. By configuring default routes pointing to null and advertising these into OSPF, we can use them to NAT all of the outgoing traffic, depending on the egress network. Please refer to the Branch HA document for further reference.

set route 1.4.17.16/29 interface null

set route 1.4.17.24/29 interface null

#Advertise all of the local subnets (Trust network in this example) through BGP.

set protocol bgp


exit

exit

#OSPF is used to advertise the active loopback interfaces. It will also receive through OSPF the routes to the data centers both through the Internet and through the PTP network.

set interface ethernet0/2 protocol ospf area 0.0.0.0

set interface ethernet0/2 protocol ospf link-type p2p

set interface ethernet0/2 protocol ospf enable

set interface ethernet0/2 protocol ospf hello-interval 5

set interface ethernet0/2 protocol ospf retransmit-interval 4






set interface ethernet0/0 protocol ospf hello-interval 5

set interface ethernet0/0 protocol ospf retransmit-interval 4




set interface ethernet0/9 protocol ospf cost 100

set interface loopback.1 protocol ospf area 0.0.0.0

set interface loopback.1 protocol ospf passive

set interface loopback.1 protocol ospf enable

set interface loopback.2 protocol ospf area 0.0.0.0

set interface loopback.2 protocol ospf passive

set interface loopback.2 protocol ospf enable

set interface loopback.1:1 protocol ospf area 0.0.0.0

set interface loopback.1:1 protocol ospf passive

set interface loopback.1:1 protocol ospf enable

set interface loopback.2:1 protocol ospf area 0.0.0.0

set interface loopback.2:1 protocol ospf passive

set interface loopback.2:1 protocol ospf enable

#Enable BGP on the tunnel interfaces.






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

apaC HeadquartersJuniper Networks (Hong Kong) 26/F, Cityplaza One 1111 King’s Road Taikoo Shing, Hong Kong Phone: 852.2332.3636 Fax: 852.2574.7803

emea HeadquartersJuniper Networks Ireland Airside Business Park Swords, County Dublin, Ireland Phone: 35.31.8903.600 Fax: 35.31.8903.601

Copyright 2009 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. JUNOSe is a trademark of Juniper Networks, Inc. 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.

3500119-001-EN Jun 2009 Printed on recycled paper.

23

To purchase Juniper Networks solutions, pleasecontact your Juniper Networks representative

at 1-866-298-6428 or authorized reseller.

Appendix 4: Calculating Routes, Forwarding Entries and IPsec TunnelsThe total number of routes received at the route reflectors and VPN concentrators will depend on how many routes each branch advertises. This can be calculated as shown in the following table:

Table 3: Route CalculationsDEVICE TYPE NUMBER OF ROUTES NUMBER OF

FORWARDING ENTRIESNUMBER OF IPSEC TUNNELS

Vpn concentrator 2 x number of branches

+

(2 x number routes advertised/branch)

x

number of branches

With ECMP: (2 + 2 x number of routes advertised/

branch) x

number of branches

2 x number of branches

Without ECMP:

(1+ number of routes advertised/branch)

x number of branches

route reflector (2+2 x number of routes advertised/branch) x number of branches

(1+ number of routes advertised/branch) x number of branches

0

Branch office 8 Without ECMP: 4 4

With ECMP:8

For instance, assuming each branch sends only one prefix, the resulting number of routes/forwarding entries required at each data center/regional office would be as shown in Table 1.

About Juniper NetworksJuniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. This fuels high-performance businesses. Additional information can be found at www .juniper .net.

implementing a bgp configuration on ipsec-based … note - implementing a bgp configuration on...

Documents