OCI VCN and SD-WAN connectivity (Silver Peak)

Introduction

In this blog we will discuss about the steps to perform in order to connect the OCI customer VCN to an SD-WAN provider. In our case the SD WAN provider is Silver Peak (https://www.silver-peak.com/company/tech-partners/cloud/oracle-cloud) and below is the solution implemented.

In our test environment we do not have a true Silver Peak VM. To accomplish the connectivity model we will use a Linux VM with Quagga and LibreSwan distribution in order to run the BGP over IPSec between the Linux VM and the DRG.

Using BGP over IPSec between the DRG and the Linux VM running Quagga connected to the SD-WAN will accomplish fault tolerance in case of an IPSec failure. The customer request is to have the traffic between OCI VCN and SD-WAN encrypted end-to-end.

Topology Architecture Diagram

We will keep the topology as simple as possible in order to demonstrate the core of the solution.

We have:

a) four private subnets in OCI 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, 10.0.4.0/24;

b) one public DMZ subnet where the Silver Peak will stay (in our case the Linux VM running Quagga);

c) One DRG attached to the VCN, the private subnets will have a default route pointing to the DRG as next-hop, the routing is depicted in the above networking diagram;

d) One Internet Gateway used by the Silver Peak to connect to the SD-WAN and establish the BGP over IPSec tunnels with the DRG for achieving BGP route advertisement for bidirectional connectivity and traffic encryption - the routing table will contain a default route pointing to the IGW as next-hop;

e) One Test VM1 on OCI with IP address of 10.0.1.7/24;

f) One Test VM2 on the Customer side with IP address of 172.31.1.2/26;

Configuration

The configuration part will include the LibreSwan, Quagga and OCI DRG.

LibreSwan configuration:

DRG IPSec tunnels status:

Quagga BGP configuration (preferring tunnel1 as primary and tunnel 2 being the standby tunnel for user traffic):

DRG BGP over IPSec configuration and tunnels status:

Verification

We will check if the BGP status reached the Established state, route received and route advertised from/to DRG.

Neighbor status:

The routes received from DRG:

We have received four prefixes from each of the BGP peers, this is the desired result in our case.
As we expect we have the route through 192.168.100.2 as preferred path the path through 192.168.100.6 as a backup path.

Let's see if the routes have been inserted in the routing table:

zebra is an IP routing manager that is providing kernel routing tables, , interface lookups, and redistribution of routes between different routing protocols.

The routes advertised to the DRG on both tunnels:

Traffic testing and the switchover process

Ping from 172.31.1.2 to 10.0.1.7:

Ping from 10.0.1.7 to 172.31.1.2:

The switcover process from tunnel1 to tunnel2 in case of an IPSec failure on tunnel1:

1 → ping started over tunnel1 from 10.0.1.7 to 172.31.1.2:

2 → route table confirms that the destination in the returning traffic 10.0.1.7 is reachable over vti01 which is our tunnel1;

3 → the traffic capture made on the tunnel1 confirms the traffic is using tunnel1;

4 → put the tunnel1 in down state;

5 → from sequence 1111 to 1163 the traffic has been stopped (BGP hold-time) and the traffic is switched to the tunnel2;

6 → the routing table confirms that it has been updated and now the destination is reachable over vti02 which is tunnel2;

7 → a packet capture made on tunnel2 confirms that the traffic is using tunnel2;

The switchback to tunnel1:

1 → ping is still running on tunnel2:

2 → the traffic capture made on the tunnel2 confirms the traffic is using tunnel2;

3 → tunnel1 enters the UP state;

4 → from sequence 1498 to 1523 the traffic has been stopped (BGP hold-time) and the traffic is switched to the tunnel1;

5 → the routing table confirms that it has been updated and now the destination is reachable over vti01 which is tunnel1;

6 → a packet capture made on tunnel1 confirms that the traffic is using this tunnel;