A hardware resource and quality perception based BGP routing dynamic self-adaptive optimization method and system

Abstract

The application discloses a kind of based on hardware resource and quality perception BGP routing dynamic self-adapting optimization method and system, this scheme is applied to the VXLAN switch of running FRR protocol stack, hardware resource usage rate of exchange chip and the real-time forwarding quality of VXLAN tunnel are acquired in real time by SAI interface when FRR control plane.When hardware resource usage rate exceeds preset threshold, FRR control plane dynamically adjusts BGP routing aggregation granularity, and detailed route is switched to aggregate route, to prevent hardware overflow;When link quality deteriorates, FRR control plane dynamically modifies the attribute of LOCAL_PREF, Community and the like of corresponding BGP route, and notifies neighbor through BGP Update, realizes the intelligent scheduling and obstacle avoidance of traffic.The application realizes the adaptive optimization of network resource by establishing double closed-loop feedback mechanism of control plane and data plane, significantly improves the reliability, stability and forwarding performance of data center network.

Description

Technical Field

[0001] This invention belongs to the field of network communication and data center switching technology, specifically relating to a method and system for optimizing BGP EVPN routing strategies in a data center network supporting VXLAN (Virtual eXtensible Local Area Network) by utilizing the FRR (Free Range Routing) protocol stack and switching chip hardware in collaboration, and by sensing hardware entry pressure and real-time link forwarding quality. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, data center networks are growing exponentially. VXLAN combined with BGP EVPN (Ethernet VPN) has become the de facto standard for building large-scale overlay networks. In a typical architecture, white-box switches or branded switches run the FRR protocol stack as the control plane, responsible for BGP route calculation and distribution, and distribute forwarding table entries to the switching chip for line-speed forwarding via SAI (Switch Abstraction Interface).

[0003] However, existing technologies have the following significant drawbacks in practical deployment: (a) The “blindness” of control plane and hardware resources.

[0004] The FRR control plane typically focuses only on the logical correctness of routing protocols, lacking real-time awareness of the capacity of underlying ASIC hardware resources (such as LPM longest prefix match tables, tunnel tables, and FDB tables). When network routing oscillations or large-scale virtual machine migrations occur, massive amounts of detailed routes (such as / 32 host routes) may instantly fill up hardware table entries, leading to packet loss of new traffic or control plane crashes. Traditional solutions rely on static threshold alarms, which cannot achieve real-time dynamic adjustment of routing policies.

[0005] (ii) The “separation” between routing and physical link quality.

[0006] The BGP protocol itself routes based on TCP sessions and policy attributes (such as LOCAL_PREF, MED, and AS_PATH), which are typically statically configured or based on simple reachability checks. BGP is unaware of the real-time quality of the underlying VXLAN tunnel (such as micro-burst packet loss, congestion delay, and jitter). When a physical link deteriorates but is not completely interrupted, BGP will continue to forward traffic to that path, leading to a decrease in application layer performance.

[0007] (iii) Lack of cross-level collaborative closed-loop mechanism.

[0008] Existing network monitoring systems (such as SNMP and Telemetry) are typically out-of-band, resulting in significant delays in data reporting and control plane decision-making. Hardware-level congestion or quality degradation cannot be directly and quickly fed back to the BGP protocol stack for immediate correction of routing attributes, leading to delays in network optimization. Summary of the Invention

[0009] To address the issue of disconnect between hardware resources and link forwarding quality in the control plane and data plane of existing BGP EVPN networks, the present invention aims to provide a dynamic adaptive optimization scheme for BGP routes based on hardware resource and quality awareness. This scheme enables the FRR protocol stack to have "dual awareness" capabilities, dynamically adjusting the granularity of route aggregation based on hardware entry utilization and dynamically modifying BGP route attributes based on real-time link quality, thereby achieving millisecond-level collaborative closed loop between the control plane and data plane.

[0010] To achieve the above objectives, the present invention provides the following specific solutions: Solution 1: A dynamic adaptive optimization method for BGP routing based on hardware resources and quality awareness, applied to VXLAN switches running the FRR protocol stack, including the following steps: Hardware resource awareness: The FRR control plane obtains the hardware forwarding table entry resource usage information of the switching chip (ASIC) in real time through the Switch Abstraction Interface (SAI). The resources include LPM entries, tunnel entries, or FDB entries. Dynamic resource adjustment: The FRR control plane sets a first threshold, a second threshold, and a third threshold, where the first threshold is less than the second threshold, and the third threshold is less than the first threshold. When the utilization rate of hardware forwarding table entries exceeds the first threshold, detailed route statistics are initiated. When the utilization rate of hardware forwarding table entries exceeds the second threshold, the FRR control plane dynamically generates or modifies route policies and applies them to the inbound or outbound directions of the BGP protocol. By adjusting the granularity of route prefix aggregation or filtering specific prefixes, the number of entries sent to the hardware is reduced. When the utilization rate of hardware forwarding table entries is lower than the third threshold, the original route policy is restored. Link quality awareness: Based on the Operation Management and Maintenance (OAM) module or Telemetry module built into the switching chip, the forwarding quality parameters of each VXLAN tunnel are monitored in real time. The forwarding quality parameters include, but are not limited to, packet loss rate (PLR), round-trip time (RTT), and jitter. Dynamic quality optimization: The switching chip reports the detected quality degradation events to the FRR control plane through the switch abstract interface; the FRR control plane dynamically modifies the routing attributes of the BGP routes corresponding to the degraded tunnels according to the preset policy, and notifies the neighbors through BGP Update to perform traffic scheduling.

[0011] Furthermore, in the resource dynamic adjustment step, the adjustment of the routing policy includes differentiated configuration based on VNI or VRF granularity; the differentiated configuration includes: independently setting the aggregation trigger threshold, the prefix length threshold of the aggregated route, and the filtering granularity of the detailed route for each VNI or VRF.

[0012] Furthermore, in the dynamic quality tuning step, the routing attribute includes at least one of LOCAL_PREF, MED, AS_PATH, or BGP Community.

[0013] Furthermore, it also includes a smooth switching step. In the smooth switching step, when switching from detailed routing to aggregated routing, the FRR control plane first sends aggregated routing hardware entries to the switching chip through the SAI interface and sets a protection period. During this period, detailed routing hardware entries are retained. Detailed entries are deleted after traffic migrates naturally or the entries age.

[0014] Furthermore, it also includes a local penalty step, in which, for tunnels with degraded quality, the FRR control plane temporarily marks the next hop of the tunnel as a penalty state in the local forwarding table, and, in conjunction with Equal Cost Multipath Routing (ECMP) weight adjustment, prioritizes scheduling new traffic to other paths before BGP global convergence.

[0015] Furthermore, in the dynamic quality optimization step, a suppression timer is introduced, which needs to be stably maintained for a preset time after the link quality is restored before the inferior label is removed.

[0016] Option 2: A dynamic adaptive optimization system for BGP routing based on hardware resources and quality awareness, the system comprising: The switching chip provides hardware forwarding table entry storage and VXLAN forwarding, and also has entry usage monitoring and tunnel quality monitoring functions; The Abstract Interface Layer (SAI) is used to connect the switching chip and the control plane, providing a unified hardware access interface. The control plane runs the FRR protocol stack, including: The perception agent module contains an event listening sub-component, which is used to capture events such as hardware forwarding table entry usage exceeding the threshold and VXLAN tunnel quality degradation events reported by the switching chip through SAI and submit them to the event queue. The perception agent module is also configured to asynchronously read events from the event queue and parse and process them, while periodically and actively querying the hardware forwarding table entry usage through the SAI interface. An event queue is used to cache the events; The policy engine module is configured to interact with the perception agent module, dynamically adjust the route aggregation granularity based on the hardware forwarding table entry usage rate obtained by the perception agent module, and / or dynamically modify the attributes of the BGP routes corresponding to the tunnels with degraded quality according to a preset policy for forwarding quality events of VXLAN tunnels, and notify the neighbors through BGPUpdate.

[0017] Furthermore, the policy engine module is configured to dynamically adjust the granularity of route aggregation based on the following mechanism: When the usage rate of hardware forwarding table entries exceeds a preset first threshold, detailed route statistics are initiated. When the usage rate of hardware forwarding table entries exceeds the preset second threshold, the FRR control plane dynamically generates or modifies the route-map and applies it to the inbound or outbound direction of the BGP protocol. By adjusting the granularity of route prefix aggregation or filtering specific prefixes, the number of entries sent to the hardware is reduced. When the usage rate of hardware forwarding table entries falls below the third threshold, the original routing policy is restored.

[0018] Furthermore, the policy engine module is configured with a smooth switching mechanism. Based on this mechanism, when switching from detailed routing to aggregated routing, the policy engine module first sends the aggregated routing hardware entry to the switching chip through the SAI interface and sets a protection period. During this period, the detailed routing hardware entry is retained. The detailed entry is deleted after the traffic migrates naturally or the entry ages.

[0019] Furthermore, the policy engine module is configured with a local penalty mechanism. Based on this mechanism, for tunnels with degraded quality, the next hop of the tunnel is temporarily marked as penalized in the local forwarding table. Combined with Equal Cost Multipath Routing (ECMP) weight adjustment, new traffic is preferentially scheduled to other paths before BGP global convergence. The policy engine module is also configured with a suppression timer, which is used to maintain a stable state for a preset time after the link quality is restored before removing the degraded mark, to prevent route oscillation.

[0020] Compared with the prior art, the solution provided by the present invention has the following beneficial effects: 1. Prevention is better than cure: By real-time sensing and dynamic aggregation of hardware entries, the problem of hardware overflow and packet loss caused by exceeding the limit of routing entries in large-scale networks is completely solved, thereby improving the robustness of the network.

[0021] 2. SLA-based intelligent routing: It breaks the limitation of BGP routing based solely on reachability, introduces physical layer quality indicators such as packet loss and latency, realizes application layer experience-driven traffic scheduling, and significantly reduces the impact of network jitter on services.

[0022] 3. Full-stack collaborative closed loop: A second-level closed-loop control link of "hardware → control plane → routing protocol → hardware" is established, which can automatically adapt to changes in network load and link status without manual intervention.

[0023] 4. Compatibility and low cost: Based on the standard SAI interface and FRR open source protocol stack, it does not require modification of the BGP protocol standard, supports the reuse of existing white-box switch hardware, and has low deployment cost. Attached Figure Description

[0024] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0025] Figure 1 This is a schematic diagram of the system architecture of the present invention; Figure 2 This is a flowchart illustrating the hardware resource awareness and dynamic adjustment of BGP routing policies in this invention. Figure 3 This is a flowchart of the hardware quality awareness and dynamic BGP routing attribute tuning of the present invention. Figure 4 This is a timing diagram of route refresh and entry switching in the collaborative smoothing mechanism of this invention. Detailed Implementation

[0026] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.

[0027] Definitions: VXLAN tunnel: A point-to-point logical tunnel between two VTEPs, responsible for forwarding VXLAN packets in the IP network; Chip entries: Hardware entries on the switching chip used to process VXLAN packet forwarding and packet header encapsulation; FRR: Free Range Routing, an open-source routing protocol stack; SAI: Switch Abstraction Interface.

[0028] BGP EVPN: A BGP-based Ethernet VPN technology used to distribute Layer 2 and Layer 3 routing information in VXLAN networks.

[0029] LPM table: Longest prefix match table, used for IPv4 / IPv6 route lookup.

[0030] OAM: Operations Management and Maintenance, used for network fault detection and performance monitoring.

[0031] Telemetry: Network telemetry technology that collects real-time data on device status and performance.

[0032] This invention provides a dynamic adaptive optimization scheme for BGP routing based on hardware resource and quality awareness. This scheme can be applied to VXLAN switches running the FRR (Free Range Routing) protocol stack, enabling the FRR protocol stack to have "dual awareness" capabilities, specifically awareness of hardware resource utilization and awareness of link forwarding quality.

[0033] This invention achieves hardware resource awareness by adding a perception agent module to the FRR control plane. This perception agent module is configured to periodically and proactively query the LPM, tunnel, and FDB entry usage rates of the switching chip via the sai_get_switch_attribute API of the SAI interface. Simultaneously, it registers SAI event callbacks to receive resource over-threshold events proactively reported by the hardware. Compared to traditional polling, this invention combines proactive querying with event-driven approaches, ensuring real-time performance while reducing control plane overhead.

[0034] Meanwhile, this invention utilizes the OAM or Telemetry hardware unit built into the switching chip to collect packet loss, latency, and jitter data for each VXLAN tunnel with microsecond-level precision. It then directly reports FRR (Failure Rate Reduction) via hardware interrupts, bypassing the operating system protocol stack to achieve sub-millisecond event transmission, thereby realizing link quality awareness. Compared to software probe solutions, this invention innovatively employs a hardware pass-through reporting mechanism, effectively improving the efficiency and accuracy of link quality awareness.

[0035] Accordingly, this invention utilizes the FRR protocol stack and the switching chip hardware in the VXLAN switch to effectively perceive the hardware table resource pressure and the real-time forwarding quality of the link. It innovatively constructs a dynamic closed-loop control mechanism to optimize the BGP EVPN routing strategy: dynamically adjusting the route aggregation granularity and / or dynamically modifying the BGP route attributes, realizing millisecond-level collaborative closed loop between the control plane and data plane in the VXLAN switch, automatically adapting to changes in network load and link status, and achieving adaptive optimization of network resources.

[0036] Based on this technical mechanism, this invention presents a dynamic adaptive optimization method for BGP routing based on hardware resources and quality awareness, which can be applied to VXLAN switches running the FRR protocol stack.

[0037] This BGP routing dynamic adaptive optimization method is mainly achieved through a series of steps: Hardware resource awareness steps: The FRR control plane obtains the hardware forwarding table entry resource usage information of the switching chip (ASIC) in real time through the switch abstract interface (SAI interface). The hardware forwarding table entry resources mentioned here include LPM table entries, tunnel table entries, or FDB table entries, etc.

[0038] Resource dynamic adjustment steps: The FRR control plane sets a first threshold, a second threshold, and a third threshold. Based on this, it analyzes the perceived resource usage of hardware forwarding table entries and dynamically adjusts the routing aggregation granularity. When the usage rate of hardware forwarding table entries exceeds a preset first threshold, detailed route statistics are initiated. When the usage rate of hardware forwarding table entries exceeds the preset second threshold, the FRR control plane dynamically generates or modifies the route-map and applies it to the inbound or outbound direction of the BGP protocol. By adjusting the granularity of route prefix aggregation or filtering specific prefixes, the number of entries sent to the hardware is reduced. When the usage rate of hardware forwarding table entries falls below the third threshold, the original routing policy is restored.

[0039] Link quality awareness steps: Real-time monitoring of forwarding quality parameters for each VXLAN tunnel based on the OAM module or Telemetry module built into the switching chip. These forwarding quality parameters include, but are not limited to, packet loss rate (PLR), round-trip time (RTT), and jitter.

[0040] Quality dynamic tuning steps: The switching chip reports the detected quality degradation events to the FRR control plane through the SAI interface. At the same time, the FRR control plane dynamically modifies the routing attributes of the BGP routes corresponding to the quality degradation tunnels according to the preset policy, and notifies the neighbors through BGP Update to realize intelligent traffic scheduling and obstacle avoidance.

[0041] The following describes the specific implementation plan for each step in this BGP routing dynamic adaptive optimization method.

[0042] This BGP routing dynamic adaptive optimization method uses hardware resource awareness steps and dynamic resource adjustment steps in synergy to form a closed-loop control of resource optimization that combines hardware resource awareness with dynamic adjustment of routing aggregation granularity.

[0043] For details, see Figure 2 In the implementation of the hardware resource awareness step in this scheme, the awareness agent module in the FRR control plane periodically (e.g., every 1-10 seconds) queries the number of used entries and the total capacity of key hardware tables (e.g., LPM table, Tunnel table, FDB table) in the switching chip through the SAI interface.

[0044] As further explanation, in this solution, the perception agent module is configured to use a hybrid query mechanism combining non-blocking polling and interrupt coordination to query key hardware entries in the switching chip. Based on this hybrid query mechanism, periodic polling (the default polling period is 5 seconds) is performed. During the query, the batch attribute acquisition interface provided by SAI is used to read the usage rates of multiple entries at once, thereby reducing the number of SAI calls. Simultaneously, the hardware can trigger an interrupt when the usage rate reaches a soft threshold, notifying the FRR to enter an early warning state. This hybrid mechanism ensures low load under normal conditions while enabling rapid response when resources are scarce.

[0045] Furthermore, in implementing the resource dynamic adjustment step of this solution, a multi-level threshold strategy is constructed to dynamically adjust the granularity of route aggregation, switching detailed routes to aggregate routes to prevent hardware overflow.

[0046] To further clarify, in this solution, when executing the aggregation strategy, a strategy engine module is configured in the FRR control plane. This strategy engine module is responsible for the automatic generation and dynamic distribution of Route-Map.

[0047] This scheme sets a total of three sets of thresholds: The first threshold is a soft threshold, which can be set to 75% for example. When the utilization rate exceeds this soft threshold, an alert is triggered. At that time, the FRR control plane will start to count the number of detailed routes under a specific VNI or VRF. The "specific VNI or VRF" in the statistics here refers to the VNI or VRF that currently contributes the most to hardware table entry usage. The specific statistical scheme is as follows: The FRR control plane traverses the BGP EVPN routing table, extracts the VNI or RT (Route Target) attribute carried by each Type-5 route, and maps it to the corresponding VRF; The number of detailed routes that have been distributed to the hardware (host routes such as / 32 and / 31 ​​with a prefix length of ≥25) is aggregated according to VNI / VRF. Generate a detailed list of route counts for each VNI / VRF, sorted by number, for the policy engine module to make decisions.

[0048] The second threshold is a hard threshold used to trigger the aggregation policy. For example, this hard threshold is preferably set to 85%. If this hard threshold is exceeded, the FRR control plane dynamically generates or modifies the incoming route-map. For a specific peer or VNI, it rejects detailed routes with prefix lengths greater than the preset detailed route prefix length threshold and only accepts aggregated routes.

[0049] As further explanation, when dynamically generating the Route-Map, the strategy engine module automatically constructs the FRR configuration syntax string based on the selected VNI and the preset aggregation prefix length (e.g., / 24), eliminating the need for manual coding and achieving automated generation.

[0050] Furthermore, the generated Route-Map is dynamically configured using the VTYSH configure terminal command, without needing to restart the BGP process, thus achieving hot reloading.

[0051] Furthermore, when revoking an aggregation, the policy engine module first backs up the original Route-Map, then deletes the aggregation policy. If BGP neighbor negotiation fails, the original policy is automatically restored to avoid routing black holes and achieve automatic rollback.

[0052] Compared with the conventional manual configuration of Route-Map, this solution realizes automatic generation, dynamic distribution and fault rollback of policies, which significantly improves operation and maintenance efficiency and reliability.

[0053] As further explanation, this solution is implemented by setting matching conditions and actions in the inbound Route-Map: match ip address prefix-len ge 25 matches all detailed routes of / 25 and above, and executes the deny action to refuse reception; while aggregate routes (such as / 16, / 24) are received normally because the prefix length is ≤24 and matches the subsequent permit rules.

[0054] Based on this step, the present invention dynamically links the above-mentioned routing matching rule mechanism with the hardware resource perception threshold, realizing closed-loop control of automatically switching detailed route filtering according to the hardware level. Compared with the existing conventional static configuration scheme, it can automatically aggregate when the hardware pressure increases and automatically recover after the pressure is relieved, without manual intervention throughout the process, and avoids the decrease in routing accuracy caused by excessive aggregation.

[0055] The third threshold is the recovery threshold, which is preferably set to 60% for example. When the hardware pressure is relieved, the FRR control plane cancels the aggregation policy and restores the reception of detailed routes through the BGP Route-Refresh mechanism to ensure routing accuracy.

[0056] As further explanation, this step can be implemented based on the BGP Route-Refresh capability defined in RFC 2918. Specifically, this solution configures an adaptive coordination logic mechanism in Route-Refresh: before sending a Route-Refresh request, the policy engine module first checks whether the neighbor supports the Route-Refresh capability (through capability negotiation). If not, a gentle route withdrawal and retransmission method is used (withdrawing the original route one by one and then announcing the new route), avoiding a hard reset of the BGP session that would cause traffic interruption.

[0057] As further explanation, this solution supports differentiated configuration based on VNI or VRF granularity during the adjustment of routing policies, that is, only performing route aggregation on the VNI with the highest pressure, rather than a global one-size-fits-all approach.

[0058] This solution includes the following steps when implementing differentiated configuration based on VNI granularity: Configuration template: Preset an independently configurable set of parameters (aggregation trigger hard threshold, aggregation prefix length, detailed filtering granularity) for each VNI and store it in the FRR configuration file. Example format: vni 2000 aggregation-threshold 85% prefix-len 24.

[0059] Pressure sorting: When the overall LPM table utilization reaches the global hard threshold, the policy engine reads the detailed route statistics of each VNI and sorts them from largest to smallest by quantity.

[0060] Selective aggregation: Starting with the highest-ranked VNI, apply its preset aggregation strategy one by one (i.e., generate the corresponding Route-Map and apply it to BGP neighbors). After aggregating each VNI, re-evaluate the hardware utilization. If it has dropped below the hard threshold, stop aggregation; if it still exceeds the threshold, continue aggregating the next VNI until the pressure is relieved.

[0061] Differentiated recovery: When hardware utilization drops below the recovery threshold, the aggregation policies of each VNI are revoked one by one in reverse order of aggregation, and VNIs with fewer detailed routes are restored first to ensure fine-grained routing for critical services.

[0062] This BGP route dynamic adaptive optimization method uses a link quality awareness step and a quality dynamic tuning step in synergy to form a closed-loop control for link quality optimization that combines link quality awareness with dynamic tuning of BGP route attributes.

[0063] For details, see Figure 3In the link quality awareness step of this solution, the OAM module or Telemetry module built into the switching chip monitors the forwarding quality indicators of each VXLAN tunnel (VTEP pair) in real time. The forwarding quality indicators monitored include, but are not limited to, packet loss rate (PLR), round-trip time (RTT), and jitter.

[0064] As further explanation, in this solution, link quality awareness is accomplished collaboratively by the OAM (Operation, Management, and Maintenance) hardware engine built into the switching chip and the Telemetry hardware acquisition subsystem. Their respective roles are as follows: The OAM hardware engine is configured to handle proactive, high-precision tunnel quality detection, specifically including: The BFD hardware offloading engine chip supports hardware termination and packet transmission and reception of BFD (Bidirectional Forwarding Detection) sessions. It can accurately calculate the one-way / bidirectional packet loss rate and latency of each VXLAN tunnel without CPU intervention, with a detection accuracy of up to 1ms, for rapid detection of link degradation events.

[0065] Periodic OAM probe: The chip sends OAM probe messages with hardware timestamps to the peer VTEP at fixed intervals (e.g., 100ms). The peer chip automatically replies in hardware, and the local chip calculates round-trip time (RTT) and jitter based on the reply timestamp to achieve continuous tracking of tunnel latency characteristics.

[0066] The Telemetry hardware acquisition subsystem is responsible for passive traffic statistics and congestion awareness, specifically including: Hardware counting: The chip independently maintains a send / receive message counter and a queue drop counter for each tunnel. The counting results are periodically synchronized to the on-chip shared memory via DMA (Direct Memory Access). The FRR control plane can read the count at any time to help determine the degree of congestion and calculate long-term packet loss trends.

[0067] All quality data collected by the OAM engine and Telemetry subsystem (including tunnel ID, packet loss rate, RTT, jitter, queue packet loss count, etc.) are reported to the FRR control plane through the predefined event callback mechanism (sai_tunnel_quality_notification) of the SAI interface. The report adopts a structured data format to ensure that the control plane can quickly parse and trigger subsequent routing policy adjustments.

[0068] Based on this, an event reporting mechanism is set up. When the forwarding quality index is detected to exceed the preset degradation threshold (such as packet loss rate > 0.1% or RTT sudden increase of 50%), the hardware notifies the FRR control plane through interrupt, Netlink message or SAI attribute change.

[0069] In the quality dynamic tuning step of this scheme, the FRR control plane matches the corresponding BGP EVPN route (the next hop is the VTEP) based on the degradation events reported by the switching chip.

[0070] To further illustrate, in order to achieve a fast, accurate, and robust mapping from hardware tunnel degradation events to BGP logical routes, this solution constructs a "real-time association and matching mechanism between hardware events and BGP routes." This mechanism is systematically designed at four levels: data structure construction, matching process, exception handling, and state consistency protection, as detailed below: (1) Construction and real-time maintenance of multidimensional dynamic hash index; During the normal operation of the BGP EVPN Routing Table (RIB), the FRR control plane does not passively wait for events to trigger, but actively creates multi-dimensional index entries for each issued EVPN route. The route types covered by the index include: Type-2 (MAC / IP advertised routes), Type-5 (IP prefix routes), and Type-3 (Inclusive Multicast routes) and Type-4 (Ethernet Segment routes). Type-2 and Type-5 use a composite key (VTEP IP, VNI) for indexing, while Type-3 and Type-4 use a single key (VTEP IP) for indexing, with the value field being a linked list of pointers to the corresponding route structure.

[0071] When BGP routes are added, deleted, or their attributes are changed, FRR synchronously updates the hash table through an internal callback function, ensuring that the index and the control plane routing table always maintain eventual consistency. This dynamic maintenance mechanism reduces the time complexity of the "event-route" matching process from O(N) traversal in the traditional scheme to O(1) precise hit, laying the data structure foundation for millisecond-level response.

[0072] (2) Hierarchical and progressive fast matching and fault-tolerant mapping; When the switching chip reports a tunnel degradation event via SAI (carrying the tunnel ID, VTEP IP, VNI, and degradation level), FRR executes the following hierarchical matching logic: Precise direct matching (main path): The FRR (Fulfilled Response Rate) event is resolved, extracting the VTEP IP and VNI, and performing a precise lookup in the dynamic hash table. If a match is found, the affected BGP routing list is locked, and the attribute modification process begins. This path covers the vast majority of matching requirements in typical network topologies.

[0073] Extended matching based on Route-Target (RT) (fault-tolerant path): Considering that physical VNIs and logical VRFs are not strictly one-to-one in cross-VNI or VPN scenarios, if an exact match fails, FRR initiates extended matching. It uses the RT value in the BGP extended community attribute to look up the associated VRF, and then matches the next hop of that VRF pointing to the degraded VTEP, ensuring no missed matches in complex network topologies. When both exact matching and RT extended matching succeed, FRR takes the union of the two as the set of routes to be modified, preventing some routes from being left unprocessed.

[0074] Range pre-filtering and batch processing: For a large number of instantaneous tunnel quality fluctuations (such as instantaneous optical module outages), FRR does not process them one by one immediately. Instead, it first performs event deduplication and aggregation based on the hash index, merges events with the same source using (VTEP IP) as the aggregation key, takes the most severe degradation level as the current state of the VTEP, and triggers unified processing after merging to prevent control plane CPU overload.

[0075] (3) Fast mapping and policy locking of matching results; After a successful match, FRR maps the real-time quality parameters in the degradation event to the corresponding attribute modification actions according to the degradation level (mild / moderate / severe), including MED adjustment, Community addition, LOCAL_PREF adjustment, etc., and processes them in descending order of degradation level.

[0076] To prevent BGP routes from changing state due to concurrent events during the matching process, FRR introduces a lightweight route locking mechanism: Upon a hash index match, a read lock is immediately applied to the matched route entry, preventing other threads from writing to that route; if the route is marked for revocation or aging out during the locking period, FRR automatically abandons the modification and releases the lock; the lock is released after the attribute modification is complete, the BGP Update message is constructed, and added to the sending queue. This mechanism ensures the atomicity of the entire "matching-modification-announcement" chain.

[0077] If no BGP route is matched for any of the matching paths, FRR writes the degradation event to the local log and then discards it, without blocking the processing flow of other events.

[0078] Based on this, the FRR control plane maps the degradation level to specific BGP route attribute modification actions according to the quality parameters carried by the tunnel degradation event and a preset policy table: For minor degradation: modify the MED attribute or prepend AS_PATH to prioritize routing traffic to other paths; For severe degradation: Modify LOCAL_PREF to an extremely low value, or attach a specific BGP Community (such as NO_EXPORT or a custom LOW_PRIO label) to make upstream devices completely avoid this path.

[0079] Through the above-mentioned hierarchical strategy, this solution achieves hierarchical traffic scheduling from "local guidance" to "network-wide detour", avoiding overly aggressive routing adjustments for minor degradation and triggering global traffic switching only in cases of severe degradation.

[0080] Furthermore, after the FRR control plane completes the attribute modification, it achieves millisecond-level traffic switching based on the configuration's fast convergence mechanism.

[0081] Specifically, the fast convergence mechanism in this solution achieves millisecond-level traffic switching through the coordinated operation of the following three sub-mechanisms: Incremental Update: When constructing a BGP Update message, FRR only carries the changed routing attributes (such as MED, Community, LOCAL_PREF) and does not retransmit NLRI (Network Layer Reachability Information). Compared to a full table refresh, the incremental Update message size is significantly reduced, lowering control plane bandwidth usage and neighbor device processing overhead, and accelerating message transmission and parsing speed.

[0082] Parallel Advertisement: The FRR control plane maintains an independent update queue for each BGP neighbor. After an attribute modification is completed, each queue triggers the sending of Update messages in parallel, without waiting for all neighbors to process them one by one. This avoids the cumulative latency caused by serial sending and ensures rapid convergence of synchronization in multi-neighbor scenarios.

[0083] Local Priority Switching: Before the BGP Update message is sent, FRR has adjusted the forwarding weights of each next hop in the ECMP group through a local penalty mechanism, so that new traffic will preferentially choose other paths on the local forwarding plane. This mechanism does not rely on BGP protocol convergence and completes local traffic deflection in sub-milliseconds, serving as a fast response layer before global BGP convergence takes effect.

[0084] The three mechanisms of incremental update, parallel notification, and local priority handover work together to keep the end-to-end latency of the entire link, from the reporting of hardware quality degradation events to the FRR control plane, through route matching and attribute modification, to the completion of the final traffic handover, within 50ms.

[0085] Accordingly, this BGP routing dynamic adaptive optimization method can establish a dual closed-loop feedback mechanism between the control plane and the data plane, realizing adaptive optimization of network resources and significantly improving the reliability, stability and forwarding performance of data center networks.

[0086] Based on the above scheme, this BGP routing dynamic adaptive optimization method further constructs a policy coordination and smooth switching mechanism. This mechanism is used to avoid traffic interruption, packet loss or routing oscillation caused by sudden changes in routing policies (such as switching from details to aggregation, or restoring details from aggregation).

[0087] Specifically, this policy coordination and smooth switching mechanism includes four sub-mechanisms: route refresh negotiation, soft switchover, local penalty, and suppression timer. Route refresh negotiation and soft switchover work together to solve the problem of seamless transition between the control plane and data plane during route policy changes (detailed to aggregate switching). Local penalty, as a fast pre-convergence response for BGP global convergence, completes local traffic deflection in sub-milliseconds. The suppression timer prevents frequent policy rollbacks after quality recovery. These four sub-mechanisms work synergistically from four dimensions—control plane, data plane, latency compensation, and stability assurance—to jointly constitute a complete guarantee system for service continuity during policy switching.

[0088] Route refresh negotiation mechanism: Before adjusting the routing policy, the FRR control plane uses BGP Route-Refreshcapability to negotiate with neighbors and request to resend routes to avoid hard interruption.

[0089] This route refresh negotiation mechanism is based on the BGP Route-Refresh capability (RFC 2918). The specific implementation process of this solution is as follows: When a BGP session is established, FRR checks whether Route-Refresh (code 2) is included in the Capabilities advertised by the neighbor.

[0090] If supported, when the FRR needs to change the inbound policy, it sends a ROUTE-REFRESH message (message type 5) to request the neighbor to retransmit the route.

[0091] If the neighbor does not support it, FRR will fall back to a milder approach: first, cancel all routes affected by the policy (send an Update cancellation message), then wait for the neighbor to actively retransmit or wait for the routes to age out, avoiding the use of clear ip bgp for hard reset.

[0092] This negotiation mechanism enables the solution to be compatible with BGP devices of different capabilities, thus expanding its applicability.

[0093] Table entry soft handover mechanism: See [link] Figure 4Based on this soft handover mechanism, when a BGP route is switched from a "detailed route" to an "aggregated route", the FRR control plane first issues the hardware entry for the aggregated route and sets a "grace period". During this period, the old detailed route entry remains valid. The old entry is then deleted after the traffic migrates naturally or after the ARP / ND entry ages, ensuring no packet loss.

[0094] Combination Figure 4 The specific process of the soft handover mechanism for this entry is as follows: Phase 1 (before the switchover): The hardware only contains detailed routing table entries (such as 10.1.1.1 / 32), and traffic is forwarded normally.

[0095] Phase 2 (Aggregate Distribution): FRR distributes aggregated route entries (e.g., 10.1.0.0 / 16) to the hardware via SAI. At this point, the hardware has both detailed and aggregated entries. Due to longest prefix matching, existing session flows still match detailed routes, while newly established sessions match aggregated routes.

[0096] Phase 3 (Protection Period): Start a 30-second timer. During this period, the hardware retains detailed routes, while the FRR sends Route-Refresh to the BGP neighbor, starts receiving aggregated routes, and stops receiving new detailed routes.

[0097] Phase 4 (Aging Deletion): After the protection period ends, the FRR command instructs the hardware to delete all detailed routing table entries, or the hardware automatically deletes them based on the idle timeout. If there is still traffic matching the details (a very small number of long-lived connections), the detailed entries are retained until the traffic ends.

[0098] Figure 4 The left vertical axis represents the timeline, while the right side shows the changes in hardware entry content and traffic matching behavior, clearly presenting the lossless switching process of "create first, then delete".

[0099] Local penalty mechanism: For a determined quality degraded tunnel, the FRR control plane temporarily marks the next hop of the tunnel as a penalty state in the local forwarding table, and combined with Equal Cost Multipath Routing (ECMP) weight adjustment, prioritizes scheduling new traffic to high-quality links at the local level before BGP global convergence.

[0100] The local penalty mechanism and the aforementioned soft switchover mechanism address different triggering scenarios: soft switchover is mainly used for smooth updates of table entries in routing aggregation / deaggregation scenarios triggered by resource pressure, while local penalty is mainly used for rapid response in traffic scheduling scenarios triggered by link quality. The two are independent of each other and can also coexist.

[0101] The specific implementation process of the local penalty mechanism is as follows: Penalty marking: After receiving a tunnel quality degradation event, FRR modifies the state of the corresponding next hop in the kernel FIB table through the Netlink interface, sets the RTNH_F_PENALTY flag, and records the penalty start time.

[0102] ECMP weight adjustment: For routes in ECMP groups that contain penalized next hops, FRR recalculates the weights: the original weight W is reduced to W × penalty coefficient (e.g., 0.1), while the weights of other paths remain unchanged. When selecting paths via hashing, the kernel allocates them according to weight probability, thus ensuring that most new traffic avoids degraded paths.

[0103] Smooth activation: The hash results of established connections remain unchanged and unaffected, avoiding connection interruption.

[0104] Automatic release: When the quality is restored and the suppression timer expires, FRR clears the penalty flag and restores the original weight.

[0105] This mechanism does not rely on BGP convergence (which typically takes seconds) and achieves sub-millisecond traffic adjustment at the local forwarding level, making it an effective supplement to BGP global optimization.

[0106] Suppression timer mechanism: To address the issue that frequent fluctuations in link quality at the edge of the degradation threshold may lead to frequent switching of routing attributes and cause routing oscillations across the entire network, this solution introduces a suppression timer during the quality recovery phase.

[0107] This suppression timer is also used to control the lifting of local penalty states and the revocation of BGP bad flags (Community, LOCAL_PREF adjustments, etc.). Its specific working mechanism is as follows: Triggering condition: When the tunnel quality index reported by the hardware is lower than the recovery threshold (e.g., packet loss rate <0.05%) for two consecutive samplings (sampling period is configurable, default is 1 second), FRR determines that the quality has been restored. At this time, the poor quality mark is not immediately revoked or the original BGP attributes are restored. Instead, the suppression timer is started (default is 300 seconds, configurable).

[0108] Monitoring during timing: During the suppression timer operation, FRR continues to monitor the tunnel's quality indicators: If the quality remains good until the timer expires, FRR will perform a recovery operation: clear the poor Community of the tunnel-associated route, restore the original attributes such as LOCAL_PREF / MED, and send a BGP Update to the neighbor; If quality degradation occurs again during the timer period (i.e., the index exceeds the degradation threshold again), the suppression timer is immediately reset, the quality state reverts to the degraded state, the original quality label remains unchanged, and the suppression timer is restarted after the next recovery.

[0109] Enhanced Exponential Backoff: To avoid frequent oscillations of the tunnel at the "recovery-deterioration-recovery" boundary, the duration of the suppression timer is doubled each time it is reset due to further degradation (e.g., 300 seconds → 600 seconds → 1200 seconds, with a maximum limit of 3600 seconds), thereby gradually reducing the sensitivity to recovery of unstable links.

[0110] This mechanism is directly linked to hardware quality data, and the inferior label is only removed after the quality is truly stable. This not only prevents routing oscillations, but also avoids the excessively long penalty caused by the traditional BGP damping mechanism based on the number of times the router is flipped, thus achieving more precise stability control.

[0111] Through the systematic coordination of the above four sub-mechanisms, this solution achieves a complete closed loop from control plane route re-collection (route refresh negotiation) to data plane table entry lossless switching (table entry soft switching), from rapid local response before BGP global convergence (local penalty) to stability guarantee during policy recovery (suppression timer), ensuring service continuity and network stability throughout the entire process of routing policy changes.

[0112] The BGP routing dynamic adaptive optimization method based on the above scheme can establish a second-level full-stack collaborative closed-loop control link of "hardware → control plane → routing protocol → hardware" for VXLAN switches running the FRR protocol stack, which can automatically adapt to changes in network load and link status without manual intervention.

[0113] The BGP routing dynamic adaptive optimization method described in this embodiment can be configured into a corresponding software program to form a BGP routing dynamic adaptive optimization system. This software program can be deployed and run on a VXLAN switch with an FRR protocol stack, and can execute the aforementioned BGP routing dynamic adaptive optimization method. It is also stored in a corresponding storage medium for the processor to retrieve and execute.

[0114] The resulting BGP routing dynamic adaptive optimization system is architecturally divided into three layers: (a) Data plane (switching chip layer) The switching chip is used to provide storage for hardware forwarding table entries (LPM table, tunnel table, FDB table, etc.) and high-speed forwarding of VXLAN packets. It also has built-in table usage monitoring and tunnel quality monitoring (OAM / Telemetry) functions, and is the hardware foundation for the system to perform forwarding.

[0115] (ii) Intermediate layer (abstract interface layer) The Abstract Interface Layer (SAI) is used to connect the switching chip and the control plane, providing a unified hardware access interface, shielding the hardware differences between different chip manufacturers, and enabling the control plane to obtain hardware status and issue forwarding entries in a standardized manner.

[0116] (III) Control Plane (FRR Protocol Stack Layer) The FRR protocol stack runs in the control plane, which is responsible for BGP route calculation and policy decision-making. It interacts with the switching chip through the SAI interface to realize the linkage between the control plane and the data plane.

[0117] The resulting overall system architecture is as follows Figure 1 As shown, the three layers communicate with each other through a standard interface, forming a complete closed loop of "hardware perception → control decision → policy execution".

[0118] This system deploys three core functional modules in the control plane that runs the FRR protocol stack: a perception agent module, an event queue, and a policy engine module.

[0119] The perception agent module is configured to collect raw data from the hardware and convert it into internal events. The event queue is configured to cache events, achieving asynchronous decoupling between event collection and processing; The strategy engine module is configured to be responsible for executing specific routing strategy adjustments based on the event content.

[0120] The three components form a sequential collaborative architecture of "collection → caching → processing," ensuring that the system can still operate stably under the impact of high-concurrency events.

[0121] The perception agent module in this system is configured to interact with the switching chip via the SAI interface to obtain the hardware forwarding table entry usage rate and VXLAN tunnel forwarding quality events.

[0122] Specifically, the perception agent module runs as a separate thread (or plugin) of FRR, and its components include: SAI wrapper layer: Encapsulates all SAI calls, providing interfaces such as get_resource_usage() and register_event_callback(), shielding the complexity of the underlying SAI API; Polling timer: Based on the FRR event loop (thread_add_timer), periodic queries are implemented to actively obtain the hardware table entry usage rate at regular intervals; Event parser: Converts raw data reported by the hardware (such as SAI attribute structure) into internal event structure and submits it to the event queue; State caching: Caches the resource utilization rate obtained from the last query for change detection and alert triggering, avoiding duplicate processing.

[0123] In terms of specific deployment, the perception agent module shares the address space with the FRR main process and communicates through an internal message queue, without requiring modification of the FRR core code, thus maintaining upgrade compatibility.

[0124] The event queue in this system is specifically a first-in-first-out (FIFO) thread-safe queue, dedicated to caching two types of events reported by the hardware: Resource utilization event: An event reported by the switching chip via SAI when the hardware entry utilization exceeds the soft threshold or hard threshold; Tunnel quality degradation event: An event reported by the switching chip via SAI when the packet loss rate, RTT, or jitter of the VXLAN tunnel exceeds the preset degradation threshold.

[0125] Furthermore, the event queue and the perception agent module in this system are configured with the following cooperation mechanism: Event Producer: The event listener module (a sub-component of the perception agent) quickly encapsulates the raw event data reported by the hardware into internal event objects within the SAI callback function, and calls the queue's enqueue interface (non-blocking) to put the events into the queue. This process requires extremely low latency (microseconds) to avoid blocking hardware interrupts.

[0126] Event Consumer: The main loop (or a separate worker thread) of the perception agent module periodically retrieves events in batches from the event queue for parsing and processing. Processing includes: parsing event types and parameters, calling the strategy engine module for decision-making, and executing corresponding routing strategy modifications or aggregation actions.

[0127] Flow control and backpressure: When the event queue length exceeds a preset threshold (e.g., 1000 events), the perception agent can temporarily stop receiving new events from SAI (by temporarily disabling callbacks or reducing the sampling frequency) to prevent control plane overload. When the queue is empty, the perception agent continues to perform periodic polling tasks.

[0128] By introducing an event queue, this system achieves asynchronous decoupling between event acquisition and event processing. This ensures rapid response to hardware interrupts and avoids the impact of processing time on event capture, thereby improving the overall robustness and scalability of the system.

[0129] In this system, the policy engine module is configured to interact with the perception agent module, dynamically adjust the routing aggregation granularity based on the hardware forwarding table entry usage rate obtained by the perception agent module, and / or dynamically modify the attributes of the BGP routes corresponding to the tunnels with degraded quality according to preset policies for forwarding quality events of VXLAN tunnels, and notify neighbors for traffic scheduling through BGP Update.

[0130] Furthermore, the strategy engine module contains three core functional mechanisms: a dynamic resource adjustment mechanism, a dynamic quality optimization mechanism, and a collaborative assurance mechanism, which correspond to the three capabilities of dynamic resource adjustment, dynamic quality optimization, and collaborative smooth assurance described in the methodology section of this solution, respectively. (1) Dynamic adjustment mechanism of resources.

[0131] This policy engine module is configured to dynamically adjust the granularity of route aggregation based on the following mechanism: When the usage rate of hardware forwarding table entries exceeds the preset first threshold (soft threshold), detailed route statistics are initiated. When the usage rate of hardware forwarding table entries exceeds the preset second threshold (hard threshold), the FRR control plane dynamically generates or modifies the route-map and applies it to the inbound or outbound direction of the BGP protocol. By adjusting the granularity of route prefix aggregation or filtering specific prefixes, the number of entries sent to the hardware is reduced. When the usage rate of hardware forwarding table entries falls below the third threshold (recovery threshold), the original routing policy is restored.

[0132] (2) Dynamic quality optimization mechanism.

[0133] This policy engine module, based on tunnel quality degradation events obtained by the perception agent module, maps degradation levels (mild / moderate / severe) to corresponding BGP attribute modification actions according to a preset policy table. These actions include MED adjustment, Community appending, and LOCAL_PREF adjustment, and traffic scheduling is implemented by notifying neighbors via BGP Update. The specific matching process of this mechanism is described in the previous section "Dynamic Quality Tuning Steps," and will not be repeated here.

[0134] (3) Collaborative guarantee mechanism.

[0135] The strategy engine module is configured with three types of collaborative protection sub-mechanisms: a smooth switching mechanism, a local penalty mechanism, and a suppression timer. These mechanisms ensure uninterrupted business operations during strategy switching from three dimensions: data plane table entry updates, forwarding plane rapid response, and stability assurance.

[0136] (3.1) Smooth switching mechanism.

[0137] Based on this mechanism, when switching from detailed routing to aggregated routing, the policy engine module first sends the aggregated routing hardware entry to the switching chip through the SAI interface and sets a protection period. During this period, the detailed routing hardware entry is retained, and the detailed entry is deleted after the traffic migrates naturally or the entry ages.

[0138] To avoid traffic interruptions, packet loss, or out-of-order delivery during the switch from detailed routes to aggregate routes, this system solution implements a smooth "create first, delete later" switchover mechanism. This mechanism differs from conventional direct replacement operations; it achieves seamless service switching through the coexistence of entries within the protection period and natural traffic migration. The specific implementation steps are as follows: Step 1: Pre-deployment of aggregated routes (coexistence of hardware entries); When the policy engine module decides to perform route aggregation for a VNI, the FRR control plane first generates the aggregated route (e.g., 10.1.0.0 / 16) and prioritizes sending the hardware forwarding table entry for this aggregated route to the switching chip via the SAI interface. At this time, the hardware entries for existing detailed routes (e.g., 10.1.1.1 / 32, 10.1.1.2 / 32, etc.) remain unchanged. The switching chip's forwarding table contains both aggregated and detailed routes. Due to the longest prefix match (LPM) principle, existing traffic flows (determined by their five-tuple hashes) will still match the more specific detailed routes, while newly arriving traffic will match the aggregated route (if no more specific detailed route exists). This coexistence ensures that existing sessions are not affected during the handover process.

[0139] Step 2: Grace Period Settings; After FRR successfully distributes the aggregated route, it starts a grace timer with a default duration of 30 seconds (configurable, ranging from 10 to 120 seconds). The purpose of this grace period is to give existing traffic on detailed routes sufficient time to migrate naturally or complete transmission. During this period: The switching chip retains both detailed and aggregated entries; FRR stops sending new detailed routes to this VNI (by rejecting new detailed routes through the inbound Route-Map). The hardware continues to forward packets that match the detailed route.

[0140] Step 3: Natural migration of traffic and aging of entries; After the protection period ends, FRR instructs the switching chip to delete all affected detailed routing hardware entries. There are two optional deletion methods: Active deletion: FRR issues deletion commands one by one through the SAI interface; Hardware aging and deletion: Utilizing the idle timeout mechanism of the switching chip entries, the idle aging time of the detailed routing table entries is set to the same value as the protection period (e.g., 30 seconds). After the protection period expires, the hardware automatically reclaims the detailed table entries with no traffic.

[0141] For detailed routes (such as long-lived TCP sessions) that consistently receive traffic hits during the protection period, the hardware will not automatically age out due to the continuous hits. In this case, FRR can be handled using two strategies: Strategy 1 (default): Retain the detailed route until traffic terminates naturally (session ends), during which time the aggregated route is only used for new traffic; Strategy 2: Forcefully delete the detailed route after the protection period ends, so that subsequent packets are forced to match the aggregated route (because the aggregated route has a larger coverage area, it will not cause packet loss, but it may cause changes in the packet encapsulation path, which needs to be tolerated by the upper layer protocol).

[0142] This solution adopts Strategy 1 by default to ensure business continuity to the greatest extent.

[0143] Step 4: Coordination with BGP route convergence; During the protection period, FRR simultaneously performs route refresh negotiation at the BGP layer (such as sending Route-Refresh), causing BGP neighbors to stop sending detailed routes and start sending aggregate routes. After the protection period ends and the detailed table entries are deleted, the hardware only retains the aggregate routes, and the BGP control plane and data plane finally reach a consistent state.

[0144] Conventional hardware routing table updates typically employ either a "delete then add" or "atomic replacement" approach. The former leads to temporary routing disruptions (packet loss), while the latter, although enabling rapid switching, cannot address the different granularity requirements of existing and new traffic. This invention achieves this by introducing a protection period and a mechanism for coexisting routing entries. Zero packet loss switching: old and new entries coexist, and there are always matching entries available; Smooth traffic transition: Existing traffic continues to be processed in detail, while new traffic is aggregated, without interference between them; Hardware resource friendly: Detailed entries are automatically reclaimed after the protection period ends, and do not occupy double resources for a long time; Parameter configurability: The protection period duration, aging strategy (active / passive), long connection retention strategy, etc. can all be dynamically adjusted through the FRR configuration file or command line to adapt to different business scenarios (such as shortening the protection period for latency-sensitive businesses, and extending the protection period or adopting strategy one for businesses with many long connections).

[0145] (3.2) Local penalty mechanism The policy engine module is configured with a local penalty mechanism. Based on this mechanism, for tunnels with degraded quality, the next hop of the tunnel is temporarily marked as penalized in the local forwarding table. Combined with equal cost multipath routing (ECMP) weight adjustment, new traffic is preferentially scheduled to other paths before BGP global convergence.

[0146] The local penalty mechanism, as a supplement to BGP global convergence, achieves sub-millisecond traffic deflection at the local forwarding layer before the control plane completes route updates. This mechanism and the smooth switching mechanism address different triggering scenarios: the smooth switching mechanism is mainly used for smooth entry updates in route aggregation / deaggregation scenarios triggered by resource pressure, while the local penalty mechanism is mainly used for rapid response in traffic scheduling scenarios triggered by link quality. The two are independent of each other and can also coexist.

[0147] The specific implementation steps are as follows: Step 1: Deterioration detection and marking; When the FRR control plane receives a tunnel quality degradation event (e.g., packet loss rate > 0.1%) reported by the switching chip through the awareness agent, the policy engine immediately extracts the next-hop IP address (i.e., the peer VTEP IP) of the degraded tunnel. Subsequently, the FRR sends a modification command to the operating system kernel routing table (or directly to the switching chip's local forwarding table) through the Netlink interface, marking the routing entry corresponding to the next hop as "penalized". In specific implementations, this can be achieved by setting kernel routing flags (e.g., RTNH_F_PENALTY) or by adding a penalty attribute (e.g., a weight reduction flag) to the next hop in the switching chip's ECMP group.

[0148] Step 2: Dynamically adjust ECMP weights; For destination networks with multiple Equal Cost Paths (ECMP), FRR recalculates the forwarding weights of each next hop in the ECMP group. Let the original weight be W (usually all paths have equal weights, such as 1), and the penalty coefficient α be set to 0.1 (configurable). The weight of the penalized next hop is temporarily adjusted to W × α, while the weights of other unpenalized next hops remain unchanged. When the kernel or switching chip selects the outgoing path based on a hash algorithm, it allocates new traffic according to the adjusted weight ratio. For example, if the ECMP group originally had 4 equal-weight paths, each with a weight of 1, for a total weight of 4; after penalizing one of them, the weight of that path becomes 0.1, the total weight decreases to 3.1, and the probability of new traffic choosing the penalized path decreases from 25% to approximately 3.2%.

[0149] Step 3: Smooth activation and connection maintenance; The aforementioned weight adjustments only affect the hash calculation results of newly established traffic. For existing connections (whose hash values ​​are already determined), the forwarding path remains unchanged, thus avoiding packet out-of-order delivery or connection interruption due to path mutations. This is achieved by keeping the forwarding decisions of existing connection table entries in the kernel or chip unchanged.

[0150] Step 4: Automatically remove the penalty; Once tunnel quality recovers and the suppression timer expires, FRR clears the penalty flag for that next hop and restores the original weight configuration of the ECMP group. If BGP global convergence has been completed during the penalty period (i.e., the upstream neighbor has updated the routing attributes via Update messages), the local penalty can be lifted early to avoid redundant operations.

[0151] The local penalty mechanism established here can achieve the following technical features: Sub-millisecond response: Without relying on BGP protocol convergence (which usually takes seconds or even longer), weights are adjusted directly at the forwarding plane, and the latency from the occurrence of a quality event to traffic deflection can be controlled within 10ms; Lossless switching: By distinguishing between newly established traffic and existing connections, the impact on existing services is avoided, ensuring smoothness; Collaboration with BGP: As a front-end rapid response method for BGP global optimization, the two form a two-layer protection of "local rapid deflection + global route convergence", which not only meets the real-time requirements of emergency obstacle avoidance, but also ensures the long-term stability of the network. Hardware acceleration: For switching chips that support programmable ECMP, weight adjustments can be directly sent to the chip by FRR via SAI without going through the kernel, further reducing latency.

[0152] (3.3) Suppression timer The policy engine module is also equipped with a suppression timer, which is used to maintain a stable state for a preset time after the link quality is restored before removing the inferior label, in order to prevent route oscillation.

[0153] To prevent frequent switching of BGP routing attributes due to instantaneous fluctuations in link quality (such as micro-burst congestion, device restarts, etc.), which could cause network-wide routing oscillations, this solution introduces a suppression timer during the quality recovery phase. This suppression timer is also used to control the removal of local penalty states and the cancellation of BGP poor quality labels (Community, LOCAL_PREF adjustments, etc.).

[0154] The implementation scheme for suppressing the timer is as follows: Timer trigger conditions; When the tunnel quality metrics (such as packet loss rate and RTT) reported by the hardware are both below the recovery threshold (e.g., packet loss rate < 0.05%) for two consecutive samplings (the sampling period is configurable, default is 1 second), FRR determines that the quality has been restored, but does not immediately remove the inferior label or restore the original BGP route attributes. Instead, it starts the suppression timer (default is 300 seconds, i.e. 5 minutes).

[0155] Monitoring during timer operation; During the suppression timer's operation, FRR continues to monitor the tunnel's quality metrics: If the quality remains good until the timer expires, FRR will perform a reversal operation: clear the poor Community of the tunnel-associated route, restore the original attributes such as LOCAL_PREF / MED, and send a BGP Update advertisement to the neighbors; If quality degradation occurs again during the timer period (i.e., the index exceeds the degradation threshold again), the suppression timer is immediately reset, the quality state reverts to the degraded state, the original quality label remains unchanged, and the suppression timer is restarted after the next recovery.

[0156] Enhanced Indexed Avoidance (optional); To avoid frequent oscillations of the tunnel at the "recovery-deterioration-recovery" boundary, this scheme supports an enhanced exponential backoff: each time the suppression timer is reset due to further degradation, the duration of the suppression timer is doubled (e.g., 300 seconds → 600 seconds → 1200 seconds, with a maximum limit of 3600 seconds), thereby gradually reducing the sensitivity to recovery of unstable links.

[0157] Conventional BGP damping mechanisms penalize based solely on the number of route flappings, failing to detect the actual recovery of link quality and often resulting in excessively long penalty times. This invention's suppression timer is directly linked to hardware quality data, only removing the inferior label after the quality has truly stabilized. This prevents oscillations and avoids excessive penalties, achieving more precise stability control.

[0158] The complete workflow of the BGP routing dynamic adaptive optimization system based on the above scheme is as follows: Perception Phase: The perception agent module periodically queries the hardware entry usage rate of the switching chip through the SAI interface, and listens for tunnel quality degradation events actively reported by the hardware. After converting the acquired data into internal events, it submits them to the event queue. Decision-making phase: The strategy engine module retrieves events from the event queue and triggers either the resource dynamic adjustment mechanism or the quality dynamic optimization mechanism based on the event type (resource utilization event or quality degradation event). Execution phase: The policy engine module executes the corresponding routing policy adjustments (dynamic aggregation or attribute modification), issues hardware entry changes through the SAI interface, and notifies neighbors through BGP Update; During the protection phase: In the above adjustment process, the smooth switching mechanism, the local penalty mechanism, and the suppression timer work together to ensure uninterrupted service and stable routing.

[0159] Through the closed-loop operation of the above four stages, this system achieves millisecond-level collaboration between the control plane and the data plane, automatically adapting to changes in network load and link status without manual intervention, significantly improving the reliability, stability, and forwarding performance of the data center network.

[0160] Regarding the BGP routing dynamic adaptive optimization scheme based on hardware resources and quality awareness proposed in this invention, the following specific application examples will further illustrate the deployment and implementation process of this scheme.

[0161] Example 1: System Overall Architecture.

[0162] like Figure 1 As shown, in this embodiment, the solution of the present invention is deployed and run on a data center switch that supports VXLAN, thereby forming a BGP routing dynamic adaptive optimization system.

[0163] Based on the diagram, this BGP routing dynamic adaptive optimization system adopts a layered architecture, mainly consisting of the following three layers: (1) Data plane (ASIC layer), specifically implemented by the switching chip, is responsible for high-speed packet forwarding.

[0164] This data plane contains: Forwarding engine: Includes hardware table entries such as LPM table, tunnel table, and FDB table, used for fast table lookup and forwarding.

[0165] VXLAN encapsulation / decapsulation module: Encapsulates and decapsulates VXLAN packets according to tunnel entries.

[0166] OAM / Telemetry monitoring unit: Built-in hardware counter, which can periodically count the number of lost packets, the number of bytes sent / received, the queue depth, etc. of each VXLAN tunnel, and report them through hardware registers or direct memory access (DMA).

[0167] (2) Abstract Interface Layer (SAI) is used to provide a unified API.

[0168] Based on the diagram, this Abstract Interface Layer (SAI) includes: sai_get_switch_attribute(): Gets the usage rate of table entries; sai_create_route_entry(): Deploys a route table entry; Event callback registration mechanism: Report hardware events (such as quality degradation) to the control plane.

[0169] (3) Control plane (FRR layer): Based on the diagram, the following are deployed and run in this control plane (FRR layer): The BGPd process is responsible for BGP session establishment and route calculation.

[0170] Perception Agent Module: A new module that subscribes to SAI status and parses hardware entry usage and quality events.

[0171] Policy Engine Module: Based on data from the Perception Agent Module, automatically generates / modifies the Quagga / FRR configuration file (such as route-map in frr.conf) for FRR, and dynamically loads it through the VTYSH interface.

[0172] Example 2: Dynamic route aggregation based on LPM table pressure.

[0173] This embodiment is based on the BGP route dynamic adaptive optimization system formed in Embodiment 1 to realize dynamic route aggregation based on LPM table pressure.

[0174] For example, if a large-scale virtual machine migration occurs under a certain VNI (VNI 2000) in a data center, resulting in 10,000 / 32 host routes, and the switch LPM table capacity is 16,000 entries, 14,000 entries (87.5%) are currently in use.

[0175] The dynamic route aggregation process based on LPM table pressure is as follows: First, during the monitoring phase: the perception agent module found through SAI that the LPM usage rate was 87.5%, which is greater than the threshold of 85%.

[0176] Next, in the decision-making phase: the strategy engine module determines that VNI 2000 is the main contributor, generates a new Route-Map: RM_AGGREGATE_VNI2000, and determines the following rules: Rule 1: match vni 2000, match prefix-len gt 24 (matches details greater than / 24), actiondeny.

[0177] Rule 2: match vni 2000, action permit (allow aggregated routes and default routes).

[0178] Next comes the execution phase: FRR applies RM_AGGREGATE_VNI2000 to the inbound policy of BGP neighbors.

[0179] FRR sends a BGP Route-Refresh Request to the neighbor.

[0180] When a neighbor retransmits a route, FRR only accepts aggregated routes such as 10.1.0.0 / 16 and rejects detailed routes such as 10.1.1.1 / 32.

[0181] The results showed that the number of hardware LPM entries plummeted from 14,000 to 200, the utilization rate dropped to 1.25%, and the network returned to stability.

[0182] Final recovery phase: After 10 minutes, the utilization rate was detected to have dropped to 50%. The policy engine module revoked the aggregation policy and resumed detailed route learning.

[0183] Example 3: BGP Community tuning based on tunnel quality.

[0184] This embodiment uses the example of a physical link between VTEP-A (IP: 10.0.0.1) and this switch experiencing congestion, with hardware telemetry detecting a packet loss rate rising to 0.5% (threshold 0.1%), to illustrate how the BGP routing dynamic adaptive optimization system based on embodiment 1 can achieve BGP Community tuning based on tunnel quality.

[0185] Combination Figure 3 As shown, the process of implementing BGP Community tuning based on tunnel quality in this embodiment is as follows: (1) Reporting: The switching chip notifies FRR via SAI: Event: Tunnel_Quality_Degrade, VTEP:10.0.0.1, VNI: 100, PLR: 0.5%.

[0186] (2) Matching: FRR queries the BGP table to find all EVPN Type-5 routes with Next-Hop: 10.0.0.1 and VNI: 100.

[0187] (3) Modify attributes: Modify the strategy: For packet loss rates between 0.1% and 1%, add Community 65535:500 (meaning "inferior links should be avoided as much as possible").

[0188] Modification operation: FRR executes bgp route-map SET_BAD_QOS to set the Communityadditive for the matched route.

[0189] (4) Announcement: FRR sends BGP Update to the upstream Spine switch (or route reflector).

[0190] (5) Linkage: The upstream Spine switch is pre-configured with a policy: when receiving a route to Community 65535:500, the LOCAL_PREF will be reduced by 50.

[0191] (6) Effect: Traffic is switched to a high-quality path to VTEP-B at the Spine layer, alleviating congestion at the switch's egress. When the hardware reports that the quality has recovered (PLR < 0.05%), FRR is removed from the Community, and traffic is automatically switched back.

[0192] Example 4: Smooth switching and anti-shake.

[0193] This embodiment illustrates how the BGP routing dynamic adaptive optimization system based on Embodiment 1 achieves smooth switching and anti-jitter, in order to avoid BGP oscillation (Flapping) caused by frequent policy switching.

[0194] Specifically, this embodiment mainly includes the following solutions for smooth switching and anti-shake: Damping mechanism: For quality degradation events, a suppression timer is introduced. For example, after the link quality recovers, it needs to remain stable for 5 minutes before the "inferior" label is removed.

[0195] Incremental update: When modifying BGP attributes, only the MP_REACH_NLRI attribute is updated, the route is not revoked, and the TCP session remains stable.

[0196] Hardware entry coexistence: During the moment of route aggregation switching, the FRR command instructs the hardware to simultaneously retain both the old detailed entries and the new aggregation entries. The hardware aging time is set to 30 seconds. During this period, new traffic follows the aggregation route, while old session traffic follows the detailed route. After 30 seconds, the hardware automatically deletes the detailed entries that have no traffic.

[0197] This embodiment takes the VNI 2000 switching from detailed routing to aggregate routing and preventing jitter as an example to explain in detail the implementation process of smooth switching and anti-jitter mechanism.

[0198] Scenario: The LPM table utilization rate reached 87.5% due to a large number of / 32 routes, triggering a hard threshold. The policy engine module decided to perform aggregation on VNI 2000.

[0199] Step 1: Deploy aggregated routes FRR sends the aggregated route 10.1.0.0 / 16 to the switching chip via SAI. At this point, the hardware already contains 10,000 detailed routes, such as 10.1.1.1 / 32 and 10.1.1.2 / 32. The hardware retains both types of entries.

[0200] Step 2: Start the protection timer FRR sets a 30-second protection timer and begins counting the number of hits on detailed routes within the protection period.

[0201] Step 3: Apply the inbound policy and request route refresh. FRR generates an inbound Route-Map (rejecting details of / 25 and above), applies it to BGP neighbors, and sends a Route-Refresh request. After the neighbor retransmits the route, FRR only accepts the aggregated route and no longer learns new detailed routes.

[0202] Step 4: Aging Detailed Routing After the protection timer expires, FRR instructs the hardware to delete all VNI 2000-related detailed routing table entries. The hardware automatically deletes detailed table entries without traffic matching based on the entry's idle timeout (configured to 30 seconds). For detailed routes that still have traffic matching within the protection period (such as long-lived TCP sessions), the hardware resets their idle timeout and retains them until the session ends.

[0203] Step 5: Anti-shake mechanism To prevent frequent handovers caused by link quality fluctuations, this embodiment introduces a suppression timer (5 minutes) after quality recovery. If the link quality deteriorates again within 5 minutes, the poor quality label will not be revoked; only after it stabilizes for 5 minutes will the Community label be revoked and the original routing attributes restored. Simultaneously, for the recovery of hardware entry utilization, a recovery threshold of 60% is set, and the aggregation policy is only revoked if three consecutive samples are below the threshold, avoiding repeated aggregation and deaggregation due to instantaneous fluctuations.

[0204] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0205] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A dynamic adaptive optimization method for BGP routing based on hardware resources and quality awareness, applied to a VXLAN switch running the FRR protocol stack, characterized in that, Includes the following steps: Hardware resource awareness: The FRR control plane obtains hardware forwarding table entry resource usage information of the switching chip ASIC in real time through the switch abstract interface SAI. The resources include LPM entries, tunnel entries or FDB entries. Resource dynamic adjustment: The FRR control plane sets a first threshold, a second threshold, and a third threshold, wherein the first threshold is less than the second threshold, and the third threshold is less than the first threshold; When the usage rate of hardware forwarding table entries exceeds the first threshold, detailed route statistics are initiated. When the usage rate of hardware forwarding table entries exceeds the second threshold, the FRR control plane dynamically generates or modifies the routing policy Route-Map and applies it to the inbound or outbound direction of the BGP protocol. By adjusting the granularity of route prefix aggregation or filtering specific prefixes, the number of entries sent to the hardware is reduced. When the usage rate of hardware forwarding table entries is lower than the third threshold, the original routing policy is restored. Link quality awareness: Based on the operation, management and maintenance (OAM) module or telemetry module built into the switching chip, the forwarding quality parameters of each VXLAN tunnel are monitored in real time. The forwarding quality parameters include, but are not limited to, packet loss rate (PLR), round-trip time (RTT), and jitter. Dynamic quality optimization: The switching chip reports the detected quality degradation events to the FRR control plane through the switch abstract interface; the FRR control plane dynamically modifies the routing attributes of the BGP routes corresponding to the degraded tunnels according to the preset policy, and notifies the neighbors through BGP Update to perform traffic scheduling.

2. The BGP routing dynamic adaptive optimization method according to claim 1, characterized in that, In the resource dynamic adjustment step, the adjustment of the routing policy includes differentiated configuration based on VNI or VRF granularity; the differentiated configuration includes: independently setting the aggregation trigger threshold, the prefix length threshold of the aggregated route, and the filtering granularity of the detailed route for each VNI or VRF.

3. The BGP routing dynamic adaptive optimization method according to claim 1, characterized in that, In the dynamic quality tuning step, the routing attributes include at least one of LOCAL_PREF, MED, AS_PATH, or BGP Community.

4. The BGP routing dynamic adaptive optimization method according to claim 1, characterized in that, It also includes a smooth switching step. In the smooth switching step, when switching from detailed routing to aggregated routing, the FRR control plane first sends the aggregated routing hardware entry to the switching chip through the SAI interface and sets a protection period. During this period, the detailed routing hardware entry is retained. The detailed entry is deleted after the traffic migrates naturally or the entry ages.

5. The BGP routing dynamic adaptive optimization method according to claim 1, characterized in that, It also includes a local penalty step, in which, for tunnels with degraded quality, the FRR control plane temporarily marks the next hop of the tunnel as a penalty in the local forwarding table, and, in conjunction with the equal cost multipath routing ECMP weight adjustment, prioritizes scheduling new traffic to other paths before BGP global convergence.

6. The BGP routing dynamic adaptive optimization method according to claim 1, characterized in that, In the aforementioned quality dynamic optimization step, a suppression timer is introduced, which must remain stable for a preset time after the link quality is restored before the inferior label is removed.

7. A BGP routing dynamic adaptive optimization system based on hardware resources and quality awareness, characterized in that, The system includes: The switching chip provides hardware forwarding table entry storage and VXLAN forwarding, and also has entry usage monitoring and tunnel quality monitoring functions; The Abstract Interface Layer (SAI) is used to connect the switching chip and the control plane, providing a unified hardware access interface. The control plane runs the FRR protocol stack, including: The perception agent module contains an event listening sub-component, which is used to capture events such as hardware forwarding table entry usage exceeding the threshold and VXLAN tunnel quality degradation events reported by the switching chip through SAI and submit them to the event queue. The perception agent module is also configured to asynchronously read events from the event queue and parse and process them, while periodically and actively querying the hardware forwarding table entry usage through the SAI interface. An event queue is used to cache the events; The policy engine module is configured to interact with the perception proxy module, dynamically adjust the route aggregation granularity based on the hardware forwarding table entry usage rate obtained by the perception proxy module, and / or, for forwarding quality events of VXLAN tunnels, dynamically modify the attributes of the BGP routes corresponding to the tunnels with degraded quality according to a preset policy, and notify neighbors via BGP Update; the policy engine module is configured to dynamically adjust the route aggregation granularity based on the following mechanism: When the usage rate of hardware forwarding table entries exceeds a preset first threshold, detailed route statistics are initiated. When the usage rate of hardware forwarding table entries exceeds the preset second threshold, the FRR control plane dynamically generates or modifies the routing policy Route-Map and applies it to the inbound or outbound direction of the BGP protocol. By adjusting the granularity of route prefix aggregation or filtering specific prefixes, the number of entries sent to the hardware is reduced. When the usage rate of hardware forwarding table entries falls below the third threshold, the original routing policy is restored.

8. The BGP routing dynamic adaptive optimization system according to claim 7, characterized in that, The policy engine module is configured with a smooth switching mechanism. Based on this mechanism, when switching from detailed routing to aggregated routing, the policy engine module first sends the aggregated routing hardware entry to the switching chip through the SAI interface and sets a protection period. During this period, the detailed routing hardware entry is retained. The detailed entry is deleted after the traffic migrates naturally or the entry ages.

9. The BGP routing dynamic adaptive optimization system according to claim 7, characterized in that, The policy engine module is configured with a local penalty mechanism. Based on this mechanism, for tunnels with degraded quality, the next hop of the tunnel is temporarily marked as penalized in the local forwarding table. Combined with the equal cost multipath routing (ECMP) weight adjustment, new traffic is preferentially scheduled to other paths before BGP global convergence. The policy engine module is also configured with a suppression timer, which is used to maintain a stable preset time after the link quality is restored before the degraded mark is removed.

Images