BGP Prefix Validation via Probe Packet Return
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
There is currently no reliable mechanism for determining if an external network has accepted a source network's prefix announcements in BGP, leading to suboptimal routing and user complaints due to lack of visibility into prefix acceptance.
Innovation Solution
A mechanism involving the generation and transmission of probe packets from a source network to an external network to validate the acceptance of network prefix announcements, using ingress ACLs to monitor and detect the return of probe packets, thereby verifying the success or failure of prefix announcements.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If public BGP Looking Glass sites are used to check prefix acceptance, then some routing visibility is obtained, but sufficient per-router or per-BGP-session level visibility is not achieved
Solution Approach 1:
The patent introduces probe packets as an intermediary mechanism to indirectly verify prefix acceptance. Instead of directly querying external networks or relying on their public interfaces, the source network sends probe packets through the external network path and monitors their return, using the probe packet response as a mediator to infer acceptance status with high precision at per-router or per-BGP-session level.
Solution Approach 2:
The patent implements a feedback mechanism where the source network monitors returned probe packets to determine whether external networks have accepted prefix announcements. This closed-loop feedback provides continuous visibility into routing acceptance status, enabling real-time detection and validation of prefix propagation throughout the external network.
2Loss of information
If netflow data examination is used to validate prefix announcements, then traffic forwarding information can be obtained, but the method fails when no traffic is received for the announced prefix
Solution Approach 1:
The patent makes the validation process self-service by having the source network actively generate and send probe packets to test routes. Instead of passively monitoring netflow data that depends on external traffic, the system autonomously creates test traffic, sends it through the announced routes, and monitors the response, making the validation independent of actual user traffic patterns.
Solution Approach 2:
The patent performs preliminary validation by sending probe packets before relying on actual traffic flow. This preliminary action tests the routing path in advance, confirming that the external network has accepted the prefix announcement and can properly route traffic, thereby validating the route before actual data traffic is sent.
3Ease of operation
If external networks rely on non-standard mechanisms like email to update filters, then filter updates may be delayed or failed, but there is no way to detect or remediate the issue
Solution Approach 1:
The patent implements continuous feedback monitoring that detects when external networks fail to accept or properly update their filters. By continuously sending probe packets and monitoring responses, the system can detect filter update failures regardless of the mechanism used (standard or non-standard), providing visibility and enabling remediation of routing issues.
Data Source
AI summary
Probe packets are transmitted from a source network to an external network to validate that the external network is accepting network prefix announcements to be loaded into forwarding tables of routers of the external network to ensure network connectivity. The network prefix announcements can be Border Gateway Protocol (BGP) announcements transmitted from the source network to the external network during a BGP peering session. After announcing a network prefix announcement, the source network can transmit a probe packet having a destination address in a range associated with the announced network prefix to the external network. An edge router of the source network can monitor incoming packets using an ingress Access Control List (ACL) to detect whether the probe packet returns, and if so, validate that the network prefix announcement was successful. If the probe packet does not return, an alert can be generated and/or remedial actions can be taken.