Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Edge to Edge: Host to host
  • Edge to Hub: Host (edge) to Site (Hub, using edge's subnet as rightsubnet)
  • Hub to Hub: Host to Host

OpenOpens:

  1. Control plane and data plane share the same interface in Hub? Edge Location?
  2. Control plane IPSec tunnel between Central Cloud with Hub is setup during Hub registeration in Central Cloud
  3. Control plane IPSec tunnel between Central Cloud with Edge location (with public IP) is setup during edge location registeration in Central Cloud
  4. Control plane IPSec tunnel between Central Cloud with Edge location (with private IP) is setup during edge location setup (depedency to check: IPsec tunnel for Initiator to Responder requires Responder to be run first)

...

  • K8s cluster is setup (by Kud)
  • Edge SDEWAN Config Agent and CNF are deployed (through EMCO) with initial configuration (e.g. As Initiator for Control plane - left: %any, leftsourceip:%config, right: CIP, rightsubnet:0.0.0.0/0). Note: at this stage, an OIP is assigned to the CNF and the Central-Edge tunnel is set up (to be confirmed)

OpenOpens:

  1. During current test, IPsec tunnel for Initiator to Responder requires Responder to be run before Initiatior, that means the SDEWAN CNF in Central cloud need to be run as Responder before a edge location (with private IP) setup, and the OIP Address range need to be confgiure first (read from IP address manager?) and can not be updated at run time, does this be expected behavior?
  2. Need to check how to get the assigned OIP after the tunnel between Central Cloud and Edge Location (with private ip) setup (through strongswan command?), this is required for Ip address manager and cluster register process.
  3. The registration of edge location information should be done by Admin manually or triggled automatically by EMCO's edge location registration process (assume simaliar information shared)?  

...

  1. Can overlay IP ranges be same for different overlay? (Suppose "yes" as supposing the edges belongs to different overlays will not communicate even share the same hub) 
  2. How to avoid EMCO deploy different microservices of one application into different overlays?

Add-hub:

  • Trigger: Admin add/update hub overlay information in Web UI or Remote Client Call with below informations:
    • Overlay name
    • hub name
    • Hub ip (if hub has more than 1 public IPs)
    • Hub overlay ip ranges
  • Steps:
    • Save hub list information in DB
    • Setup hub-hub tunnel (data plane): e.g. left: HIP1, right: HIP2, overlay CertificateId
    • Setup hub as responder of edge-hub tunnel (data plane): e.g. left: HIP, leftsubnet: Hub overlay ip subnet, rightsourceip: Hub overlay ip ranges

...

Flow: Application Connection

Add-application-rule:

  • Trigger: Admin add/update application crule in Web UI or Remote Client (ONAP4K8s connectivity orchestrator?) Call with below informations:
    • Application name
    • Deployed edge location name
    • Firewall/SNAT/DNAT
  • Steps:
    • Save application rule information in DB
    • Setup openwrt rules in SDEWAN CNF of edge location

Add-application2application-rule:

  • Trigger: Admin add/update application crule in Web UI or Remote Client (ONAP4K8s connectivity orchestrator?) Call with below informations:
    • Application1 name
    • Application2 name, port
    • Edge location1 names for application1
    • Edge location2 names for application2
  • Steps:
    • Save application2application rule information in DB
    • Setup openwrt SNAT rule of SDEWAN CNF for edge location1
    • Setup openwrt DNAT rule of SDEWAN CNF for edge location2
    • Setup ip route rule in hubs between edge location1 and edge location2

OpensOpen:

  1. The registration of application/microservice connection information is done by Admin manually or triggled automatically by EMCO's deployment process (assume simaliar information shared)?  

...