SD-EWAN Scenarios
This page intend to list bunch of scenarios for our SD-EWAN case, including the decomposed scenarios and the overall integrated scenario.
- 1 Decomposed scenarios
- 1.1 Decomposed Scenario A: Site-to-Site tunnel with static public IP address
- 1.1.1 CRs for the scenario
- 1.1.1.1 Rest calls
- 1.1.1 CRs for the scenario
- 1.2 Decomposed Scenario B: Host-to-Site tunnel when the initiator requests an overlay IP
- 1.2.1 CRs for the scenario
- 1.2.2 Rest calls
- 1.3 Decomposed Scenario C: Host to host tunnel
- 1.3.1 CRs for the scenario
- 1.3.2 Rest calls
- 1.1 Decomposed Scenario A: Site-to-Site tunnel with static public IP address
- 2 Targeted Scenarios
- 2.1 Scenario A: Edge to traffic hub tunnel where inter micro-service communication across edges that attached to same traffic hub.
- 2.1.1 Sample CR for edgeA
- 2.1.2 Strongswan configs for edgeA
- 2.1.3 Sample CR for edgeB
- 2.1.4 Strongswan configs for edgeB
- 2.1.5 Sample CR for Hub
- 2.1.6 Strongswan configs for hub
- 2.2 Scenario B: Edge to Edge tunnels when micro-service communication happens across edges without involving hubs
- 2.2.1 Sample CR for EdgeA
- 2.2.2 Strongswan configs for edgeA
- 2.2.3 Sample CR for EdgeB
- 2.2.4 Strongswan configs for edgeB
- 2.3 Scenario C: Hub to hub tunnel when inter micro-service communication across edges that attached to different traffic hubs
- 2.3.1 Sample CR for edgeA
- 2.3.2 Strongswan configs for edgeA
- 2.3.3 Sample CR for edgeB
- 2.3.4 Strongswan configs for edgeB
- 2.3.5 Sample CR for HubA
- 2.3.6 Strongswan configs for HubA
- 2.3.7 Sample CR for HubB
- 2.3.8 Strongswan configs for HubB
- 2.1 Scenario A: Edge to traffic hub tunnel where inter micro-service communication across edges that attached to same traffic hub.
- 3 Overall scenarios
Decomposed scenarios
Decomposed Scenario A: Site-to-Site tunnel with static public IP address
In this scenario, both sites have static public IP address and setup a tunnel between sites. After the tunnel is established, the clients within the site should be able to ping the clients on the other side through the tunnel. The tunnel is authenticated through pre-shared key.
Scenario Description:
Tunnel between site A and site B
Suppose there are two sites A and B. A comes with the subnet 10.1.0.1/24, B comes with the subnet 10.2.0.1/24
Gateway for A is 192.168.1.10
Gateway for B is 192.168.1.11
A and B would like to establish a tunnel
10.1.0.1/24 == 10.2.0.1/24
CRs for the scenario
Rest calls
Sites settings
GET /cgi-bin/luci/sdewan/ipsec/v1/sites
{ { "name": “siteA", "remote":"192.168.1.11", "crypto_proposal": "test_proposal_1", "pre_shared_key": "test123", "authentication_method": "psk", "connections": [ { "name": "connection_A", "type": "tunnel", "mode": "start", "local_subnet": "10.1.0.1/24", "remote_subnet": "10.2.0.1/24", "crypto_proposal": "test_proposal_1" } ] }, { "name": "siteB", "gateway":"192.168.1.10", "crypto_proposal": "test_proposal_1", "pre_shared_key": "test123", "authentication_method": "psk", "remote_identifier": "@moon.strongswan.org", "local_identifier": "@sun.strongswan.org", "connections": [ { "name": "connection_B", "type": "tunnel", "mode": "start", "local_subnet": "10.2.0.1/24", "remote_subnet": "10.1.0.1/24", "crypto_proposal": "test_proposal_1" } ] } ] |
|---|
Proposal settings
GET /cgi-bin/luci/sdewan/ipsec/v1/proposals
{ "proposals": [ { "name": "proposal1", "crypto_algorithm": "aes128", "hash_algorithm": "sha256", "dh_group": "modp3072" } ] } |
|---|