CLOS Network Routing Micro-loop Prevention via Interface Check
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
CLOS network topology with eBGP design is prone to routing micro-loops when a downstream device loses paths for a given prefix, leading to transient loops as upstream devices continue passing packets back to the downstream node until forwarding tables are updated.
Innovation Solution
A method to determine a next hop and egress interface for datagrams in a CLOS network, ensuring the egress interface is different from the receipt interface by looking up destination information and stored forwarding information, and replacing the preliminary next hop egress interface with a safe multipath next hop interface if it matches the receipt interface, thereby avoiding micro-loops without discarding packets.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If eBGP is used for routing in CLOS networks, then routing flexibility and scalability are improved, but routing micro-loops occur during link failures
Solution Approach 1:
The patent applies preliminary action by pre-computing and storing alternative next-hop interfaces in the forwarding information base (FIB) before failures occur. When a packet is received, the system checks whether the normally selected next-hop interface would create a micro-loop, and if so, immediately uses a pre-identified alternative interface. This eliminates the need for reactive route withdrawals and re-convergence, preventing micro-loops before they can form.
Solution Approach 2:
The patent applies preliminary anti-action by proactively identifying and storing alternative next-hop interfaces that would avoid micro-loops before failures occur. The system pre-computes these alternatives based on the CLOS topology and BGP routing information, so that when a failure occurs, the anti-loop action is already in place and can be immediately applied without causing transient loops.
2Reliability
If traditional loop avoidance methods are used, then micro-loops are prevented, but packets are discarded during convergence
Solution Approach 1:
The patent introduces an intermediary mechanism - the alternative next-hop interface stored in the FIB - that mediates between the need for loop avoidance and continuous packet delivery. Instead of discarding packets or waiting for BGP convergence, the intermediary alternative interface allows packets to be forwarded along a different path that avoids the micro-loop, maintaining productivity while ensuring reliability.
3Adaptability or versatility
If forwarding tables are updated during link failure, then routing convergence occurs, but transient micro-loops are created
Solution Approach 1:
The patent applies preliminary action by pre-computing alternative next-hop interfaces and storing them in the FIB before any failure occurs. This eliminates the transient period during which BGP would normally update forwarding tables, as the alternative paths are already prepared and can be immediately used, maintaining routing stability throughout the convergence process.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The problem of routing micro-loops in networks having a CLOS topology, such as data center CLOS networks employing the exterior border gateway protocol (eBGP) for example, is solved by: (a) receiving, on an interface of one of the nodes, a datagram, the datagram including destination information; (b) determining a next hop and an egress interface using (1) an identifier of the interface on which the datagram was received, (2) the destination information of the received datagram, and (3) stored forwarding information such that a routing micro-loop is avoided without discarding the datagram; and (c) forwarding the datagram via the egress interface. For example, this problem may be solved by(a) receiving, on an interface a node of the CLOS network, a datagram, the datagram including destination information; (b) looking up, using the destination information of the received datagram and stored forwarding information, a next hop egress interface on the node; (c) determining whether or not the next hop egress interface on the node is the same as the interface on which the datagram was received; and (d) responsive to a determination that the next hop egress interface on the node is the same as the interface on which the datagram was received, (1) replacing the next hop egress interface with a safe multipath next hop egress interface, and (2) forwarding the datagram via the safe multipath next hop egress interface, and otherwise, responsive to a determination that the next hop egress interface on the node is not the same at the interface on which the datagram was received, simply forwarding the datagram via the next hop egress interface.