Pod Traffic Redirection via Routing Table Updates

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing network traffic redirection systems take longer than desired to reroute traffic when a destination pod fails, as they rely on periodic updates and synchronization across multiple devices, leading to delayed detection and rerouting.

Innovation Solution

Implementing a system where nodes can immediately reroute network traffic by removing the failed pod's address from their routing tables and forwarding packets to a second pod with a higher metric before the ingress device is aware of the failure, thereby bypassing the need for synchronization and accelerating recovery.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the system waits for the ingress device to detect failure and update routing tables, then routing consistency is maintained, but traffic redirection latency increases

Engineering Contradiction:
Improverouting consistencyVSAvoidtraffic redirection latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the failure detection and routing update functions into two independent components: (1) ingress device performs failure detection and control plane updates, and (2) data plane nodes independently perform real-time routing table updates based on failure events. This segmentation allows the data plane to operate autonomously without waiting for control plane propagation, resolving the contradiction between routing consistency and redirection latency.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary action by having data plane nodes proactively update their routing tables immediately upon detecting a failure event, before the ingress device completes its failure detection and control plane updates. Nodes subscribe to failure event notifications and pre-update their routing information, ensuring traffic is redirected without waiting for the control plane to propagate the failure information.

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If the system uses centralized control plane updates for routing changes, then routing accuracy is ensured, but update speed decreases

Engineering Contradiction:
Improverouting accuracyVSAvoidupdate speed
Core Design Contradiction:
Measurement precisionVSSpeed

Solution Approach 1:

The patent merges the centralized control plane update mechanism with distributed data plane autonomy. The control plane provides authoritative failure detection and notification (ensuring accuracy), while data plane nodes independently apply routing updates based on these notifications (ensuring speed). This hybrid approach combines the accuracy of centralized control with the speed of distributed execution.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent implements a feedback mechanism where data plane nodes subscribe to failure event notifications from the control plane and automatically update their routing tables in response. This closed-loop feedback system ensures that routing updates are triggered by actual failure events (maintaining accuracy) while executing locally at each node (maintaining speed).

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11824765B2Fast redirect of traffic when pods fail
Publication Date: 2023.11.21 CISCO TECHNOLOGY INC
  • US11824765B2 patent drawing
  • US11824765B2 patent drawing
  • US11824765B2 patent drawing

AI summary

Systems, methods, and devices are disclosed for re-routing network traffic directed to a pod device. Traffic is routed from an ingress device towards a first node in communication with multiple pods. In response to the detection of a failure event associated with the first pod, a network device address of the first pod is removed from a routing table. If a packet is received from the ingress device that is destined for a service, the routing table is used to look up a pod for handling a service request associated with the service. A network device address of a second pod is determined based on not finding the network device address of the first pod in the routing table. The packet is then forwarded to the second pod using the second device address before the ingress device knows that the first pod has failed.