Versions Compared

Old Version 19

changes.mady.by.user Huifeng Le (Deactivated)

Saved on

compared with

New Version 20

changes.mady.by.user Huifeng Le (Deactivated)

Saved on

Key

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

...

  • K8s cluster is setup (by Kud)
  • Web UI (Optional), API Server, SDEWAN controllerRsync backend, DB service are deployed (manually or through EMCO)

Traffic Hub:

  • K8s cluster is setup (by Kud)
  • Hub SDEWAN Config Agent CRD Controller and CNF are deployed (through EMCO) with initial configuration (e.g. NAT: enable DNAT for k8s API service and Istio Ingress service).

Edge Location (With Public IP):

  • K8s cluster is setup (by Kud)
  • Edge SDEWAN Config Agent SDEWAN CRD Controller and CNF are deployed (through EMCO) with initial configuration (e.g. NAT: enable DNAT for k8s API service and Istio Ingress service).

Edge Location (With Private IP):

  • K8s cluster is setup (by Kud)
  • Edge SDEWAN Config Agent SDEWAN CRD Controller and CNF are deployed (through EMCO) with initial configuration (e.g. NAT: enable DNAT for k8s API service and Istio Ingress service, ; IPSec: as Initiator for Control plane - left: %any, leftsourceip:%config, right: Owned Hub's HIP, rightsubnet:0.0.0.0/0).

Opens:

  1. During current test, IPsec tunnel for Initiator to Responder requires Responder to be run before Initiatior, that means the SDEWAN CNF in Hub need to be run as Responder before a edge location (with private IP) setup, and the OIP Address range need to be configured 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 Hub and Edge Location (with private ip) setup (through strongswan command?), this is required for Ip address manager and cluster register process.
    1. Solution: Central Hub controller's IP address manager assign one OIP, then set Hub's responder's IPsec configuration with IP range to include only 1 IP (OIP) - Does this make sense?
  3. The registration of edge location information should be done by Admin manually or triggled automatically by EMCO's edge location registration process (assume similiar information shared)?
  4. Suppose edge location's OIP is assigned after setup and all following operation (e.g. overlay configuration) will reuse this OIP, right?  
    1. Suppose the answer is "No", and multiple OIP maybe assigned with edge location for different Hubs during overlay configuration, right?

...

Restful API definition and Back-End flow

ResourceDescriptionURLFieldsBack-End flow
OverlayDefine a group of edge location clusters (devices) and hubs, a overlay is usually owned by one customer and full mesh connections are setup automacally between hub-hub and device-device (with public IPs)/scc/v1/overlays
  • name
  • description
  • caid

Registeration:

  • SCC requests a CA from cert-manager, the CA is used as root CA for this overlay
  • SCC save the caid in DB
ProposalDefine proposals which can be used for IPsec tunnel in this overlay/scc/v1//overlays/{overlay-name}/proposals

HubDefine a traffic Hub in an overlay/scc/v1/overlays/{overlay-name)/hubs






Register Hub:

  • Trigger: Admin add/update hub information in Web UI or Remote Client Call with below informations:
    • Name, Description
    • Public IP address list
    • Managed IP ( ? )
    • Shared flag (whether the hub can be shared cross overlays)
    • Overlay name
    • CertificateId
    • Kubeconfig
  • Steps:
    • Save in DB
    • Setup control plane host-host tunnel with Central Cloud (e.g. Add a new IPSec policy in Central Cloud CNF with: left: CIP, right: HIP, CertificateId)

...