Service-Aware VPN for Dynamic Cloud Native Routing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In large-scale cloud native environments, manual construction of MAC/IP route distribution policies to prevent unnecessary service communication is error-prone and inefficient, especially in dynamic settings where container pods have short lifespans and frequently change locations, leading to outdated routing policies.

Innovation Solution

An automated method to determine service flow definitions among container pods and derive cluster topologies, allowing for the creation of granular IP/MAC route distribution policies that are dynamically updated based on communication paths, using an orchestrator to apply these policies to edge endpoints via the BGP control plane or management plane protocols.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual MAC/IP route distribution policies are constructed to control service communication, then unnecessary service communication is prevented, but the system becomes error-prone and inefficient in large-scale dynamic environments

Engineering Contradiction:
Improverouting policy accuracyVSAvoidrouting policy management complexity
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system automatically generates and updates MAC/IP route distribution policies by having the orchestrator determine service flow definitions and communication paths among container pods. The routing policies are self-updating based on dynamic service interactions, eliminating manual intervention and reducing errors while maintaining reliability in large-scale environments

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system continuously monitors service communication patterns and uses this feedback to dynamically update routing policies. The orchestrator observes actual service flows and adjusts MAC/IP route distribution accordingly, ensuring policies remain accurate and efficient as services are added, removed, or modified

Inventive Principle:
Principle #23Feedback

2Productivity

If manual routing policies are created to control container pod communication, then network traffic is optimized, but the policies become outdated quickly in dynamic environments with short-lived container pods

Engineering Contradiction:
Improvenetwork traffic efficiencyVSAvoidrouting policy validity duration
Core Design Contradiction:
ProductivityVSDuration of action of stationary object

Solution Approach 1:

The routing policies are made dynamic through continuous automatic updates by the orchestrator. As container pods are created, moved, or terminated, the system dynamically regenerates service flow definitions and updates MAC/IP route distribution policies in real-time, ensuring policies remain valid and optimized throughout their entire lifecycle without manual intervention

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system proactively determines service communication requirements and pre-configures routing policies before container pods actually communicate. The orchestrator anticipates service flows and establishes optimized routes in advance, ensuring network traffic efficiency is maintained from the moment services begin interacting

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If all container pod MAC/IP entries are advertised in the BGP control plane, then complete service reachability is achieved, but the scale of routing entries becomes unmanageable with 10,000+ container pods

Engineering Contradiction:
Improveservice reachabilityVSAvoidforwarding table size
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system extracts and advertises only the essential MAC/IP routing information needed for actual service communication in the BGP control plane. By determining service flow definitions and identifying which container pods actually communicate, the system filters out redundant routing entries, maintaining complete service reachability while reducing forwarding table size to manageable levels

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The routing information is segmented into service-specific flow definitions rather than advertising all container pod entries uniformly. The orchestrator divides the network into service communication groups and advertises routing policies at the service level rather than individual container level, reducing overall routing table complexity while maintaining adaptability for service reachability

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS11336567B2Service aware virtual private network for optimized forwarding in cloud native environment
Publication Date: 2022.05.17 CISCO TECHNOLOGY INC
  • US11336567B2 patent drawing
  • US11336567B2 patent drawing
  • US11336567B2 patent drawing

AI summary

Techniques for defining a service flow definition among container pods that provide services in a network. The techniques may include an orchestrator of a computer network platform of the network determining which container pods need to communicate with which container pods. The service flow definition thus indicates needed paths between the container pods. In configurations, a cluster topology may be determined where the cluster topology indicates corresponding nodes of the network in which each container pod is located, as well as end points of the network with which the corresponding nodes communicate. Based at least in part on the service flow definition and the cluster topology, corresponding route distribution policies may be determined for the end points. The corresponding route distribution policies may be applied to the end points.