Route failover can be achieved in multiple ways. While typically the IP Monitoring feature on the SRX platform is used, customers can also configure the Border Gateway Protocol (BGP) to achieve the same objective, provided that they have the necessary infrastructure.
This article demonstrates with an example how to implement VPN failover and fallback by using the Border Gateway Protocol (BGP) in the event of failure of a primary internet service provider (ISP).
Note: For configuring route failover by using IP Monitoring, refer to KB29227 - [J/SRX] Example – Configuring a primary and backup VPN with route failover using ip-monitoring [juniper.net] .
To configure VPN failover across multiple ISPs using BGP, use the following example:
Topology
SRXA --------Internet Cloud---------SRXB
In this example, both SRXA and SRXB have two site-to-site route-based VPNs established on interfaces. SRXA and SRXB have two VPNs configured such that the primary VPN uses interface ge-0/0/0 of SRXA and interface ge-0/0/2 of SRXB and the secondary VPN uses interface ge-0/0/1.0 of SRXA and interface ge-0/0/3 of SRXB.
Existing Interface Configuration on SRXA
root@SRXA# run show interfaces terse | match inet ge-0/0/0.0 up up inet 1.1.1.1/24 >>> Primary VPN external interface ge-0/0/1.0 up up inet 2.2.2.1/24 >>> Secondary VPN external interface ge-0/0/4.0 up up inet 192.168.20.1/24 >>> Host network for the VPN
Existing Interface Configuration on SRXB
root@SRXB# run show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/2 up up ge-0/0/2.0 up up inet 3.3.3.1/24 >>Primary VPN external interface ge-0/0/3.0 up up inet 4.4.4.1/24 >>Secondary VPN external interface ge-0/0/4.0 up up inet 192.168.10.1/24. >>> Host network for the VPN
The logical setup on these two devices is as follows:
st0.1-----SRX A -ge-0/0/0 -------ge-0/0/2 SRX-st0.1
st0.2-----SRX B -ge-0/0/1 -------ge-0/0/3 SRX--st0.2
VPN configuration
To configure the IKE gateway and IPsec VPN, refer to Example: Configuring a Route-Based VPN . Make sure to also configure Dead Peer Detection on the SRX device for failure detection. Refer to KB21652 - [SRX] Dead Peer Detection (DPD) behavior on SRX devices to configure DPD [juniper.net] .
Additional configurations that would be required for in the BGP scenario are covered in the following section:
On SRXA
set security ipsec vpn vpn1 bind-interface st0.1. >>>> Primary VPN set security ipsec vpn vpn2 bind-interface st0.2. >>>> Secondary VPN set security zones security-zone untrust interfaces st0.1 host-inbound-traffic system-services all set security zones security-zone untrust interfaces st0.2 host-inbound-traffic system-services all set interfaces st0 unit 1 family inet address 169.254.255.2/30 set interfaces st0 unit 2 family inet address 169.254.255.6/30
set protocols bgp group EBGP neighbor 169.254.255.5 peer-as 65001 set protocols bgp group EBGP neighbor 169.254.255.1 peer-as 65001
On SRXB
set security ipsec vpn vpn1 bind-interface st0.1. >>>Primary VPN on SRXB set security ipsec vpn vpn2 bind-interface st0.2. >>>>Secondary VPN on SRXB set security zones security-zone untrust interfaces st0.1 host-inbound-traffic system-services all set security zones security-zone untrust interfaces st0.2 host-inbound-traffic system-services all set interfaces st0 unit 1 family inet address 169.254.255.1/30 set interfaces st0 unit 2 family inet address 169.254.255.5/30
set protocols bgp group EBGP neighbor 169.254.255.6 peer-as 65000 set protocols bgp group EBGP neighbor 169.254.255.2 peer-as 65000
Configuring Route Export using BGP for Interested Traffic over VPN
SRXA
The local subnet that needs to access the VPN resources is 192.168.20.0/24. Hence, configure the export policy as shown:
set policy-options policy-statement EXPORT term 1 from protocol direct set policy-options policy-statement EXPORT term 1 from route-filter 192.168.20.0/24 exact set policy-options policy-statement EXPORT term 1 then accept
SRXB
The local subnet that needs to access the VPN resources is 192.168.10.0/24. Hence, configure the export policy as shown:
set policy-options policy-statement EXPORT1 term 1 from protocol direct set policy-options policy-statement EXPORT1 term 1 from route-filter 192.168.10.0/24 exact set policy-options policy-statement EXPORT1 term 1 then accept
Routing Import
On SRXA, the remote subnet is 192.168.10.0/24 and the secondary VPN interface is st0.2. Given this, the configuration for AS-path-prepend for the route from the secondary peer would be as follows:
set policy-options policy-statement IMPORT1 term 1 from protocol bgp set policy-options policy-statement IMPORT1 term 1 from neighbor 169.254.255.5 set policy-options policy-statement IMPORT1 term 1 from route-filter 192.168.10.0/24 exact set policy-options policy-statement IMPORT1 term 1 then as-path-prepend 65001
Similarly, the remote subnet for SRXB is 192.168.20.0/24 and the configuration for AS-path-prepend, therefore, would be:
set policy-options policy-statement IMPORT term 1 from protocol bgp set policy-options policy-statement IMPORT term 1 from neighbor 169.254.255.6 set policy-options policy-statement IMPORT term 1 from route-filter 192.168.20.0/24 exact set policy-options policy-statement IMPORT term 1 then as-path-prepend 65000
Route Verification
After configuring the AS-path-prepend, the route should be reflected in the routing table on both SRX A and SRX B for the secondary VPN peer.
From SRXA
[edit] root@SRXA# run show route 192.168.10.0 inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24 *[BGP/170] 01:59:29, localpref 100 AS path: 65001 I, validation-state: unverified > to 169.254.255.1 via st0.1 [BGP/170] 02:15:19, localpref 100 AS path: 65001 65001 I, validation-state: unverified. >> Path prepend applied > to 169.254.255.5 via st0.2
From SRXB
root@SRXB# run show route 192.168.20.1 inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.0/24 *[BGP/170] 01:49:12, localpref 100 AS path: 65000 I, validation-state: unverified > to 169.254.255.2 via st0.1 [BGP/170] 02:13:23, localpref 100 AS path: 65000 65000 I, validation-state: unverified. >>>Path prepend applied > to 169.254.255.6 via st0.2
Validating Tunnel Status on SRXA
[edit] root@SRXA# run show security ipsec security-associations Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131073 ESP:aes-cbc-128/sha1 c788bc15 2151/ unlim - root 500 3.3.3.1 >131073 ESP:aes-cbc-128/sha1 3c22b727 2151/ unlim - root 500 3.3.3.1 <131074 ESP:3des/sha1 c4f1fa46 2274/ unlim - root 500 4.4.4.1 >131074 ESP:3des/sha1 50120ed6 2274/ unlim - root 500 4.4.4.1
Currently traffic is flowing via tunnel st0.1 as tested on SRXA and SRXB.
root@SRXA# run ping 192.168.10.1 interface ge-0/0/4.0 PING 192.168.10.1 (192.168.10.1): 56 data bytes 64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=1.592 ms 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=1.531 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=1.517 ms root@SRXB# run ping 192.168.20.1 interface ge-0/0/4.0 PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=1.588 ms 64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=1.506 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=1.511 ms
Failover Test
When connectivity between SRXA and SRXB for the primary VPN is broken, only the secondary VPN is up as shown below:
[edit] root@SRXA# run show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 1150523 UP a8daa1f2e2f13aea 0b0cddee7a91d8d4 Main 4.4.4.1 1150526 DOWN 528d8c164bce675e 6968116bba4f7912 Main 3.3.3.1 >> Primary VPN is down.
The route is using the secondary tunnel interface as shown here:
root@SRXA# run show route 192.168.10.1 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24 *[BGP/170] 14:02:27, localpref 100 AS path: 65001 65001 I, validation-state: unverified > to 169.254.255.5 via st0.2. >>>>Secondary VPN via secondary ISP
root@SRXB# run show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 4288521 UP a8daa1f2e2f13aea 0b0cddee7a91d8d4 Main 2.2.2.1 4288531 DOWN 6237fe0174c4cf5d 0000000000000000 Main 1.1.1.1 >> Primary VPN is down.
The route for the proxy subnet is using the secondary tunnel.
[edit] root@SRXB# run show route 192.168.20.1 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.0/24 *[BGP/170] 14:15:59, localpref 100 AS path: 65000 65000 I, validation-state: unverified > to 169.254.255.6 via st0.2. >>>Secondary tunnel route is active.
When connectivity is restored for the primary ISP, the routes for the VPN subnet will fall back to primary tunnel interface (that is, st0.1) on both SRXA and SRXB.
root@SRXA# run show route 192.168.10.1 Nov 15 06:15:15 inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24 *[BGP/170] 00:01:56, localpref 100 AS path: 65001 I, validation-state: unverified > to 169.254.255.1 via st0.1 [BGP/170] 14:11:28, localpref 100 AS path: 65001 65001 I, validation-state: unverified > to 169.254.255.5 via st0.2 [edit] root@SRXB# run show route 192.168.20.1 inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.0/24 *[BGP/170] 00:02:12, localpref 100 AS path: 65000 I, validation-state: unverified > to 169.254.255.2 via st0.1 [BGP/170] 14:20:06, localpref 100 AS path: 65000 65000 I, validation-state: unverified > to 169.254.255.6 via st0.2
Note that for VPN failover detection, we can use DPD or VPN monitoring, depending on the customer's environment.